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.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
