Perl 6: Apocalypse 6 Released 247
data64 writes "The latest Apocalypse talks about subroutines. Looks like we finally get type signatures which are way more powerful than the rudimentary prototypes available with Perl5."
Where there's a will, there's a relative.
Re:Will this work on Debian? (Score:1, Insightful)
Don't forget Parrot (Score:5, Insightful)
Re:ughgh (Score:1, Insightful)
I can understand some obscurity in lower level languages, like C, or as low as ASM itself. But a higher level scripting language should be as close to english (or another human language) as possible.
I dont see the inherent advantage in desinging a language thats hard to read. Frankly I'd rather see scripts written in VBScript than perl.
Re:ughgh (Score:3, Insightful)
It can also make things *harder*. The grammar and syntax of English is very fast and loose, but well known to it's speakers. Most likely the English-based programming language won't be able to mimic every little natural-language nuance, leaving the developer the headache of remember what rules are followed in which and when. When one says "or" in common, everyday conversation, it generally means an exclusive "or." When I say "or" in just about programming language, it means an inclusive "or." In an English language development language do you worry about conjugating verbs? What about tenses? Etc. You get the drift.
Using English keywords is great & helps simplify the problem, but as someone way smarter than me said "Things should be made as simple as possible -- but no simpler."
-Bill
Re:ughgh (Score:4, Insightful)
When they say theres more than one way to do it, syntax is included in there too.
Re:ughgh (Score:1, Insightful)
Perl 6: Replacing old cruft with new cruft! (Score:4, Insightful)
Perl 6 was meant to be a total rewrite. Nothing was meant to be sacred, cruft could disappear, and we'd be left with a mean language, true to its roots, and working on a hot new VM.
Instead we get stuff like this:
sub *print (*@list)
Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!
Each page of this Apocalypse presented me with a new piece of cruft to look horrified about. Slurpy arrays!? Oh my god. Wall even goes on about 'psychological reasons' for syntax! 'Default values' and 'Rules' are things that are easily done with existing code.. it's not even as if they result in particularly crufty code in Perl 5.
I'm still looking forward to Perl 6, but it really does seem as if Parrot is where the true action is. Perl 6 really does look as if it is being designed by committee.
Will Perl 6 lead to Slashcode 3? (Score:3, Insightful)
Considering all the features available, it seems like this would be the ideal time to freshen up slashcode. Then, maybe we'd see valid HTML 4, CSS support, layout without n-level deep tables, etc.
Use what you need (Score:5, Insightful)
Perl has always had a lot of esoterica. Don't let it bog you down. You can be amazingly productive in perl without ever knowing what a typeglob is.
Re:ughgh (Score:3, Insightful)
Once I was bored and wrote one line of C code that iterated over an array, and printed its elements separating then with commas, and printed an "and" instead of a comma for the last element. The code consisted of a for, a printf, and ?
Now, don't try to tell me it was readable. Every language can be used to write horrible code.
Besides, that doesn't even look as Perl. "?$where" makes no syntactical sense, variables have names like $where and that's it, "Str + $label" makes no sense either, unless Str is a constant, and "Int +$skip = 0" makes about as much sense as in C, because supposing it's comparing an addition with 0 it should be using ==.
Re:Perl, the new ADA (Score:3, Insightful)
I don't know about you, but I like my languages to be pretty static. You can't really learn a language that's different everyday. Also, I don't like languages that let you do things 80 different ways. There are enough fights over where the curley braces go. Perl is not a team sport. Open source perl scripts are slightly less open than open source programs.
Now, if Parrot has only one instruction for things like "until" and "while", and someone wrote a decompiler that supported each person's own style of programming, then we may be in business
This is kind of like the whole
Re:Perl is turning into a completely new language (Score:5, Insightful)
Forget the interpreter... (Score:3, Insightful)
Re:ughgh (Score:2, Insightful)
I can make ANY language look bad if I can break the rules.
Re:Perl is turning into a completely new language (Score:3, Insightful)
Re:More Information (Score:3, Insightful)
Python --
Similar to Perl. Tighter syntax, slightly less flexable
Ruby --
Much better OO implementation much smaller library.
So Perl 6 should be way more flesable than either of the other 2. We have to wait another 4/6 apocylopses to see about the comparison of the object orientation.
A completely different kettle of fish (Score:5, Insightful)
This will make Perl an attractive contender for serious application development; something which it came reasonably close to in late Perl5 but didn't quite get there because while you could do most things in a consensually "proper" way, the roll-your-own methodology just wasn't convincing enough for pointy haired project managers.
The primary difference with Perl6 is that it will have full support for strict(ish) typing and object orientation which makes it suitable for large projects where it's impractical to expect programmer A to know anything about how programmer Z's module is implemented internally and vice versa.
The new feature set (together with Perl's availability on a wide range of platforms and the huge range of freely available interfaces on CPAN) means that Java and .NET will be facing some stiff competition in just about every conceivable application niche.
If the speed improvements are genuine then (assuming that one were in a position to choose) for probably the first time ever we will be in a position where there is hardly any real need to maintain skills in multiple languages as Perl will be at least adequate for the vast majority of implementations. It's not unreasonable to suppose the list of exclusions being limited to CPU bound code in high-performance content servers (eg RDBMS, HTTP) and real-time and embedded apps requiring hand-coded assembler or at least tightly optimised C.
Whether you agree with that or recoil in horror at the thought of your favourite language being marginalised, Perl is clearly not just a "glue" language any more. It's about to become a fully-fledged enterprise application development platform.
I'm sure you've already guessed, but for the record I am very much looking forward to this.
There is one fly in the ointment I guess. Perl, like C, is very free-form in terms of what it lets you do but the flip side of that coin is that such languages also let you write dangerously unstructured and unmaintainable code. They require good training and a degree of self discipline to use well. Self taught programmers who didn't have strict typing and nested scoping enforced on them at the beginning of their coding career almost inevitably tend to grow up writing code that is less secure and harder to read than do those who learned back in their college days to associate variable declaration at the wrong level of scope with lower assignment grades and some stern finger wagging from their tutor.
The new Perl will continue to make the impossible possible and the merely hard very easy, but for the first time it will provide support for a more formal structure where that is considered a good thing.
Remember though that Perl is still very much a grassroots phenomenon. Whether this hits anybody's radar screen out in the real world has to depend on how well and how rapidly it is taken up by the Perl community. i.e. upon the willingness of existing Perl code monkeys to grab the inevitable (presumably three-humped) Camel Book, learn the new features and use them deliberately to adopt a more structured and more scalable coding style.
It's on this point I think that Perl6 will succeed or fail. We will need plenty of real world examples out there so that new users have something from which to learn righteous coding principles, and so that sceptical project managers will see successful implentations from which to draw confidence and inspiration.
Perl is a Write-Only language (Score:4, Insightful)
One problem with Perl, is that it's very hard to read somebody else's Perl code. Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers. If you've ever maintained a large Perl program written by someone other than yourself, you know what I'm talking about.
Adding more features to the language will only make this problem worse. Very few Perl programmers know more than a fraction of Perl's syntax. More syntax means more stuff that your average Perl programmer doesn't understand! This is a huge impediment to writing a large project in Perl.
Languages like C and Java stay alive precisely because they're not very expressive. You can write huge behemoth-sized projects and still have some hope of maintaining them, because there just aren't that many ways to obfuscate the code.
Re:Perl, the new ADA (Score:3, Insightful)
IME, Ada is exceptionally well-liked by the people who know it (note: use != know). I've seen far fewer complaints about it from Ada programmers than I've seen from, e.g., C++ or Perl programmers about those languages.
ADA's a good language, but no one uses it.
Right, just like how no one uses Linux on the desktop.
Re:Why perl will survive: (Score:1, Insightful)
Yay lisp! er, I mean perl!
Re:Why perl will survive: (Score:4, Insightful)
As far as i can tell, perl 6 is supposed to evoke four main reactions:
Re:Perl is a Write-Only language (Score:3, Insightful)
Bad idea. Look back at the history of "extensible languages" which allowed dynamic modification of the grammar. It was tried in the 1970s and early 1980s, in forgotten languages like EL1, BALM, and SPEAKEASY. Some dialects of LISP had such extensibility, with painful results.
The proposed solution doesn't deai with maintainability. It only addresses project organization.
A tool that converted existing Perl code into a standard format, changing the syntax without affecting the results, would actually do what the post claims. That would make code much more maintainable, if the tool was smart enough to understand the idioms of the language.
For example, the ugly hack used to do object oriented programming in Perl 5:
my $self = shift;
my $item = shift;
my $index = shift;
my $headercontent = $self->findbefore($item,\%stoptags);
$self->{'headercontent'} = $headercontent;
my $captioncontent = $self->findcaption($item);
$self->{'captioncontent'} = $captioncontent;
Addendum... (Score:3, Insightful)
Yesterday, Perl and Larry Wall came up in, believe it or not, a conversation I had with a friend regarding moviemaking. I had recently watched the director's commentary tracks on the DVDs of Rodriquez's "El Mariachi" and "Desperado", and I was explaining how impressed I was with his pragmatism. One of the most astonishing examples of this, to me, were his repeated admissions of complete disregard for certain kinds of continuity because "this is an action movie, things are happening very fast, and no one is going to notice it anyway." (That's a paraphrase.) He explained that he has x amount of time to get y amount of shots in a day's shooting, and worrying about details that no one is going to notice just doesn't make any sense.
Prior to watching these commentaries, I had rewatched Payne's "Election", which I think is a brilliant film, and after watching it I also watched it with the director's commentary. Payne is clearly a perfectionist, and he went to great lengths to preserve continuity and to create verisimilitude. (For example, two of his pet peeves in movies are cars without windshield mounted rear-view mirrors, and cars that are too clean.) I greatly admired Payne's attention to detail. Similarly, I greatly admire Kubrick's filmaking.
As the rare kind of guy who has both Knuth and Wall on my bookshelf behind me and who esteems both highly[1], and who appreciates both Rodriguez's pragmatic efficiency and Kubrick's auteur obsessiveness, I don't actually believe that there's the conflict there that other people assume there is. To me, it's a question of appropriateness. One approach is "correct" in one situation but "incorrect" in another.
To me, the very best filmmaker would know when to be like Rodriguez and when to be like Kubrick. Similarly, the best programmers would know when to be like Larry Wall and when to be like, say, Wirth. But that kind of versatility is rare. As is the case in so many things, human nature being what it is, most people have a preferred modality of thought and problem-solving, and operate in that mode whether it's effective or not. That's okay, providing that they somehow limit themselves to problems where their preferred method is appropriate. But many don't; and, worse, some proseltyze that their modality is what's "best" for everyone else, in every situation.
[1] Or, another supposed opposition: Tannenbaum and Torvalds. In their debate, Tannenbaum was the purist, Torvalds the pragmatist. If they were actually arguing about the same problem space, one of them would have had to be wrong and the other right. But they really weren't. I think that many of Tannenbaum's points about the superiority of microkernel architecture were correct and have been proven to be correct. On the other hand, you can't really argue with the success of Linux.
Re:Perl is a Write-Only language (Score:3, Insightful)
Huh? The only way to deal with maintainability is via project organization.
Even the most B&D, only-one-way-to-do-it language will permit obfuscated programming. The simplest way is by the (in)judicious use of De Morgan's laws on conditionals. For the more advanced obfuscator, just write a "subtract and branch if negative" function and code the entire algorithm using nothing but that. Every programming language, no matter how strict, provides an unlimited range of choices -- of identifiers, of data structures, of algorithms.
Coding is fundamentally about making such choices, and syntax is just the very lowest level at which they can be made. Human beings make (and disagree on) these choices, which inevitably means that maintainability is a social issue, not a technical one. So technical fixes alone can never solve the problem.
What we're proposing instead is a tool that can support in the necessary social processes by allowing you to reward adherence to, and punish transgressions of, your preferred syntactic style. But that's still ultimately a social solution because you have to convince your team to use the tool in the first place and ensure that they don't quietly turn it off when you're not watching.
And it still won't address the problem of getting them to choose meaningful variable names, or a sane data structure, or an algorithm that mortals can understand. No tool -- except possibly a big stick -- will do that.
Of course, we are also offering a complete parser for Perl, written in Perl. So if you do want to grab the parse tree of a program and reformat it (applying whatever artificially intelligent refactoring you can muster), the necessary support structures for that will be there too.
Re:ughgh (Score:3, Insightful)
a) highly consistent
b) easy to learn
c) very well fitted to the problem space
assuming the language is succesful the language gets applied to larger and larger problem areas and features get added that were originally considered in the design. The language moves towards becoming
a') inconsistent
b') complex
c') highly versitile over a wide range of problem spaces
If Perl were only still used mainly as a replacement for awk and sed it wouldn't be controversial. But over time Perl became a replacement for shell scripting and finally the "duct tape of computer science". To do this its added a tremendous number of libraries and these were developed independently of one another.
Since computer scientists are more reasearch oriented they tend to use "younger" tools; conversely people in the field are often using older tools for a variety of reasons.
___________
Finally one area I disagree with you is:
Ideally, there'd be a wide range of computing languages each perfectly and exquisitely engineered for their respective problem spaces. But, right now, computing isn't even close to being mature enough to support such a thing.
I actually think there are languages that are highly specialized for individual fields. In practice though the general purpose languages tend to be used much more often because these tools are too specialized. For example in math there are languages for:
-- number theory over finite fields
-- number theory over abstract fields
-- sparse matrix problems
-- crack based pde
-- ring theory
But in practice most people just Maple, Mathematica or Matlab because they don't want to have to learn a wide range of tools and these other languages are missing important features in other areas (like TeX export or GUIs).
Re:Seeing the forest through the trees (Score:3, Insightful)
Probably so...though a lot of this is because individual Perl programmers will each learn their preferred subset of Perl6, and will use it. Woe, woe unto the maintenance programmer who has learned a different dialect of Perl6! Woe unto the maintenance programmer when you have redefined the language syntax for your own convenience!
Easier to write, harder to read once written. Languages with a lot of syntax are the Dark Side of the Force.
Re:Perl is a Write-Only language (Score:4, Insightful)
Concede the likelyhood that this is due to one of two things:
1. "Most Perl hackers" are incapable of reliably writing readable, maintainable Perl code.
2. "other skilled Perl hackers" are not very good at reading Perl code.
Try reading through some of the modules in the Perl core some time. More often than not, they are exceptionally well-written, documented very nicely and easily maintained.
In my experience, given a pool of developers in any language, it is usually very rare to find one that can write truly elegant, readable code. Perl's flexibility just makes it so that those that write unreadable code can write some really unreadable Perl. Perl's low barrier of entry is part of the problem, and generally companies don't know what to look for when selecting a Perl developer, so you get a lot of novices out there in these positions pumping out utter shit, but it runs, so it must be OK.
Re:Perl, the new ADA (Score:3, Insightful)
I attribute Ada's glorious failure to a few things, and none of them are the language itself: