We think about extensibility a lot. We think about languages we don't know how to think about yet. But leaving spaces in the grammar for new languages is kind of like reserving some of our land for national parks and national forests. Or like an archaeologist not digging up half the archaeological site because we know our descendants will have even better analytical tools than we have.
This quote, and what little I've sampled of Perl 6, reminds me of a few lines from the movie Wonder Boys:
Grady, you know how in class you're always telling us that writers make choices? [...] And even though your book is really beautiful, I mean, amazingly beautiful, it's... it's at times... it's... very detailed. You know, with the genealogies of everyone's horses, and the dental records, and so on. And... I could be wrong, but it sort of reads in places like you didn't make any choices. At all.
wherein Larry Wall foresees the future: "I think when the new JavaScript engines come out we'll probably see renewed interest in a JavaScript backend." - December 6, 2007.
Kids learning about computers have a slightly different set of problems to solve than programmers being paid to program. The hard part of programming is integrating with the real world; DrScheme solves that problem by making its own world.
Do you have in mind a particular integration with the real world that is language-specific, but where DrScheme would not help a professional programmer ramp up familiarity with a Schemey way of doing it?
I think I disagree with you, but have to understand what you're arguing to be sure.
Nope, I'm being more general. Throw darts at random programming ads. Take that job. Chances are, it will be something like "move QUUX formatted records from BAZ mainframe to new Oracle Windows Java 7.0 Lightweight Enterprise Server", rather than "start completely anew to help elementary school students learn calculus". Things like ad-hoc record parsing and network connectivity and the ability to easily fork() end up being more important than a clean OO system or a nice UI library, and so on. (Not that they are mutually exclusive... but it's likely that Oracle Windows Java 7.0 Enterprise Server has drivers for Java but not DrScheme, saving you thousands of hours of programming time.)
What you say is indeed true, if you take a monolithic approach to problem solving. And I tire of this approach--dammit, we're tool-builders! We have been shown the Unix Way, and yet we ignore it time and again, forcing us into suboptimal solutions to our problems.
Moving "QUUX formatted records from BAZ mainframe to new Oracle Windows Java 7.0 Lightweight Enterprise Server" involves these things: a source, a sink and the pipe character. Your source and sink may necessarily be in Java--meh, whatever works. But now you have a decoupled framework for doing these kinds of jobs, and you haven't invested any more time or effort than you would have with your one-off, inflexible solution. And you can now stuff anything in that pipeline. And I regularly use racket for exactly this, using protocol buffers as the pipe character. It's not rocket science, it's the Unix Way. People, embrace it and free yourself from the monolithic millstone!
You're assuming that BAZ mainframe wants to let me move data away. They don't, so the only way to do so is with ugly hacks. That's the bulk of programming: making things that don't want to interoperate interoperate.
If everything was a service, then everything would be easy, and our tools would look a lot different. But if you can't change the world, you can at least make living in an imperfect world easy, and that's what Perl tries to do.
If the mainframe won't cooperate, you'll have work to do no matter what. But you can isolate that work into as little as possible. That is what the Unix tools do.
Everything is a service, if you make it so. A component is a service, offering the functionality of its interface. The 'wc' tool is a service--its interface is its command-line switches. And you're right, when everything is a service, everything is easy (I'd say easier).
I'm a python programmer and this article really makes me interested in Perl. The only problem is that Perl 6 haven't shipped yet in more then 4 years since this article was written, have it?
Perl 5 has nothing to do with Perl 6 development or even releases. Even after Perl 6 is released Perl 5 will still continue to evolve and grow.
At the moment Perl 6 specification gives a good evolution map for Perl 5 development. So you need not to have to ever worry about Perl 6.
Perl 5 is a solid language in itself. Perl has been amazingly useful since almost 25 years now. And anybody who denies this is simply trolling. Its useful for almost anything to everything. From scripting, to application development, to prototyping to building reliable applications in any domain.
Perl adapts to nearly every programming paradigm out there. Object oriented, functional, declarative you say it Perl has it. Its amazingly flexible, easy to learn and extensible.
You also get to benefit from the community experience and knowledge accumulated over years. You get the power of CPAN. There are also amazing resources to learn Perl.
Its a tool that you will never stop being in love with.
Those of us who have used Perl and pushed its boundaries to get amazing stuff done over years, even now can't write down words to describe its greatness. We can only tell you how great it is, but when you see it yourself you will know it.
But the position of any new Perl programmer is enviable to say at the least. He stands at the gates of a city which is going to take him to places he has never seen and experiences he has never been through. Most of them are going to change his life for ever.
Object oriented, functional, declarative you say it Perl has it. Its amazingly flexible, easy to learn and extensible.
My first programming job was in Perl back in the late 90's. Loved it, but I have to say that the OO facilities left something to be desired. I found them fatiguing. It took Java, then Smalltalk for me to really get OO. Perl requires too much mastery of mechanism just to do objects, so it's not the best environment for learning OO.
I agree with chromatic below; Java and C++ do not teach you OO. They teach you cut-n-paste without a text editor. (When Bar extends Foo, you're copying-and-pasting Foo's code into Bar, and then tweaking it. Or at least that's how class-based OO is used a good percentage of the time.)
A better way to program is with interfaces and composition via delegation, something that Java and C++ support but have no syntax for making it easy. Perl's Moose object system, on the other hand, has easy support for composition via roles and delegation via ... well, delegation :)
And, you have "extends"-style OO available if you think it's the right solution to a particular problem. So really, I think it's a fine way to learn OO. Doing things right is easier, if you decide to do them right.
(We do Java OO right at Google, but it sure involves a lot of typing and @hacky-attributes. And I've never seen good Java OO anywhere else.)
As a Smalltalker with a decade of experience, I too find Java a bit lacking. That said, it was a better environment for OO than Perl at the time. I was able to get a feel for refactoring through Java, though. That primed me for Smalltalk and the joy of no primitive types.
Really? I see inheritance as a good antidote for cut'n'paste. If you don't physically duplicate code, you'll never have to read both copies just to make sure they're still the same. I agree most devs do it wrong, but I think it's because they're purely pragmatic and haven't read or thought philosophically about the open/closed principle, programming-by-difference, Liskov-substitutability…
And I do want to remind readers that Moose is not the Perl object system, it's an object system added on top of the mess that a huge collection of legacy code presumes.
My history is the opposite. I failed to understand objects in C++, then learned Java, and then learned Perl. Playing with the mechanism helped me understand OO. (Exploring Smalltalk after that helped.)
After learning Moose a couple of years ago, I don't miss the Perl 5 mechanism at all.
I have hardly ever seen such high praise for a language. I guess I'll have to learn it sometime and see what the hoopla's about. With the Modern Perl book, of course, if it's still the best-of-breed then.
There is no hoopla outside of the echo chamber. If you want a truly amazing language I would suggest things like Haskell, Racket, Clojure, Erlang, Smalltalk, and/or Common Lisp.
If you're looking for more batteries included then I'd suggest Python or perhaps Ruby. Things are always going on in those communities and they've made some great killer apps like Blender (python), Rails (Ruby), Django (Python) and countless more. These languages are just as flexible as Perl, though they have their strengths and weaknesses in different places than Perl does.
One way to measure the utility of a language is to see how its users perceive it. Both in the times of technology hype and otherwise. If I look at the Java world, I see most programmers come there because they need a job. I would program in Perl even if I would not be paid for it, just for the fun of it. Its like painting, or playing the piano, or drinking fine wine. I would like to do them, even there is no direct benefit from them.
Some languages get a special distinction that its users just love to program in it. Languages and tools like Lisp, C, Perl, Vi, Emacs etc they just never go away. Because someone somewhere is always discovering some goodness in them and is using it. And that process is timeless. These languages have managed to last for decades sometimes their adoption drops, sometimes it peaks, sometimes there is a constant line of usage. But they don't go away.
If you read the mailing lists during early days of Perl on comp.lang.perl.* and other writings by people like Tom Christiansen. You will see some unique tone of passion and excitement. The golf competitions, the discussions on one liners, the growth of CPAN, the occasional gems posted on Perl Monks. Great books like Programming Perl, Higher Order Perl and Modern Perl Book and Perl's extreme practical approach and emphasis of 'Getting things done'.
I guess for people on Unix platforms who had no other respite but to use C and a mash of other Unix text processing utilities. Or for Java programmers who have to write 10 classes to open a file and do trivial operations.
Perl is almost like giving Ice water to somebody in hell.
Although Python is taking more of these roles over time, Perl is still the thing that holds much of the internet's infrastructure and tools together, as well as internal servers, so it's a good thing to know if you're interested in all that.
Hmmm, Python has some great frameworks and is a great language.
But unfortunately, its almost like going backwards. Perl was invented because C + Unix text processing utilities together were not proving to be good for many tasks like Text processing, fast prototyping etc. Now using another C based language which doesn't do that, takes us back to the old problem again.
IMO, Python doesn't solve those problems. Regex support is really bad in Python and file operations are not trivial. There is too much of Java feel to it and it just doesn't have the feel of bash/perl/awk's scripting powers. Scoping is just not right. There doesn't seem to be a sane ways of evolution without breaking backwards compatibility. No equivalent of CPAN. And in many ways white space based parsing is not good for large and nested code blocks. It still doesn't have multiline lambda's. And its too much do-it-one-true-way kind of language, that sort of is a blocker for quick hacking. Because I like to write what I think, and not the other way around. The language is too verbose, and unlike Perl and Emacs there are no exponential productivity gains over time.
But I agree though, that Python does have some other good things. The OO syntax is neat, there are some great frameworks like Twisted and Django. And there is low barrier to entry which makes new bie feel just at home. The tutorials are just too good. And good standard libraries ship with it.
What you're saying seems handwavey and imprecise. What -- specifically -- is wrong with regular expressions and file operations in python? How is white space parsing "not good" for large and nested code blocks? (And why do you have large nested code blocks in the first place? Break those up! Those are hard to read regardless!) And how is there a "java feel"? What does that even mean? And in what way is python verbose? In my experience almost everything about it is almost as terse as possible, from the lack of needing curly braces to the minimalist syntax to naming things like "str" instead of "string"
Its a lovely quote, but I've used Perl, I know what it provides. I've also used lisp. I just think if you're going to make a claim you need to back it up with something solid.
I gave you the solid things, but you give 'You aint gonna need it' kind of answer to everything Python doesn't have.
Coming to asking people forcefully shorten their code blocks. It's none of language's business to dictate its style on me and steal my freedom. A language is supposed to behave the way I want. That's its very purpose.
No multiline lambdas, No CPAN equivalent, Seamless interaction with shell like $output = `command` is absent. No first class regular expressions. Lack of ability to provide the command line power Perl gives. No switch statement, No equivalent of Perl's smart match operators, Nothing like Moose, Nothing like Devel::Declare, Parsing power nowhere even near to Python. And I can go on and on..
I guess these are solid enough things(at least for me)
"Coming to asking people forcefully shorten their code blocks. It's none of language's business to dictate its style on me and steal my freedom. A language is supposed to behave the way I want. That's its very purpose."
if True:
x = 1
[copy the above line, paste it 999,998 times]
x = 1
print x
Python runs that and doesn't say anything about by block length; it just behaves the way I want and prints x (after a short pause). What are you talking about?
for x in re.findall(r'\d+', '12 drummers, 11 pipers'):
print x
How is this bad?
> file operations are not trivial.
File operations are trivial and well designed. You know, there is much more to file operations than in-place substitute.
> There is too much of Java feel to it
Bullshit.
> and it just doesn't have the feel of bash/perl/awk's scripting powers.
Want it to feel like Perl? Don't bother - use perl.
> Scoping is just not right.
Scoping doesn't require your testimony.
# foo doesn't exist
if blah:
foo = 'bar'
# foo exists if blah
This is perfectly fine.
> There doesn't seem to be a sane ways of evolution without breaking backwards compatibility.
When you change the semantics of the language, bozo syntax tricks don't help. Python 3 has semantic changes - syntax tricks aren't going to handle them.
> No equivalent of CPAN.
A large stdlib and PyPi.
> And in many ways white space based parsing is not good for large and nested code blocks.
Spaghetti will look like spaghetti, irrespective of whether block separators are braces or indentation.
> It still doesn't have multiline lambda's.
"still doesn't" sounds like it is something which is planned but not achieved yet. It is not something that Python designers are planning to incorporate in the language. Perl has multiline lambdas but I only used single line lambdas for sort, grep et al - anything larger than that becomes a named function. Unless you have blocks, multiline lambdas aren't used that much.
> And its too much do-it-one-true-way kind of language, that sort of is a blocker for quick hacking.
There can't be an objective explanation to a subjective statement.
> Because I like to write what I think, and not the other way around.
What's the other way round? I like to think what I write? So in Python you think what you write? That makes zero sense.
> The language is too verbose, and unlike Perl and Emacs there are no exponential productivity gains over time.
Complete, utter bullshit. There isn't a single language in the world where the productivity gains are exponential over a long time - there might be some when you are a beginner which gets capped pretty fast.
I am going to neglect the responses 'Bullshit' basically because that means you don't have an answer at the moment.
>>There isn't a single language in the world where the productivity gains are exponential over a long time - there might be some when you are a beginner which gets capped pretty fast.
Sorry to ruin your party. But there are languages where there are exponential gains in productivity with time. Languages like Lisp, Perk, Haskell etc. But I can't convince that to people who can't look beyond 'readability matters' and consider that as the Pinnacle of programming language design.
Coming to regular expressions they are first class citizens in Perl. That is basically what takes them to the next level. Now scripting on Unix has always been so much about Text processing. That is how it has always been. tr, sed, awk and dozen other text processing utilities. And then there is Perl. If you are not getting 'Text processing' thing correct, then you already loose the scripting race with a very huge margin.
Perl added a lot of new semantics to the language too given/when statements, smart matching operators etc. Python broke it for as simple a thing as a print statement. That is the whole point(The language is too brittle to evolve). And I'm sure any new thing in Python is going to go the same way.
And stdlib is no where near CPAN. Although I agree PyPi is doing a good job.
You are right that I must use Perl,And you are also right that Python is an awesome language. There are great frameworks Twisted, Django, NumPy. I've used Twisted extensively. In many Python ways is a great language for web development, for studying algorithms(because its better psuedocode), and due to its frameworks like Twisted - its good for network programming.
But I am sorry to say Python doesn't do well in scripting areas. And it so happens once you start there and go a little deeper you can just go on and on with Perl.
> I am going to neglect the responses 'Bullshit' basically because that means you don't have an answer at the moment.
Saying 'python feels like java' or 'exponential gains from switching language' is bullshit, and augmenting it with "calling it bullshit means you don't have an answer" is more bullshit.
> But I can't convince that to people who can't look beyond 'readability matters' and consider that as the Pinnacle of programming language design.
I don't remember mentioning 'readability matters' as being pinnacle of programming. You are responding to arguments you are imagining I am making.
> Sorry to ruin your party. But there are languages where there are exponential gains in productivity with time. Languages like Lisp, Perk, Haskell etc.
Get off your high horse. Lisp, Perl, Haskell aren't some exclusive club only you are allowed into. I have used Racket, Clojure, Python, Ruby etc. and if your gains are exponential accumulated over a period of 1 month between say Python and Racket, be assured you are a very lousy Python programmer. Let alone exponential, a gain of even 2x is quite a stretch. Why don't you put your money where your mouth is and show me your 'exponential gains'?
> Sorry! I shouldn't have hurt your religion at the first place.
In place of spewing this nonsensical shit, you could have quoted me an example of "exponential gains".
Out of curiosity, have you actually programmed in Lisp or Haskell? I am not saying you have, I am not saying you haven't; it's just that people who claim "fuck yeah macros - now I am 100x more productive" are mostly people who haven't actually used them and are regurgitating blogosphere bullshit.
> Well I should have learned long back to not argue with impolite people.
Sheesh. In this thread, there is nothing but platitude in your posts, and you are constantly trying to put down people(everyone else who doesn't agree with you about perl is a troll, saying that what you know about python is not correct is me defending my religion etc etc), and then you whine about people being impolite. Pot, meet kettle.
> This is one lesson I'm not going to forget.
Another lesson would be to actually learn and use Lisp before claiming exponential gains.
It's not impolite to say you are regurgitating blogosphere bullshit when you claim with utmost confidence "I am sorry to ruin your party but there are languages like lisp and haskell which results in exponential gains" when actually you haven't used either one of them.
What you consider as verbosity in Python might the 'being explicit' philosophy of Python. For example though the succinctness of crafting a Perl regular expression is alluring , I have found writing regular expression the Python way and referring the results in an explicit
manner helpful in keeping the code readable.
The gain you mention (though the exponential part is debatable) is not limited to Perl alone[1]. Scripting languages provide a substantial gain in developer productivity freeing them from things like typing,
faster debug cycle etc. and that gain is not limited
to using Perl alone.
Check Table 1. in the reference I have mentioned, which
compares the time it took to develop the same application
in Tcl with time it took for development using in C/C++/Java. I think similar gain can be seen when one uses other scripting languages (say Python or Perl).
I don't generally see sales pitches of this level on sites actually selling something.
>And anybody who denies this is simply trolling.
Logical fallacy: Appeal to emotion. "My argument cannot be argued with because " is always a logical fallacy. "amazingly useful" is subjective, so of course it can be argued and doing so is not trolling but perfectly reasonable. Don't make claims you don't wish to back up.
>Its useful for almost anything to everything. From scripting, to application development, to prototyping to building reliable applications in any domain.
Logical fallacy: Misleading vividness. While what you say may be true, you've just described a programming language. There is nothing in this sales pitch that is perl specific.
>Perl adapts to nearly every programming paradigm out there.
This one is a better claim. The proper term is "multi-paradigm". Most (all?) Lisp dialects are also multi-paradigm, among various other languages.
>Its amazingly flexible, easy to learn and extensible.
"Amazingly flexible" is subjective. For example, a Smalltalk or Lisp programmer isn't going to be impressed (nor would programmers of Self, IO, etc., etc.).
Easy to learn can be tested to some degree and I believe you'll find the data against you. It would be an interesting to catalog the kinds of questions that get asked about the various languages. In my anecdotal experience, people start having problems with perl right at the beginning with e.g. how variables work.
Extensible is again "Misleading vividness". I can think of more languages that have a similar level of extensibility than those that do not.
>You also get to benefit from the community experience and knowledge accumulated over years.
Misleading vividness.
>You get the power of CPAN.
Overemphasized. Use a JVM-language (e.g. Clojure), for example, and you'll get the power of any open source JVM-language code ever written.
>There are also amazing resources to learn Perl.
Again, if you look at popular languages today there are few that wouldn't tick this box.
>Its a tool that you will never stop being in love with.
This claim is just ridiculous and wrong. I used perl professionally for over half a decade. At first I didn't care that much one way or the other. I was a C++ programmer and this was easier in some cases (but less flexible in other ways that I was used to exploiting). But as the years went on I grew to hate the language more and more until I just couldn't bare it anymore. I hated the backwards defaults (e.g. dynamic variables are fantastic. But as a default? wtf?), how ugly sigils look in code, the embarrassing "OO" syntax at the time and, one of the worst, how the community was constantly trying to prove they were relevant (obviously still the case). You could never mention Perl online or around Perl people without having to listen to the same tired tautologies about how incredibly powerful it is (wtf have you been using to think this?), etc.
So no, it's not a tool you'll never stop being in love with. This is the "Mind projection fallacy". You feel that way, but the vast sea of perl developers who abandoned ship for Python, Ruby, PHP, etc. obviously don't.
>Those of us who have used Perl and pushed its boundaries to get amazing stuff done over years, even now can't write down words to describe its greatness.
More "Misleading vividness". We all have stories like this in our favorite languages, but practitioners of other languages don't seem to feel compelled to post them anywhere and everywhere.
>We can only tell you how great it is, but when you see it yourself you will know it.
Appeal to mysticism. Sure we will.
>But the position of any new Perl programmer is enviable to say at the least.
Hah! If you had just said "Programmer" I would have found this an inspiring sentiment, but Perl programmer? No. I don't envy several months of "wtf" (e.g. the first time you figure out that your code accidentally applies ++ to a var that has a string in it and instead of crashing so you detect this immediately it does something with it).
You could never mention Perl online or around Perl people without having to listen to the same tired tautologies about how incredibly powerful it is (wtf have you been using to think this?), etc.
Haha. No, if you come here most ridiculous posts like you have I'm going to call you out on it. That's your tl;dr.
You are making tautological as if they were meaningful and subjective ones as if they were truth [1]. The "infer"ing you did is called "projection". I would have given you similar treatment if you had made a post like you did on a wide range of subjects. But since you have made Perl part of your identity you take anything said about personally. I don't think that's a mentally healthy thing to do, but one would have to ask a professional to know for sure.
[1] Again in this post with "Nothing that you can do will make Perl less enjoyable, less powerful". Enjoyable is subjective and calling Perl "powerful" is a near tautology since the majority of active languages are exactly as powerful if not more so.
If you're interested, skim through Modern Perl [0].I really like this description from this Amazon review [1]:
"I had a hard time characterizing this wonderful book. It explains the fundamentals, but it's not an introductory book like Learning Perl. It covers almost every feature of the Perl 5 language, but it's not a reference book like Programming Perl. It explains common idioms, but it's not a guide to Perl 5 fluency like Effective Perl Programming. It contains many practical suggestions, but it's not a book of tips like Perl Hacks.
I can only describe it as a "textbook". If I had to pick a single book to teach Perl 5, this is the one I'd choose. As I read it, I was reminded of the first time I read K&R (C Programming Language) and how much learning was packed into it. (It's the only college programming text I still have). In a slim 250 pages, Modern Perl obsoletes most of my shelf of Perl 5 books. It's not intended for a complete novice to programming (any more than K&R was), but in the hands of a competent programmer or a diligent student it will teach everything that one needs to know to write Perl 5 well."
The OP was asking about Perl 6, not Perl 5. Perl 6 has enough interesting things that a python programmer might get interested but Perl5 is a pain to use (coming from the python perspective).
Ignore the semantic games other responses play. If you're asking "Has anyone released an implementation of Perl 6 that's suitable for everyday use by someone who isn't interested in developing Perl 6 itself?", the answer is no.
I haven't used it, primarily due to the risks involved in using Mono for business purposes. (I have no interest in discussing this.)
My latest understanding is that it's still a single-developer project with better performance on many benchmarks than Rakudo but much worse startup time and significant feature overlap. It has monthly releases but makes no promises of stability or usability across releases.
One of my big takeaways from this article is Larry's view on the history of language. He was quite serious when he compared Ada to English, and I find it really interesting to think about Perl 100 years from now. Will it still be around in some form? Might it be a bigger language than English? Might the notion of a "small" programming language being the ideal be somewhat quaint when a CPU with 4GB of integrated memory dances on the head of a pin?
Anyway, what I'm getting that is 4 years is a pretty short amount of time now that Larry Wall has made me think about it.
Perl 6 has very ambitious goals. One aspect of Perl 6 is it pays extreme emphasis on sane, safe extensibility. Perl 6 grammars are killer features. For all those people who wanted lisp like extensibility inside C kind of a language, Perl 6 will be a perfect match.
Given those goals, Perl as a language has a long bright future. Because flexible and extensible languages evolve their way out of time.
Compared to all languages in its class, Perl hasn't broken backwards compatibility since past 25 years. Python had to break it for some very simple syntax changes. Perl has never done it, not even once in past 25 years. That is quite a feat considering so much syntax has been added to the language since then. Perl 5 has also found a way to add more syntax without dealing with the core by modules like Devel::Declare.
So Perl evolution is set for many years. You will see it evolve grow. New neat ideas and many like Moose will find their way into Perl.
Basically what makes it special is its hackable, flexible and extensible. And such languages generally stay around for a long time.
Back-compat can have many meanings - but my understanding is that every major release does break some back-compat in some way - otherwise it would not be a major release. And if you think that binary compatibility is not be fair - then how about pseudo-hashes?
This is not to say that I don't agree that Perl has perhaps the best back-compat of all the languages that still evolve - but these absolute statements have this slightly sect feeling.
From what I've read various places (but can't find a reference at the moment), the version bump from 3 to 4 was just to be able to have the Camel book coincide with a major version (i.e. "this book describes Perl 4" instead of "this book describes Perl 3.1.4.1.5" or whatever).
Heh, thanks! I read through the whole thing very carefully before posting, and couldn't find it. Now I see it's in the Introduction: "Perl 4 introduced the first Camel book. Really. We mostly just switched version numbers so the book could refer to 4.000."
I find it really interesting to think about Perl 100 years from now. Will it still be around in some form?
There is a really excellent SF novel 'A Deepness in the Sky' by Vernor Vinge.
It's a few thousand years from now, and one really important job is "Programmer-Archeologist". Their job is to grub around in libraries, find an already existing solution, adapt it to present needs. This is important because without quality automation running your spaceship, you could die.
There are hints that some of these libraries are really old: an off-hand comment is made referencing what must be unix epoch.
I'm not sure there will be an official Perl 6 shipment. I did recently download the February Rakudo Star (which compiles Perl 6 into Parrot VM bytecode), and I've enjoyed playing around with it. Fair disclosure: I've been writing and loving Perl 5 since 1999.
The difficulty right now for anyone from a Perl 5 background who would otherwise jump into Perl 6, is that running your Perl 6 program is really, really slow. I don't know if it's the compile step or execution or something else.
I asked the same question few years ago and the answer back then was "there will never be official Perl 6, anything that implements Perl 6 specification is Perl 6." I don't know about other implementations, but latest Rakudo Star[1] was released just a month ago.
At the risk of being annoying, virtually all the research done in linguistics departments anywhere in the world is research in the cognitive science of language, so a social science, not a humanity. This certainly includes Berkeley around 1970 or so (assuming that's when Wall was there).
You should never "wait" for a programming language. :) I say this as someone who is deeply involved in Perl 6 development.
Learn Perl 5 if you want to learn how a full-featured, complete, and liberating-to-use programming language works.
Check out Perl 6 if you want to see what some of us are building, and if you value ideas as such, even when they haven't all been put together into a finished, polished product.
In my opinion, none of the language will solve the problems with programming or bad programs. The only thing which could help programmers is the way they think of the solution and how they approach to it. Thinking about long term solution for a given problem may help.
An actual tl;dr for this article would be almost as long as the article itself. There's lots of good stuff in there. However, if the length of the article intimidates you, I suggest starting at the sentence before the heading "early binding; late binding". Everything before that is historical perspective -- interesting but not as useful as the rest of the article.
I was just joking. It wasn't meant to be a personal attack.
Hey its just my opinion that engineering is an easier problem than other business activities. Programming is more predictable. You can fix bad programmers.
Just a curious question... was writing the book harder than programming?
This quote, and what little I've sampled of Perl 6, reminds me of a few lines from the movie Wonder Boys:
Grady, you know how in class you're always telling us that writers make choices? [...] And even though your book is really beautiful, I mean, amazingly beautiful, it's... it's at times... it's... very detailed. You know, with the genealogies of everyone's horses, and the dental records, and so on. And... I could be wrong, but it sort of reads in places like you didn't make any choices. At all.