[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scheme acceptance [no flames]
>>>>> "JRH" == John R Hall <overcode@lokigames.com> writes:
JRH> Well, Perl is a hell of string processing language. Scheme really isn't.
JRH> Sure, it CAN be done it Scheme, but a hundred lines of Scheme can often
JRH> be accomplished in one line of Perl (which will invariably consist of
JRH> top-row symbols).
I disagree. String processing (as any other specific task) has more to do with
the library support and well designed API. In this respect Scheme has one HUGE
advantage over both Perl and Python. Scheme supports very powerful macros. By
means of this "evaluate twice" feature you could well end up with scheme string
processing code, in fact, shorter than perl's one for complicated text
manipulations. The fact that Scheme does not do this yet has to do with its poor
acceptance and, thus, lack of manpower to write these libraries.
>> Yet, very little fraction of programmers have ever used Scheme.
>> Scheme has been around since 1976 and certainly could address all the needs of
>> script programming (and much more). However, every scripting language which came
>> later beat Scheme hands down in market acceptance. Examples are: Basic, Perl
>> and now Python. Well, Python is elegant and is reasonably designed. But why
>> Perl gained lion mindshare in CGI and other scripting is a puzzle for me.
JRH> Because it's very heavily targetted to slicing and dicing data, pumping
JRH> it into a database, and printing a result. It's a UNIX-orienting hacking
JRH> tool, made to get a job done without too much concern for theory. Scheme
JRH> is a great algorithmic language, but it's hardly practical for many of
JRH> the things Perl is good at.
JRH> Don't get me wrong; I like Scheme a lot, and next to C I'd rather use
JRH> Scheme than most other languages. But there are some things it's not
JRH> well adapted to.
The only think Scheme is not well adapted to is high performance number
crunching. Except for the performance Scheme is a very powerful general purpose
language.
JRH> The point is that a random programmer isn't likely to stumble into
JRH> Scheme and learn it overnight, whereas said programmer might find Python
JRH> to be a bit
JRH> more closely connected to other languages that he or she already knows.
Yes, human psychology plays very important role in programming.
JRH> Perhaps more Scheme implementations should provide these.
JRH> Perhaps we need an "extended R5RS" standard so that we can have a
JRH> standardized set of extensions across multiple implementations.
JRH> Scheme is supposed to be portable, but this is really quite a joke. Just
JRH> try porting an average MzScheme program to Guile. Let me know if you
JRH> want a bottle of Advil halfway through.
No Advil. A bottle of expensive Cognac to say the least. The things Scheme
needs badly are good enough standard modular system and good enough standard
OO-model. Scheme has been too concerned with doing "right thing" and as we all
know "designing right thing takes forever".
The biggest problem with Scheme is that its support and community is too
fragmented. With other languages like Perl or Python there is a core team of
designers and everybody else just "shut up". In scheme community everyone has
its own view of the universe and the things move much slower because of that.
Illustative example is Guile: they are stagnating but they do not have enough
courage to admit this and switch to another more healthier Scheme project like
MzScheme which could well double the community. Actually, I heard that at some
point in 1995 or 1996 MzScheme was considered as a code base for emerging Guile
project but for some reason SCM was peaked instead.
Next example is Scheme Shell scsh. It is based upon yet another Scheme vertual
machine called Scheme48 (correct me if I am wrong). Scheme48 is not supoported
anymore and scsh version number is < 0.5 (beta quality at best) for several
years already. This kind of fragmentation makes no good for anyone.
>> Uhh, sorry for being pathetic on the eve of presidential elections:-)
>> I am finaly at the constructive portion of my e-mail.
>> Is it feasible to have a parser which translates Python code into Scheme code so
>> that people write Python-like code and can convert it to Scheme so that Python
>> users get all the benefits from the features they are just talking about?? Might
>> be, significant share of the exsisting Python code would run without
>> modifications under Scheme as well.
JRH> Hmmm... That's interesting.
JRH> Theoretically, it could definitely be done. But would it be practical in
JRH> terms of performance?
I don't understand what it has to do with performance. It is a scheme code which
runs as fast (as slow) as any other scheme code. You just run your code
translater Python->Scheme once and store *.scm files somewhere.
Of course, a better solution whould be to give Scheme a reasonable syntax. By
word reasonable syntax I mean a syntax which make language more attractive from
human prespective.
JRH> Linux has been competing with NT for years, and it's still not on top. I
JRH> personally think Linux is a better OS in general. But it really doesn't
JRH> matter - if Scheme solves problems FOR YOU, then use it, and others
JRH> might pick it up as well.
You should look on the dynamics. Linux is gaining ground fast while Scheme's
share is constant at best. Besides I am not sure that Linux is that good
OS. Here we have the problem reversed: instead of designing a modern OS from
scratch one goes with a 30 years legacy UNIX inheriting its **** system API
(substitute your favorite 4-letter word for **** above).
JRH> I do wish that Scheme would become a mainstream language, though.
Noble goal.
-- Leo
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Leonid Razoumov, + E-mail: lrazoumov@qualcomm.com +
+ Qualcomm Inc., + http://www.qualcomm.com +
+ 5775 Morehouse Drive, + +
+ San Diego, CA 92121-1714, + VOICE: +1-858/651-5163 +
+ USA + FAX: +1-858/658-2113 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++