Python and Ruby
in [Python]
|
From: Jonathan Gardner on 2 Feb 2010 17:01 On Feb 1, 6:36 pm, John Bokma <j...(a)castleamber.com> wrote: > Jonathan Gardner <jgard...(a)jonathangardner.net> writes: > > One of the bad things with languages like perl > > FYI: the language is called Perl, the program that executes a Perl > program is called perl. > > > without parentheses is that getting a function ref is not obvious. You > > need even more syntax to do so. In perl: > > > foo(); # Call 'foo' with no args. > > $bar = foo; # Call 'foo; with no args, assign to '$bar' > > $bar = &foo; # Don't call 'foo', but assign a pointer to it to '$bar' > > # By the way, this '&' is not the bitwise-and '&'!!!! > > It should be $bar = \&foo > Your example actually calls foo... > I rest my case. I've been programming perl professionally since 2000, and I still make stupid, newbie mistakes like that. > > One is simple, consistent, and easy to explain. The other one requires > > the introduction of advanced syntax and an entirely new syntax to make > > function calls with references. > > The syntax follows that of referencing and dereferencing: > > $bar = \@array; # bar contains now a reference to array > $bar->[ 0 ]; # first element of array referenced by bar > $bar = \%hash; # bar contains now a reference to a hash > $bar->{ key }; # value associated with key of hash ref. by bar > $bar = \&foo; # bar contains now a reference to a sub > $bar->( 45 ); # call sub ref. by bar with 45 as an argument > > Consistent: yes. New syntax? No. > Except for the following symbols and combinations, which are entirely new and different from the $@% that you have to know just to use arrays and hashes. \@, ->[ ] \%, ->{ } \&, ->( ) By the way: * How do you do a hashslice on a hashref? * How do you invoke reference to a hash that contains a reference to an array that contains a reference to a function? Compare with Python's syntax. # The only way to assign a = b # The only way to call a function b(...) # The only way to access a hash or array or string or tuple b[...] > Also, it helps to think of > > $ as a thing > @ as thingies indexed by numbers > % as thingies indexed by keys > I'd rather think of the task at hand than what each of the funky symbols on my keyboard mean.
From: Jonathan Gardner on 2 Feb 2010 17:06 On Feb 2, 7:23 am, "bartc" <ba...(a)freeuk.com> wrote: > Jonathan Gardner wrote: > > One of the bad things with languages like perl and Ruby that call > > without parentheses is that getting a function ref is not obvious. You > > need even more syntax to do so. In perl: > > > foo(); # Call 'foo' with no args. > > $bar = foo; # Call 'foo; with no args, assign to '$bar' > > $bar = &foo; # Don't call 'foo', but assign a pointer to it to '$bar' > > # By the way, this '&' is not the bitwise-and '&'!!!! > > $bar->() # Call whatever '$bar' is pointing at with no args > > > Compare with python: > > > foo() # Call 'foo' with no args. > > bar = foo() # 'bar' is now pointing to whatever 'foo()' returned > > bar = foo # 'bar' is now pointing to the same thing 'foo' points to > > bar() # Call 'bar' with no args > > > One is simple, consistent, and easy to explain. The other one requires > > the introduction of advanced syntax and an entirely new syntax to make > > function calls with references. > > If you get rid of the syntax specific to Perl, then having to explicitly > obtain a function reference, or to dereference the result, is not such a big > deal: > > foo # Call 'foo' with no args. > bar = foo # Call 'foo; with no args, assign to 'bar' > bar = &foo # Don't call 'foo', but assign a pointer to it to 'bar' > bar^ # Call whatever 'bar' is pointing at with no args > > (Here I use ^ instead of -> to dereference.) Compared with Python, it saves > 3 lots of (), but needs & and ^ added. Still a net saving. > On one shoulder, a demon taunts the programmer: "Ohmygosh, you can save three keystrokes if you introduce an entirely new syntax with odd squiggles that make no pronounceable sound in the English language! Perhaps one day, you can program APL in Python!" The angel that sits on the other shoulder says, "Alas, poor programmer, one day, you'll have to read that and understand it. And heaven help us when we hire a poor college graduate to maintain the code we wrote five years ago. Or worse, when that poor college graduate writes code and expects us to read it!" Thankfully, Guido has banished that demon from the realm of Python a long time ago. > > One of the bad things with languages like perl and Ruby that call > > without parentheses is that getting a function ref is not obvious. > > I'd say that having this "&" symbol in front of "foo" makes it more obvious > than just foo by itself. But I agree not quite as clean. > > Another thing is that you have to know whether "bar" is a function, or a > function ref, and use the appropriate syntax. Sometimes this is helpful, > sometimes not. > Thankfully, in Python, everything is a ref, so everything is consistent.
From: Jonathan Gardner on 2 Feb 2010 17:09 On Feb 1, 6:50 pm, Nobody <nob...(a)nowhere.com> wrote: > On Mon, 01 Feb 2010 14:13:38 -0800, Jonathan Gardner wrote: > > I judge a language's simplicity by how long it takes to explain the > > complete language. That is, what minimal set of documentation do you > > need to describe all of the language? > > That's not a particularly good metric, IMHO. > > A simple "core" language doesn't necessarily make a language simple to > use. You can explain the entirety of pure lambda calculus or combinators > in five minutes, but you wouldn't want to write real code in either (and > you certainly wouldn't want to read such code which was written by someone > else). > > For a start, languages with a particularly simple "core" tend to delegate > too much to the library. One thing which puts a lot of people off of > lisp is the lack of infix operators; after all, (* 2 (+ 3 4)) works fine > and doesn't require any additional language syntax. For an alternative, > Tcl provides the "expr" function which essentially provides a sub-language > for arithmetic expressions. > > A better metric is whether using N features has O(N) complexity, or O(N^2) > (where you have to understand how each feature relates to each other > feature) or even O(2^N) (where you have to understand every possible > combination of interactions). > > > With a handful of statements, > > and a very short list of operators, Python beats out every language in > > the Algol family that I know of. > > Not once you move beyond the 10-minute introduction, and have to start > thinking in terms of x + y is x.__add__(y) or maybe y.__radd__(x) and also > that x.__add__(y) is x.__getattribute__('__add__')(y) (but x + y *isn't* > equivalent to the latter due to __slots__), and maybe .__coerce__() gets > involved somewhere, and don't even get me started on __metaclass__ or > __init__ versus __new__ or ... > > Yes, the original concept was very nice and clean, but everything since > then has been wedged in there by sheer force with a bloody great hammer. I strongly suggest you read the documentation on these bits of Python. If you're scared of __new__ versus __init__, then you haven't been programming very long in any language. There is a case when you need one over the other. The same goes for the other concepts. Programming languages that don't provide these features (like Javascript) are nice for toy programs, but lack the power to accommodate the needs of large apps.
From: Ben Finney on 2 Feb 2010 17:21 Jonathan Gardner <jgardner(a)jonathangardner.net> writes: > Compare with Python's syntax. > > # The only way to assign > a = b > > # The only way to call a function > b(...) > > # The only way to access a hash or array or string or tuple > b[...] For all of your examples, there are other ways supported. I do wish this focus on “only way” would depart, it's a fallacy and not helpful. What is important (and supports the main point of your message) is that for each of the above, whether or not they are the only way, they are the one *obvious* way to do the operation. -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney
From: Steve Holden on 2 Feb 2010 18:05
Ben Finney wrote: > Jonathan Gardner <jgardner(a)jonathangardner.net> writes: > >> Compare with Python's syntax. >> >> # The only way to assign >> a = b >> >> # The only way to call a function >> b(...) >> >> # The only way to access a hash or array or string or tuple >> b[...] > > For all of your examples, there are other ways supported. I do wish this > focus on “only way” would depart, it's a fallacy and not helpful. > And besides which most people get the quote wrong. The "authoritative" version from the Zen is, as you clearly already know There should be one-- and preferably only one --obvious way to do it. > What is important (and supports the main point of your message) is that > for each of the above, whether or not they are the only way, they are > the one *obvious* way to do the operation. > Quite. People might be interested to know the history of the Zen, which I got directly from Tim Peters over lunch one day. It was composed, apparently, during the commercial breaks one evening while he was watching professional wrestling on the television! So it's wise not to take the Zen too seriously. It wasn't written to guide, but to amuse. The fact that it can do both is a testament to Tim's sagacity. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ |