Re: [tlug] ruby and python in Japan

[Curt Sampson <cjs@??>]

Well, some random thoughts on this:

On Tue, 27 Feb 2007, Stephen J. Turnbull wrote:

> PHP:
>    Never used it, no comment.  Maybe, see "Perl"?

Lots of nasty code written in it, lots of backwards compatability
options that destroy security but have to be turned on for certain
libraries, and in general a configuration management nightmare.

> Ruby, Python, Scheme:
>    Efficient interpreted languages...

I don't think I'd class Scheme in with Ruby and Python. Scheme can
be compiled without difficulty (unlike Ruby, which appears to me to
be uncompilable), and I'd understood that mzscheme was a pretty good
compiler.

Perhaps more significantly, Scheme is far more consistent than Ruby:
it's a small kernel of stuff that makes very good sense. Ruby has bags
hanging off the side of it all over the place, compared to Scheme,
though Perl is even worse in that respect. And Scheme has macros, which
appears to me to be quite an important distinction. Meta-programming in
Ruby is possible, but painful and will never perform well.

>    Scheme suffers from being a Lisp.

Boy, do I know some people who would take exception to that! Being a
Lisp, even to a mostly-non-Lisper like me, seems to me to be more of an
advantage than a disadvantage.

> Haskell, ML, Erlang:
>    Modern functional languages.  Don't know ML and Erlang, but
>    Haskell is compiled and very heavyweight.  Great for abstraction,
>    incredibly powerful, but mind-bending.

I'm not sure I'd class ML as a "modern" functional language in the way
Haskell is; after all, Haskell was very much designed to replace ML.
Of course, if you consider OCaml to be an ML, that distinction narrows
somewhat.

I'd probably taxonimize this with ML at the root of the tree, Erlang and
OCaml as close descendents, and Haskell rather further away from the
rest of them.

> (un) Common Lisp:
>    Rest in peace.

Oh, I don't know about that. For all the issues it has, it does have
some very good points, too, from what I understand, such as the very
large set of standard libraries. I think it actually could have been
what Java is, had there been a freely available implemenation.

> Javascript:
>    A whole 'nuther smoke, this is (normally) a client-side
>    interpreted language, heavily dependent on a standard DOM.  Ie,
>    can be combined effectively with any of the above, which are
>    server-side.

A reasonably nice language, and a perfect example of how lack of library
standardization can kill a decent language.

cjs
--
Curt Sampson       <cjs@??>        +81 90 7737 2974