Ruby aesthetics

[HAL_9000]

I just want to add that in my opinion, what really make Python so popular
are, among other things:

1) Indentation-based syntax
2) "There is only one way to do it"

I think 1) at the time Python was introduced (several years ago) was
really “revolutionary” (well, yes, there were already several non-popular
languages that were indentation-based such as ABC(?)), as all other
mainstream languages such as C/C++, Java, and Perl have the free-form
syntax. Making the syntax to be indentation-based really enforces clean
coding, independent of the programmer’s discipline.

Regarding 2), combined with 1), it really just makes all Python codes very
consistent. We know what exactly to write to accomplish something, and it
is very rare that we encounter a cryptic code.

This is not a flame!

I think what you’re saying is very interesting, because it’s
almost the exact opposite of my opinion.

Disclaimer: I’ve never used Python.

I do think the idea of “significant indentation” is interesting,
but I would want the tab character to be illegal. (Yes, I know
the arguments in favor of tabs; let’s not get into that one.)
It’s bad enough mixing tabs and spaces in an ordinary language,
but in Python it seems like an additional inconvenience.

I am still grieving that
Ruby carries Perl’s idiom of statement modifier

..... if/unless/while/until .....

I like it.

Also, in Ruby there are several method synonyms, such as Array
“indexes” and “indices”, which unnecessarily add more complications to the
language.

I like these, too.

I think these are several reasons why not all people migrated from Python
to Ruby. (And of course we all know the superiority of Ruby to
Python, right? ) I am just speculating, that, since Ruby was written
after Python was introduced, if these two factors (among other
things) have been taken into Ruby, probably Ruby had replaced Python to a
great extent…

Is this true? Ruby was written after Python was introduced?
When was Python born?

Hal

···

----- Original Message -----
From: “William Djaja Tjokroaminata” billtj@z.glue.umd.edu
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, September 03, 2002 11:22 AM
Subject: Re: Ruby aesthetics

[James6 (James)]

I just want to add that in my opinion, what really make Python so popular
are, among other things:

1) Indentation-based syntax
2) "There is only one way to do it"

Wow. These are two things that would keep me away from any language.
I gave Python a shot, but the forced formatting (among other things) turned
me off.

I didn’t get far enough to find if there really was only one way to do
things.

Still, that would make debugging easier: Just maintain a database of all
code done the Right Way, and if your code doesn’t match The One Way To Do
It, then it’s wrong.

James

[Peter_Hickman]

William Djaja Tjokroaminata wrote:

1. Indentation-based syntax

I’ve used Python and although I soon got used to this I had a major
problem. I indent my code as I’m developing but I put the debug code
hard on the left margin. This makes inserting a print statement or
whatever easy and detecting it when it requires removal is also easy.
However Python required my debug code the indent correctly and therefore
my debug code ‘disappears’ into the body of the code. Adding comments to
mark the code starts to become a real chore. What was 5 print statements
ends up as 15 lines added to the code.

An editor macro helps but the ‘paperwork’ starts to build up and bulk
out the code. At this point the language is starting to get in my way.

2. “There is only one way to do it”

1. Makes code maintenance nice and easy
2. It had better be a sensible ‘way to do it’ (Think Java classes v.s.
   Ruby classes)

I think 1) at the time Python was introduced (several years ago) was
really “revolutionary” (well, yes, there were already several non-popular
languages that were indentation-based such as ABC(?)), as all other

Yes it was ABC, Python took it’s indentaion model from ABC as I recall.
And yes ABC was ‘non-popular’.

[Luc_Heinrich1 (Luc Heinrich)]

You’re right, I should have said ‘ugly’ instead of ‘useless’, not the
same thing.

···

On dimanche, sep 1, 2002, at 12:32 Europe/Paris, Matt Gushee wrote:

Now if you called them ugly, I’d be the first to agree with that.

–
Luc Heinrich - lucsky@mac.com

[Phlip4 (Phlip)]

Ruby: squares_less_than_10 = numbers.find_all{|i| i<10}.map{|i| i^2}

I like list comprehensions (they’re somewhat Haskell-ish), but, as many of
my pythonesque friends have stated, “they’re not very true to python’s
syntax.” And, in this form, perhaps a little ugly.

But I suspect someone could bottle that cranky syntax up into a function
called “comprehend” taking a list and a lambda, no?

···

–
Phlip
greencheese.org
– The first few lines of code must “hook” the
computer, and make it “care” about the program –

[Tim_Hammerquist2 (Tim Hammerquist)]

Gavin Sinclair graced us by uttering:

But this is also the greatest way in which Python has
contributed to the modern coding community. For example,
I’ve never, ever, ever seen a Python function definition like
this.

def foo(arg1, arg2)
do_stuff()
do_some_more_stuff()
while some_condition:
do_some_conditional_stuff()
for var in some_list:
do_more_stuff_with(arg1)

…I wish I could say the same for Perl.

Since Perl has braces-as-syntax instead of
invisible-undetectable-because-its-not-there-whitespace-as-syntax,
you can get vim/emacs/whatever to reindent Perl for you.

Of course, you never need to reindent Python code, except for
when:

• you want to change the indent level from 8 to 3, e.g.

Vim: block in VISUAL mode and use < or > keys works for me.

• you cut and paste some code into a loop

Vim: with a sufficiently detailed indent spec, Vim’s specialized
put routines should help, namely ‘]p’ and ‘]P’. Also see
:help i_CTRL-R and related commands.

My objection may not play out much in practice (I’d never
practice it because of the explicit self parameter!), but it is
a very strong (and stubborn) philosophical objection for me.

We’ve all got some. You’re among friends.

I’ll conclude with one (new) feature from Python that makes me
green with envy: list comprehensions. For those who don’t know
what that means, here’s an example:

Ruby: squares_less_than_10 = numbers.find_all{|i| i<10}.map{|i| i^2}

Python: squares_less_than_10 = [x^2 for x in numbers if x < 10]

Don’t get me wrong, I love Ruby’s powerful array-manipulation
capabilities. But list comprehensions are soooo cooool!

I think this illustrates one of several instances where
Pythonistas recognized how difficult Python made it to do
something many other languages took for granted. This nice
little shortcut was added, but I also agree that list
comprehensions are very not-Pythonesque.

And I have no problem with Ruby’s solutions. They tend to be
more consistent, in any case.

Tim Hammerquist

···

“Tim Hammerquist” tim@vegeta.ath.cx wrote:
–
A successful [software] tool is one that was used
to do something undreamed of by its author.
– S. C. Johnson

[Michael_Schneider]

Bruce Williams wrote:

I’ll conclude with one (new) feature from Python that makes me green with
envy: list comprehensions. For those who don’t know what that means,
here’s an example:

Ruby: squares_less_than_10 = numbers.find_all{|i| i<10}.map{|i| i^2}

Python: squares_less_than_10 = [x^2 for x in numbers if x < 10]

Don’t get me wrong, I love Ruby’s powerful array-manipulation capabilities.
But list comprehensions are soooo cooool!

Cheers,
Gavin

I like list comprehensions (they’re somewhat Haskell-ish), but, as many of my
pythonesque friends have stated, “they’re not very true to python’s syntax.”
And, in this form, perhaps a little ugly.

Basically, I don’t think this is a shoe that matches what Python is wearing.

A little background so you get a feel where I am comming from:

From a language Point I come from:

LISP/ CLOS/ C++/ Modula3/ Various AI languages/ Java

From a scripting point:
I started with perl 4, then switched to Python 1.2, and have been then
since, I have looked at Ruby a couple of
times, but went back to python. (case must be strong 'nuff to drive a
change).

Lately, I have been working with integration Scripting and C++ for rapid
development.

I am looking at ruby again, the key things that I like about python:

• functions as first class entities
• Ability to use multi-processor machines (I have a number of
  multi-processor SGI’s to use

But the most valuable to me is the support of fundamentally different
approaches to software development in the same language

Some Examples::
*Pure OO model with mutiple inheritance (Ruby seems to support
this with modules for mixins
*Pure functional (Ruby seems to have some support for this, but not
as strong as Python
* Simple script, (no objects)

This multiple-technique support is one of the reasons that I like
python. (Note: this is not
a Ruby Flame, I do like Ruby’s:
* end statement rather then indent
* Ruby Code Block
* iterator model (this probably drove python’s iterator model)
* GC Model

####################### What I really Like

···

################################################

There are 2 strong languages, with similar core techniques that draw
from each other. I
am a big fan of competition. I think that competition works.
Competition in an open
source environment adds a very nice twist.

It allows for cross-pollination between the language (Pyton now has
support for full closures and
iterators). Ruby may get list comprehension.
Ruby may get native threads…

In short: I like ruby, and I like python, but I really like having them
both

Thanks for the great language,
Mike

[Reimer_Behrends]

[…]

I’ll conclude with one (new) feature from Python that makes me green
with envy: list comprehensions. For those who don’t know what that
means, here’s an example:

Ruby: squares_less_than_10 = numbers.find_all{|i| i<10}.map{|i| i^2}

Python: squares_less_than_10 = [x^2 for x in numbers if x < 10]

That calls for a functional abstraction (functional abstraction is
essentially a fancy software engineering term for factoring out commonly
occuring code sequences into a procedure, function, or method of its
own) rather than a new language feature. This abstraction is most easily
added to Enumerable:

module Enumerable

map all elements through a filtering block, keeping all the results

that aren’t nil.

def condmap
result =
each do
> elem |
item = yield elem
result << item unless item.nil?
end
result
end

end

To be used as follows:

squares_less_than_10 = numbers.condmap{|x| x**2 if x < 10 }

In general, you do not want to expand the language when existing
abstraction mechanisms can already capture the same thing adequately and
with more room for customization.

		Reimer Behrends

···

Gavin Sinclair (gsinclair@soyabean.com.au) wrote:

[William_Djaja_Tjokr1 (William Djaja Tjokroaminata)]

Well, I don’t really know, but probably if it is not done the (only) right
way, it will not even compile anyway :), so there is no need to maintain
the database.

As an example, when we need an IF clause, there is really one way to do
it in Python:

if condition:
    statement

In Ruby, we can have

if condition
    statement
end

unless ! condition
    statement
end

unless not condition
    statement
end

statement if condition

etc. So, I guess in some sense, Ruby still has the Perl’s “there is more
than one way to do it” influence.

Regards,

Bill

···

============================================================================
JamesBritt james@jamesbritt.com wrote:

Still, that would make debugging easier: Just maintain a database of all
code done the Right Way, and if your code doesn’t match The One Way To Do
It, then it’s wrong.

James

[William_Djaja_Tjokro (William Djaja Tjokroaminata)]

Hi,

I am too hoping that we will have this discussion in a friendly
environment, as we are all Ruby lovers

I used Perl before I used Python. The primary driving force behind the
switch from Perl to Python is the special issue of “Linux Magazine” on
Python (even until now I think the Linux Magazine editors are still Python
supporters). They shared their experience on how wonderful the Python
code was, and I tried it. And coming from some Perl background, it
was! Compared to Perl, code and object model in Python are very
clean. After programming years in free-form languages, I could really
appreciate the advantages of indentation-based syntax.

What finally turned me off was that in Python the object is modeled rather
crudely using a hash (in Ruby also, but not as naked as in Python). For
example, to access the object instance variable, the object method is
defined as

def f1 (self, x1, x2, ....)
    self.x1 = x1
....

This shows how crude the object model is in Python. (Well, in Ruby we
don’t see this until we code Ruby in C .)

Then when I finally switched from Python to Ruby, I felt like I switched
to “a (very much) better Perl” than to “a better Python”. In other words,
there is no question regarding comparison between Perl and Ruby; but
Python and Perl, well, let’s just say that the two are different …

Regarding whether Matz knew Python or not before he wrote Ruby, let’s ask
Matz…

Regards,

Bill

···

============================================================================
Hal E. Fulton hal9000@hypermetrics.com wrote:

This is not a flame!

I think what you’re saying is very interesting, because it’s
almost the exact opposite of my opinion.

Disclaimer: I’ve never used Python.

I do think the idea of “significant indentation” is interesting,
but I would want the tab character to be illegal. (Yes, I know
the arguments in favor of tabs; let’s not get into that one.)
It’s bad enough mixing tabs and spaces in an ordinary language,
but in Python it seems like an additional inconvenience.

I am still grieving that
Ruby carries Perl’s idiom of statement modifier

..... if/unless/while/until .....

I like it.

Also, in Ruby there are several method synonyms, such as Array
“indexes” and “indices”, which unnecessarily add more complications to the
language.

I like these, too.

I think these are several reasons why not all people migrated from Python
to Ruby. (And of course we all know the superiority of Ruby to
Python, right? ) I am just speculating, that, since Ruby was written
after Python was introduced, if these two factors (among other
things) have been taken into Ruby, probably Ruby had replaced Python to a
great extent…

Is this true? Ruby was written after Python was introduced?
When was Python born?

Hal

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

I do think the idea of “significant indentation” is interesting,
but I would want the tab character to be illegal. (Yes, I know
the arguments in favor of tabs; let’s not get into that one.)
It’s bad enough mixing tabs and spaces in an ordinary language,
but in Python it seems like an additional inconvenience.

I do think the idea of “significant indentation” is interesting, but:

• for historycal reason, we can’t distinguish tabs and spaces at a
  glance. this is very bad for “significant indentation”.

• somehow “significant indentation” brings separation betweeen
  expression and statement. I don’t like this. I feel this is a
  restriction for no reason. for example, in Python, lambda body
  must be an expression. you have to define a named function if you
  want a function which body contains statements.

Is this true? Ruby was written after Python was introduced?
When was Python born?

True. I knew Python before I designed Ruby. Python started somewhere
around Christmas 1989.

						matz.

···

In message “Re: Ruby aesthetics” on 02/09/04, “Hal E. Fulton” hal9000@hypermetrics.com writes:

[William_Djaja_Tjokr1 (William Djaja Tjokroaminata)]

Hi,

Yes, I now recall that the indentation-based syntax sometimes could really
get in the way, and when I just wanted to temporarily comment-out a
section of code, I had to reindent the whole section; it was indeed a
pain. On the other hand, for some reason, my eyes prefer to see Python’s
format to Ruby’s format (at least usually the Python block is one line
shorter and if we don’t use a blank line, that is two lines shorter). But
overall, taking also into account Matz’s reasons regarding the
indentation, if I am to design my own language, probably I will also stick
to the Ruby format .

Which brings us to the second point. Perl was kind of a
“maximalist” language; there are almost always more than one way to do
something. Python claimed to be a “minimalist” language. When I switched
from Perl to Python, it really felt like a breeze, because everything was
in order. Therefore, when I switched from Python to Ruby, I felt it was
like a step backward in this regard. I don’t mind that a language
provides many constructs/methods as long as each one has different purpose
and/or has different performance. Otherwise, I think it will become more
burden to the programmer. Does anybody know why Ruby didn’t aim to be a
“minimalist” language?

(For example, both “if” and “unless” are given instead of just “if”; I
haved used both regularly, but still I cannot avoid having “!” from time
to time, in which case probably then only “if” is sufficient. Also both
“!” and “not” are given, and further they have different precedence; I
think even in Perl they are just synonymous; I think it is probably better
to simply use parentheses whenever precedence is in doubt instead of
relying on the precedence table, just like many programming books say.)

Regards,

Bill

···

============================================================================
Peter Hickman peter@semantico.com wrote:

William Djaja Tjokroaminata wrote:

1. Indentation-based syntax

I’ve used Python and although I soon got used to this I had a major
problem. I indent my code as I’m developing but I put the debug code
hard on the left margin. This makes inserting a print statement or
whatever easy and detecting it when it requires removal is also easy.
However Python required my debug code the indent correctly and therefore
my debug code ‘disappears’ into the body of the code. Adding comments to
mark the code starts to become a real chore. What was 5 print statements
ends up as 15 lines added to the code.

An editor macro helps but the ‘paperwork’ starts to build up and bulk
out the code. At this point the language is starting to get in my way.

2. “There is only one way to do it”

1. Makes code maintenance nice and easy
2. It had better be a sensible ‘way to do it’ (Think Java classes v.s.
   Ruby classes)

[Dossy]

I can’t tell who originally wrote this, but:

I’ll conclude with one (new) feature from Python that makes me green with
envy: list comprehensions. For those who don’t know what that means,
here’s an example:

Ruby: squares_less_than_10 = numbers.find_all{|i| i<10}.map{|i| i^2}

Python: squares_less_than_10 = [x^2 for x in numbers if x < 10]

What about this in Ruby, instead:

squares_less_than_10 = numbers.collect { |x| x**2 if x < 10 } - [nil]

– Dossy

···

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

[Tim_Hammerquist2 (Tim Hammerquist)]

Michael Schneider graced us by uttering:

From a scripting point:
I started with perl 4, then switched to Python 1.2, and have
been then since, I have looked at Ruby a couple of times, but
went back to python. (case must be strong 'nuff to drive a
change).

Wow. You might even want to look into Perl5. It’s a noticeable
step up in functionality and adds it’s own OO facility (ugly as
it may be…)

Lately, I have been working with integration Scripting and C++
for rapid development.

On second thought, don’t look at Perl for C/C++ integration… at
least not until Perl6.

But the most valuable to me is the support of fundamentally
different approaches to software development in the same
language

Some Examples::
*Pure OO model with mutiple inheritance (Ruby seems to
support this with modules for mixins
*Pure functional (Ruby seems to have some support for
this, but not

You can’t have both pure OO and pure functional. At least one
must be tainted and/or emulated. Ruby is just tainted more toward
the OO angle.

But Python’s “pure functional” face is emulated much like Ruby’s:

• Ruby “functions” like system(), fork(), exit(), system() are
  implicit invocations of the respective functions in the
  Kernel module.

• Similarly, Python “functions” like eval(), exit(), file(),
  len(), open(), quit(), etc. actually call their respective
  methods in the builtins module. Try ‘dir(builtins)’
  at the Python interpreter prompt for a more complete list.

But you’re quite free to write shellscript-ish things like this,
which uses only the implicit functions of the Kernel module.

#!/usr/local/bin/ruby -w

bring up interface and background the process

system ‘/etc/ppp/ppp-on > ~/.ppp_log 2>&1 &’

wait for ppp interface

until system %q{netstat -ai | grep ‘^ppp’} do
select(nil, nil, nil, 2)
print ‘.’
end

run some_app unless already running

if /\bsome_app\b/m !~ ps -x
fork or exec(‘some_app’)
end

Ruby may get native threads…

Actually, I’m not really anxious for this. Sure, there are
advantages, but when you consider that Python’s native threading
is broken, especially when considering signal handling, I’m quite
happy with Ruby’s threads.

Tim Hammerquist

···

–
We are Pentium of Borg. Division is futile. You will be approximated.
– seen in someone’s .signature

[Gavin_Sinclair]

[…]

I’ll conclude with one (new) feature from Python that makes me green
with envy: list comprehensions. For those who don’t know what that
means, here’s an example:

Ruby: squares_less_than_10 = numbers.find_all{|i| i<10}.map{|i| i^2}

Python: squares_less_than_10 = [x^2 for x in numbers if x < 10]

That calls for a functional abstraction (functional abstraction is
essentially a fancy software engineering term for factoring out commonly
occuring code sequences into a procedure, function, or method of its
own) rather than a new language feature. This abstraction is most easily
added to Enumerable:

module Enumerable

map all elements through a filtering block, keeping all the results

that aren’t nil.

def condmap
result =
each do
> elem |
item = yield elem
result << item unless item.nil?
end
result
end

end

To be used as follows:

squares_less_than_10 = numbers.condmap{|x| x**2 if x < 10 }

That’s very nice indeed. Would there be any support for adding this, or
something like it, to the language standard? Maybe not, since there’s a
redundancy (collect{…}.compact). But I’d like to see it for sure.

In general, you do not want to expand the language when existing
abstraction mechanisms can already capture the same thing adequately and
with more room for customization.

True, but what about getting all pairs of number less than 10 whose combination
mulitplies to greater than 25?

result = [[a,b] for a in (1…10) for b in (1…10) if a * b > 25]

This construct hasn’t had much popularity in this thread, but I think it would
be a worthwhile addition to the language. It’s simply a beautiful abstraction.
(I know a little about functional programming, but cannot be said to have a
background in it: my appreciation for list comprehensions is more
mathematical.)

Reimer Behrends

Gavin

···

----- Original Message -----
From: “Reimer Behrends” behrends@cse.msu.edu

Gavin Sinclair (gsinclair@soyabean.com.au) wrote:

[Florian_Frank2 (Florian Frank)]

This simple example isn’t much of a problem. But List comprehensions can
be much more complex: You can have lots of generators like “numbers”
and tests like “x < 10” and still get a list of elements (which can
have a special type) back.

I have hacked a module to have list comprehensions in Ruby which uses
Enumerables and Procs (see the attachment). The Syntax isn’t as nice and
the block variables have to reflect the order in which the generators
were given to the constructor.

A more complex example would be

L(0…4, 0…4, lambda { |x, y| x > y }) { |p| p.join “;” }

which returns an array of all pairs in the range 0…4 where x > y as
strings separated by “;”.

In Haskell LCs support Lazy Lists, which my module doesn’t support at
the moment. I don’t know if Python can handle Lazy Evaluation in list
comprehensions.

List comprehension are fun to play with: You can code a very short
version of the quicksort algorithm with them:

def quicksort(seq)
x = seq.shift or return
quicksort( L(seq, lambda { |y| y < x })) + [ x ] +
quicksort( L(seq, lambda { |y| y >= x }))
end

(But since Ruby 1.7 will have a primitive form of a partition function
you get a short quickshort for free which is also more efficient than
this solution.)

lc.rb (2.12 KB)

···

On Sun, 2002-09-01 at 16:18, Phlip wrote:

But I suspect someone could bottle that cranky syntax up into a function
called “comprehend” taking a list and a lambda, no?

–
Give me a man or a woman who has read a thousand books and you give me
an
interesting companion. Give me a man or a woman who has read perhaps
three
and you give me a dangerous enemy indeed.
– Anne Rice, “The witching hour”

[Drew_Mills2 (Drew Mills)]

I must confess to a lack of Ruby guru-ness. It would be a great tutorial if
someone would be gracious enough to give a token-by-token (blow-by-blow
sounds so violent) commentary on what Reimer just wrote.

Thanks,

Drew

···

-----Original Message-----
From: Reimer Behrends [mailto:behrends@cse.msu.edu]
Sent: Sunday, September 01, 2002 5:59 PM
To: ruby-talk ML
Subject: Re: Ruby aesthetics

Gavin Sinclair (gsinclair@soyabean.com.au) wrote:
[…]

I’ll conclude with one (new) feature from Python that makes me green
with envy: list comprehensions. For those who don’t know what that
means, here’s an example:

Ruby: squares_less_than_10 = numbers.find_all{|i| i<10}.map{|i| i^2}

Python: squares_less_than_10 = [x^2 for x in numbers if x < 10]

That calls for a functional abstraction (functional abstraction is
essentially a fancy software engineering term for factoring out commonly
occuring code sequences into a procedure, function, or method of its
own) rather than a new language feature. This abstraction is most easily
added to Enumerable:

module Enumerable

map all elements through a filtering block, keeping all the results

that aren’t nil.

def condmap
result =
each do
> elem |
item = yield elem
result << item unless item.nil?
end
result
end

end

To be used as follows:

squares_less_than_10 = numbers.condmap{|x| x**2 if x < 10 }

In general, you do not want to expand the language when existing
abstraction mechanisms can already capture the same thing adequately and
with more room for customization.

  	Reimer Behrends

[HAL_9000]

What finally turned me off was that in Python the object is modeled rather
crudely using a hash (in Ruby also, but not as naked as in Python). For
example, to access the object instance variable, the object method is
defined as

def f1 (self, x1, x2, ....)
    self.x1 = x1
....

This shows how crude the object model is in Python. (Well, in Ruby we
don’t see this until we code Ruby in C .)

Hmm, I think that at the lowest level (whether C extension or guts of
the interpreter or assembly language) you would have to see this –
it can’t be hidden at that level. A method has to know what the value
of ‘self’ is ultimately.

Regarding whether Matz knew Python or not before he wrote Ruby, let’s ask
Matz…

Well, I broke down and did a little web search. Apparently
Python dates back to 1991, making it at least two years older
than Ruby. I didn’t know that.

I knew I had heard of Python (1996?) before I heard of
Ruby (1999) but they both were in existence before that, of
course.

Hal

[Tim_Hammerquist2 (Tim Hammerquist)]

Yukihiro Matsumoto graced us by uttering:
[ snippage ]

I do think the idea of “significant indentation” is
interesting, but:

• for historycal reason, we can’t distinguish tabs and spaces
  at a glance. this is very bad for “significant indentation”.

This is true, and has spawned a whole new religious war in the
comp.lang.python NG, esp. relating to whether to use hart-tabs or
softtabs in Vim.

• somehow “significant indentation” brings separation
  betweeen expression and statement. I don’t like this. I
  feel this is a restriction for no reason. for example, in
  Python, lambda body must be an expression. you have to
  define a named function if you want a function which body
  contains statements.

I don’t like this either, but I thought the sig. indent was a
completely separate mantra from the “no statements in most places
they would be useful” concept. I don’t see why you can’t have
sig. indent w/o Python’s annoying exclusion of statements from
conditional contexts.

Thoughts? Not that I want sig. indent for Ruby. No need to
mess with a good thing. But if someone were designing a new
language and he/she didn’t want it to be as annoying as Python,
what do you think?

Tim Hammerquist

···

–
Perl did not get where it is by ignoring psychological factors.
– Larry Wall in 199809031634.JAA26895@wall.org

[Gavin_Sinclair]

Hi,

[…]

Which brings us to the second point. Perl was kind of a
“maximalist” language; there are almost always more than one way to do
something. Python claimed to be a “minimalist” language. When I switched
from Perl to Python, it really felt like a breeze, because everything was
in order. Therefore, when I switched from Python to Ruby, I felt it was
like a step backward in this regard. I don’t mind that a language
provides many constructs/methods as long as each one has different purpose
and/or has different performance. Otherwise, I think it will become more
burden to the programmer. Does anybody know why Ruby didn’t aim to be a
“minimalist” language?

Ruby strikes a good balance between minimalism and maximalism. You need some
flexibility.

(For example, both “if” and “unless” are given instead of just “if”; I
haved used both regularly, but still I cannot avoid having “!” from time
to time, in which case probably then only “if” is sufficient. Also both
“!” and “not” are given, and further they have different precedence; I
think even in Perl they are just synonymous; I think it is probably better
to simply use parentheses whenever precedence is in doubt instead of
relying on the precedence table, just like many programming books say.)

“unless” is manna from heaven. “if not” is such a contortion. Positive logic
is clearer than negative logic. In C-related languages, I would code the
if/else in such a way as to avoid “not”.

So what on earth is wrong with “unless”? It’s a perfectly normal English word
given a perfectly good use in Perl/Ruby.

The point about precedence is well made. For a language that follows POLS,
there certainly seem to be some tricky (and arbitrary) precedence issues, and I
don’t know them. Thankfully, they haven’t surprised me yet.

One point you should have mentioned was aliases. I don’t know how many people
in the group like them. Personally, I like them in the built-in classes,
because it accomodates different language backgrounds. I prefer “map” and
“indices”; were it not for aliases, I’d probably have to conform to “collect”
(what the hell does that mean? and “indexes” (a bastard of a word if ever
I saw one).

The point is, however, that everyone knows about the “built-in” aliases; in
users’ classes, domain-specific functionality should guide the choice of method
names reasonably clearly.

Regards,

Bill

–Gavin (sorry to respond so verbosely to a point you didn’t even make

···

----- Original Message -----
From: “William Djaja Tjokroaminata” billtj@z.glue.umd.edu