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."
This discussion has been archived.
No new comments can be posted.
Perl 6: Apocalypse 6 Released
Related Links Top of the: day, week, month.
With your bare hands?!?
Re:20-odd pages... (Score:3, Interesting)
No no no no no. I know that :) I mean:
foreach (@list) { $list[$i] = 'No jam today!' if ($_ =~ /jam/);
}
... where $i is an index into the array. Like a for() loop, but without the gatepost error possibility. Yes, you can do it yourself with my $i=0 and $i++ in the loop, but it's a mess, especially if you next or last anywhere in there - it means you have to put the $i++ at the top, and start at $i = -1, which is bizarre.
Perl is turning into a completely new language (Score:4, Interesting)
Instead if Perl kept on changing then you can't be sure and when you have literally thousands of little perl scripts everywhere this is intolerable.
Perhaps they should have kept Perl 5 as
ughgh (Score:3, Interesting)
multi *caller (?$where = &CALLER::_, Int +$skip = 0, Str +$label)
my brain can't grok that
Perl, the new ADA (Score:5, Interesting)
Perhaps the cleverness of the ideas are not being tempered by real use at this point. A language does not become great by adding new syntax and semantics for each feature but by refining it to the essential units needed to express all the rest. We should not celebrate the fact that "will" and "is" are very similar ways to express traits in perl 6. We should ask instead why do we need both? Further, is it possible for me to define a new "wont" statement in perl, or are "will" and "is" special things only language designers can implement?
Re:Perl is turning into a completely new language (Score:5, Interesting)
No, most of these "features" as you call them are not added into perl, they are added in as bundled modules. Perl's core is kept small for this very reason. As for Perl 6, that is going to be radically different but perl5 will be able to live on the same machine as perl 6 and I would imagine that a great deal of people will keep both around and maintain both for a great while.
Re:ughgh (Score:4, Interesting)
No. That's conceptually wrong.
A (programming) language should make it easy to construct solutions for problems it has been designed to solve. Natural languages, such as English, are good for certain sets of problems and quite bad for other sets of problems.
Would you like to replace math notation with sentences in English?
When did obfuscated code kill a language? Never (Score:5, Interesting)
The original poster simply pulled something similar. There is no requirement that your perl look anything like that, nor is "powerful" perl more obfuscated than plainish looking perl. This is total FUD drummed up by someone who has presented a corner case....which I can assure you can be done for any language. In fact, I wouldn't touch a language for which this didn't hold.
Seeing the forest through the trees (Score:5, Interesting)
What I think though is important to remember is that if all you look at is the syntax, you won't appreciate the power -- and simplicity -- of the idioms. Taken out of context and put into cooked up examples meant to show off the new syntax, it looks bad... really bad. But once you actually start programming in it, you'll find that most of what you want and need to do will actually come quite simply.
That vast majority of all this new syntax will be applied in the vast minority of programming cases. Much of it will get sucked up into modules, classes, etc., that you'll use without worrying about what's actually going on under the hood. And "the rest of us" will just have an incredibly powerful language that is actually easier to program.
Cheers,
Richard
GCC Larry.pl -Wall (Score:3, Interesting)
Got about 10 pages into it before the
Question regarding:
my %pet is Hash of Array of Array of Hash of Array of Cat;
why not:
typedef my Hash of Array of Array of Hash of Array of Cat %pet;
IMHO, without typedef, C++ would be lost, particularly when the STL is on the loose...
Larry, your Boss is as good as mine...
The shortest distance to a solution (Score:3, Interesting)
Perl 6 is easier than Perl 5. Really. (Score:5, Interesting)
I certainly don't look forward to COBOLScript [csis.ul.ie].
Human languages are an ambigious mess. Computers only want unambigious constructs. Having programmed in COBOL and and a few so called "fourth generation languages", let me say that writing in something that is close to English is really irritating. It's never quire English enough to allow me to express myself. You end up having to learn a specialized language that isn't really quite English. If I'm going to learn a specialized language, I might as well learn something that is easy to type and easy to scan visually.
Perl is a big, complex language, yes. But like real languages, you can learn it with very simple steps. You can get complex, productive things done with a just a quick introduction. If you want more power, it will take more learning, but it's available. Perl 6 aims to accomplish this evem better tham Perl 5.
Yes, the example given in the article are a bit convoluted. The entire point of the article is to explore all of Perl 6, not just the commonly used bits. In fact, one of main goals of Perl 6 is to make the common case and the introductory case less confusing than in Perl 5. Really. And everything revealed so far has supported this, it's just that Larry doesn't make it too clear.
Take for example expressing that a function takes three arguments in Perl 5. The best you can do is:
(The "...." represents spaces because Slashdot's code filter is crap.)
In this example, Perl will not check that callers do the right thing. In Perl 6, you get this:
A clear improvement, and Perl will actually verify that callers do the right thing when calling you, usually catching an error at compile time!
In general Lary's Apocalypses have been a bit obscure. He's focusing on the big picture and the little details. Damien's Exegesis's [perl.com] is generally alot easier to read for people less interested in deep thought and more interested in concrete details. Wait a week or two for Exegesis 6 and give that a read. I think you'll find that the common case is slightly simplier and more obvious than in Perl 5, while the system also allows for more complex expressions that weren't well supported in the Perl 5.
Re:Perl 6: Replacing old cruft with new cruft! (Score:4, Interesting)
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!
Perl is more based in natural languages than in "traditional" programming languages. In natural languages, what you are saying depend on the context, the same words say different things if they are used in diffeerent situations or positions inside a phrase.
Well, in perl that also happens (in perl 5 you'll find a lot more examples of this, starting with the "$" in $a, $a[1] and $a{"red"}).and I think that it was more common in the previous versions (at least in Perl 6 I believe you'll have $a, @a[1] and %a{"red"})
Re:Don't forget Parrot (Score:3, Interesting)
I agree. When parrot comes out, there will essentially be 4 development platforms:
The fourth will be used for applications where speed is really key (real time, database engines, OS's, etc.)
For all other apps, it will be a matter of choosing one of the other 3 environments, and a language.
This choice will be particularly interesting given the fact that some languages (e.g. perl) will work with more than 1 of these environments (.NET and Parrot).
It's going to be an interesting world...
Why Perl6 matters (Score:1, Interesting)
Having said that, I believe Parrot is a disaster that will never actually function correctly. No matter - someone will write a better Perl6 VM. I would not be surprised if it came out of ActiveState, Ximian or Microsoft.
I think it is safe to say (Score:1, Interesting)
That Larry has now COMPLETELY LOST HIS MIND:
I suppose you could also write that as:
but for linguistic reasons it's probably better to keep the variable name near the left and put the long, heavy phrases to the right. (People tend to prefer to say the short parts of their sentences before the long parts--linguists call this the "end-weight" problem.) The Hash is implied by the %pet, so you could leave out the "is" part and just say:
Another possibility is:
I'm really glad I learned Ruby..
Re:ughgh (Score:3, Interesting)
Actually from a grammer standpoint Perl is far closer to a real human language than almost any other language. For example the use of pronouns (implied variables) in Perl is very much like a human language and very unlike most computer languages.
The inventor of Python agrees with this assessement but since he considers this a bad thing he didn't emulate it in Python.
Ever hear of APL? (Score:2, Interesting)
Of course, with all of this power APL also invented the write-only program and the one-liner, both predecessors to the obfuscated C contest... and I must say that those using C and C++ can only dream of approaching the unreadability that was APL. Then again, only APL used its own character set... it used single symbols derived from mathematics as its operators. No constructing multi-character composite operators in that language... just custom terminals, or... a special type-ball for your selectric based 2741 terminal (there's a trip down memory lane).
To return to my point, though.
APL died for a number of reasons, but probably the biggest was how totally undigestible its code became with very little effort. I wrote some fairly simple programs, relatively well written for APL, avoiding the tradition of making everything a one-liner, actually including comments... you know those things written in intelligible English that explains what a program does... oh, yeah, I haven't seen any of those in years in my C/C++ shops... and yet as little as a few months after I wrote those beautiful, elegent APL programs I had no clue how they worked and could only change them by re-writing them. A very good reason for a language to die.
The shame of it all is the APL was probably the best language ever invented for solving hard-core math and arithmetic problems, yet it died before it could even run on its natural platform, the super-pipelined vector processors such as the Cray-1 and its relatives.
Re:ughgh (Score:2, Interesting)
Sand (Score:3, Interesting)
Sand is a programming language I've been planning for a long time, but its timetable has picked up as I'm more and more convinced that Perl 6 is going to fill a niche that I don't work in. Plus, I've really never been comfortable with bytecode interpreters.
That's not to slight Perl 6. I'm sure it will be a fine language, but I'm looking at moving on to a design that focuses on maintainability and compilability (that is: to machine code). Since none of the languages out there satisfy my desire for these attributes plus the flexibilty that I've come to love in Perl, I have to write it myself.
Re:Perl 6: Replacing old cruft with new cruft! (Score:4, Interesting)
I have heared that he explained in his first books how perl works from natual language point of views.
In the Apocalypses I saw also a lot of reasoning about how something is seen by a the human mind.
I can not help myself. But PERL transforms even more into a unreadable language.
I wrote a lot of perl scripts in Perl 4, about 300k LOC. After not looking at them after 1 or 2 years C++ coding, most of the tricks I used I did not understand anymore
Every time when I see a post about a new language I jump on it as I was a language geek when I started programming.
As soon as I see more than one $ or % or # sign in a sinlge line of code, I just trash the language.
I simply can not get why this is needed. I fully agree with the one who said programming languages should approach english. (probably because I learned Pascal as first true programming language, after BASIC and assembler)
I think a programmer should be able to read any program in any language. Or at least should be able to get a clue about what a program does, and how it does it.
Thre are so few constructs: variables, declarations, definitions, statements, structures, arrays.
Around that some programming concepts are woven
Why to make that more complex by silly abreviated keywords? (sub in perl, def in python) By useless and meaningless (for a uneducated reader) $ and # and % signs?
Perl is a language you an not learn by examining perl programs. You need a geek explaining it or time to read ALL docs. Thats a true draw back
Thats basicly why I stopped using perl. When Perl4 emerged I thought, better than C-shell definitly
Well, and I left C++ and went to Java
angel'o'sphere
Re:More Information (Score:5, Interesting)
If Perl6 goes according to plan, absolutely. In fact, it'll be particularly relevant to Ruby and Python.
More than any other thing, in my opinion, Perl has CPAN going for it. Other languages have tried similar code sharing projects, and none of them have come close to matching CPAN's breadth and (despite the occasional wonky module) usefulness.
More than any other thing, in my opinion, Java has the JVM going for it. Not that it's the only virtual machine out there, but it's the only one which really has broad distribution. The ability to distribute compiled bytecode, and to run it in a "sandbox", are two of Java's biggest selling points.
If Perl6 succeeds, neither of these languages will keep their greatest advantages. Perl6 is merely to be a Parrot compiler... and where Sun has actively tried to keep other languages off of the JVM, the Parrot developers want to entice other languages onto the Parrot. Any languages rewritten to target the Parrot, then, should (given some hooks, perhaps) be able to take advantage of the CPAN modules which are the wealth of the enormous Perl community.
To the extent that Perl6 succeeds, Python, Ruby, Scheme, O'Caml, and who-knows-what other languages stand to find themselves able to "write once, and run anywhere". Potentially, this could lower the bar for new and interesting languages to compete, since they'd primarily be competing as languages, with the runtime environment issues (more or less) abstracted away. In the same way that Mozilla allowed for today's proliferation of browsers, Parrot could be a very good thing for languages.
But while Perl6's progress will certainly be relevant, in the long term it risks obsolescence by virtue of its own ambitions. Frankly, if that were the case, I don't think it'd bother Larry all that much... however the Perl community doesn't seem to be ready to go gentle into that good night. A lot of Perl6's remarkably ambitious agenda seems to me an effort to stave off the possibility of the danger that Perl will become a victim of its own, and Parrot's, success.
a short story... (Score:1, Interesting)
&foo.do
push(@foo, "rapidly", 1,2,3)
my macro sic {
leave Block;
&foo.returns = sig(Num);
will do { return +@many[$one] }
From lines in the article. try it! it's fun!
Re:ughgh (Score:4, Interesting)
To my mind, the best computing language designer would be someone with extensive education and experience in: computer engineering, computer science, linguistics, mathematics, engineering and business processes, maybe psychology, and perhaps some other things I'm forgetting at the moment. My point is that a good designer would have a very strong comprehension of the problem space (the problems this tool is intended to solve), how the tool is likely to actually be used in the real world, how the problem space will evolve over time, all coupled with a very strong comprehension of the most efficient method of implementing this tool in the technology available. That's asking a lot.
In Wall's case, I think that he has a fair amount of experience as a practical coder, which is the impetus for his extremely strong emphasis on pragmatism in his language design. This would be a disaster for most designers, probably, but Wall's education in linguistics probably tempers that pragmatism with some comprehension of higher-level abstraction and some imposition of rigor. You can most clearly see this aspect of Wall's world-view coming through in the Perl 6 design.
However, even though in some sense the scientific view related to linguistics is an abstraction similar to the scientific view of computer science, they're fundamentally dissimilar. Linguistics is an attempt to comprehend and formalize a very complex and exquisitely functional system--human language. In contrast, Computer Science is not a descriptive science; it tends to be proscriptive--looking for the best way to do things, often from an ahistorical almost-Platonic perspective. As a result, it tends to be overly ideological. I chose the word "proscriptive" with some care, as in the realm of human language it identifies a fault line. Linguists tend to be notoriously relativist, asserting that what is "correct" is simple what exists. Proscriptivists, such as one's fourth grade English teacher, insist that there's truly "correct" and "incorrect" usage. In this sense, Wall's background in linguistics clearly has influenced his philosophy of computing language design; and, I think, computing language purists really are psychologically akin to the proscriptivist grammarians like the aforementioned fourth grade teacher.
For my part, in the realm of tools, I prefer aesthetic purity or elegance only when it serves utility (or, at least, doesn't interfere with utility). Perl is well-matched to its problem space, and in this it actually does have, in my opinion, some beauty. I mean, from one perspective a Swiss Army knife is god-awful ugly; but from another, its compact and wide-ranging utility is attractive. Because Perl is intended to operate in such a large problem space, I believe that simplicity, and the form of beauty that is a function of simplicity, is largely denied to it. So? We can't have everything. 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. In other engineering and science disciplines, there are a variety of tools and methods and specializations each well-suited to the problem domain they serve. And it works because a civil engineer isn't expected to do nuclear engineering work, nor an astrophysicist to do nuclear physics. But programmers are still expected to be jack-of-all-trades, and thus their tools are required to be as versatile--but also as unoptimized--as they are.
Type declarations already in perl5? (Score:3, Interesting)
You can?
Why didn't anyone say so before? I've never seen this in Perl code until now.