Python and Ruby
in [Python]
|
From: John Bokma on 1 Feb 2010 21:56 Nobody <nobody(a)nowhere.com> writes: > On Mon, 01 Feb 2010 14:35:57 -0800, Jonathan Gardner wrote: > >>> If it was common-place to use Curried functions and partial application in >>> Python, you'd probably prefer "f a b c" to "f(a)(b)(c)" as well. >> >> That's just the point. It isn't common to play with curried functions >> or monads or anything like that in computer science today. Yes, >> Haskell exists, and is a great experiment in how such a language could >> actually work. But at the same time, you have to have a brain the size >> of the titanic to contain all the little details about the language >> before you could write any large-scale application. > > No, not really. Haskell (and previously ML) are often used as introductory > languages in Comp.Sci. courses (at least in the UK). At least in the early 90's this was also the case in the Netherlands, at the University of Utrecht. We got Miranda/Gofer, and in a different, more advanced course Linda (Miranda for parallel machines). Also the inner workings of functional programming languages was a course. (Can't recall the name of the book that was used, but it was quite good IMO). I want to start (re)learning Haskell later this year, because I liked Miranda/Gofer a lot back then. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: Paul Rubin on 2 Feb 2010 03:18 Nobody <nobody(a)nowhere.com> writes: > 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). M. Felleisen wrote a paper trying to formalize some metric on the expressive power of programming languages. I skimmed through it for about a minute and wasn't convinced, but it apparently has gathered some respect. I want to read it more carefully sometime: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656
From: waku on 2 Feb 2010 05:21 Steven D'Aprano wrote: > On Sat, 30 Jan 2010 16:58:34 +0000, tanix wrote: [...] > > 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. for reading written code, it's surely helpful to have the code indented, though for *human* reading, the count of blanks seems rather inessential, as long as intended difference in indents is more pronounced than incidental difference between same-level lines. for writing new code, it's not necessarily that helpful to be *forced* to keep with strict indenting rules. in early development phases, code is often experimental, and parts of it may need to be blocked or unblocked as the codebase grows, and for experimentation, the need to carefully and consistently indent and de-indent large chunks of code can easily lead to a mess (blame it on the programmer, not the language, but still). yes, there are editors that help you indent chunks of code, but see below. there are languages where indentation can be either enforced and allow one to omit some syntactic nuissance like braces or begin-end clauses, or made optional, requiring other syntactic means for delimiting blocks etc. (consider f# with its #light declaration, for example.) [...] > 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. as long as you are limited to your own code, sure. but if many work on the same bit, and use different editors and indentation policies, blanks-tabs indentation issues are not unlikely. you can have blanks converted to tabs and vice versa automatically, but that's clearly a nuisance. > > > > 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. if blanks and tabs are mixed together as indentation, the setting of your ide can easily mess up the indentation, making the structure unclear. in some editors, you can have braces highlighted, so that it's even easier to see where a block ends or starts. and more advanced editors help one see the structure of the code, whereby both indentation and braces are made less important for the reader. but yes, indentation surely helps in reading the code. > > > > 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". the point here was, i think, that blanks may have no syntactic meaning, though they can still be essential at the lexical level. your example targeted the lexical level, and that's rather irrelevant to the problem of syntactically meaningful indentation discussed here. vQ
From: bartc on 2 Feb 2010 10:23 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. > 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. -- Bartc
From: Jonathan Gardner on 2 Feb 2010 16:55
On Feb 1, 6:21 pm, Nobody <nob...(a)nowhere.com> wrote: > > You don't need to know the entire language before you can use any of it > (if you did, Python would be deader than a certain parrot; Python's dark > corners are *really* dark). > I'm curious. What dark corners are you referring to? I can't think of any. Especially with the direction Python 3 is going, it seems like even the slightly dim corners are being rounded away. I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, __getattribute__, __new__ and __get__. These are the darkest corners I know of, and these are not at all dark. It takes a few paragraphs of documentation to explain all the details of each these features. I hold the entire Python language in my head, and I can still remember when my next meeting is. Compare that to something like Haskell, where you have to read entire books before you truly understand what monads are actually doing behind the scenes, and how Haskell actually interprets and runs your program, or to understand what the esoteric error messages that crop up are actually caused be. Yes, there are people that know how to do stuff in Haskell. These are really smart people, the cream of the crop, so to speak. But that doesn't make Haskell a simple language. |