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.
Perl 6 vs. Python 3 - who will get to 1000 users first?
Here's URLs where the event was announced.
http://www.meetup.com/SVPerl/e...
http://perl6releasetalk.ticket...
Actually, if you look closely, the GP is actually a Perl script for computing the Fibonacci Sequence.
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.
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 ...
| 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.
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."
This reminds me of the old joke about Forth: Real programmers can tell the difference between Forth and line noise.
Well you CAN write maintainable code in perl, you just have to use some discipline. Turn "use strict;" on everywhere, break your project up into packages across functional lines and have unit tests on everything. You know, all that stuff that no companies ever do. Given the choice between having to maintain a perl project and a ruby one, I'd take the perl project every time. At least you'll have some chance that the developers wrote some decent code, if only in self defense since they usually end up maintaining it themselves for a few years.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
> 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.
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
The best part is you can append gibberish to it and tell everyone that you've done lots of work and nobody will know the difference. Hell, it might actually do something useful!
I am going to admit that I write (or have written) some Perl. I've even given it away. I'd also like to take this time to apologize for my Perl.
I wrote a "safe list" script for a friend, it was really damned simple. People signed up and sent email messages to each other for the purposes of MLM - that's not why I wrote it, that's just what people did with it. It had a small but functional administration panel. It was about as secure as a screen door. Usernames and passwords were in a plain text file - you were SUPPOSED to move it and chmod it but I don't think anyone ever did even though it was mentioned a few times in the README.TXT.
Anyhow, he wanted to sell the script. I said that was cool. I was more interested in the code so I made a few versions. It was usually purchased a few times and then hit Usenet in .zip form. They could have at least taken my email out of the damned thing if they were going to steal it. I've long since dropped that email. The last version (released in something like 2002) was free for the taking and my friend charged to install and customize it as he'd learned a little by then.
So here's the easiest to install script and the least secure thing on the internet - plain text files, indeed, and I *still* see it installed from time to time. I can only imagine that the email address still gets emails from people asking what chmod means or how to upload the file or how they put it in their C drive and nobody seems to be able to access it from the internet.
Yup... My Perl... Breaking machines, frustrating users, and being insecure for 25 years and running.
A little part of me is kind of proud of that but my formal statement is, indeed, an apology.
"So long and thanks for all the fish."
- Hard to read code with multiple '$'s and '@'s on every line
I prefer to have variables differentiated (scalars, arrays and hashes) and clearly identified from other syntax or text. It makes code more readable IMHO.
- In-place string modification is asking for bugs
You mean string interpolation? This in fact is one of Perl strengths
$str = "There are $num apples".
is clearer and less busy, easier to remember than
str = "I have {a} apples".format(a=num)
- Clumsy OOP
Specifics? There are some valid criticism of Perl's 5 OOP but the success of CPAN and a long list of highly successful reusable OO modules highlights its practical side.
- Poor selection of publicly available libraries; some have critical bugs that have not been fixed for years
Now you are well into troll territory or you really haven't used Perl much. DBI, CGI, LWP, IO::Socket, HTML::Parser, GetOpt::Long, Devel::NYTProf (not really a module but a totally awesome profiler) the list goes on.
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
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.
Now I only have to wait for it to appear in Debian stable ...
Watch this Heartland Institute video
"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?