Python and Ruby

[Jean Guillaume Pyraksos]

What are the arguments for choosing Python against Ruby
for introductory programming ? Python has no provisions
for tail recursion, Ruby is going to... So what ?
Thanks,

JG

 

[Stefan Behnel]

Jean Guillaume Pyraksos, 27.01.2010 14:01:

What are the arguments for choosing Python against Ruby
for introductory programming ?

PEP 20:

http://www.python.org/dev/peps/pep-0020/

Stefan

 

[Simon Brunning]

What are the arguments for choosing Python against Ruby
for introductory programming ?

Frankly, either would be a good choice.

I think Python is a little cleaner, but I'm sure you'd find Ruby fans
who'd argue the complete opposite. Both have good ecosystems, (i.e.
good communities, and plenty of good libraries and frameworks) - but
Python is probably a bit ahead here having been around a bit longer.

Python has no provisions
for tail recursion, Ruby is going to... So what ?

This would be a very strange reason to pick one language over the
other - it's a very minor point.

 

[Jonathan Gardner]

I think Python is a little cleaner, but I'm sure you'd find Ruby fans
who'd argue the complete opposite.

Are you sure about that?

There's a lot of line noise in Ruby. How are you supposed to pronounce
"@@"? What about "{|..| ... }"?

There's a lot of "magic" in Ruby as well. For instance, function calls
are made without parentheses. Blocks can only appear as the first
argument. There's a lot more, if you put your mind to it.

Indentation is also optional in Ruby. You can quickly fool a newbie by
not indenting your code properly, which is impossible in Python.

Python is much, much cleaner. I don't know how anyone can honestly say
Ruby is cleaner than Python.

 

[Jonathan Gardner]

I think the main difference is in culture, especially for  
*introductory* programming.

To add to that, Python is the type of language where experienced
programmers can pick it up by reading code, and newbies won't get
hopelessly lost. I've taught less-than-formal introductory programming
classes to people who are new to programming. Python gets out of the
way, and allows you to focus on the programming concepts, such as
variable, functions, parameters, classes, and algorithms.

 

[rantingrick]

To add to that, Python is the type of language where experienced
programmers can pick it up by reading code, and newbies won't get
hopelessly lost. I've taught less-than-formal introductory programming
classes to people who are new to programming. Python gets out of the
way, and allows you to focus on the programming concepts, such as
variable, functions, parameters, classes, and algorithms.

Well said Jonathan!! Well said!! (both posts)

 

[hackingKK]

Well said Jonathan!! Well said!! (both posts)

I share the same experience.
As pointed out in the "how to think like a computer scientist in Python"
I found that when I was teaching first time programmers, Python was the
best choice.

Not just the clean syntax but preciseness of the language itself was
very helpful.
as I callit "get in get your work done and get out!" methodology works
very well for absolute beginner students for programming.
new comers to this list might be happy to note that python reads very
closely to spoken English.
But I want to add more. while it is great tool for beginners, it is a
power box for advanced users who have the attitude of "cut the crap off
and come to the point" For such programmers python is extremly good,
I teach all types of students and now have convinced a few univercities
here in India to include python in engineering curriculam.


Happy hacking.
Krishnakant.

 

[Nobody]

There's a lot of "magic" in Ruby as well. For instance, function calls are
made without parentheses.

That's also true for most functional languages, e.g. Haskell and ML, as
well as e.g. Tcl and most shells. Why require "f(x)" or "(f x)" if "f x"
will suffice?

Python is much, much cleaner. I don't know how anyone can honestly say
Ruby is cleaner than Python.

I'm not familiar with Ruby, but most languages are cleaner than Python
once you get beyond the "10-minute introduction" stage.

 

[tanix]

That's also true for most functional languages, e.g. Haskell and ML, as
well as e.g. Tcl and most shells. Why require "f(x)" or "(f x)" if "f x"
will suffice?


I'm not familiar with Ruby, but most languages are cleaner than Python
once you get beyond the "10-minute introduction" stage.

I'd have to agree. The only ones that beat Python in that department
are Javascript and PHP. Plus CSS and HTML if you can call those languages.

The very idea of using a number of blanks to identify your block level
is as insane as it gets. First of all, combinations of blanks and tabs,
depending on how your ide is setup to expand tabs, may get you bugs,
you'd never imagine in your wild dreams.

Braces is the most reliable way to identify blocks.

Sane compilers ignore blanks altogether.



--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP,
organized by major topics of language, tools, methods, techniques.

All collections are fully searchable down to specific chapter.

 

[Steven D'Aprano]

I'd have to agree. The only ones that beat Python in that department are
Javascript and PHP. Plus CSS and HTML if you can call those languages.

Your sentence makes no sense. You agree that "most" languages are cleaner
than Python, and then in the very next sentence, out of the hundreds if
not thousands of languages invented, you can only list TWO that are
better than Python -- and those are Javascript and PHP!!!

That's like saying "most things are harder than diamond -- the only
things that beat diamond are jelly and talc".

The very idea of using a number of blanks to identify your block level
is as insane as it gets.

Not at all. People do it all the time. The very idea of expecting people
to count nested braces to identify block level is what is crazy, which is
why in languages with braces people still indent the blocks.

First of all, combinations of blanks and tabs,
depending on how your ide is setup to expand tabs, may get you bugs,
you'd never imagine in your wild dreams.

Not really. The bugs are quite simple, and generally easy to fix. To
describe them as unimaginable is stupid.

for x in [1, 2, 3]:

.... print x
.... print x+1
File "<stdin>", line 3
print x+1
^
IndentationError: unexpected indent


If you can't imagine getting an IndentationError from making an
indentation error, there's something wrong with you.

In any case, if your IDE mixes tabs and spaces, your IDE is broken and
you should fix your tools rather than blame the language.

Braces is the most reliable way to identify blocks.

Nonsense. For the compiler, both are equally reliable, and for the human
reader, indents beat braces easily.

Sane compilers ignore blanks altogether.

Really? So a "sane compiler" sees no difference between:

for x in mylist:

and

forxinmylist:


I'm glad I don't have to program using a compiler you consider "sane".

 

[Dennis Lee Bieber]

Braces is the most reliable way to identify blocks.

Braces (and ANY begin/end markers) are superfluous in any language
the has decent syntactic keywords... They only exist because some
languages chose to end, say, conditionals, on the first ";"

if (condition)
statement;
statement;

vs
if (condition)
{
statement;
statement;
}

vs
if (condition) then
statement;
statement;
endif


The first is misleading, as the second "statement" is not part of
the conditional.

The middle adds {} (or begin/end) pairs to avoid the situation of
the first.

The third is explicit without possibility for confusion. Note that
in these sample language, indentation is mere convention for the reader
and serves no syntactic purpose -- one could as easily write

if (condition)
{
statement;
statement;
}

but who would want to maintain that unintuitive mess.

Python just replaces the {} pairs with indent/dedent, leaving a
result that is both visually intuitive, and syntactically meaningful.

Sane compilers ignore blanks altogether.

Ah... Like FORTRAN (except for the first 6 spaces on the line)

DO10I=3,14159,26
vs
DO 10 I = 3 . 14159 26

in which the first is a loop statement and the second is an
assignment... And one must parse all the way up to the "," or "." to
determine which is which (and backtrack to the start of the statement if
the parsing assumed the incorrect branch)

 

[rantingrick]

That's also true for most functional languages, e.g. Haskell and ML, as
well as e.g. Tcl and most shells. Why require "f(x)" or "(f x)" if "f x"
will suffice?

yuck! wrapping the arg list with parenthesis (python way) makes the
most sense. Its to easy to misread somthing like this

onetwothree four five six

onetwothree(four, five, six) #ahhh... plain english.

 

[Steven D'Aprano]

yuck! wrapping the arg list with parenthesis (python way) makes the most
sense. Its to easy to misread somthing like this

onetwothree four five six

onetwothree(four, five, six) #ahhh... plain english.

I think the readability factor is mostly down to what you're familiar
with. But consistency is also important: in Python, you always refer to
an object the same way. Given an object called x, you ALWAYS refer to the
object itself as x. In languages that don't use parentheses, x refers to
the object, unless the object is a function, in which case x refers to
the result of calling the object with no arguments.

Other languages need special syntax to get access to the function object
itself. Because it's hard to do, people don't do it often. But in Python,
getting the function object is easy, and so treating functions as first-
class objects is easy.

 

[Nobody]

I'd have to agree. The only ones that beat Python in that department are
Javascript and PHP. Plus CSS and HTML if you can call those languages.

The very idea of using a number of blanks to identify your block level is
as insane as it gets.

I don't have a problem with layout (indentation level as a syntax element).

First of all, combinations of blanks and tabs,
depending on how your ide is setup to expand tabs, may get you bugs, you'd
never imagine in your wild dreams.

If you IDE places tab stops other than every 8 columns, it's broken.

Configurable tab stops in a text editor is one of those "features" that
differentiates a "coder" from a software engineer. A coder implements it
because it's easy to implement, without giving a moment's thought to the
wider context (such as: how to communicate the non-standard tab stops to
any other program which needs to read the file).

Even so, it's quite simple to implement layout in a way which doesn't
care about tab widths:

1. If the current line begins with exactly the same sequence of whitespace
characters as the last non-blank line, it's part of the same block.

2. If the sequence of whitespace characters at the beginning of the
current line is an extension of that for the last non-blank line
(i.e. it starts with the previous sequence, then adds some more
whitespace), then it's the first line of a inner block.

3. If the current line begins with a left substring of the sequence for
the last non-blank line, then it belongs to an outer block (whichever one
has that sequence).

4. If none of the above are true, it's a syntax error.

Braces is the most reliable way to identify blocks.

No they aren't. Indentation is much easier for humans to process than
scanning the file for braces (and not missing any). If you have any
indentation in the code, humans will interpret it as indicating the
nesting, even if the compiler doesn't. E.g.:

if(x) {
if(y)
foo();
else
bar();
}

See the problem? The compiler will match the else with if(y), but a human
will tend to match it with if(x).

Layout ensures that a human sees what the compiler "sees".

Given that any sane program uses indentation to reflect the program's
structure, braces (or "begin", or "end" (or endif/endwhile/etc)) are
redundant.

 

[John Bokma]

Configurable tab stops in a text editor is one of those "features" that
differentiates a "coder" from a software engineer. A coder implements it
because it's easy to implement, without giving a moment's thought to the
wider context (such as: how to communicate the non-standard tab stops to
any other program which needs to read the file).
[..]

if(x) {
if(y)
foo();
else
bar();
}

See the problem?

Nope, because a good editor will format this correctly. One written by
software engineers ;-)

Given that any sane program uses indentation to reflect the program's
structure, braces (or "begin", or "end" (or endif/endwhile/etc)) are
redundant.

An editor can correct the indenting of the braces example but can't with
this one.

if x:
if y:
foo()
else:
bar()

While braces might be considered redundant they are not when for one
reason or another formatting is lost or done incorrectly.

FWIW: I have no problem with how Python doesn't use braces nor on how
other languages do insist on braces or other structure markers.

 

[Steven D'Aprano]

An editor can correct the indenting of the braces example but can't with
this one.

if x:
if y:
foo()
else:
bar()

While braces might be considered redundant they are not when for one
reason or another formatting is lost or done incorrectly.

I've heard this argument before, and I don't buy it. Why should we expect
the editor to correct malformed code?

Would you expect your editor to correct this malformed code?

result = sin(x+)y

Why should broken indentation be held to a higher standard than any other
breakage in code?

 

[John Bokma]

I've heard this argument before, and I don't buy it. Why should we expect
the editor to correct malformed code?

Or a prettyfier. It doesn't matter. The point is that with braces there
*is* redundancy that be used to fix the code.

Would you expect your editor to correct this malformed code?

result = sin(x+)y

Nice straw man.

Let me repeat again: I am ok with how Python works. To be honest I think
it's cleaner compared to using {}. But in there are real life examples
in which Python code will break where code with braces will survive.

 

[John Bokma]

I've heard this argument before, and I don't buy it. Why should we expect
the editor to correct malformed code?

I do expect my editor to assist me in coding. In Emacs I have to do some
effort to enter the broken C code in the earlier post, and when I
reformat the code, it will be lined out correctly. I can't do that with
the above example, because it's correctly formatted.

You don't have to buy my argument, I am not selling it.

While in the past I wrote that an editor can't make you that more
productive I want to take that back, on the record. Since I've switched
to Emacs the editor has saved me several times from minor issues. Either
because it refused to indent correctly thanks to a missing closing }, ), ]
or other error. With the correct mode in Emacs one gets, in my
experience, immediate feedback when making mistakes one otherwise find
during the run/compiling phase.

Note that I am also not selling Emacs. It's free after all.

 

[Steven D'Aprano]

Or a prettyfier. It doesn't matter. The point is that with braces there
*is* redundancy that be used to fix the code.

Prettyfiers are significant in languages that allow braces (or begin/end
tokens) and indentation to go out of sync. Since that can't happen with
Python, it's not a problem that needs solving. Prettyfiers exist to work
around a limitation of languages where indentation is not significant.

Arguing that an advantage of braces is that prettyfiers can work with
them easily is a silly argument. That's like saying an advantage of horse-
drawn buggies over cars is that it will go faster when you hit the horse
with a whip. That's true, but you only need the whip because of the lack
of accelerator pedal.

A much better argument would be that an advantage of significant
indentation is that you no longer need a prettyfier, and a second
advantage is a major reduction in flame wars over coding styles.

Nice straw man.

It's not a straw man. It's a serious argument. There is an infinite
number of problems with malformed code that your editor can't fix, and
your prettifier can't deal with. Why should we care if indentation is one
more?

There are tools out there (such as some web forum software) that corrupt
whitespace. Those tools are broken, and if you (generic you), as a
developer, are relying on those tools to code with, then shame on you.
And if you're the creator of such broken tools, then shame on you more.
You wouldn't arbitrarily decide to remove leading "E"s from the user's
text, or trailing full stops, so why do you arbitrarily remove whitespace?

Let me repeat again: I am ok with how Python works. To be honest I think
it's cleaner compared to using {}. But in there are real life examples
in which Python code will break where code with braces will survive.

Yes. So what? They are rare and insignificant in practice. For every line
of code that you get via a webforum that mangles indentation, you get ten
thousand lines of code from some place that doesn't.

So long as code is written by and for human beings, the benefit of
significant indentation is 100% practical, and the practical benefit of
braces will remain insignificant.

 

[John Bokma]

Prettyfiers are significant in languages that allow braces (or begin/end
tokens) and indentation to go out of sync. Since that can't happen with
Python,

Yes it can. I *have* seen Python with broken indentation on web
pages, and good luck sorting it out. Blaming it on "broken tools" is
just another straw man. It happens, and if you're learning Python and
interested in that code you have a problem.

Snipped the rest, because you start to sound like a zealot. I should've
know better.