why the lucky stiff wrote:
Wash your mouths out, guys. In English, "serious" is a highly derogatory and offensive and dull term. Get that out.
I'd listen to _why; he's serious!
James
···
_why
.
I prefer the word elegant to beautiful.
Elegant code = the best part of programming
Part of making code elegant is writing it, then stripping away the
cruft and distilling the essence of the algorithm in what remains.
Like sculpture.
Hello tony,
···
On Mon, 10 Jan 2005 19:51:04 +0900, you wrote:
i happen to intensely hate python also for what its worth
reason: 3 wasted hours due to an indentation "bug"
yeah, that can be a killer if you don't use a fixed width font.
i found the only way to avoid that was to write python code with a dos
or some console editor (like the console version of vim, boxer, etc).
if i had any complaint about ruby it would be begin/end blocks. i
thought we ( as programmers) were done with that when pascal fell by
the wayside. i much prefer {curly brackets} to designate blocks of
Even C++ Freaks like Björn Stroustroup don't like brackets because
they are too much overloaded, thats why the new cast operators use <>.
I think the current balance between backets and begin/end in ruby is
very good. In Pascal the problem was that you had if/begin/end and no
implicit begin as part of the control statement. Ruby and all later Wirth
languages (Modula/Oberon) learned from the wrong Pascal way.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
>i happen to intensely hate python also for what its worth
>reason: 3 wasted hours due to an indentation "bug"yeah, that can be a killer if you don't use a fixed width font.
i found the only way to avoid that was to write python code with a dos
or some console editor (like the console version of vim, boxer, etc).if i had any complaint about ruby it would be begin/end blocks. i
thought we ( as programmers) were done with that when pascal fell by
the wayside. i much prefer {curly brackets} to designate blocks of
Heh, you don't like indentation _and_ you don't like begin/end blocks?
The reason for having begin/end blocks is simple: the
blocks-by-indentation in Python is _good_ -- code looks really
readable; however, the problem with that was in distinguishing end of
code blocks when you have several blocks. That's solved using
begin/end blocks -- the code is as readable and at the same time
there's no end ambiguity.
···
On Mon, 10 Jan 2005 21:56:18 +0900, tony summerfelt <snowzone5@hotmail.com> wrote:
On Mon, 10 Jan 2005 19:51:04 +0900, you wrote:
code...
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
--
Premshree Pillai
'there's only ONE way to do it'
No! The correct statement is:
'There should be one-- and preferably only one --obvious way to do it.'
what can i say:
There's Only One Way To Do It.
--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/\)
from:
http://mail.python.org/pipermail/python-announce-list/2000-September/000500.html
so i guess my question is: who's right with the statement you or the
author of python 
but my comment remains the same. only python masters will know the
'obvious way ' to do it...the rest of us just get flamed for being
perl/ruby/tcl/rebol/lua programmers 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
···
On Mon, 10 Jan 2005 23:01:22 +0900, you wrote:
i happen to intensely hate python also for what its worth
reason: 3 wasted hours due to an indentation "bug"yeah, that can be a killer if you don't use a fixed width font.
i found the only way to avoid that was to write python code with a dos
or some console editor (like the console version of vim, boxer, etc).
actually, i was using vim, but without a distinction in the highlighting
for tab / space. and i have 4 space tabs 
if i had any complaint about ruby it would be begin/end blocks. i
thought we ( as programmers) were done with that when pascal fell by
the wayside. i much prefer {curly brackets} to designate blocks of
code...
i use {}s constantly. i find that the distinction of having
end sometimes and } sometimes (while, def, class, if) makes for
really readable code and makes it much easier to see whats a builtin
to the language, admittedly i gave in to loop {} lately, tho i think
i'll return to while true as i prefer that i think
Alex
···
On Jan 10, 2005, at 1:56 PM, tony summerfelt wrote:
On Mon, 10 Jan 2005 19:51:04 +0900, you wrote:
actually, while there is some truth to this, i disagree.
there is never only one way to do something, i'm sure i can
point out multiple ways in python to do a single thing.
the fact is, different approaches are required, different
design decisions could be made, and the language should
preferably reflect these decisions well, otherwise you
end up with lots of guess work and implications.
the fact is, python ain't all that bad, but it has a lot
of duplications in its standard lib, i find the "sum" method
for example very stupid, and the duplication of method for
getting the length of a string is eww. not like in ruby
where they are exported via known alias's, but instead
*entirely* different methods for finding the value.
anyways, in the main python gets it right. just a few
shortcomings, but i'm happy to see that with 2.4 its
catching up to ruby, and in some areas, surpassing it,
the functional stuff doesn't really impress me, given
guido's background, i'm surprised there's not more,
doesn't really give it practical use cases though, list
processing via iterators etc in ruby is a neat and readable
solution to most of these problems.
perl otoh, goes very wrong, it provides many many ways
of doing the same thing. and none of them sensible
at least while python provides several ways, they are
in most cases, *fairly* sensible, but perl, its just
a long running joke by the authors, i'm sure of it
Alex
···
On Jan 10, 2005, at 3:01 PM, benjamin.ferrari wrote:
'there's only ONE way to do it'
No! The correct statement is:
'There should be one-- and preferably only one --obvious way to do it.'
the _obvious_ is very important here.
Alan Garrison wrote:
Zach Dennis wrote:
That's pretty funny. =) Well if you drop the 'L' you can get:
RAM
Ruby, Apache, MySQL
And now you have a larger target audience of both Linux users, Windows users, and those Mac folk to!
RAP = Ruby + Apache + PostgreSQL?
/mysql makes my head hurt
How abuot we join forces and give the user the option:
RAMP or RAM/P
Zach
Alan Garrison ha scritto:
RAP = Ruby + Apache + PostgreSQL?
I'm always been a fan of the FRAP acronym (freebsd ruby apache pgsql)
Yeah, I'm trying to think of a tool beginning with 'C' that can go on the front
···
In message <41E2C87E.8010508@cronosys.com>, Alan Garrison <alang@cronosys.com> writes
RAP = Ruby + Apache + PostgreSQL?
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html
i also mention that lua WAS easier, but got the same reaction...
either way, my experience with the python community was less than
pleasant...this was before i started flaming them on a regular
basis
i've had excellent contact here and in the tcl group though and that's
more than made up for it...
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
···
On Tue, 11 Jan 2005 04:36:24 +0900, you wrote:
when i mentioned that ruby might be easier to embed into a C program
than python is, the response was 'BS'. keeping in mind that i've done
both but the python person hadn't.
(*) Neither is sufficiently harder than the other to warrant a "mine's
better than yours" argument over language features.
Wash your mouths out, guys. In English, "serious" is a highly
derogatory and offensive and dull term. Get that out.
If serious programmers can't talk about ducks, I'm out of here!
Yes, "serious" programmers can write in every language regardless of
syntax or flavor. New languages should be infinitely easy to pick up
once you have the basic concepts down. But it's the languages they
choose for themselves that are the truly beautiful ones -- the ones
people need to pay attention to.. (Python and Ruby are both cool in
my book, but the level of fun to be had with blocks is unrivalved).
it might seem like that if you know ruby really well and use a lot of
the {|x| ...} syntax...
i find my code still has an inordinate amount of begin/end blocks
so my code looks amateurish compared to what i've seen here...
as i learn more efficient ruby that will diminish...
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
···
On Mon, 10 Jan 2005 14:16:22 +0100, you wrote:
I think the current balance between backets and begin/end in ruby is
very good.
Heh, you don't like indentation
i LIKE the indentation (it was the person i was replying to that
didn't like it). it makes you write neatly formatted code, removes
brackets/begin/end...BUT debugging a 10,000 line whitespace bug is
annoying.
_and_ you don't like begin/end blocks?
i don't like using 'begin' and 'end' i would much prefer using the
curly's for the blocks (or square brackets like rebol uses).
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
···
On Mon, 10 Jan 2005 23:07:31 +0900, you wrote:
Even C++ Freaks like Björn Stroustroup don't like brackets because
they are too much overloaded, thats why the new cast operators use <>.
yup. lisp just ain't all that amazing really
and having {} instead of () isn't that great
my mind parses ruby with interspersed {} and begin/end
*much* better than python / perl / c etc. they are
all too.. samey. :'s everywhere, $'s everywhere,
() / {}'s everywhere,
i'm still waiting for someone to come up with a
nicer syntax for || and some neat preprocessor/Filter
hacks to make ruby entirely non perl like for
all the perl haters out there 
I think the current balance between backets and begin/end in ruby is
very good. In Pascal the problem was that you had if/begin/end and no
implicit begin as part of the control statement. Ruby and all later Wirth
languages (Modula/Oberon) learned from the wrong Pascal way.
*nod*
Alex
···
On Jan 10, 2005, at 2:16 PM, Lothar Scholz wrote:
tony summerfelt wrote:
>> 'there's only ONE way to do it'
>
>No! The correct statement is:
>
>'There should be one-- and preferably only one --obvious way to do
it.'
what can i say:
> There's Only One Way To Do It.
> --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/\)
from:
http://mail.python.org/pipermail/python-announce-list/2000-September/000500.html
so i guess my question is: who's right with the statement you or the
author of python
good point, but what about python itself?
16:20:18-ferrari@herrober:~$ python
Python 2.3.3 (#1, May 18 2004, 19:29:58)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
putting this into the python implementation seems more official to me
than a personal signature.
···
On Mon, 10 Jan 2005 23:01:22 +0900, you wrote:
tony summerfelt wrote:
···
On Mon, 10 Jan 2005 23:01:22 +0900, you wrote:
'there's only ONE way to do it'
No! The correct statement is:
'There should be one-- and preferably only one --obvious way to do it.'
what can i say:
There's Only One Way To Do It.
--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/\)
On the other hand, I've read comments (not here) to the effect that the phrase "The Ruby Way" implies that there is but one correct way to do things (as opposed to "A Ruby Way" of doing something).
James
perl otoh, goes very wrong,
and i think perl6 is going to be very wronger...i wish larry wall
would stop listening to the python complains about perl...they aren't
gonna use perl6 anyway...and from the sounds of it a lot of current
perl programmers won't either...
the perl oo always felt tacked on to me...most of the perl code i
write is perl4 anyway...
it provides many many ways
of doing the same thing. and none of them sensible
they make sense to a perl programmer
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
···
On Tue, 11 Jan 2005 00:03:43 +0900, you wrote:
A few things to think about for those that worry about popularity.
(1) One learns a language because one learns something from learning
a language, not because the language is immediately the
end-all-beat-all. I still want to play with O'Caml and Haskell, and
I doubt I'll ever use them "for work".
(2) If we must chose what is widely adopted, we would always use Java
for every project -- or we might be stuck on Cobol. This is not the
case, as one can always choose the right tool for the job. That tool
is probably not Ruby in 1/2 the cases out there, but that doesn't
lessen Ruby's value. To mix metaphors, some people are always
looking for hammers in their toolbox, or sometimes swiss army knives.
Sometimes you need a torque wrench. It depends. Knowing "more"
can never hurt.
(3) However it is very clear that languages can grow in popularity
from the bottom up. Use a little Ruby on a special homebrew project,
use it on some build machines at work, and pretty soon you've
converted 1 or more new people to Ruby. Nothing wrong with that.
Ruby adoption levels do not prevent you from using it.
(4) Ruby popularity isn't as small as one might think. I have the
Python list and the Ruby list side-by-side in GMail right now, and the
Ruby list is 80% as active as the Python list. Not bad!
I really don't think Python-fans are wrong in the least. It's a
decent language, and some of the decisions such as playing down lambda
and the blocks type approach means solutions are developed differently
-- but that doesn't make them wrong. I like list comprehensions,
for instance.
If you can grok the "C" and kernel development mindsets, a lot of this
makes sense. Simplicity and obviousness mean a lack of cleverness at
face value, but they are very practical, straight forward, and easy to
understand for the most part. Those goals aren't all bad.
Personally, I'm looking for convergence, not distance between the
languages.
Zach Dennis wrote:
How abuot we join forces and give the user the option:
RAMP or RAM/P
The O'Reilly site has an "On LAMP" section.
For Ruby it would be (ready?)
"On RAMP"
*2* puns in one!
Oh, my sides hurt now.
James
···
Zach