"Anton van Straaten" <firstname.lastname@example.org> writes:
> Yoann Padioleau wrote:
> > I have to admit that perl can be cryptic, but certainly not Ruby nor
> > python have too continuations.
> Python can be cryptic, and its continuations are an example of that - a
> hacked feature that wasn't designed into the language from the beginning,
I am not sure call/cc was in scheme from the beginning.
Many things were added to lisp after (true closure, oo, multimethod, macro, ...)
and lisp is still a good langage.
Even steele the author of scheme made a paper "growing a langage" which
says that designer of langage should plan that the langage will grow, that
feature will be added (and that the good way to make this easy is a good
> and it shows. Besides, what's up with that __init__ thing? :)
> > The only advantage i see in scheme over other langages, is its powerful
> macro system.
> > That's all.
> There are many more advantages, which perhaps you haven't seen yet. I say
> this as someone who only found Scheme after many years of working with many
> languages, including all the usual suspects, like Pascal, C, C++, Java, and
> scripting languages including Perl and Python.
> Some high-level examples of the advantages of Scheme include:
> * A very regular syntax,
many people dont like that at all.
> which along with a built-in syntax reader,
> contributes to the ability for programs to easily read and manipulate other
perl have eval which allow too this kind of thing.
> Macros take advantage of this capability, but it can be
sure, that is what i said, the only true advantage of scheme over other langage
is its powerful macro system.
> surprisingly useful in all sorts of ways that don't involve macros.
> * Related to the above point, code and data are represented using the same
> syntax, which aside from the benefits for automated manipulation of
> programs, also makes it very easy to persist high-level structures in a very
can do that easyly too with perl eval and Data::Dumper.
> usable and maintainable way. The scripting languages tend to use XML for
> this kind of purpose, which entails a lot of often unnecessary complexity
> and overhead.
> * Very well-designed integration of features such as closures,
> continuations, and macros, which allows these features to be used together
> to build domain-specific languages. It's not just the presence of these
> individual features, but how they interact. SCSH is an example of this - it
> provides the kinds of benefits which Perl apparently needed to embed into
> the core of the language. Scheme is a tool for building languages, in a way
> that none of the scripting languages can achieve. This point assumes that
> you're familiar with the benefits of the domain-specific language approach
> to development.
True (related to the powerful macro system).
> * As a consequence of the above point, Scheme is a multi-paradigm language,
> capable of supporting functional programming, OO programming, logic
> programming, goal oriented programming, etc., with language extensions that
> support these features.
> * The ability to achieve very high performance, often on par with or even
> exceeding that of C or C++. It's easy to design a powerful high-level
> language that's slow - it's much more difficult to design a powerful
> high-level language that's also fast. The best examples of the latter are
> all either functional or semi-functional languages, including Scheme. This
> is partly because the functional paradigm supports automated "algebraic"
> program transformations that can be performed by compilers in order to
> achieve better performance, and allows programs to be translated into
> lower-level languages in the most efficient possible ways.
Hmmm, functionnal zealots say this for about 20 years, and never
succeed i think.
> However, I think you're right that the SCSH FAQ doesn't quite succeed in
> communicating to someone who is comfortable with traditional scripting
Sure, because they dont know what they are talking about.
> why they should throw out all the arbitrary syntax they've worked
> so hard to memorize, and instead learn something that's more cleanly
> designed for extensibility and power. Part of the problem is that fully
> describing and contrasting these capabilities to those of the "scripting
> languages" would require an entire series of articles.
Sure, comparing langages is hard, so at least dont lie.
Yoann Padioleau, INSA de Rennes, France,
Opinions expressed here are only mine. Je n'écris qu'à titre personnel.
**____ Get Free. Be Smart. Simply use Linux and Free Software. ____**