Comments on: The Philosopher’s Song http://lesscode.org/2005/12/22/the-philosophers-song/ AAaaaaahhhhrrrrrrr! Mon, 17 Sep 2007 09:11:26 +0000 http://wordpress.org/?v=2.0.1 by: Path of the Digital Katana » Be the Ronin with your languages http://lesscode.org/2005/12/22/the-philosophers-song/#comment-8639 Tue, 22 Aug 2006 02:36:05 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-8639 <p>[...] The lesscode blog isn&#8217;t too active any more, but it has much sage advice, and a good post from last year that&#8217;s been referred to many times. &#8220;The Philosopher&#8217;s Song&#8221; is a ranging muse on the efficacy of languages, and the rage of Ruby vs. Python and the sameness of now to history. [...]</p> […] The lesscode blog isn’t too active any more, but it has much sage advice, and a good post from last year that’s been referred to many times. “The Philosopher’s Song” is a ranging muse on the efficacy of languages, and the rage of Ruby vs. Python and the sameness of now to history. […]

]]> by: Roger Lancefield http://lesscode.org/2005/12/22/the-philosophers-song/#comment-6384 Mon, 31 Jul 2006 14:42:30 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-6384 <p>(A belated) thanks for a great 'lunch time' read Bill. Common-sense and a voice of reason never go out of style!</p> (A belated) thanks for a great ‘lunch time’ read Bill. Common-sense and a voice of reason never go out of style!

]]> by: Christopher Dunn http://lesscode.org/2005/12/22/the-philosophers-song/#comment-1012 Sun, 29 Jan 2006 00:56:40 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-1012 <p>It is important to recognize the variety of use cases when discussing the appropriateness of a language. There are more than just "enterprise systems programming" and "large-scale applications development". The best uses for dynamic languages are the most oft-neglected by serious programmers:</p> <p>1) Proto-typing 2) User-interfacing</p> <p>Proto-typing</p> <p>Ruby and Python are both wonderful for rapid proto-typing. Python may have an edge in library availability and in its similarity to C++/C# (if one of those happens to be the eventual target). For C#, maybe Boo is best. If only portions of the script will be translated into a statically-typed language, then Ruby stands out as it eschews reference-counting (though Boost-Python works well to hide the complexity).</p> <p>User-interfacing</p> <p>Tcl is the typical choice, a horrendous one because it so severely limits both productivity and maintainability. But Ruby, Perl, Scheme, and many others are much too difficult for a non-programmer. This is where Python shines. The things that hard-core programmers dislike about Python are precisely the things that make it so valuable for non-programmers. It's a language which encourages maintainable code no matter who writes it. Python makes important things like documentation, modularity, OOP, and testing so trivial that a part-time programmer <em>might</em> be induced to try them.</p> <p>The blog author correctly points out in the footnote that where Ruby is most vociferously advocated, there are many reasonable alternatives, including Smalltalk, Common Lisp, Scheme, Ocaml/F#, Eiffel, Haskell, Dylan, etc. That completely misses the great value of dynamic languages: intuitiveness.</p> It is important to recognize the variety of use cases when discussing the appropriateness of a language. There are more than just “enterprise systems programming” and “large-scale applications development”. The best uses for dynamic languages are the most oft-neglected by serious programmers:

1) Proto-typing
2) User-interfacing

Proto-typing

Ruby and Python are both wonderful for rapid proto-typing. Python may have an edge in library availability and in its similarity to C++/C# (if one of those happens to be the eventual target). For C#, maybe Boo is best. If only portions of the script will be translated into a statically-typed language, then Ruby stands out as it eschews reference-counting (though Boost-Python works well to hide the complexity).

User-interfacing

Tcl is the typical choice, a horrendous one because it so severely limits both productivity and maintainability. But Ruby, Perl, Scheme, and many others are much too difficult for a non-programmer. This is where Python shines. The things that hard-core programmers dislike about Python are precisely the things that make it so valuable for non-programmers. It’s a language which encourages maintainable code no matter who writes it. Python makes important things like documentation, modularity, OOP, and testing so trivial that a part-time programmer might be induced to try them.

The blog author correctly points out in the footnote that where Ruby is most vociferously advocated, there are many reasonable alternatives, including Smalltalk, Common Lisp, Scheme, Ocaml/F#, Eiffel, Haskell, Dylan, etc. That completely misses the great value of dynamic languages: intuitiveness.

]]> by: Robert Sayre http://lesscode.org/2005/12/22/the-philosophers-song/#comment-916 Tue, 03 Jan 2006 15:44:38 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-916 <p>Closures do matter and JavaScript wins :)</p> Closures do matter and JavaScript wins :)

]]> by: James Britt http://lesscode.org/2005/12/22/the-philosophers-song/#comment-847 Mon, 26 Dec 2005 04:53:40 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-847 <p>"All other things being equal if closures count for that much, then s’talk and CLisp get to be at the races."</p> <p>Sort of. All other things are not equal, though. Syntax matters, as does a free, robust, cross-platform implementation with a decent set of equally robust, cross-platform libraries. </p> <p>I'd <em>love</em> to be able to develop Web apps on Windows and simply drop them into place on my Linux server, while sharing code with folks using Macs, and know that code revisions are safely tracked through SVN or darcs.</p> “All other things being equal if closures count for that much, then s’talk and CLisp get to be at the races.”

Sort of. All other things are not equal, though. Syntax matters, as does a free, robust, cross-platform implementation with a decent set of equally robust, cross-platform libraries.

I’d love to be able to develop Web apps on Windows and simply drop them into place on my Linux server, while sharing code with folks using Macs, and know that code revisions are safely tracked through SVN or darcs.

]]> by: James Britt http://lesscode.org/2005/12/22/the-philosophers-song/#comment-846 Mon, 26 Dec 2005 04:18:07 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-846 <p>"Two minority language communities going at it over book sales, is mildly embarrassing ..."</p> <p>PLEASE, I beg of you, please do not advance the idea that these dopey squabbles are occurring on behalf of the Ruby or Python communities. Many Rubyists are quite embarrassed by these sorts of petty tirades. The narrow-minded views of many Railers should not be conflated with any general opinions of Ruby hackers. </p> <p>I suspect the same is true for most Pythonistas.</p> “Two minority language communities going at it over book sales, is mildly embarrassing …”

PLEASE, I beg of you, please do not advance the idea that these dopey squabbles are occurring on behalf of the Ruby or Python communities. Many Rubyists are quite embarrassed by these sorts of petty tirades. The narrow-minded views of many Railers should not be conflated with any general opinions of Ruby hackers.

I suspect the same is true for most Pythonistas.

]]> by: Zilch Zero http://lesscode.org/2005/12/22/the-philosophers-song/#comment-845 Sun, 25 Dec 2005 21:14:30 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-845 <p>So why is it that <del>a loudmouthed boy from Denmark</del>, who managed to come up with an ORM (you go, dude!), has the balls to deride Mr Eckel, who -- among other things -- sat on the C++ language committee for the better part of 8 years?</p> <p>Appears the hype Tim O'Reilly is bathing DHH in -- for his (O'Reilly's) benefit to be sure -- has finally gone to <del>the boy-wonders</del> head beyond the point of annoyance.</p> <p><em>Ed. -- Portions of this message have been marked flame-bait.</em></p> So why is it that a loudmouthed boy from Denmark, who managed to come up with an ORM (you go, dude!), has the balls to deride Mr Eckel, who — among other things — sat on the C++ language committee for the better part of 8 years?

Appears the hype Tim O’Reilly is bathing DHH in — for his (O’Reilly’s) benefit to be sure — has finally gone to the boy-wonders head beyond the point of annoyance.

Ed. — Portions of this message have been marked flame-bait.

]]> by: Bill de hOra http://lesscode.org/2005/12/22/the-philosophers-song/#comment-838 Fri, 23 Dec 2005 16:36:32 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-838 <p>"You almost made it!"</p> <p>LOL! You got me. But there is valid point here - closures seem to be a common technical argument pro Ruby compared to Python/Java/C#. All other things being equal if closures count for that much, then s'talk and CLisp get to be at the races.</p> “You almost made it!”

LOL! You got me. But there is valid point here - closures seem to be a common technical argument pro Ruby compared to Python/Java/C#. All other things being equal if closures count for that much, then s’talk and CLisp get to be at the races.

]]> by: Anonymous http://lesscode.org/2005/12/22/the-philosophers-song/#comment-836 Fri, 23 Dec 2005 03:36:00 +0000 http://lesscode.org/2005/12/22/the-philosophers-song/#comment-836 <p>"* Anyone that really feels Ruby closures are a critical technical factor should be wondering why they’re not develping in Smalltalk or CLisp."</p> <p>You almost made it! You were arguing against language quibbles, and it was good, and then you had to resort to the very thing you were arguing against in a footnote.</p> “* Anyone that really feels Ruby closures are a critical technical factor should be wondering why they’re not develping in Smalltalk or CLisp.”

You almost made it! You were arguing against language quibbles, and it was good, and then you had to resort to the very thing you were arguing against in a footnote.

]]>