Slashdot Mirror

Truth be told, there are details in it that I don't understand (I only know enough PERL to get by), but its author does a fair job of explaining it. My preferred flavour of line noise is <? echo "guess"; ?>

Mark Jason Dominus demonstrated this some time ago....When Hashes go wrong. Also interesting that the exploit he posted for perl also uses 10,000 inputs to demonstrate the problem.

(Re: OCaml typing, this talk gives a nice, accessible overview of typing in ML (OCaml is a dialect of ML). The way it works, in short, is that the compiler infers all the types at compile time.)

In principle the "level" of any language is not bound of course, because after all, you can do any computation in any real language. But I do think each langauge has its sweet spot. So I do think C++'s level is bound. It may be multiparadigm, but that's really just two paradigms: Structured and OO. It doesn't include the Functional paradigm in any complete or pleasant way. And Functional Programming is the most powerful of them all. IMO that is; others may disagree.

OCaml is functional at its heart, but includes all three paradigms. (I know I keep banging on about OCaml, but it's my favorite language at the moment.) Oh, and it's fast too.

C++ doesn't have built-in garbage collection. I do think garbage collection is desirable in all but a few cases (those cases would be when you have tight timing requirements or when you need to run efficiently in small memories). So that's another thing that limits its level.

I feel the same way as you about Java. It always seemed a little half assed to me. But its cross-platformedness is definitely very nice assuming the users have downloaded the 8MB or whatever of runtime.

Ruby looks good. I'll have to take a close look at it some time. In the meantime, I'm pretty happy with Python as my scripting language of choice. It's a pretty decent language and has good library support.

But this is still a leaky abstraction:

• if you put a huge file or even line into a variable in memory, there's a cost. Performance could suffer or it could just not run at all. [*]
• making string concatenation (for example) so easy may lead you to do more than is necessary and more than would be ideal from a performance perspective. Certainly with high-level stuff, it's harder to see the cost of a single line of code.
• similarly, if you aren't careful, you could end up with a regular expression that is NP-complete and therefore slow.

But it's still a useful one because these things are smaller/less common problems than the ones in C that you mentioned.

I think Joel is right - the really good programmers are the ones who understand the system at all levels. That's something I strive for personally, since I don't anticipate that ever changing.

But at the same time, many of the specific leaky abstractions he mentioned can be plugged. The C++ one, certainly - it really only is like that because of backward compatibility. Java has no such problem. The SQL one, maybe not - but even when I have to mess with the query planner, it's less work than having to do everything myself.

And as a general rule, I think our abstractions have lowered the entrance barrier to programming, increased the scale an expert can work on, and increased the speed at which an expert can do things. From the article, I don't think he disagrees. He just pointed out that they can be dangerous, which is definitely true.

[*] - Perl 6 will support streaming regular expressions, so in one way this is less of a problem, or at least can be sidestepped. But still you might not know that and put it into a variable first, you might put large chunks of the results of the regexp into a variable, or you might make regexps that backtrack...so the leak is still there, just smaller.

Dominus gave a hilarious and insightful talk at YAPC 2002 about Design Patterns, titled, Design Patterns Aren't.

ML is actually a great example of strong typing: Strong Typing and Perl (Strong Typing Doesn't Have to Suck)

Propoganda
Design Patterns in Dynamic Programming
"Design Patterns" Aren't (google cache link)

Well, maybe they thought about it. But if they only implement a (non-trivial) subset of regexp search I will admire them even more.
Regexp are horrible from a complexity point of view.
According to this link regepx's complexity is of O(M*N), where M unfortunately is in the order of Googles DB, if my short calculation is correct. Note, this may be wrong, but the point stays that regexp searching is quite expensive and kills most of the optimizations you could do if you didn't want to provide them.

I know what you mean, since I've picked up a lot of theory in similar ways over the years. Along those lines, Lambda the Ultimate is a good place to get pointers to a variety of current research. It's worth getting at least some of the theory closer to its source. Have you read SICP, for example? That was one of the books that got me back into theory after many years out of CS at university (the CS I did was pretty lame - mainly learnt Pascal, very little real CS theory).

If you're into that sort of thing, though, SICP is just a gateway drug. Lambda calculus, type inferencing, type theory in general, and much, much more follows, and pretty soon all the mainstream languages are looking pretty pale... It all does give some good criteria by which to compare languages, though, and helps avoid being limited in one's thinking by the language one happens to be using.

BTW, I agree about not teaching closures in Perl to newbies. Perl and Python both have enough hardcoded ways to do things that you don't need to rely on closures, except to be perverse. The more important concept for useful programming is higher-order functions, since they provide a capability that's directly useful in Perl (or any language), and closures can be introduced in that context.

You've probably come across this before, but here's a nice piece about ML's type system from a partly Perl perspective.

I know what you mean, since I've picked up a lot of theory in similar ways over the years. Along those lines, Lambda the Ultimate is a good place to get pointers to a variety of current research. It's worth getting at least some of the theory closer to its source. Have you read SICP, for example? That was one of the books that got me back into theory after many years out of CS at university (the CS I did was pretty lame - mainly learnt Pascal, very little real CS theory).

If you're into that sort of thing, though, SICP is just a gateway drug. Lambda calculus, type inferencing, type theory in general, and much, much more follows, and pretty soon all the mainstream languages are looking pretty pale... It all does give some good criteria by which to compare languages, though, and helps avoid being limited in one's thinking by the language one happens to be using.

BTW, I agree about not teaching closures in Perl to newbies. Perl and Python both have enough hardcoded ways to do things that you don't need to rely on closures, except to be perverse. The more important concept for useful programming is higher-order functions, since they provide a capability that's directly useful in Perl (or any language), and closures can be introduced in that context.

You've probably come across this before, but here's a nice piece about ML's type system from a partly Perl perspective.

I'm also toying with a proposal for Testing Perl, though it may be more of a niche market than Software Development with Perl or Extreme Perl. Maybe not.

Maybe you ought to read Perl Contains the Lambda-Calculus by Mark-Jason Dominus. Here's a teaser:

Unlike most popular programming languages, Perl is powerful enough to express the lambda-calculus directly, without the need to write a simulator. This means that if you want to try programming in the lambda-calculus, you can do it directly in Perl, without having to implement a program to parse and evaluate lambda-calculus expressions first. Perl's parser will parse lambda-expresisons, if you write them properly, and its evaluator will evaluate them.

Maybe you ought to read Perl Contains the Lambda-Calculus by Mark-Jason Dominus. Here's a teaser:

Unlike most popular programming languages, Perl is powerful enough to express the lambda-calculus directly, without the need to write a simulator. This means that if you want to try programming in the lambda-calculus, you can do it directly in Perl, without having to implement a program to parse and evaluate lambda-calculus expressions first. Perl's parser will parse lambda-expresisons, if you write them properly, and its evaluator will evaluate them.

Many geeks (including Perl geek Mark-Jason Dominus) are still boycotting Amazon because of their software patents.

The mess above is known as japh.pl. Here's an explanation of it.

Perl:
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*= 2) +=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[ P.]/&&
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print

Explanation

Many "... for dummies" books may be fine but this review of Perl for Dummies made me suspicious of the whole series.

No, Perl has too many capabilities to be considered a purely functional language, however it does have first-class functions, so any program that can be created in more than one functional language (say Lisp and ML) can also be created in Perl:

http://perl.plover.com/lambda/

Now hold on a second... i learned O'Caml in an intro course also, and yeah, it was pretty annoying at the time, but since then, i've looked into it independently, and it really does seem like quite a nice language. Incidentally, Doug Bagley's Shootout was one of the first pieces of evidence i found that O'Caml is actually a language you can get real work done in. Aside from that, i emailed one of my professors and got his opinions on the language. He said that unless he's writing driver code, or something similarly low-level, it's his language of choice, adding that it's a shame industry is so harsh to newer languages.

Ok, about O'caml [O'caml = Objective Caml = a variant of ML with objects]. I had to use it for a PL class last semester. It's kind of nice, but don't expect it to be in any way like any language you've ever used (unless you know some other ML variant, of course).

This is true -- it's unlike anything you've ever used before. But that's not a bad thing, necessarily! This is a different way of thinking about programming, and many people feel it's better than the traditional procedural models.

In many ways it's very nice. In other ways it will drive you absolutely insane. For example, O'caml has very strong typing rules (which are good). It has almost no diagnostics when it decides it doesn't like your code (which is very very bad). It also apperantly sometimes gets very confused. For example, sometimes you'll get something like this:

Almost no diagnostics? Did you use the debugger? ocamldebug has many features of gdb, supposedly. Although i'll admit i have little experience with it, from what i've seen, it provides a comprehensive debugging environment.

Granted, the interactive interpreter has few debugging features, but it's not really meant for debugging large chunks of code -- that's why they have a debugger :)

foo.ml, line 100, chars 16-30: this expression has type int, but is used here with type int

This can be a little maddening after a few hours.

This happens when you write screwy code -- the types may have the same name, but they aren't the same underneath. That's another thing you have to look out for -- things don't change, they just get new environments. This is what functional programming is all about, and why it's much better for certain tasks (like things where you have to step back, or undo -- think web browser, text editor...). Incidentally, i doubt it happens with built-in types like int...

Other annoyances: no function overloading. So to print a string, use print_string. To print an int, use print_int. And so on. This is just how it works (I think you can write a wrapper which will check the type and dispatch the right call, but that's fairly irritating in and of itself).

No function overloading equates to good type-checking. If you allow functions or operators to be overloaded, you compromise the type inference system, which is one of the nicest features of O'Caml. (Besides, you can do things like print_string "n = " ^ (string_of_int n). You just have to be a bit more cognizant of what you're passing around...)

mjd (of perl fame) actually gave a nice talk on why strong typing is so cool -- ML's type system was able to prevent an infinite loop bug! The anecdote starts at slide 27, though for full effect, i'd recommend you read the entire talk

Another thing that irritates me (probably just because I'm from a C/C++/Perl background), is that sometimes you use no ';' to end a statement, sometimes one, sometimes a pair.

You only use a single semi-colon when you want to throw away the return-value of an expression -- it's an imperative feature. That's what's so cool about O'Caml: it doesn't tie you down to any one paradigm, but rather it supports them all -- functional, imperative, object-oriented, ...

And the double semi is for when the compiler can't tell you've started a new statement. It actually makes quite a bit of sense once you understand the reasoning behind it.

Also, I found the documentation to be very erratic (the modules docs are quite complete, but try finding simple examples of how to do OO, without reading the BNF grammar they put in the docs - that's no way to learn a language).

Unfortunately, i'm inclined to agree with you here. Their documentation is very erudite, and difficult to comprehend. And regrettably, there are almost no good books on the language. (My professor pointed me to The Functional Approach to Programming, by Couisneau and Mauny, but it's more of a textbook, and doesn't cover the object-oriented features of the language.) Presumably this is due to the fact that big businesses don't recognize O'Caml by name (case in point: how many good C books are there? what about LISP?).

Nice stuff: strong typing, cool type matching stuff, bytecode and native compilers, seems like a decent module system.

Regarding the module system, i don't have enough experience to say anything intelligent about it myself, but all my professors are in love with it. They say it's more advanced than anything available, even in Java (the other language they teach us).

But if you don't already know it, good luck. You'll need it.

You make it sound so painful! :) On the contrary, i think any geek who gives it a whirl will find it refreshing and mind-expanding. <strike>Like LSD!<strike>

majiCk

Now hold on a second... i learned O'Caml in an intro course also, and yeah, it was pretty annoying at the time, but since then, i've looked into it independently, and it really does seem like quite a nice language. Incidentally, Doug Bagley's Shootout was one of the first pieces of evidence i found that O'Caml is actually a language you can get real work done in. Aside from that, i emailed one of my professors and got his opinions on the language. He said that unless he's writing driver code, or something similarly low-level, it's his language of choice, adding that it's a shame industry is so harsh to newer languages.

Ok, about O'caml [O'caml = Objective Caml = a variant of ML with objects]. I had to use it for a PL class last semester. It's kind of nice, but don't expect it to be in any way like any language you've ever used (unless you know some other ML variant, of course).

This is true -- it's unlike anything you've ever used before. But that's not a bad thing, necessarily! This is a different way of thinking about programming, and many people feel it's better than the traditional procedural models.

In many ways it's very nice. In other ways it will drive you absolutely insane. For example, O'caml has very strong typing rules (which are good). It has almost no diagnostics when it decides it doesn't like your code (which is very very bad). It also apperantly sometimes gets very confused. For example, sometimes you'll get something like this:

Almost no diagnostics? Did you use the debugger? ocamldebug has many features of gdb, supposedly. Although i'll admit i have little experience with it, from what i've seen, it provides a comprehensive debugging environment.

Granted, the interactive interpreter has few debugging features, but it's not really meant for debugging large chunks of code -- that's why they have a debugger :)

foo.ml, line 100, chars 16-30: this expression has type int, but is used here with type int

This can be a little maddening after a few hours.

This happens when you write screwy code -- the types may have the same name, but they aren't the same underneath. That's another thing you have to look out for -- things don't change, they just get new environments. This is what functional programming is all about, and why it's much better for certain tasks (like things where you have to step back, or undo -- think web browser, text editor...). Incidentally, i doubt it happens with built-in types like int...

Other annoyances: no function overloading. So to print a string, use print_string. To print an int, use print_int. And so on. This is just how it works (I think you can write a wrapper which will check the type and dispatch the right call, but that's fairly irritating in and of itself).

No function overloading equates to good type-checking. If you allow functions or operators to be overloaded, you compromise the type inference system, which is one of the nicest features of O'Caml. (Besides, you can do things like print_string "n = " ^ (string_of_int n). You just have to be a bit more cognizant of what you're passing around...)

mjd (of perl fame) actually gave a nice talk on why strong typing is so cool -- ML's type system was able to prevent an infinite loop bug! The anecdote starts at slide 27, though for full effect, i'd recommend you read the entire talk

Another thing that irritates me (probably just because I'm from a C/C++/Perl background), is that sometimes you use no ';' to end a statement, sometimes one, sometimes a pair.

You only use a single semi-colon when you want to throw away the return-value of an expression -- it's an imperative feature. That's what's so cool about O'Caml: it doesn't tie you down to any one paradigm, but rather it supports them all -- functional, imperative, object-oriented, ...

And the double semi is for when the compiler can't tell you've started a new statement. It actually makes quite a bit of sense once you understand the reasoning behind it.

Also, I found the documentation to be very erratic (the modules docs are quite complete, but try finding simple examples of how to do OO, without reading the BNF grammar they put in the docs - that's no way to learn a language).

Unfortunately, i'm inclined to agree with you here. Their documentation is very erudite, and difficult to comprehend. And regrettably, there are almost no good books on the language. (My professor pointed me to The Functional Approach to Programming, by Couisneau and Mauny, but it's more of a textbook, and doesn't cover the object-oriented features of the language.) Presumably this is due to the fact that big businesses don't recognize O'Caml by name (case in point: how many good C books are there? what about LISP?).

Nice stuff: strong typing, cool type matching stuff, bytecode and native compilers, seems like a decent module system.

Regarding the module system, i don't have enough experience to say anything intelligent about it myself, but all my professors are in love with it. They say it's more advanced than anything available, even in Java (the other language they teach us).

But if you don't already know it, good luck. You'll need it.

You make it sound so painful! :) On the contrary, i think any geek who gives it a whirl will find it refreshing and mind-expanding. <strike>Like LSD!<strike>

majiCk

Now hold on a second... i learned O'Caml in an intro course also, and yeah, it was pretty annoying at the time, but since then, i've looked into it independently, and it really does seem like quite a nice language. Incidentally, Doug Bagley's Shootout was one of the first pieces of evidence i found that O'Caml is actually a language you can get real work done in. Aside from that, i emailed one of my professors and got his opinions on the language. He said that unless he's writing driver code, or something similarly low-level, it's his language of choice, adding that it's a shame industry is so harsh to newer languages.

Ok, about O'caml [O'caml = Objective Caml = a variant of ML with objects]. I had to use it for a PL class last semester. It's kind of nice, but don't expect it to be in any way like any language you've ever used (unless you know some other ML variant, of course).

This is true -- it's unlike anything you've ever used before. But that's not a bad thing, necessarily! This is a different way of thinking about programming, and many people feel it's better than the traditional procedural models.

In many ways it's very nice. In other ways it will drive you absolutely insane. For example, O'caml has very strong typing rules (which are good). It has almost no diagnostics when it decides it doesn't like your code (which is very very bad). It also apperantly sometimes gets very confused. For example, sometimes you'll get something like this:

Almost no diagnostics? Did you use the debugger? ocamldebug has many features of gdb, supposedly. Although i'll admit i have little experience with it, from what i've seen, it provides a comprehensive debugging environment.

Granted, the interactive interpreter has few debugging features, but it's not really meant for debugging large chunks of code -- that's why they have a debugger :)

foo.ml, line 100, chars 16-30: this expression has type int, but is used here with type int

This can be a little maddening after a few hours.

This happens when you write screwy code -- the types may have the same name, but they aren't the same underneath. That's another thing you have to look out for -- things don't change, they just get new environments. This is what functional programming is all about, and why it's much better for certain tasks (like things where you have to step back, or undo -- think web browser, text editor...). Incidentally, i doubt it happens with built-in types like int...

Other annoyances: no function overloading. So to print a string, use print_string. To print an int, use print_int. And so on. This is just how it works (I think you can write a wrapper which will check the type and dispatch the right call, but that's fairly irritating in and of itself).

No function overloading equates to good type-checking. If you allow functions or operators to be overloaded, you compromise the type inference system, which is one of the nicest features of O'Caml. (Besides, you can do things like print_string "n = " ^ (string_of_int n). You just have to be a bit more cognizant of what you're passing around...)

mjd (of perl fame) actually gave a nice talk on why strong typing is so cool -- ML's type system was able to prevent an infinite loop bug! The anecdote starts at slide 27, though for full effect, i'd recommend you read the entire talk

Another thing that irritates me (probably just because I'm from a C/C++/Perl background), is that sometimes you use no ';' to end a statement, sometimes one, sometimes a pair.

You only use a single semi-colon when you want to throw away the return-value of an expression -- it's an imperative feature. That's what's so cool about O'Caml: it doesn't tie you down to any one paradigm, but rather it supports them all -- functional, imperative, object-oriented, ...

And the double semi is for when the compiler can't tell you've started a new statement. It actually makes quite a bit of sense once you understand the reasoning behind it.

Also, I found the documentation to be very erratic (the modules docs are quite complete, but try finding simple examples of how to do OO, without reading the BNF grammar they put in the docs - that's no way to learn a language).

Unfortunately, i'm inclined to agree with you here. Their documentation is very erudite, and difficult to comprehend. And regrettably, there are almost no good books on the language. (My professor pointed me to The Functional Approach to Programming, by Couisneau and Mauny, but it's more of a textbook, and doesn't cover the object-oriented features of the language.) Presumably this is due to the fact that big businesses don't recognize O'Caml by name (case in point: how many good C books are there? what about LISP?).

Nice stuff: strong typing, cool type matching stuff, bytecode and native compilers, seems like a decent module system.

Regarding the module system, i don't have enough experience to say anything intelligent about it myself, but all my professors are in love with it. They say it's more advanced than anything available, even in Java (the other language they teach us).

But if you don't already know it, good luck. You'll need it.

You make it sound so painful! :) On the contrary, i think any geek who gives it a whirl will find it refreshing and mind-expanding. <strike>Like LSD!<strike>

majiCk

But "use strict" doesn't force the programmer to declare types, it just requires the programmer to declare variables. The variables remain varients with implicit type conversions. For a description of strongly typed languages without explicit type conversions (and how it contrasts to Perl) take a look at Strong Typing

Why shouldn't one of the primitive types of a language be that of an address ?

Pointers also prevent a lot of compiler optimizations due to aliasing issues. I'd rather have a highly optimizing compiler that knows how to do all the neat pointer tricks rather than one that is kept intentionally dumb because it can't tell when I'm doing neat pointer tricks. (Of course I'd also like more communication between the compiler and the linker so that virtual methods could be converted to static if not overriden.)

Literate programming was invented around 1983 by the very famous Donald Knuth, author of the TeX typesetting system and the multi-volume series The Art of Computer Programming. It is based on two important ideas.

The first idea is that good program documentation shouldn't be squeezed into little `comments'. It should be structured more like a technical article for a journal, and it should have all the support that a journal article usually gets, including good typesetting. The programmer should have the opportunity to annotate each section of the code with as much explanation as is necessary and appropriate.

Literate programming is so interesting because the documented parts of the program do not have to be in the same order as the program itself. Code can be written in whatever order is best for people to understand, and re-ordered automatically when the compiler needs to run the program.

Documentation can be typeset automatically using tools to extract the literate comments from the code. For more information on this, see:

• Knuth's original paper on literate programming
• Literate programming in C
• Litearteprogramming.com
• POD is not Literate Programming

No problem - I was just as glad to find these when I first did. BTW, when on the perl.com page, you should find MJD's name, and click on it to see a list of the other articles he's written for perl.com. It will make you a better perl hacker.

Also, see his personal web site at www.plover.com in the perl stuff section. He has some good articles on the way regex's really work (NFA's) and other things.

He's a good writer, and I haven't found anything he wrote on perl that I didn't like. (There were a few things though that didn't apply to me or were a bit too basic intended for beginners)

I'd trust what Mark-Jason Dominus said or what Tom Christiansen said about the Perl for Dummies book.

I haven't looked at it yet, but I've heard good things about Elements of Programming with Perl. I've also been told that MacPerl: Power and Ease does a good job of teaching perl programming as well as teaching the MacOS specific areas of MacPerl.

and an article with a good exposition. Bricolage . . . fine word for this eulogy.

Perl's expressions are far from regular. They are NP-Complete.
--
Man is most nearly himself when he achieves the seriousness of a child at play.