From: John Bokma on
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
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
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
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
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.