What Programming Languages Should You Learn Next?

[wesley chun]

http://it.slashdot.org/it/08/03/18/1633229.shtml

it was surprising and disappointing that Python was not mentioned
*anywhere* in that article but when someone replied, it sparked a long
thread of post-discussion.

-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
http://corepython.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com

 

[Gerhard Häring]

http://it.slashdot.org/it/08/03/18/1633229.shtml

it was surprising and disappointing that Python was not mentioned
*anywhere* in that article [...]

Probably because Ruby is all hot and sexy nowadays ;-) Though it's
remarkably close to Python, apparently. So close that I couldn't be
bothered to learn it.

In fact, for me personally, Python was about the last programming
language I learnt out of intrinsic motivation. I tried to take a look at
functional langugages like Haskell and Erlang, but I tend to quickly get
bored of toy examples and can learn best if I can apply a new language
to a real problem that it can solve better than the other languages I
know. Haven't found that killer problem so far ...

-- Gerhard

 

[Paul Rubin]

Probably because Ruby is all hot and sexy nowadays ;-) Though it's
remarkably close to Python, apparently. So close that I couldn't be
bothered to learn it.

Ruby is apparently more Smalltalk-like and some consider it cleaner
than Python. Like you, I figure it's close enough to Python that
I haven't bothered with it.

In fact, for me personally, Python was about the last programming
language I learnt out of intrinsic motivation. I tried to take a look
at functional langugages like Haskell and Erlang, but I tend to
quickly get bored of toy examples and can learn best if I can apply a
new language to a real problem that it can solve better than the other
languages I know. Haven't found that killer problem so far ...

The killer problem for Erlang is highly concurrent, distributed
systems. I've been wanting to read Joe Armstrong's book about it
since I have some interest in that sort of thing. It's not simply the
ability to run vast numbers of threads and automatically marshal data
between them (even if they're on separate computers), but also its
convenient management of software faults through "supervision trees".
In most languages we normally program our functions to notice error
conditions and recover from them, raise exceptions that are handled
elsewhere in the app, etc. In Erlang you just let the thread crash,
and have the supervision system deal with restarting it, logging the
error, etc. This separation of concerns apparently helps reliability
of nonstop services like phone switches considerably. Also, Erlang
has hot-patching facilities so you can upgrade your program while it's
running, with 10,000 active network connections staying up and nobody
outside noticing that anything has changed.

Re Haskell: I've been spending a lot of time on Haskell recently,
though I haven't done anything nontrivial with it yet (just some small
stuff). But I think it's better for complex program development than
Python is, and even small Haskell programs, (while they are more
difficult to write, at least at my present level of experience) seem
both cleaner and more solid in terms of confidence of correctness than
the corresponding Python programs. Also, Haskell code runs a lot
faster than Python code (real native-code compiler that can use
multicore hardware), and there is a clever automatic unit testing
system (QuickCheck) that relies on Haskell's static type system to
generate random tests automatically. On the other hand, Python's
standard libraries do more stuff and are better packaged. It's
certainly easier to do lightweight internet scripting in Python. If I
were writing something like a compiler, I'd probably use Haskell.

 

[Torsten Bronger]

Hallöchen!

http://it.slashdot.org/it/08/03/18/1633229.shtml

it was surprising and disappointing that Python was not mentioned
*anywhere* in that article but when someone replied, it sparked a
long thread of post-discussion.

Well, not because I like Python so much, but I find this blog entry
highly unoriginal. Browsing through Wikipedia gives more
insight ...

Tschö,
Torsten.

 

[Torsten Bronger]

Hallöchen!

[...]

Re Haskell: I've been spending a lot of time on Haskell recently,
though I haven't done anything nontrivial with it yet (just some
small stuff). But I think it's better for complex program
development than Python is,

Could you elaborate on this? (Sincere question; I have almost no
idea of Haskell.)

Tschö,
Torsten.

 

[Paul Rubin]

Could you elaborate on this? (Sincere question; I have almost no
idea of Haskell.)

http://wiki.python.org/moin/PythonVsHaskell is a fairly high-level
comparison.

I think it's easier to write complex code in Haskell because:

1) it has a powerful static type system that lets you express
important invariants and have them enforced at compile time. This not
only catches errors but helps you understand the program logic almost
like running the code under a debugger does. If you try to fill a gap
by putting in a piece of the wrong shape, it just won't fit and the
compiler will tell you what you really wanted. On the other hand,
most types are inferred by the compiler, so you don't need a lot of
cumbersome declarations like in Java.

2) The basic list type in Haskell works something like Python
iterators, but they don't change state when you consume an item. In
fact all Haskell data is immutable. You avoid vast classes of bugs
this way. But you do have to change the way you think about
programming.

I may write a longer comparison post sometime later.

 

[Sean Allen]

Haven't found that killer problem so far ...

for Haskell, check out HAppS. They have
some great web application stuff going on.

 

[sturlamolden]

Could you elaborate on this? (Sincere question; I have almost no
idea of Haskell.)

If you already know Python, you will find Whitespace just as useful as
Haskell.

 

[Donn Cave]

....

I think it's easier to write complex code in Haskell because:

1) it has a powerful static type system that lets you express
important invariants and have them enforced at compile time. This not
only catches errors but helps you understand the program logic almost
like running the code under a debugger does. If you try to fill a gap
by putting in a piece of the wrong shape, it just won't fit and the
compiler will tell you what you really wanted. On the other hand,
most types are inferred by the compiler, so you don't need a lot of
cumbersome declarations like in Java.

Worth repeating.

One of the perhaps surprising consequences, Haskell code can
be very easy to modify. I've been fooling around with computer
programs for a couple decades, and I'm just getting used to the
idea that I can casually rewrite Haskell code and get the compiler
to find what I missed. I have come to feel that the indiscipline
of dynamic typing in languages like Python leads to an intuitively
surprising rigidity. Ten years ago I would cheerfully accept this,
given the meager and clumsy support for static typing in languages
like C++, but today, it makes me appreciate Haskell's potential
for complex projects.

Donn Cave, (e-mail address removed)

 

[Reedick, Andrew]

-----Original Message-----

From: [email protected] [mailtoython-
[email protected]] On Behalf Of Donn Cave
Sent: Thursday, March 20, 2008 3:39 PM
To: (e-mail address removed)
Subject: Re: What Programming Languages Should You Learn Next?


Worth repeating.

One of the perhaps surprising consequences, Haskell code can
be very easy to modify. I've been fooling around with computer
programs for a couple decades, and I'm just getting used to the
idea that I can casually rewrite Haskell code and get the compiler
to find what I missed. I have come to feel that the indiscipline
of dynamic typing in languages like Python leads to an intuitively
surprising rigidity. Ten years ago I would cheerfully accept this,
given the meager and clumsy support for static typing in languages
like C++, but today, it makes me appreciate Haskell's potential
for complex projects.

Haskell does look interesting (especially in light of that one summer
job way back when doing a _lot_ of Lotus-123 spreadsheet programming.)
There's a Haskell wiki: http://www.haskell.org/


Quicksort in Haskell versus C is amazing:
http://www.haskell.org/haskellwiki/Introduction#What.27s_good_about_func
tional_programming.3F

Quicksort in Python inspired by Haskell's quicksort:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66473



*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

 

[Terry Reedy]

| Quicksort in Haskell versus C is amazing:
|
http://www.haskell.org/haskellwiki/Introduction#What.27s_good_about_functional_programming.3F

Sorry, bogus comparison, and not so amazing.

1.The short doubly recursive definition of qsort has nothing to do with
Haskell.

2. The Haskell code refers to an external function 'filter'. The C code
inlines the filter code.
If that is shoved to an external function, we get this 'amazing' (but
untested ;-) C code:

void qsort(int a[], int lo, int hi) {
int l;
if (lo < hi) {
ll = partition(a, lo, hi);
qsort( a, lo, ll-1 );
qsort( a, ll+1, hi );
}
}

The is a fair comparision, and it looks nearly as good as the Haskell code.
This can also be written as a one-liner if one finds such to be more
'amazing'.
The C code does not even need code for the base case. Amazing!

3. The Haskell code makes two scans of the array (one for each filter)
instead of just one and makes a copy of the array (minus the pivot) in two
pieces. instead of none Whether the 'slice' 'xs' makes a copy or is just a
view I don't know. Then it does more allocations and copies to put the
separated pieces back together. The C code does the filtering in place.
Hence no need to concatenate the sorted pieces. Of course that looks more
complex -- because it is -- unless hidden away in the
double-filter-in-place partition function. So Haskell trades textual
terseness for computation space and, probably, time.

Python makes the same trade-off, and I like it and use it for that reason.
One can certainly like Haskell for that reason too, but it is a trade-off.
What would be amazing would be a algorithm that could rewrite the
external-arrays Haskell/Python code to the equivalent of the in-place C
code. Can one even write such an equivalent in Haskell? (If it is purely
functional, then no, though one obviously can in Python.)

For efficiency, standard C qsort code turns the second (tail) recursive
call into a loop. A Python version of the same could easily eliminate the
first recursive call with an explicit stack. Again, less elegant code for
more speed.

| Quicksort in Python inspired by Haskell's quicksort:
| http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66473

The list slicing could be done once instead of twice.

Terry Jan Reedy

 

[Paul Rubin]

What would be amazing would be a algorithm that could rewrite the
external-arrays Haskell/Python code to the equivalent of the in-place C
code.

I don't think JHC (a fancy optimizing Haskell compiler) goes quite
that far, but it compiles Haskell to C code that looks pretty much
the same as imperative code that a careful programmer would write.

Can one even write such an equivalent in Haskell? (If it is purely
functional, then no, though one obviously can in Python.)

Yes, you can write in an imperative styld while staying purely
functional. The trick is to notice that
b = f(a)
c = g(b)
d = h(c)
...
requires evaluating f,g,h in exactly that order. So you can
write sequential code as a bunch of nested function calls that
the compiler optimizes away. Haskell has syntactic support
for this, so the code you'd write looks somewhat C-like:

do {
b <- f a;
c <- g b;
d <- h c
}

but it is actually even cooler than that (complicated to explain so I
won't try here). The result is that you really insist, you can code
an imperative quicksort that looks about the same as the C one and
compiles to about the same machine code, but is fully typesafe and
polymorphic.

 

[Bryan Olson]

http://it.slashdot.org/it/08/03/18/1633229.shtml

it was surprising and disappointing that Python was not mentioned
*anywhere* in that article but when someone replied, it sparked a long
thread of post-discussion.

What I found disappointing was how many people thought they
should be answering the question rather than asking it.

I'm good with a number of popular languages, and I can talk
knowledgeably and BS-free about many more. In grad school,
I had an instructor who is a real programming language
expert. Listening to his lectures was sometimes a bit like
watching ESPN show the world championship of a game at
which I usually beat my friends. There are levels beyond
levels beyond my level. And I'm a pro.


It is to the shame of my alma mater that they denied
tenure to Dr. Sasaki.