Searching for the best scripting language,

[Richard James]

Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?

On Saturday Slashdot ran this article on the "best" scripting
languages.
http://developers.slashdot.org/developers/04/06/12/2125229.shtml?tid=126&tid=156

"Folks at the Scriptometer conducted a practical survey of which
scripting language is the best. While question like that is bound to
generate flamewars between the usual Perl vs PHP, Python vs Perl,
VBScript vs everything crowds, the Scriptometer survey is practical:
if I have to write a script, I have to write it fast, it has to be
small (less typing), it should allow me to either debug itself via a
debugger or just verbose output mode. sh, Perl and Ruby won the
competition, and with the difference of 1-2 points they were
essentially tied for first place... Interesting that ICFP contests
lately pronounced OCaml as the winner for rapid development."

Scriptometer site:
http://merd.sourceforge.net/pixel/language-study/scripting-language/

Needless to say, the Ruby site was Slashdot-ed today.

What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?

Or should I convert my code base to Ruby and or OCaml?

Let the rabid "in defense of Python" flames begin!

-- R.J.

 

[Markus Zywitza]

Hi everybody

What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?

Well, better look again at Guido's Tutorial, as it reads at the very
beginning:

"""
If you ever wrote a large shell script, you probably know this feeling:
you'd love to add yet another feature, but it's already so slow, and so
big, and so complicated; or the feature involves a system call or other
function that is only accessible from C
"""

The page misses completely the handling of more complex tasks than those
typically used in any shell (hey, those examples could even be realized
with a DOS batch file ). Python might not be the number one choice
for testing whether a file is readable, but ask them why Fedora has
chosen Python for their Anaconda OS Installer and not a shell script...

-Markus

 

[Edward Diener]

Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?

On Saturday Slashdot ran this article on the "best" scripting
languages.
http://developers.slashdot.org/developers/04/06/12/2125229.shtml?tid=126&tid=156

"Folks at the Scriptometer conducted a practical survey of which
scripting language is the best.

"Practical surveys" are always as hilarious as practical programming, unless
one is asleep to their implications. One of the simple ones, which no doubt
formed much of the basis of this survey, always is: in which situation do I
have to type the least number of characters. For the brainless, this is a
valid test of programming excellence. Hopefully not all programmers in the
world have been reduced to such brainlessness yet.

 

[Ryan Paul]

"Folks at the Scriptometer conducted a practical survey of which
scripting language is the best. While question like that is bound to
generate flamewars between the usual Perl vs PHP, Python vs Perl,
VBScript vs everything crowds, the Scriptometer survey is practical:
if I have to write a script, I have to write it fast, it has to be
small (less typing), it should allow me to either debug itself via a
debugger or just verbose output mode. sh, Perl and Ruby won the
competition, and with the difference of 1-2 points they were
essentially tied for first place... Interesting that ICFP contests
lately pronounced OCaml as the winner for rapid development."

What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?

Or should I convert my code base to Ruby and or OCaml?

I recently learned ruby, merely out of curiosity. Now that I know it, I
dont write ANY shell utilities with python anymore. Ruby is a much better
choice for almost all simple administrative tasks. For larger programs,
there are times when python seems like a better choice. Python enforces
consistency and readability. In an environment where many people will be
working on the same code for an extended period of time, the benefits of
python become apparent. That isnt to say that ruby *cant* be used in
situations like that. If ruby programmers layout strict guidelines for a
project regarding style and methodology, it would be just as effective.

The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }

One of my other favorite features of ruby, is the ability to globally add
methods to base types. While I strongly feel that the ability to extend
base types is a powerful feature, I'm sure many python programmers would
disagree.

Or should I convert my code base to Ruby and or OCaml?

Ruby and Python really have a lot in common. The one you use should
ultimately be based on your style and how you feel about programming. If
you like lots of mutability, lots of functional idioms, and inline regular
expressions, switch to ruby! If not, stick with python.

I'm an ardent OCaml advocate. Anyone who uses c++ should have their head
examined. OCaml is a fast, statically typed, object oriented language with
type inference, pattern matching, automatic memory management, and
inherent parametric polymorphism (you dont need templates!). Native
compilers AND dynamic interpreters are available. It even comes with an
interactive top-level like python does. OCaml programs typically run
faster than comparable c++ programs, and they take significantly less time
to write. OCaml has a built-in list type, and it comes with all the usual
list manipulation functions (map and filter). OCaml is somewhat difficult
to learn however. If you have the intellectual capacity and the time
required to learn a challenging language, learn OCaml. Additionally, I
should mention that OCaml libraries can easily be integrated with python
programs via pycaml. I use OCaml instead of C to write python extensions.

--SegPhault

 

[David Eppstein]

Scriptometer site:
http://merd.sourceforge.net/pixel/language-study/scripting-language/

Needless to say, the Ruby site was Slashdot-ed today.

Scriptometer seems heavily biased towards conciseness of code.
Needless to say, that's not why we use and love Python...

 

[Graham Breed]

Ryan Paul wrote:
....

required to learn a challenging language, learn OCaml. Additionally, I
should mention that OCaml libraries can easily be integrated with python
programs via pycaml. I use OCaml instead of C to write python extensions.

do you have examples? i could only get it to work the other way round.


graham

 

[Lothar Scholz]

Needless to say, the Ruby site was Slashdot-ed today.

This has nothing to do with ./
The site was hacked and corrupted two weeks ago and since this time
one a stub is online.

 

[Lothar Scholz]

Ruby and Python really have a lot in common. The one you use should
ultimately be based on your style and how you feel about programming. If
you like lots of mutability, lots of functional idioms, and inline regular
expressions, switch to ruby! If not, stick with python.

Or if you need real multithreading and WxPython. This are IMHO the
reasons not to switch to ruby. The python implementation is
technically much better. And the python libraries are still much
better then ruby.

As the person behind "http://www.python-ide.com" and
"http://www.ruby-ide.com" i can tell you that otherwise the language
are almost the same. For example from the 18000 lines of code for the
debugger about 2000 lines are different for this two languages.

But look yourself. A weekend should be enough for a python programmer
to learn ruby.

 

[Carl Banks]

What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?

Everything. It's definitely one of the most useless side-by-side
comparisons I've ever seen.

The program lengths criterion is ridiculous. It rewards Perl for
using unreadable line noise.

(Since when does Perl have an interactive interpretter?)

 

[Max M]

Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?

Everyone knows that any scripting language shootout that doesn't show
Python as the best language is faulty by design.

regards Max M

 

[Eric S. Johansson]

Let the rabid "in defense of Python" flames begin!

I will defend python from a different perspective namely that of handicapped usability. Python doesn't contain a whole lot of "modem line noise" characters and with the help of python mode in emacs, does a lot of the indentation properly. So all in all, it minimizes hand use which minimizes physical pain.
I suspect that a blind user would also have greater ease using and working with python for the same reason. modem line noise characters and, funny spelling mixed case are the three biggest impediments to usability by handicapped people.

I would love to have an IDE (to tie into another thread) which would work well with speech recognition. There is already a project (voice coder) which has built a lot of the infrastructure necessary to do so but it (in my opinion) is hampered by the one-way nature of that integration. I believe for handicapped accessibility to programming environments to be truly useful there needs to be a two-way integration where the IDE reveals information about the application so that appropriate grammars and symbols will be revealed and made speakable.

---eric

 

[Cameron Laird]

.
.
.

(Since when does Perl have an interactive interpretter?)

.
.
.
Long time <URL:
http://phaseit.net/claird/comp.lang.perl.misc/perl_interactive.html >.

 

[Peter Hansen]

The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }

This is proof of something, I'm sure, but for me it's simply another
indication that (a) Ruby is more like Perl than it is like Python,
(b) unreadable code can be written in any language, and (c) I
really don't mind using 15 lines to write something if it means
the resulting code can readily be understood.

Thanks for reinforcing my lack of interest in switching to Ruby.

-Peter

 

[Peter Hickman]

Peter Hansen wrote:
Please don't take that code snippet as an example of Ruby but more as evidence
of a bad programmer, as you said "unreadable code can be written in any
language" and Paul Ryan has just proved it.

Take it this way, if someone showed you some badly written Python would that put
you off Python?

 

[Peter Hansen]

Take it this way, if someone showed you some badly written Python would
that put you off Python?

I'm waiting to see anyone succeed at writing Python code that badly.
I'd argue that it's not possible, unless one is deliberately trying
to make Python look bad.

(Note: I'm not saying people don't write really poor Python code,
or even code that looks awful. I am saying that I don't think
even the worst that I've seen would actually have made me say
"Ugh, Python must suck!" as a result, if I didn't already know
what Python was really like.)

-Peter

 

[Peter Hickman]

I'm waiting to see anyone succeed at writing Python code that badly.
I'd argue that it's not possible, unless one is deliberately trying
to make Python look bad.

True, Python's indenting goes a long way to discourage the one line merchants.

 

[Cameron Laird]

The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }

This is proof of something, I'm sure, but for me it's simply another
indication that (a) Ruby is more like Perl than it is like Python,
(b) unreadable code can be written in any language, and (c) I
really don't mind using 15 lines to write something if it means
the resulting code can readily be understood.

.
.
.
Regular expressions are great. They're also
limited. My experience is that it's quite
rare for anything meaningful to an end-user
to find its most natural implementation in
an RE.

That's what this subthread brings to *my*
mind. I recognize that Mr. Paul was doing
"utility programming", not application
development.

 

[Nick Vargish]

Show me a programming environment where lines of code per minute is
the most important coding metric, and I'll show you a place where I
would refuse to write code.

Do those guys come from some kind of scripting sweat shop? "Hurry it
up, those scripts have to be on the streets of Hong Kong by Tuesday!"
(Apologies to the Simpsons.)

That's my feeling about the Scriptometer "practical survey". I'll
stand by my statement if you want to substitute "terseness" for "lines
of code per minute".

Nick

 

[Steve Lamb]

Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?

Nope. This study is bogus on one large account.

[ following lines from the 'study' ]

if I have to write a script, I have to write it fast, it has to be
small (less typing)

It holds as paramount the lest amount of typing possible. While there is
a good argument that less is more, esp. when comparing something like Java vs.
Python there is a point where that trend reverses itself. IE, 8-10 lines to
do a "hello world" is a little too verbose. On the other hand boiling complex
logic and processing down to a barely comprehensible mess does nothing for
long-term stability, maintainability or, indeed, even short-term programming.

While this guy argues that less typing means faster scripts I'd wager than
in many cases where things are boiled into one liners more time is taken
debugging simple to spot errors if the script were expanded out a bit. In
short his basic premise is flawed. He starts out saying that one of the most
important factors is typing.

I've worked in shell and Perl. Haven't worked in Ruby yet. I still
prefer Python because, even though I am typing a little more (actually, in
some cases a little less[1]) I am coding faster ovarall because I'm trying to
do it right, not tight.


[1] In reality my Perl code was often slightly larger than my Python code
because I refused to use certain Perlisms. My coding practice in Perl was far
more rigid than the language allowed. This was so I could have some chance of
being able to read and modify my code at a later date. Could I have whipped
out tons of tight little one-liners in my Perl code and made it shorter than
my Python code? Sure. Did I want to? Hell no.

 

[Richard James]

This has nothing to do with ./
The site was hacked and corrupted two weeks ago and since this time
one a stub is online.

This info was from an early post on comp.lang.ruby

http://groups.google.com/groups?dq=...roups?hl=en&lr=&ie=UTF-8&group=comp.lang.ruby

And it was corrected to reflect that the Ruby site is "down for
maintenance".

Maybe they need to use Zope?

And it's /.