Slashdot Mirror
Larry Wall Unveils Perl 6.0.0
An anonymous reader writes: Last night Larry Wall unveiled the first development release of Perl 6, joking that now a top priority was fixing bugs that could be mistaken for features. The new language features meta-programming — the ability to define new bits of syntax on your own to extend the language, and even new infix operators. Larry also previewed what one reviewer called "exotic and new" features, including the sequence operator and new control structures like "react" and "gather and take" lists. "We don't want their language to run out of steam," Larry told the audience. "It might be a 30- or 40-year language. I think it's good enough."
I went to a presentation at a Unix convention in San Diego in 2000, 15 years ago, where Larry Wall talked at length about Perl 6, and how he was hard at work on it.
Well, better late than never.
Neither perl6.org and its mailing lists seem to mention anything about this. The links in TFA are blocked by OpenDNS too.
Didn't quite believe it would ever happen.
Not that I'm eager to adopt it, we have lots of perl5 code and the conversion would be significant.
Perl 6 vs. Python 3 - who will get to 1000 users first?
In related news, Larry has announced he is changing spelling of his name to more accurately describe his life's work:
Larry
W(rite)
O(nly)
L(anguage)
Where are we going and why are we in a handbasket?
I think it's been unveiled a few times now
I miss looking at my modem's line noise.
Hopefully it sucks less than Duke Nukem Forever.
You never wrote anything in perl.
Actually, if you look closely, the GP is actually a Perl script for computing the Fibonacci Sequence.
I saw that there are several implementations that use JVM. For those who have been following the situation a bit closer is there any progress behind a non JVM Perl6?
Man blir trött av att gå och göra ingenting.
Perl still has a place, however it isn't the golden child language it once was.
Perl heyday was during the mid-late 1990's when having a Relational Database was considered an expensive (in software price and/or in system requirements) so for Web Applications, that needed to do a server side data processing there was a lot of reading flat text data. Perl is still king at flat text processing. However with MySQL, PostGreSQL and Microsoft SQL Server 2000 being created and designed to be good enough to handle the large data sets, and with system resources that can fit on your mid range server. So PHP, Java servlets, ASP took Perl golden child status, as they are better designed to interact with the database, as well the ability to embed your code with your HTML simplifying the process.
So its place as the de facto language for all things web is rather dated... However it is still good for text processing and can do what it needs to do.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
GNU Unix!
And the book appeared more than 11 years ago, so indeed, it's about time. Now I only have to wait for it to appear in Debian stable ...
only viable scripting language choice
FTFY
I've fallen off your lawn, and I can't get up.
ok, now *that* was funny :)
I've fallen off your lawn, and I can't get up.
oh ... wait.
| Last night Larry Wall unveiled the first development release of Perl 6, joking that now a top priority was fixing bugs that could be mistaken for features.
Sounds good.
| The new language features meta-programming — the ability to define new bits of syntax on your own to extend the language, and even new infix operators.
Hey Larry, I found a huge bug which could be mistaken as a feature!
No coroutines. So sad. That still leaves Lua and Stackless Python as the only languages with symmetric, transparent coroutines without playing games with the C stack.
Neither Lua nor Stackless Python implement recursion on the C stack. Python and apparently Perl6/More implement recursion on the C stack, which means that they can't easily create multiple stacks for juggling multiple flows of control. That's why in Python and Perl6 you have the async/await take/gather syntax, whereas in Lua coroutine.resume and coroutine.yield can be called from any function, regardless of where it is in the stack call frame, without having to adorn the function definition. Javascript is similarly crippled. All the promise/future/lambda stuff could be made infinitely more elegant with coroutines, but all modern Javascript implementations assume a single call stack, so the big vendors rejected coroutines.
In Lua a new coroutine has the same allocation cost as a new lambda/empty closure. And switching doesn't involving dumping or restoring CPU registers. So in Lua you can use coroutines to implement great algorithms without thinking twice. Not as just a fancy green threading replacement, but for all sorts of algorithms where the coroutine will be quickly discarded (just as coroutines' little brothers, generators, are typically short lived). Kernel threads and "fibers" are comparatively heavy weight, both in terms of performance and memory, compared to VM-level coroutines.
The only other language with something approximating cheap coroutines is Go.
I was looking forward to Perl 6. But I think I'll skip it. The top two language abstractions I would have loved to see were coroutines and lazy evaluation. Perl6 delivered poor approximations of those things. Those approximations are okay for the most-used design patterns, but aren't remotely composable to the same degree. And of course the "most used" patterns are that way because of existing language limitations.
These days I'm mostly a Lua and C guy who implements highly concurrent network services. I was really looking forward to Perl6 (I always liked Perl 5), but it remains the case that the only interesting language alternative in my space are Go and Rust. But Rust can't handle out-of-memory (OOM). (Impossible to, e.g., catch OOM when creating a Box). Apparently Rust developers think that it's okay to crash a service because a request failed, unless you want to create 10,000 kernel threads, which is possible but stupid. Too many Rust developers are desktop GUI and game developers with a very narrow, skewed experience about dealing with allocation and other resource failures. Even Lua can handle OOM trivially and cleanly without trashing the whole VM or unwinding the entire call stack. (Using protected calls, which is what Rust _should_ add.) So that basically just leaves Go, which is looking better and better. Not surprising given how similar Go and Lua are.
But the problem with Go is that you basically have to leave the C worldbehind for large applications (you can't call out to a C library from a random goroutine because it has to switch to a special C stack; which means you don't want to have 10,000 concurrent goroutines each calling into a third-party C library), whereas Lua is designed to treat C code as a first-class environment. (And you have to meet it half way. To make Lua coroutines integrate with C code which yields, you have to implement your own continuation logic because the C stack isn't preserved when yielding. It's not unlike chaining generators in Python, which requires a little effort. A tolerable issue but doable in the few cases it's necessary in C, whereas in Python and now Perl6 it's _always_ an issue and hinderance.
Saw this and had some bad flashbacks to using Perl. What a monstrosity. Even a friend of mine who loved it admitted he could read his own code later on. If you have to write a one liner, fine, but I had to maintain actual code written in Perl. It makes my skin crawl just thinking about it.
I got tired of writing programs that looked like line noise.
Maybe you should have written better code.
"First they came for the slanderers and i said nothing."
It took him that long because he would write something and then spend the next few months trying to read it.
So PHP, Java servlets, ASP took Perl golden child status, as they are better designed to interact with the database.
Really? IMHO, nothing beats DBI.
..., as well the ability to embed your code with your HTML simplifying the process.
Ugh, this is why I don't like PHP or ASP. MVC all the way...which Perl has many frameworks for...
> So PHP, Java servlets, ASP took Perl golden child status, as they are better designed to interact with the database,
I think it has to do with readability and cost to maintain, not specific API design choices.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
If that was the first development release, what on earth was the 2010 release of Rakudo Star?
The problem with Perl 6 was never a lack of development releases, it's 15 years of NOTHING BUT development releases.
What the fuck is Perl and what asshole uses it? Is it anything like Fortran, Pascal, or Ada? Let it fucking die with dignity already.
ASP.NET MVC is going on 8 years old.
Better Perl code is not much more than line noise. You failed hard there.
I used perl a lot over the years.
comparing it to a compiled language (C, Ada, Fortran, etc) or a web centric (java, java script, php, etc) language is not a good comparison.
when I need something done (and needed more than the shell) and I had to maintain it.
I wrote it in perl.
all sorts of sysadmin widgets.
many are still being used today (15+ years later)
I wrote clean decent code with comments & modules.
finding the cpu & disk hogs, by the day, week & month.
who was running what when the system crashed.
cgi code for low volume web server tasks
updating DNS
queueing outgoing faxes & saving history
rotating log files and saving a limited number of copies.
how much code have you written ? and had it stay running for decades ?
the people that took over my positions when I changed jobs never had a problem updating the code or using it.
This is my opinion based on what little I know and understand of the rumors and lies Thanks, Randal
I agree. Ive written data intensive processing including data conversions.. and the only thing that has beaten it is c or c++. Ive written them in php and it would take four hours to run on 30 gb... but perl could do the same job in 1 hour
Next you're going to complain about how bad pencils are because you have bad handwriting.
Once a subject goes over the mock horizon, it gets pretty hard to distinguish entire discussion threads from line noise.
I wrote a couple of large projects in Perl last year, before switching to Python3 and never looking back. There is a plethora of reasons why Perl is ripe for abandonment:
- Hard to read code with multiple '$'s and '@'s on every line
- In-place string modification is asking for bugs
- Clumsy OOP
- Poor selection of publicly available libraries; some have critical bugs that have not been fixed for years
And all this before having to maintain code written by someone else, in a language better suited for one-liner programs.
DBI is stable, it just works. I have lots of headache in Every Single One of the database middleware. Except DBI.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
As a C/C++ programmer the Perl scripts I wrote usually ended up having at least as much of comments as code lines, just to make sure I could understand them next day. Even if one did not use the magic default variables or excessive regexp's, the code would always become unreadable before it was ready. And then there were still people who tried to make themselves gurus by writing the shortest and most cryptic Perl code possible.
The ability to add custom syntax.... Because regular perl syntax isn't confusing enough!!
And it is still garbage. But now it's old garbage, which You have been eating for the past eight years, so You are desensitized to its taste.
So, both Perl 6 and GNU/Hurd are finally production-ready? So let's start migrating Facebook and Google then...
cpghost at Cordula's Web.
Back in 2005 I remember hearing about how the fancy new Perl 6 VM was going to be super awesome. So I waited and waited. And then I waited some more.
Meanwhile, I'm 5 years into a personal project that's nowhere near ready to ship, so I think I finally understand what took him so long.
Congratz, Larry. You da man.
p.s. Obligatory: What year is it?
Perl syntax, as is, is already pretty hard for everyone to digest (if you have never maintained any perl written by a bunch of self-declared genius, don't try to comment), wait till all the geniuses can extend that language. I'll need to keep a machine gun under my desk, in case I go ballistic.
Same experience here. Say what you want about Perl 5 but it is still one of the fastest interpreted languages around.
I do a lot of prototyping in Python. But if i want speed, i usually use Perl.
perl6 is a complete overhall of the language. It isn't merely perl5++. They are similar, but they aren't compatible, which is why the perl5 interpreter will be maintained in parallel [so stated]. It has a huge number of new features, including real classes [instead of implementing a class as a hash].
The perl6 interpreter [written in perl6, BTW], will be able to run perl5 code (e.g. it hooks on .pm or .pm6, etc.) and run a mix of the two. It will also be able to run python code, ruby, javascript, etc. if one wants to add the front end. So, in some ways, it's like .NET. You can run a program comprised of perl6, perl5, python, C, etc. all coexisting in one program. Also, on the back end, perl6 will generate true byte code, and can generate javascript, python, or other backend languages.
You can also define your own operators (e.g. "nand" for not (x and y), or do full metaprogramming.
perl6 classes can define "how they're implemented" (e.g. implement me as a C struct, python dictionary, javascript hash, or java class, etc.). In other words, if you request a C struct binding, the data will be stored that way. So, you fill in your object, then you can pass it off to a C function without any glue code. In and out, in and out, back and forth, at extreme speed.
perl5 is not my main language (e.g. I make my living writing C code), but I've been coding perl5 for 20 years [and I maintain a codebase of 250,000 lines just for my personal scripts]. I've been following the progress for a few years now and I've been waiting for perl6 to give it a try.
perl6 has ripped off concepts from just about every other language--that's a good thing. Traits, mixins, interfaces(?), multimethods, a full set functional programming operations [like Haskell, Scala, etc.], full set operators [just like python].
What I've described is merely the tip of the iceberg, done from memory of what I was reading a year or two ago.
BTW, in case you didn't already know, slashdot runs on perl5 ...
Like a good neighbor, fsck is there
I have bad pencils because of bad handwriting :(
The cool kids jumped on the python bandwagon saying perl was old, but in all this time they have yet failed to:
- created a language that has libraries like perl has,
- created a scripting language that can execute sql safely like perl can,
- created a language that has regular expression support as part of the syntax (so you don't have to enter in yet another level of indirection and escape all the whatevers ' " \ / when you're trying to simply match some string easily),
- created a scripting language that is also fast.
Which are all the reasons I love and use perl.
Religion is what happens when nature strikes and groupthink goes wrong.
Thanks Larry :)
Political correctness is really just herd psychology pushed by insecure people who desperately seek social conformity.
BTW, in case you didn't already know, slashdot runs on perl5 ...
Is that supposed to be a plus or a minus?
Watch this Heartland Institute video
Now I only have to wait for it to appear in Debian stable ...
Watch this Heartland Institute video
only viable scripting language choice
FTFY
I used ReXX, you insensitive clod!
And it runs so well on all those Linux servers!
Don't put 'd' and 'ed' on the end of everything.
Somebody here is connected enough to do this...I really hope they'll see this, and do so...
Someone REALLY need to ask Larry Wall, to his face, how it feels to have been beaten to market by Duke Nukem Forever.
I think you should be a bit more careful about saying that PHP is better designed to interact with databases. It took quite a long time for PHP to implement _any_ sort of SQL injection protection, and with as many completely different (and completely incompatible) different methods of interacting with the database it's had over the years (PDO, PearDB,et al), it's pretty difficult to argue that it's in any way superior to DBI.
Python only viable scripting language choice
FTFY
But still no "advanced macros, non-blocking IO or much of synopsis 9 and 11"...
"It might be a 30- or 40-year language. I think it's good enough."
No, actually Perl6 is not 30+ years old. Its not a replacement for Perl5, no matter how much Mr. Wall would like it to be. There's a lot of working Perl5 programmers that wish the community calling itself Perl6 (which is totally distinct from the Perl5 community for all practical purposes, despite some attempts be leaders to force coordination on us) would acknowledge the fact that Perl6 is Perl Not at all, and call this language something different.
I don't know if Mr Wall realizes how much harm he's done to working Perl5 programmers by continuing to insist on calling this thing he's worked on "Perl" at all.
Peace, or Not?
Is it true that Duke Nukem Forever was the first commercial software written entirely in Perl 6?
- For the complete works of Shakespeare: cat
Except that their regex engine isn't very fast. I prototyped a project that used a lot of regexes in both python and perl and the python implementation was between 4 and 7 time slower. I really wanted to use python, but it wasn't the right tool for the job.
That's why anyone with a clue will see statements of "only viable" with comic disdain.
Say what you will, but perl is very, very good at parsing text.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Like I said. Viable.
I used REXX too, BTW. On the Amiga (which would be William S. Hawes's AREXX, of course.) The Amiga OS was the only OS where Rexx was properly integrated, IMO, along with a decent range of applications with ARexx ports you could use. It certainly isn't in Windows or Linux. Don't know about OS2, never dipped a toe in that.
I built an ARexx interface into our Imagemaster application when ARexx first came out, and every Amiga application we did thereafter (my company was one of the most broadly known, and easily one of the most profitable doing software for the Amiga -- small team, great products, proper compensation, great tech support, and only one competitor who was always playing catch-up (ASDG Inc.)), you could do just about anything you could think of with it high-level IPC the way it should be done, and doesn't seem to have been done since then. A real shame. Oh, and as a current OS X user, Apple-script is a horrific, broken kluge by comparison. Again, a real shame.
But viable beyond that... not really. Perl was what the powers that be always seemed to insist on, and Rexx simply didn't have the string handling chops that Perl did, so arguing always pretty much foundered on that point alone.
Today, we have Python, and Perl is not a viable choice in comparison. The only reason to choose Perl now is if you can't, or refuse to, learn a better way. Although there certainly is a lot of that, lol.
I've fallen off your lawn, and I can't get up.
Yes, it is. Unfortunately, it isn't maintainable the way the vast majority of programmers use it, and to do that you have to give up quite a large set of its features -- the ones that read like Sanskrit or APL. For that reason, I won't allow it to be used for any of our projects. If speed is an issue, we can always drop to c, which can be *both* maintainable *and* faster than Perl or Python. Because our style requirements don't rule out any language features. Just poor style, such as K&R.
For most anything else Python v2.latest is the obvious choice. Unless you need backwards compatibility (older OS envs), and then Python.notcurrent is the choice.
I've fallen off your lawn, and I can't get up.
Back in the late 1970s - early 1980s, I was approached by an engineer at a local company to test FORTH. A really cool language that was based on building your own new command built from base syntax. Isn't the idea of functions the same basic thing?
Self-importance and self-indulgence is the root of ALL evil.
It's supposed to be ironic, considering how every N months, another "perl is dead" meme gets posted to slashdot [usually as the result of an article posted by a dice shill]. This was mentioned at a perl conference in a talk by a core developer titled [something like] "Is perl really dead?". He went on to say that there are actually more jobs in perl than a number of other languages. IIRC, MS uses perl as the master control for building either the kernel or office.
In truth, I'm actually language agnostic. I've learned, used, [and forgotten] quite a few languages over the years. To me, a language is a tool in the toolbox, not a religious icon.
I recently taught myself python, just to see if I was missing something.
Starting out, I was against the indentation thing. That turned out to not be such a problem.
But, what is a serious problem is the way globals are handled. In most languages, symbols are globals if you don't declare them local to a given function. In python, it's the reverse--you say "global sym" inside the function. It also has some goofy rules about whether a symbol is global or not. If a global is written to in function x, it can be implicitly referenced in function y [without a global declaration]. But, if y tries to write to it, then y needs a "global sym" too--or the interpreter will flag it. This led to a whole host of problems. And no way to solve this by declaring "global sym" at file scope like virtually every other language. This is a major defect.
Also, python has no equivalent of "for (x = 0; x < 10; ++x)". You need to say "for x in range(10)". Fair enough. But, python, seems to have no equivalent to "for (x = 0; x < 10; ++x, ++y, z -= 6, cur = next)" or "for (x = ...; check_x(x); x = next_x(x))" without defining an iterator of some sort.
Plus, if there's a syntax error [on say a 100 line file], it takes the python interpreter takes 2+ seconds to spit it out. In that time, my "check all perl scripts" script that invokes "perl -c" on all files has processed 100,000 lines of perl code.
The stated mantras are:
Python -- there's one right/best way to do things
Perl -- there's many ways to do things
Having been used to perl's flexibility, I was surprised how difficult python was if I didn't write "idiomatic" python. In fact, despite having 200,000 lines of perl, I don't write "idiomatic" perl code. I've never used importer, carp, etc. I've always written my own equivalents. But, instead of my perl code looking like APL, it would be fairly easy to understand by a C programmer [which is one of my design goals].
Like a good neighbor, fsck is there
I'm not sure I'd reject a language out of hand just because people can write terrible code with it. I'd rather reject those programmers.
I do agree with you on K & R style, though. Vertical space is valuable real estate.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
REXX on OS/2 was pretty good. BTW, there have been several variants of REXX made by the inventor, like NetRexx.
>- created a language that has libraries like perl has,
I'm using Python exactly because there is a library for everything i need. Scientific Python, numpy, pygtk etc.
>- created a scripting language that can execute sql safely like perl can,
Python DB-API has prepared statements: ...execute("SELECT * FROM x WHERE a=?", 2)
>- created a language that has regular expression support as part of the syntax (so you don't have to enter in yet another level of indirection and escape all the whatevers ' " \ / when you're trying to simply match some string easily),
r"this is a regexp" where nothing needs to be escaped from Python. PLEASE no fucking special syntax for anything else that can go into a library.
>- created a scripting language that is also fast.
Pypy, Shedskin
Just a nitpick, but "failed to created" is not English. The correct form is either "failed to create" or "failed to have created". I have noticed a disturbing trend where native English speakers are now confusing present tense, past tense, and infinitives (yes, native speakers, and generally Americans). My only guess is that as non-native speakers climb the social totem pole (to stardom, for example), native speakers have started parroting their mistakes. And nothing trumps stardom, not even grammatical errors.
There's way more libraries in Python than perl now mang.
One of the goal (longer term, so don't expect it fully working with this preview release. Maybe neither with the final at christmas) is to allow other language being accessible to Perl6.
To quote one of the links:
But Larry was especially proud of Perl's ability to drop down into other languages. ("This is why we say all languages are really just dialects of Perl 6...") Python and Lua are even included in the Inline library. And Larry pointed out a new library that adds Ruby-esque rules, so exclamation points and question marks can be used at the end of identifiers. ("If that's what it takes to make Ruby programmers happy...")
Example:
- Inline-Perl5/ - Wraps a Perl5 interpreter as a module in Perl6 with data passing. Means perl5 and perl6 mixed *TODAY*. Works with compatibility down to all perl5's bugs/weirdness. Might still suffer limitation when passing some weird constructs around, and some speed limitation.
- v5 - abuse Perl6's ultra flexible grammar and meta programming to teach perl6 (...'s interpreters - like Raduko) to understand perl5 (...'s syntax). Should allow perfect passing of weird constructs, without any speed limitation. But is a new implementation of perl5 interpreter so might break some legacy code which unknowingly relied on bugs of the actual perl5 interpreter.
These 2 modules exist already and are used in the wild.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
perl6 is a complete overhall of the language. It isn't merely perl5++. They are similar, but they aren't compatible, which is why the perl5 interpreter will be maintained in parallel [so stated]. The perl6 interpreter [written in perl6, BTW], will be able to run perl5 code (e.g. it hooks on .pm or .pm6, etc.) and run a mix of the two. It will also be able to run python code, ruby, javascript, etc. if one wants to add the front end. So, in some ways, it's like .NET. You can run a program comprised of perl6, perl5, python, C, etc. all coexisting in one program.
Speaking of which:
- Inline Perl5 : hooks into the (still maintained) perl5 interpreter to run Perl5 code down to the latest bugs/weirdness.
- v5: (ab)uses the ultra flexible grammar and meta programming of Perl6 ('s interpreter - like Raduko) so that it can interpret Perl5 ('s language syntax).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Perl6 ('s interpreter - like Raduko)
That should be "Rakudo" (jp: way of the camel)
I shouldn't be posting when I'm that much tired.
perl6 (...'s interpreters - like Raduko)
That should be "Rakudo" (jp: way of the camel)
I shouldn't be posting when I'm that much tired.