compileIt for revolution?

[Dennis Brown]

Dan,

Rev is chock full of stuff that I will never use.  Perhaps half or  
more of the commands are irrelevant to my needs.  However, I see on  
this list folks that love those irrelevant things in their  
applications.  You have your ideas about the kind of applications you  
want to use Rev for.   Do you consider everyone else's applications  
to be irrelevant that do not fit into your concept of what Rev should  
be used for  --dooming them to use tools too arcane to ever  
accomplish their tasks in a reasonable lifetime?  You are not the  
only one who is too old to spend the rest of his life programming in  
C ;-)

I choose Rev as my language of choice, because I could see  
accomplishing my ambitious goals in what is left of my expected  
lifetime.  I do not write "professionally" to sell products to  
others.  I write to solve problems that I want to solve for myself  
and my friends.  I am a renaissance man with many interests and  
skills.  Therefore, my problems are varied and the solutions must be  
timely for me to have time enjoy them all.

Array improvements are a subject near to my heart.  Arrays could have  
been implemented in a way that would make them one or two orders of  
magnitude faster for the types of applications that need speed.  Or,  
they could have been implemented in a way that would make them more  
general for other applications.  Or, they could do both.  In Rev  
today we sort of have a half attempt at both.  You don't have to  
butcher a language to make it satisfy a large number of needs.  A lot  
of the proposed "Butchery" that you see on these threads are just a  
symptom of the needs.  The solutions should not to be left unexplored  
just because the ones with needs are not language architects and make  
unpalatable suggestions.  Rather it should be seen as a call and  
challenge to the language architects to put their heads together and  
propose solutions for the needs.

Many times the needs can be met by a greater understanding of the  
more obscure capabilities already in the language.  This list is  
wonderful for getting this kind of help.  Many of these obscure  
capabilities are in fact extensions to the language to provide a low  
level engine primitive to get around speed issues with doing things  
in the straight forward algorithmic way.  Building special purpose  
operators to speed up specific applications is how the problems are  
ultimately solved for everyone.  I am all for this, even if I don't  
need those things for my stuff, because someone else will use those  
things to make something wonderful that I or others will appreciate  
and use.  I just want the stuff to be useful for at least 5-10% of  
the folks, and that a good effort is made to make it consistent for  
the language.

I should point out that I agree with 90% of what you say.  I just see  
that you have formed some opinions from you long experience, just as  
I have from mine.  I was involved in the "personal computer" industry  
since the first (8008) microprocessor was created.  No two persons  
experience is the same, and therein is the beauty.  As a former boss  
of mine use to say, "If you agree with me all the time, one of us is  
not needed!"

I too am somewhat disturbed at many commands in the language that  
seem to specific to a platform or even a database.  It is tough to  
draw the line between the "Language" and just a package of handlers  
for your scripting convenience.  However, I think a line should be  
drawn.  Core language definitions should be well thought out and not  
changed.  Convenience handlers should be understood as such,  
bountiful, and improvements permitted.

I'm getting too old for these soap boxes --the altitude is getting to  
me ;-)

Dennis


On Jun 23, 2005, at 8:26 PM, Dan Shafer wrote:

> I'm *always* going to come down on the side of keeping the language  
> as simple as possible. In my opinion, it is already too burdened  
> with baggage that is of use to a tiny fraction of its users in  
> order to accommodate a few people with specific programming needs.  
> As it becomes more complex -- even if those complexities are  
> posited as "optional alternatives" -- it becomes more and more  
> impenetrable to those who do not have a computer science background  
> or formal computer training. Those folks already have enough  
> languages to pick from. I strongly desire for this one to escape  
> the clutches of the Programming Priesthood.