Re^3: Why do people say 'Perl' is dead?!?!

[BrowserUk]

what language-monstrosity is that?!?!

Haskell.

And if you follow the thread forward a couple of posts, you encounter a seemingly innocent question: "and what if you want to concatenate three pieces?"

The most telling story is that in the year since it was asked, no one has attempted to answer that; never mind the follow-ons: four pieces; five pieces; ...

[sundialsvc4]

Gack.

There are definitely what I call “proof-of-concept” (POC, a.k.a. PITA) languages, which are designed by academics for academics (or for military contracts).   They trust the computer so much, and the programmer so little, that an actual programmer can’t actually do a damn thing with it.   :-)   And then there are the handful “war-horse” languages such as Perl (and, in its own world, COBOL) that can be relied upon to ride into battle with you and to bring you out both victorious and alive.

As I have related before, I have also watched a very famous company that should have known better dive into a Ruby project to replace a Perl project ... only to discover, not only that they were “merely re-implementing something that already worked,” but that the replacement didn’t work because the actual implemented state of the Ruby libraries they were relying on were not as thoroughly implemented as those they were conditioned to rely-upon in Perl.   The entire project turned into a death march.   A pragmatic language implementation, I think, lives-or-dies more based on its available library base than by the properties of the language itself.

[cavac]

And then there are the handful “war-horse” languages such as Perl (and, in its own world, COBOL) that can be relied upon to ride into battle with you and to bring you out both victorious and alive.

Actually, shouldn't that be "to ride into battle for you"? Thats how Perl works, isn't it? You have to show it how a access the battle plan and the battle field, set the option if you want to win or loose and have that whole thing automated in no time. And you'd probably find most of the stuff you need already on CPAN, so you would only have to write some basic glue logic anyway...

[Jenda]

The best thing is that the whole idea of a "safe string" with a single "quoting" is ... erm ... nonsense.

I mean what makes string "safe" to insert into "INSERT INTO Foo VALUES ('$here') is totally different than what makes it safe to insert into <input ... value="$here"/> or <span onclick="alert('$here')">..., or "open my $IN, $here or die;</c> etc. etc. etc.

It makes sense to mark something "unsafe" (aka. tainted = coming from an non-trusted source), but what makes it safe differs.

OTOH, try to implement something similar (without the use of the builtin tainting!) in Perl. It's also gonna take a bit of code to overload all string operators to work for the String::Safe and String::Unsafe.

[BrowserUk]

It makes sense to mark something "unsafe" (aka. tainted = coming from an non-trusted source), but what makes it safe differs.

The Haskell concept of 'Unsafe' is quite different from tainting. And it is quite complex to explain.

In part it is to do with substitutability. A Haskell compiler uses term rewriting to 'reduce' programs at compile time. So, in the same way that a C compiler might substitute the number 86400 in place of the source code calculation 24*60*60, the Haskell compiler can and will calculate the result of whole complex functions and substitute the result everywhere that function is called; and do this recursively until -- in effect -- the entire result of the program has been calculated at compile time and the resultant program is nothing more than a single constant or set of constants.

It can do this because in Haskell, functions are "pure". That is, they will always produce the same result for a given set of inputs and they don't have side-effects. Because of the lack of side-effects, the compiler is free to reorder the entire program in whatever way it sees fit. And because of the determinacy of purity, the entire program can be reduced at compile time.

Of course, "constant" programs aren't very useful. To be useful, a program has to accept data from external sources, and return results to the outside world based upon those inputs. And there immediately you've had to introduce impurity into the system.

You cannot completely reduce functions, even pure functions, at compile time, if you don't know what its argument values will be until runtime; you also cannot reorder the program to produce its outputs prior to obtaining its inputs; and both those operations -- input & output -- have side-effects. Input (for example) may move a file-pointer; therefore the input function if called again with the same values will return different results; it is therefore impure -- and "Unsafe". Ditto, writing output to disk or screen, changes that output medium in some way, and if the output function is called again with the same arguments, it has a different affect on the outside world. Therefore impure and unsafe.

Essentially, any data that isn't hard-coded into the source of the program is unsafe.

But it goes further than that. To append an externally derived integer to an internal (hard-coded and therefore safe) string effectively means that the result has to become unsafe. In effect it has to change its type. And changing the type of something is an anathema to type-safety theory. So then you have to introduce weird and obscure theorems -- the Monad -- to the process of allowing the pure and impure -- safe and unsafe -- to interact within a program, so as not to violate the provability of the programs produced.

And it is at that point that things start to get complicated. Programming start to become less about solving real-world problems and more about satisfying obscure and mostly irrelevant theorems -- that maybe a few dozen people in the world really understand, though many more pretend to. Whilst there is some evidence that the splitting of programs into two distinct sets of operations -- those that can be resolved at compiler time and those that cannot, can allow for "elegant" source code to result in efficient and safe runtime code; the Haskell means of arriving there results in a language that is out of reach -- intellectually -- from your average programmer.

The means has become and end unto itself.

But Haskell is not alone in this. Theoretically nice-to-have, monocultures are beginning to crop up in languages all over. Whether it is const correctness in C++; type-safety in Java; a rejection of exceptions in GO; or Only-OO in Perl. Theory is overtaking pragmatism at a time when the cost of development practices are under increasing scrutiny, placing unproven theoretical goals ahead of getting the job done is very short sighted.

[Jenda]

So all this is supposed to be another way to interface the purely functional stuff with the rest of the world without the use of monads? Do you have any links to a longer explanation? It's been years since I did work with a purely functional language and it was (Concurrent) Clean which takes a wholly different approach to IO in a purely functional language, but I'd still like to learn more.