Re: Python from Wise Guy's Viewpoint
Hannu Kankaanp?? wrote:
[color=blue]
> mike420@ziplip. com wrote in message
> news:<LVOAILABA JAFKMCPJ0F1IFP5 N3JTNUL0EPMGKMD S@ziplip.com>.. .[color=green]
>> THE BAD:
>>
>> 1. f(x,y,z) sucks. f x y z would be much easier to type (see Haskell)
>> 90% of the code is function applictions. Why not make it convenient?[/color]
>
> Python has been designed to attract non-programmers as well. Don't
> you think f(x,y,z) resembles the mathematical notation of passing
> a function some parameters, instead of "f x y z"?[/color]
Yes -- which is exactly why many non-programmers would prefer the
parentheses-less notation -- with more obvious names of course;-).
E.g.:
emitwarning URGENT "meltdown imminent!!!"
DOES look nicer to non-programmers than
emitwarning(URG ENT, "meltdown imminent!!!")
Indeed, such languages as Visual Basic and Ruby do allow calling
without parentheses, no doubt because of this "nice look" thing.
However, as I explained elsewhere, there are probably-insuperable
language-design problems in merging "implicit call" and first-classness
of all names unless you basically go all the way following Haskell
with implicit currying and non-strictness (and assignments should
probably go away too, else how to distinguish between assigning to
x a nullary function f itself, and assigning to x the result of
_calling_ f without arguments...?). Not to mention:
emitwarning URGENT highlight "meltdown imminent!!!"
where the need to disambiguate between highlight being the second
of three parameters to emitwarning, or a function called with
the string as its sole parameter and its RESULT being the second
of two parameters to emitwarning, is important for human readers
(indeed some languages that DO allow parentheses-less calls, such
as Ruby, warn against actually USING this possibility in all cases
where ambiguity-to-human-readers may result, such as the above --
the need to be very careful and selective in actually using the
capability makes me less and less willing to pay any large price
for it).
In other words, it's a language design tradeoff, like so many
others -- one which I believe both Python and Haskell got just
right for their different audiences and semantics (I know VB
_didn't_, and I suspend judgment on Ruby -- maybe firstclassness
of all names isn't as important as it FEELS to me, but...).
[color=blue][color=green]
>> 6. Requiring "return" is also dumb (see #5)[/color]
>
> You really don't get any of this "explicit is better than implicit"
> thing, do you? Requiring people to write "return" instead of
> leaving it as optional like in Ruby, is again one reason why
> Pythonistas *like* Python instead of Ruby. You come to[/color]
I think that making return optional is slightly error-prone,
but it DOES make the language easier to learn for newbies --
newbies often err, in Python, by writing such code as
def double(x): x+x
which indicates the lack of 'return' IS more natural than its
mandatory presence. So, it's a tradeoff one could sensibly
chose either way. Of course, such cases as:
def buhandclose(boh ):
try: boh.buh()
finally: boh.close()
would give you a bad headache in trying to explain them to
newbies ("hmyes the result of buhandclose IS that of the
last expression it evaluates, BUT the one in the finally
clause, although evaluated AFTER boh.buh(), doesn't really
count because..." [keeps handwaving copiously & strenously]).
So, mandatory 'return' does make the language more uniform,
consistent, and easy to master, though not quite as easy to
"pick up casually in a semi-cooked manner". Still, I for
one don't condemn Ruby for making the opposite choice -- it
IS a nicely balanced issue, IMHO.
[color=blue]
> Anyway, as a conclusion, I believe you'd be much happier with
> Ruby than with Python. It doesn't do this weird "statement vs
> expression" business, it has optional return, it has optional
> parens with function calls, and probably more of these things
> "fixed" that you consider Python's downsides. You're trying to[/color]
But doesn't make higher-order-functions as much of a no-brainer
as they're in Python, sigh.
[color=blue]
> make Python into a language that already exists, it seems, but
> for some reason Pythonistas are happy with Python and not rapidly
> converting to Ruby or Haskell. Instead of trying to tell us[/color]
My own reasons for the choice of Python over Ruby are quite
nuanced and complicated, actually (those for either of them
over Haskell have much to do with pragmatism over purity:-).
It boils down to my desire to write application programs,
often requiring cooperation of middling-sized groups of people,
rather than experimental frameworks, or programs written by a
lone coder or a small group of highly-attuned experts. I have
the highest respect for Ruby -- it just doesn't match my needs
QUITE as well as Python does. But, yes, if somebody doesn't
really think about what kind of programs they want to write,
but rather focuses on syntax sugar issues such as return being
optional or mandatory "per se", then it's definitely worthwhile
for that somebody to try Ruby and leave c.l.py in peace:-).
Alex
Hannu Kankaanp?? wrote:
[color=blue]
> mike420@ziplip. com wrote in message
> news:<LVOAILABA JAFKMCPJ0F1IFP5 N3JTNUL0EPMGKMD S@ziplip.com>.. .[color=green]
>> THE BAD:
>>
>> 1. f(x,y,z) sucks. f x y z would be much easier to type (see Haskell)
>> 90% of the code is function applictions. Why not make it convenient?[/color]
>
> Python has been designed to attract non-programmers as well. Don't
> you think f(x,y,z) resembles the mathematical notation of passing
> a function some parameters, instead of "f x y z"?[/color]
Yes -- which is exactly why many non-programmers would prefer the
parentheses-less notation -- with more obvious names of course;-).
E.g.:
emitwarning URGENT "meltdown imminent!!!"
DOES look nicer to non-programmers than
emitwarning(URG ENT, "meltdown imminent!!!")
Indeed, such languages as Visual Basic and Ruby do allow calling
without parentheses, no doubt because of this "nice look" thing.
However, as I explained elsewhere, there are probably-insuperable
language-design problems in merging "implicit call" and first-classness
of all names unless you basically go all the way following Haskell
with implicit currying and non-strictness (and assignments should
probably go away too, else how to distinguish between assigning to
x a nullary function f itself, and assigning to x the result of
_calling_ f without arguments...?). Not to mention:
emitwarning URGENT highlight "meltdown imminent!!!"
where the need to disambiguate between highlight being the second
of three parameters to emitwarning, or a function called with
the string as its sole parameter and its RESULT being the second
of two parameters to emitwarning, is important for human readers
(indeed some languages that DO allow parentheses-less calls, such
as Ruby, warn against actually USING this possibility in all cases
where ambiguity-to-human-readers may result, such as the above --
the need to be very careful and selective in actually using the
capability makes me less and less willing to pay any large price
for it).
In other words, it's a language design tradeoff, like so many
others -- one which I believe both Python and Haskell got just
right for their different audiences and semantics (I know VB
_didn't_, and I suspend judgment on Ruby -- maybe firstclassness
of all names isn't as important as it FEELS to me, but...).
[color=blue][color=green]
>> 6. Requiring "return" is also dumb (see #5)[/color]
>
> You really don't get any of this "explicit is better than implicit"
> thing, do you? Requiring people to write "return" instead of
> leaving it as optional like in Ruby, is again one reason why
> Pythonistas *like* Python instead of Ruby. You come to[/color]
I think that making return optional is slightly error-prone,
but it DOES make the language easier to learn for newbies --
newbies often err, in Python, by writing such code as
def double(x): x+x
which indicates the lack of 'return' IS more natural than its
mandatory presence. So, it's a tradeoff one could sensibly
chose either way. Of course, such cases as:
def buhandclose(boh ):
try: boh.buh()
finally: boh.close()
would give you a bad headache in trying to explain them to
newbies ("hmyes the result of buhandclose IS that of the
last expression it evaluates, BUT the one in the finally
clause, although evaluated AFTER boh.buh(), doesn't really
count because..." [keeps handwaving copiously & strenously]).
So, mandatory 'return' does make the language more uniform,
consistent, and easy to master, though not quite as easy to
"pick up casually in a semi-cooked manner". Still, I for
one don't condemn Ruby for making the opposite choice -- it
IS a nicely balanced issue, IMHO.
[color=blue]
> Anyway, as a conclusion, I believe you'd be much happier with
> Ruby than with Python. It doesn't do this weird "statement vs
> expression" business, it has optional return, it has optional
> parens with function calls, and probably more of these things
> "fixed" that you consider Python's downsides. You're trying to[/color]
But doesn't make higher-order-functions as much of a no-brainer
as they're in Python, sigh.
[color=blue]
> make Python into a language that already exists, it seems, but
> for some reason Pythonistas are happy with Python and not rapidly
> converting to Ruby or Haskell. Instead of trying to tell us[/color]
My own reasons for the choice of Python over Ruby are quite
nuanced and complicated, actually (those for either of them
over Haskell have much to do with pragmatism over purity:-).
It boils down to my desire to write application programs,
often requiring cooperation of middling-sized groups of people,
rather than experimental frameworks, or programs written by a
lone coder or a small group of highly-attuned experts. I have
the highest respect for Ruby -- it just doesn't match my needs
QUITE as well as Python does. But, yes, if somebody doesn't
really think about what kind of programs they want to write,
but rather focuses on syntax sugar issues such as return being
optional or mandatory "per se", then it's definitely worthwhile
for that somebody to try Ruby and leave c.l.py in peace:-).
Alex
Comment