Perl 6 Released(perl6advent.wordpress.com)
perl6advent.wordpress.com
Perl 6 Released
https://perl6advent.wordpress.com/
190 comments
This is probably one of the best unintended things to ever happen. Using other languages is the equivalent of world travel for a human. All the worst code I've ever seen is written by one language programmers, and perl is among the top of that category for a variety of reasons. I have seen maintainable, performant perl5, but the barrier is high.
That's a nice way of looking at the brain drain in the Perl community over the last decade. And, you're probably right. If we think in terms of general health of the free and open programming world, it has been remarkably improved by some of the folks who've migrated through different languages over the years. To the point where we have not one, not two, not a dozen, really nice languages with excellent communities, but several dozens of them (and at least two dozen that are large enough and effective enough to build pretty much anything with them). We have an embarrassment of riches, frankly.
There was a time when going into a large project, you could choose between Java, C/C++, or Perl. There were outliers (even some with significant footholds in some industries, like TCL), but those were the options I saw in front of me at every junction. Today, we can choose to work in so many languages, and get good results, find good community, find good library and tooling and cross-platform support, and enjoy all the stuff we found so nice about Perl way back when.
There was a time when going into a large project, you could choose between Java, C/C++, or Perl. There were outliers (even some with significant footholds in some industries, like TCL), but those were the options I saw in front of me at every junction. Today, we can choose to work in so many languages, and get good results, find good community, find good library and tooling and cross-platform support, and enjoy all the stuff we found so nice about Perl way back when.
Indeed, perl people were and still are fanatical about easy text (i.e. richer than cstring) manipulation, and those other two languages fell short back then and even today you still have to do gymnastics for things perl does easy and well out of the box. Text is something that a majority of applications need to deal with at some point, and a source of hard bugs and security issues when done wrong. I am thankful for perl's influence, but I disregard it as a serious language outside of some niches like ETL and log processing. I'm skeptic that perl6 will change that, and there's been so much progress elsewhere that failure doesn't matter much, but I will wait a couple more years to see how the community responds and take a look at it myself if it pans out.
Perl 6's semantics are so different from Perl 5 it should effectively be a new language. It has metaprogramming macros like CL, concurrency that's as well thought out as Erlang/OTP, they eliminated all of the syntax warts that Perl 5 had with all the implicit magic, and out-of-the-box is absolutely fantastic with rules/grammars that I'd argue it's about as good as Haskell's Parsec. (Speaking of Haskell, I've seen some code that's written in a purely functional Haskell-ish fashion in idiomatic Perl 6.) Oh and there's finally a good object system instead of stop-gapping with Moose (which actually was kind of fun, meta-object programming was cobbled on, but I digress).
The take away - don't conflate it with your 1995 Perl. It's about as similar to Perl 5 as C#1 (pre-generics, pre-LINQ, pre-RX, pre-async, pre-NuGet, pre-basically-everything-good) is to modern C#.
The take away - don't conflate it with your 1995 Perl. It's about as similar to Perl 5 as C#1 (pre-generics, pre-LINQ, pre-RX, pre-async, pre-NuGet, pre-basically-everything-good) is to modern C#.
> All the worst code I've ever seen is written by one language programmers
Some of the worst code I've seen was written by people who think the choice of programming language matters all that much (the rest was written by beginners or physicists).
Some of the worst code I've seen was written by people who think the choice of programming language matters all that much (the rest was written by beginners or physicists).
Happened to me, had to choose a language to write a web crawler in ended up with Python (this was 5 or 6 years ago.)
We got a contractor in who was a Perl guru, he wrote one of the popular web frameworks but even he couldn't put forwards a good case for using it over PHP.
And now in the company my brother works for (a cloud hosting provider) they are currently switching from Perl to Python.
We got a contractor in who was a Perl guru, he wrote one of the popular web frameworks but even he couldn't put forwards a good case for using it over PHP.
And now in the company my brother works for (a cloud hosting provider) they are currently switching from Perl to Python.
Speaking as the primary author of a book in one of the popular perl web frameworks (who is having difficulty doing stuff other than perl because a. my skills in perl are too much in demand, and b. Because for most of my normal work I haven't found anything perl can't do as easily or easier than other tools yet) here's my semi-considered opinion.
Meh, all the dynamic languages are basically the same. They're all basically things that manpipulate strings and C pointers. For perl/python/ruby/js here's what I'd sort of recommend:
* Pick from your team's strength, unless:
* Lots of turnkey logic, code quality and debug tools are not a priority, and you want to be able to hire fast and cheap: PHP.
* Lots of turnkey logic, per-performance isn't a problem and you want some higher order programming capability: Ruby.
* You want to manage a java-like large team for not so trivial logic, and you prioritise uniformity over expressivity. Python. Also python is a good environment for academic work as it helps the academic programmers not shoot themselves in the foot so much and academic code is a mess. Which is why python is such a good extension language for other tools.
* Async greenfield stuff where you don't need to worry about external libraries much: javascript. Also the only game in town for web front ends (plus its transpiling friends). Javascript is like a syntatically impoverished perl in this regard.
* You've got a whole bunch of mess in business logic and/or systems logic that you need to encapsulate, and you've got a small highly capable team who want to prioritise expressivity over uniformity. Perl excels here. So does python, but it'll make you do even more horrible things papering over the mess.
Regarding the last point, I believe if it reaches a tipping point perl 6 will be a good thing for async, multicore and parsing related stuff, and should be long-term productive and reduce the requirement for having as highly capable and a disciplined team that is really a requirement for non-trivial perl5 code bases.
Also perl5 is second to none for programming language back compat. I had a decent sized non-trivial project I'd written for internal (research) purposes, then neglected for several years. Then I had to look at the running code again. I'd been through several minor OS upgrades, moved to a completely different OS and gone through at least three major versions of perl. Aside from a couple of missing CPAN modules that I had forgotten about in the Makefile.PL, everything was fine out of the box.
Meh, all the dynamic languages are basically the same. They're all basically things that manpipulate strings and C pointers. For perl/python/ruby/js here's what I'd sort of recommend:
* Pick from your team's strength, unless:
* Lots of turnkey logic, code quality and debug tools are not a priority, and you want to be able to hire fast and cheap: PHP.
* Lots of turnkey logic, per-performance isn't a problem and you want some higher order programming capability: Ruby.
* You want to manage a java-like large team for not so trivial logic, and you prioritise uniformity over expressivity. Python. Also python is a good environment for academic work as it helps the academic programmers not shoot themselves in the foot so much and academic code is a mess. Which is why python is such a good extension language for other tools.
* Async greenfield stuff where you don't need to worry about external libraries much: javascript. Also the only game in town for web front ends (plus its transpiling friends). Javascript is like a syntatically impoverished perl in this regard.
* You've got a whole bunch of mess in business logic and/or systems logic that you need to encapsulate, and you've got a small highly capable team who want to prioritise expressivity over uniformity. Perl excels here. So does python, but it'll make you do even more horrible things papering over the mess.
Regarding the last point, I believe if it reaches a tipping point perl 6 will be a good thing for async, multicore and parsing related stuff, and should be long-term productive and reduce the requirement for having as highly capable and a disciplined team that is really a requirement for non-trivial perl5 code bases.
Also perl5 is second to none for programming language back compat. I had a decent sized non-trivial project I'd written for internal (research) purposes, then neglected for several years. Then I had to look at the running code again. I'd been through several minor OS upgrades, moved to a completely different OS and gone through at least three major versions of perl. Aside from a couple of missing CPAN modules that I had forgotten about in the Makefile.PL, everything was fine out of the box.
I have a nagging feeling that server side JavaScript will soon become the new PHP. It is getting more and more popular among not-so-good programmers, and given its loose syntax I think it will lead to disastrous code. Not to mention that ECMA is working toward ADDING new feature to the language instead of deprecating some obscure ones, which would make the language easier to use.
Of course, PHP makers made their share of mistakes with their decisions - register_globals, safe_mode (which was not), inconsistent function naming in standard libs, myriad of weird bugs (like syntax error (still) throwing HTTP response 200),...
Of course, PHP makers made their share of mistakes with their decisions - register_globals, safe_mode (which was not), inconsistent function naming in standard libs, myriad of weird bugs (like syntax error (still) throwing HTTP response 200),...
> Not to mention that ECMA is working toward ADDING new feature to the language instead of deprecating some obscure ones, which would make the language easier to use.
We'll see what happens longer-term. Certainly until recently the focus has been on the web (and deprecating features on the web is rather pointless: the web still supports things that were deprecated two decades ago, as dropping support breaks sites which makes users change browser or stick with an older version).
There's plenty of things listed in Appendix B of the spec, "Additional ECMAScript Features for Web Browsers", which contains much of the worst parts. Perhaps more will move there in the future, or to some separate section of previously-standardised-but-now-optional features.
We'll see what happens longer-term. Certainly until recently the focus has been on the web (and deprecating features on the web is rather pointless: the web still supports things that were deprecated two decades ago, as dropping support breaks sites which makes users change browser or stick with an older version).
There's plenty of things listed in Appendix B of the spec, "Additional ECMAScript Features for Web Browsers", which contains much of the worst parts. Perhaps more will move there in the future, or to some separate section of previously-standardised-but-now-optional features.
As a fan of node.js, I'm afraid you are probably right... and not just front end guys. Some of the most horrific JS code tends to come from (imho) "enterprise" C# and Java devs... there are some patterns you just do not need to do in a dynamic language environment... and only complicates things for no real gain.
There are some really beautiful patterns emerging in the JS community though. React (mercury and others), Redux, RxJS, Koa, etc... But it takes a different kind of discipline to break up modules, and write pure functions instead of relying on typical OO paradigms for systems development. I cringe every time I see a senseless/useless DI/IoC system in JS that adds nothing but indirection and complexity (looking at you Angular).
There are some really beautiful patterns emerging in the JS community though. React (mercury and others), Redux, RxJS, Koa, etc... But it takes a different kind of discipline to break up modules, and write pure functions instead of relying on typical OO paradigms for systems development. I cringe every time I see a senseless/useless DI/IoC system in JS that adds nothing but indirection and complexity (looking at you Angular).
" I cringe every time I see a senseless/useless DI/IoC system in JS that adds nothing but indirection and complexity (looking at you Angular)."
Isn't it supposed to make testing easier? (Personally I never managed to get the Angular hype, but I am a Python dev mainly).
Isn't it supposed to make testing easier? (Personally I never managed to get the Angular hype, but I am a Python dev mainly).
If you're doing node-style (cjs) modules, you can use something like proxyquire[1] with testing to inject dependencies without complicating your modules, or creating logical indirection. If the only reason you have DI is for testing in a scripted platform, you're probably doing something wrong.
You can write, compose and composite plain objects and pure functions in JS modules that can be tested very easily without resorting to complex DI systems (with naming disconnects even).
[1] https://www.npmjs.com/package/proxyquire
You can write, compose and composite plain objects and pure functions in JS modules that can be tested very easily without resorting to complex DI systems (with naming disconnects even).
[1] https://www.npmjs.com/package/proxyquire
> debug tools are not a priority, and you want to be able to hire fast and cheap: PHP.
I had a quick squizz at XDebug, and I'll try to remember it's existence next time I need to do some php debugging. On the other hand it looks quite high friction what with the extra config required.
For the normal use case I use `perl -d myscript.pl` as my goto debug tool, and I use the amazing test infrastructure to try to ensure that I'm debugging tests rather than interactive code. For web front end interactions I'm usually looking at:
For old codebases that have never run aside from inside apache, usually it's a matter of up to a day to decouple from the web server, although botched incrementally accreted mod_perl codebases can be much harder to tame (couple of months).
For the normal use case I use `perl -d myscript.pl` as my goto debug tool, and I use the amazing test infrastructure to try to ensure that I'm debugging tests rather than interactive code. For web front end interactions I'm usually looking at:
perl -d `which plackup` dev_server.psgi
For old codebases that have never run aside from inside apache, usually it's a matter of up to a day to decouple from the web server, although botched incrementally accreted mod_perl codebases can be much harder to tame (couple of months).
I can't compare to the tools you mentioned since I haven't done much PHP in the last 10 years, but for Perl, I would strongly recommend you check out the following (Most are from the CPAN):
* For a graphical IDE: Komodo or Padre or Eclipse with EPIC (great debugger support in those, since Perl 5's built-in debugger is pretty old-skool, requiring significant skill and experience to use effectively)
* For code quality/standards static analysis: Perl::Critic
* For performance profiling: Devel::NYTProf (seriously one of the best profilers I've used in any language)
* For test coverage analysis: Devel::Cover
* For benchmarking: Benchmark (core module) and friends
* A REPL: Devel::REPL or Reply
* On-demand debugging: Enbugger and Devel::Trepan
* Unit testing: Test::More (and there are many, many other Test::* modules for anything you can think of that use the same general testing framework as the basic Test module that comes with Perl 5)
I'd have to disagree with code quality in regards to PHP. While the way it's traditionally done can have code quality problems, that isn't something which is inherent in the language. I've had great results working with Laravel. At least for my use case, it's basically just been a better Rails that happens to be in PHP. It's also compatible with HHVM and Hack, which can be useful depending on your needs.
I'd have thought that the security record of PHP would give Perl the edge, but perhaps that wasn't evaluated.
I don't know.. this presentation is pretty discouraging: https://media.ccc.de/v/31c3_-_6243_-_en_-_saal_1_-_201412292...
The track record for PHP in recent years has been pretty good.
The track record for PHP in recent years has been pretty good.
That was covered fairly extensively here[1], and there's some problems with that talk. First and foremost, the modules he's referring to are either not core, or deprecated (CGI). It's really more a case of poor programmer behavior and slightly confusing behavior in a once core (and long known to be problematic and avoided) recently (at the time) deprecated core module than a language problem.
1: https://news.ycombinator.com/item?id=8813479
1: https://news.ycombinator.com/item?id=8813479
argh too many parentheses in your reply. Short answer, need to develop on perl/sharedhosting fast? [pull this trick](https://www.reddit.com/r/perl/comments/3xb6xz/neat_trick_for...).
I too have to learn Python for the machine learning libraries. CPAN has very little ML.
> one of the popular web frameworks
Which?
Which?
Pretty sure the vagueness was intentional so as not to identify him.
Plus I can't remember cos it was a conversation we had 5 years ago. We talked over MVC and open source (we both had open source projects) PHP, Perl, C# and Python weighing up the best option to write all the code in. Ended up using Python. It used a multi threaded library and crashed every so often with all sorts of weird errors. Never got to the bottom of it.
How is it really advanced?
I was under the impression that it's just another dynamic scripting language semantically equivalent to Perl5, Python, Ruby, JavaScript, and so on.
And obviously new languages of this kind aren't going to be very successful or interesting because knowing and using JavaScript is going to be mandatory forever due to browsers and with Babel and ES6/7 it's as good as any other such language.
Plus in addition to JavaScript, Ruby, Python and PHP have a lot of momentum as well.
I was under the impression that it's just another dynamic scripting language semantically equivalent to Perl5, Python, Ruby, JavaScript, and so on.
And obviously new languages of this kind aren't going to be very successful or interesting because knowing and using JavaScript is going to be mandatory forever due to browsers and with Babel and ES6/7 it's as good as any other such language.
Plus in addition to JavaScript, Ruby, Python and PHP have a lot of momentum as well.
I wouldn't discount language advances, there's kind of a Renaissance happening with languages the past couple years... even newer options Closure/ClosureScript along with new looks at Erlang, Haskell, F# etc... and JS bringing in new patterns.
WebAssembly will offer many options as browser adoption happens and cross-compilation with support for source maps is becoming very common as well.
I'm a fan of JS and ES5/7 in particular... that doesn't mean that other options won't take root. JS has plenty of advantages in that it's the same code client/server, less disconnect in objects, serialization constructs built in (JSON), easy translation to/from dbms (no ORM needed), etc. Just the same, a decade ago, everyone avoided JS like the plague.
WebAssembly will offer many options as browser adoption happens and cross-compilation with support for source maps is becoming very common as well.
I'm a fan of JS and ES5/7 in particular... that doesn't mean that other options won't take root. JS has plenty of advantages in that it's the same code client/server, less disconnect in objects, serialization constructs built in (JSON), easy translation to/from dbms (no ORM needed), etc. Just the same, a decade ago, everyone avoided JS like the plague.
This is impossibly exciting. Most people don't realize it yet, but it's like a programming language hand grenade just went off in the world...little bits of the new paradigms in Perl 6 are going to start winding their way into languages of the future.
I first remember learning about rumors around the development of Perl 6 about the time I picked up Perl 5 for the first time. I had been doing a bunch of C and C++ code (and a smattering of Java) up to that point, but coding in Perl was like hitting the idea accelerator. At the time (programming resources on the Internet were few and far between) I didn't even know where to look to find resources to do things in C++ that were quick one-off scripts in Perl. Need CGI? No problem. Mucking around with a database, here ya go.
I jettisoned C++ and dove heavily into Perl for years after that. I'm pretty sure that Perl made me a much worse programmer (it turns laziness into a kind of opiate), but a better conceptual developer -- I now had a much better idea of what computers could do, and didn't have to reinvent an entire civilization every time I wanted to do something (not a joke, where and when I worked, I was partially responsible for working on a pre-STL String library for C++, that's where we were in the world). Perl was really the first time I had encountered the productivity benefits a true high-level language could bring.
I've since abandoned Perl and have moved onto Python for day-to-day. There's lots of electrons spilled by many former Perlers who've made similar transitions. I've never really liked Python in the same way I liked writing Perl. With Python I've always felt like I'm assembling Tinker Toys or an erector set into a thing. It's quick to build and it works in the end but there's not much passion in it. With Perl I always felt like I was writing poetry -- code just sort of fell out of me.
I thought about checking out Go, but there's something about the sort of terse opinion the language designers have about the language that's made me feel like the entire language is a premature optimization that's going to go stale quick.
Perl 6 feels like we've just entered a new evolutionary period, where we've been given all new tools, where the opinion is careful inclusionism. It's like being stuck writing couplets and haiku in Perl 5 and now we can write anything.
Congratulations Larry et. al. This has been a long time coming, and I hope this is an amazing start!
I first remember learning about rumors around the development of Perl 6 about the time I picked up Perl 5 for the first time. I had been doing a bunch of C and C++ code (and a smattering of Java) up to that point, but coding in Perl was like hitting the idea accelerator. At the time (programming resources on the Internet were few and far between) I didn't even know where to look to find resources to do things in C++ that were quick one-off scripts in Perl. Need CGI? No problem. Mucking around with a database, here ya go.
I jettisoned C++ and dove heavily into Perl for years after that. I'm pretty sure that Perl made me a much worse programmer (it turns laziness into a kind of opiate), but a better conceptual developer -- I now had a much better idea of what computers could do, and didn't have to reinvent an entire civilization every time I wanted to do something (not a joke, where and when I worked, I was partially responsible for working on a pre-STL String library for C++, that's where we were in the world). Perl was really the first time I had encountered the productivity benefits a true high-level language could bring.
I've since abandoned Perl and have moved onto Python for day-to-day. There's lots of electrons spilled by many former Perlers who've made similar transitions. I've never really liked Python in the same way I liked writing Perl. With Python I've always felt like I'm assembling Tinker Toys or an erector set into a thing. It's quick to build and it works in the end but there's not much passion in it. With Perl I always felt like I was writing poetry -- code just sort of fell out of me.
I thought about checking out Go, but there's something about the sort of terse opinion the language designers have about the language that's made me feel like the entire language is a premature optimization that's going to go stale quick.
Perl 6 feels like we've just entered a new evolutionary period, where we've been given all new tools, where the opinion is careful inclusionism. It's like being stuck writing couplets and haiku in Perl 5 and now we can write anything.
Congratulations Larry et. al. This has been a long time coming, and I hope this is an amazing start!
All this progression rings true, but also the initial attraction of Perl. Back in the late '90s I used Perl at a job where everyone else worked in C. This was in the days that programmers of compiled languages were skeptical of interpreted languages. One day a friend invited me by where he worked, where the sysadmin was a "real computer guy". The sysadmin turned out to be a man with long hair and a long gray beard. He was using a very thin Sony laptop with Linux and a command-line TTY (he said he'd never bothered to install X-Windows) and after he deployed a new release of the company's code using a single command and started nmap running on the internal network (he wanted to see who else was running a Unix), he asked me what sort of programming I did. I was a bit cowed, and apologetically said that I didn't really program, I only did scripting in Perl. He looked at me in the eye for the first time and said, "Perl is most bodaciously a real programming language."
Seeing Perl 6 release notes like "Use of EVAL now requires a declaration of ‘use MONKEY-SEE-NO-EVAL’" and "Non-digit unicode characters with a numeric value (½ and such) can now be used for that numeric value" reminds me of the nerd coolness of Perl, so different from the straightforward sensible air of Python. I don't see many deep-hacker sysadmins these days, but I hope the excitement of Perl 6 can inspire some inefficiently marvelous coders...
Seeing Perl 6 release notes like "Use of EVAL now requires a declaration of ‘use MONKEY-SEE-NO-EVAL’" and "Non-digit unicode characters with a numeric value (½ and such) can now be used for that numeric value" reminds me of the nerd coolness of Perl, so different from the straightforward sensible air of Python. I don't see many deep-hacker sysadmins these days, but I hope the excitement of Perl 6 can inspire some inefficiently marvelous coders...
Haven't looked at perl in quite a while... just seeing your comments on the release notes brings a smile to my eye... as opposed to JS not fixing the text strings to use UTF-8 from UCS16 as it might "break" something... as opposed to all the new and old code that behaves unexpectedly.
I always loved how simple it was to do simple things in perl... I've been hoping to find something I need go for, so I can actually dig into it... far more likely to find an excuse to use perl 6 sooner.
I always loved how simple it was to do simple things in perl... I've been hoping to find something I need go for, so I can actually dig into it... far more likely to find an excuse to use perl 6 sooner.
I have trouble learning Python for the past decade, after I learned Perl in order to deal with DNA sequences and BLAST APIs in college. Although its syntax is straight forward, I failed to find any inner feeling to comprehend it.
I thought it is only me. I share exact same experience. After I programmed in Perl for almost 1.5 year.I switched to python for just fun . But I never comprehend deeply whats going on in python like I do in Perl , even though I have written advanced code in python.
I've always felt like I hit weird and unexplainable performance walls in Python...my code is either quite fast, or quite slow, and the syntax differences that cause that aren't always clear. With Perl 5, things just sort of chug along at a predictable Perl speed and you could always try to tune certain parts for more speed, but if you didn't bother you had a reasonable idea at how it should perform. Things like this always make me feel like Python is doing things I don't understand.
That really shouldn't be the case. You get hashtable namespace lookups slowing everything down in either language. Beyond that, there shouldn't be any real barrier. Did you try profiling your Python?
> We will continue to ship monthly releases, which will continue to improve performance and our user’s experience.
Is that a Freudian slip? Do they really only have one user? :-)
Is that a Freudian slip? Do they really only have one user? :-)
Ugh, good catch. Looks like someone fixed it up already, thanks.
Reminds me of a friend whose band cut an album back before anybody could do it, and got a local music chain to put them on the shelves. A month later, he bought a single copy from that store, explaining, "I just wanted to double my record sales"
I'm really excited about Perl6, it is so jam packed with interesting novel features, that it serves as an amazing testbed for stretching the limits of what programming languages are capable of. I always feel that Ruby was a language that came out of Perl; a subset of it's features, carefully selected and implemented with the knowledge of what did not go too well with Perl. This might just happen again with Perl 6, judging from the exotic features it brings together.
Thanks Larry and co! So this Christmas it did happen :)
Thanks Larry and co! So this Christmas it did happen :)
Congrats! The new regex features sound exciting ("Dramatically reforms and sets a new standard in regex syntax, which scales up to full grammars – powerful enough to parse Perl 6 itself")
I really liked the post that precedes the submitted one, in which Perl 6 is described as a teenager being adopted into a family, "An Unexpectedly Long-expected Party" https://perl6advent.wordpress.com/2015/12/24/an-unexpectedly...
I really liked the post that precedes the submitted one, in which Perl 6 is described as a teenager being adopted into a family, "An Unexpectedly Long-expected Party" https://perl6advent.wordpress.com/2015/12/24/an-unexpectedly...
And also interesting unicode features in the regexes... \d matches anything that is a digit in unicode for example. What if you only want ascii though, like for computer languages and maybe security?
EDIT: security as in, no similar-looking but different characters to confuse users etc...
EDIT: security as in, no similar-looking but different characters to confuse users etc...
Guess one can always do [0-9]+. Though I can't see why, for example, an arabic numeral pose a security problem. ISIS?
There are a number of security issues, mostly around using "look alike" Unicode characters in phishing/impersonation attacks. See, for example:
http://unicode.org/reports/tr36/ http://unicode.org/faq/security.html https://www.blackhat.com/presentations/bh-usa-09/WEBER/BHUSA...
http://unicode.org/reports/tr36/ http://unicode.org/faq/security.html https://www.blackhat.com/presentations/bh-usa-09/WEBER/BHUSA...
Learn X in Y Minutes[0] is a fresh and quick intro to Perl6. It looks jolly good, readable(!) and quite fun!
I hope I get to work on a project in Perl6.
[0] https://learnxinyminutes.com/docs/perl6/
[0] https://learnxinyminutes.com/docs/perl6/
Also http://perl6intro.com/ is a good intro.
First thing I read is:
#`(
Multiline comments use #` and a quoting construct.
(), [], {}, 「」, etc, will work.
)
Quoting is highly generalised in Perl 6. Comments happen to be more feature rich and dynamic than other languages. They aren't simply ignored by the compiler but completely parsed and used in a variety of ways. The flexibility looks odd because it's meant more for quoted string interpolation, but reuses the same mechanism for comments. Generality of concepts is a common theme throughout Perl 6, if something looks round and spins it should be a wheel.
For example all of the literate style POD6 comments are accessible within a variable as a fully structured tree in the $=pod variable. The 'q' quoting context in the main language allows you to use any matched quote/bracket from unicode as the markers of the start and end of a string or regex, or comments as you've picked up on.
This is super helpful if you want all sorts of weird quotes and brackets inside of a string and still have it interpolated for variables for example.
For example all of the literate style POD6 comments are accessible within a variable as a fully structured tree in the $=pod variable. The 'q' quoting context in the main language allows you to use any matched quote/bracket from unicode as the markers of the start and end of a string or regex, or comments as you've picked up on.
This is super helpful if you want all sorts of weird quotes and brackets inside of a string and still have it interpolated for variables for example.
say q⧚This string has a "'weirdly quoted bit in'"!⧛;
This string has a "'weirdly quoted bit in'"!
As someone that has spend significant time in Perl5, why would they use something like `$=pod`? I get that the name starts with '=' just like the pod syntax, but that doesn't mean it needs to be in the variable name. I would almost just rather that they have some sort of namespace just for 'special' variables like Python with their 'dunder' variables (i.e. double-underscore like __doc__).
I find it charming. It doesn't need to be the way that particular special variable is done, but twigils are a thing in Perl 6, and I think this is a reasonable use of them.
You still have to check the docs for the dunder variables in Python. Having the same special character convention (like __var__) doesn't magically make me aware of what they all are and what they all mean. And, I've done enough Python programming to know it's a crapshoot to google for them (just as it's a crapshoot to google for sigils and twigils in Perl). You just have to know where to look for the right docs or know who to ask for where to look for the right docs (perldoc perlvar, in the case of Perl...I assume there's something similar for Perl 6, and I don't remember what it is for Python).
You still have to check the docs for the dunder variables in Python. Having the same special character convention (like __var__) doesn't magically make me aware of what they all are and what they all mean. And, I've done enough Python programming to know it's a crapshoot to google for them (just as it's a crapshoot to google for sigils and twigils in Perl). You just have to know where to look for the right docs or know who to ask for where to look for the right docs (perldoc perlvar, in the case of Perl...I assume there's something similar for Perl 6, and I don't remember what it is for Python).
There is a special namespace like that. In fact, there are several, and they are selected by placing a second specials character after the sigil.
I've seen parsed comments in TCL and I didn't like them there. Honestly this generalization sounds like another way to write-only code, especially the unicode brackets.
Only if you're the kind of moron that would do it to begin with. At no point is anyone saying you should use weird quoting in comments at all. The parsed comments are used to populate dynamic documentation related to functions and classes that you can inspect at runtime. What's so bad about that?
Hi Ultimatt,
I was saddened when I saw that someone who loves Perl 6 used the word 'moron'. It is "closely tied with the American eugenics movement" according to wikipedia and is a deprecated diagnostic categorization of someone having a mental age of 8-12 years old -- an audience we supposedly wish to attract, not repel.
I'm not at all meaning any moral judgement. I've used such words myself in the past in much more terrible and significant ways. I'm just feeling low about how unkind we can sometimes be to others and sad to see these few opportunities on HN to discuss Perl 6 ending up sidetracked not only by what might be called trolling but also by seeing P6ers (including me sometimes) making things worse.
I thank you for and want to help sustain your passion about the technical aspects of Perl 6. I'm also hoping to encourage more compassionate ways of connecting with all folk, including trolls, and to being passionate about that too.
And a merry new year to all. :)
I was saddened when I saw that someone who loves Perl 6 used the word 'moron'. It is "closely tied with the American eugenics movement" according to wikipedia and is a deprecated diagnostic categorization of someone having a mental age of 8-12 years old -- an audience we supposedly wish to attract, not repel.
I'm not at all meaning any moral judgement. I've used such words myself in the past in much more terrible and significant ways. I'm just feeling low about how unkind we can sometimes be to others and sad to see these few opportunities on HN to discuss Perl 6 ending up sidetracked not only by what might be called trolling but also by seeing P6ers (including me sometimes) making things worse.
I thank you for and want to help sustain your passion about the technical aspects of Perl 6. I'm also hoping to encourage more compassionate ways of connecting with all folk, including trolls, and to being passionate about that too.
And a merry new year to all. :)
All insults have a similar history - "idiot" is the same kind of thing, just from a little further back in history.
I guess the intention is to let you use whatever form of parenthesis inside the comment without causing problems.
Perl was probably the first language I did interesting stuff in (yay IRC-bots, who didn't write one in Perl) but I gradually moved on to other languages. I didn't keep up with it at all, only knew that Perl6 took forever. Then I read up on Perl6 and now I'm really excited about the language. One of the projects I want to work on involves building a DSL, most likely an external one. I was pretty set on using ANTLR4 for it but now I'm seriously thinking about Perl6 as that seems to be one of the strength of the language.
Guess what you can do both at the same time! :D There is already a module which converts an ANTLR4 grammar into a full Perl 6 grammar which then provides a ready made parser for you :) https://github.com/drforr/perl6-ANTLR4
> Perl was probably the first language I did interesting stuff in but I gradually moved on to other languages
Same here. But recently I had to convert a strange proprietary file format from a poll into CSV for a personal project of mine, and I decided to use Perl (5) just for nostalgia sake. I got a solution in minutes despite not having used Perl in years and I enjoyed programming on it, I'd say more than Python and sometimes bash which are my go-to scripting languages. Perl is the kind of language that you enjoy using for quick but effective hacks, maybe because it doesn't get in your way. Definitely I'm going to use it more.
Same here. But recently I had to convert a strange proprietary file format from a poll into CSV for a personal project of mine, and I decided to use Perl (5) just for nostalgia sake. I got a solution in minutes despite not having used Perl in years and I enjoyed programming on it, I'd say more than Python and sometimes bash which are my go-to scripting languages. Perl is the kind of language that you enjoy using for quick but effective hacks, maybe because it doesn't get in your way. Definitely I'm going to use it more.
Duke Nukem Forever and Perl 6 in my lifetime? Next thing you'll know we will have cold fusion.
NetHack 3.6 just recently came out too!
http://www.nethack.org/v360/release.html
http://www.nethack.org/v360/release.html
SuperTux 0.4.0
What a time to be alive!
http://supertuxproject.org/
What a time to be alive!
http://supertuxproject.org/
A couple of years I had a nice talk about operating systems with a couple of pretty smart people (smarter than me, at least). I remember bringing up GNU Hurd and saying how sad I was it still wasn't there, yet. And somebody else said to look at it in a more positive way, because by the time it would be ready, at least I could run Perl 6 and Duke Nukem Forever on it.
So who knows, maybe we'll see Hurd 1.0 before, say, 2020. ;-)
So who knows, maybe we'll see Hurd 1.0 before, say, 2020. ;-)
Maybe they'll rewrite Hurd in Perl 6...
I'm hopeful that Perl 6 will prove more endearing and long-lasting than Duke Nukem Forever, which was, frankly, a stinker (then again, we all grew up waiting for it, and Duke's 12 year old boy humor does not age gracefully).
And TextMate Forever, er, 2. Is Half-Life 3 next?
Don't get ahead of yourself, Half-Life 2: Episode 3 needs to come out first. :P
All signs point to Valve skipping HL2E3 and going straight to HL3 (I was pretty sure they'd confirmed it): http://www.denofgeek.us/games/half-life/250840/why-half-life...
Please. Next logical step is Half Life 3 :)
My first thought for Perl 6 killerapp: a html5/js build replacement for grunt, gulp and other such monstrosities.
You can write a replacement for gulp in Perl 6, but if it doesn't have the plugins, who will use it?
Grunt and gulp have huge plugin ecosystems, which is both a blessing (you can find ready-made plugins for a lot of tasks) and a curse (everything moves very rapidly, plugins get abandoned, blacklisted and superseded all the time - if you want to compile TypeScript files, half the blogposts will recommend gulp-tsc .. but wait, it's been blacklisted, you should use gulp-typescript instead ).
Grunt: ~5400 plugins: http://gruntjs.com/plugins
Gulp: ~2000 plugins: http://gulpjs.com/plugins/
Gulp's list of blacklisted plugins: https://github.com/gulpjs/plugins/blob/master/src/blackList....
Grunt and gulp have huge plugin ecosystems, which is both a blessing (you can find ready-made plugins for a lot of tasks) and a curse (everything moves very rapidly, plugins get abandoned, blacklisted and superseded all the time - if you want to compile TypeScript files, half the blogposts will recommend gulp-tsc .. but wait, it's been blacklisted, you should use gulp-typescript instead ).
Grunt: ~5400 plugins: http://gruntjs.com/plugins
Gulp: ~2000 plugins: http://gulpjs.com/plugins/
Gulp's list of blacklisted plugins: https://github.com/gulpjs/plugins/blob/master/src/blackList....
I personally like the idea of using good old Make for that task. You don't need "huge plugin ecosystem", you just need executables to use it. And unlike many other systems it does incremental builds without any special machinery.
That's a valid approach, but "Good old Make" is only good if you are already familiar with it (and its quirks). If you're a new-ish web developer, "learning Make" and "learning Gulp" are two equally foreign tasks.
Also think of your target audience. All of them can program in JavaScript more or less, not all of them will want to learn Perl to do something they can do without learning a new language.
How many of the plugins do you use and how many are overengineered for a simple purpose?
In a fairly simple project, I have these:
gulp-autoprefixer -- CSS vendor prefixes
gulp-concat -- concatenates multiple files into one
gulp-cssmin -- CSS minifier
gulp-imagemin -- image optimizer/minifier
gulp-rename -- renames files produced by other streams
gulp-ruby-sass -- transpiles SASS to CSS
gulp-template -- interpolates some variables, e.g. environment settings or external dependency URLs, into a file (basically lodash's .template )
gulp-typescript -- transpiles TypeScript to JS
gulp-uglify -- JS minifier
gulp-util -- provides things like access to environment variables, console.log replacement, Gulp-specific throwable errors
gulp-watch -- automatically recompiles when source files change
gulp.spritesmith -- converts images to CSS sprites[deleted]
No need for a new DSL for js package management, most of the projects which use grunt/gulp should just be using npm package.json's scripts. If you need to do complex builds use a Makefile. The most established build DSL is bash and it still does the job better on most aspects than grunt/gulp.
grunt/gulp/etc. have better alternatives in many languages. The reason they're popular is they're written in javascript, so people working in javascript can have their build configured in the same language as the rest of their project.
I can't say I'll be using Perl6 for my next project, but I'm glad it's here because it should push other languages forward in meaningful ways. I think the PL landscape has been missing something and Perl6 was it.
On a side note, I love how welcoming all the language is around getting people to join the community. Off to the irc we go :)
Perl was the very first language I learned. I was using it to parse incoming emails to insert records into a timetracking database, so i could log my time via email. loved it.
But ya know, 15 years is a long time. in fact i was around 16 at the time, and am 30 now, and remember talk about perl 6.
I'm a ruby guy now, and I don't see how I could ever go back to perl. Is perl 7 going to take another 15? or 30?
Despite whatever features came about; i should not need to wait half my life to get them. That I think reflects poorly on the perl culture, or its momentum. And it's not that perl 5 was without issues (though they were rare for me)
Maybe a revival will come about from this, and maybe a change of pace and approach; but as it stands the 15 years it took to release feels closer to failure than to a success, and to tie my code to such neglected foundations does not jive with me. Or maybe I just really like ruby now.
Honestly, I hope something good comes of it. Even if its just new features that other languages go on to adopt or take cues from.
But ya know, 15 years is a long time. in fact i was around 16 at the time, and am 30 now, and remember talk about perl 6.
I'm a ruby guy now, and I don't see how I could ever go back to perl. Is perl 7 going to take another 15? or 30?
Despite whatever features came about; i should not need to wait half my life to get them. That I think reflects poorly on the perl culture, or its momentum. And it's not that perl 5 was without issues (though they were rare for me)
Maybe a revival will come about from this, and maybe a change of pace and approach; but as it stands the 15 years it took to release feels closer to failure than to a success, and to tie my code to such neglected foundations does not jive with me. Or maybe I just really like ruby now.
Honestly, I hope something good comes of it. Even if its just new features that other languages go on to adopt or take cues from.
There is no Perl 7. Perl 5 has been having releases the whole time you've been doing Ruby. Each minor release of Perl 5 since 5.10 had major features comparable to Python 2 to 3 but with full backwards compatibility. Perl 6 is a whole new language. There is no plan for a Perl 7 instead like Smalltalk and friends Perl 6 will just endlessly bootstrap itself to the next generation with its MOP and grammar engine.
I don't think Perl 7 will be a thing in anyone's planned future. There are now two languages in the Perl family: Perl 5 and Perl 6. Perl 5 is still developed, has yearly releases and feature additions. Perl 6 is a brand new language that just had its first release. There is some history involved in why it took 15 years and why it's named "Perl" and not something else, but it's an entirely new language.
Perl 5 is still around and being developed.
Perl 6 is a different language.
Perl 6 is a different language.
I installed rakudo and played with it a little. However, the repl was horrible. Is there a repl that accepts multiline subroutines and if possible readline support?
I think you may want to install the module called Linenoise. If you have panda (Perl 6 module installer), just type panda install Linenoise and you should be all set. https://github.com/hoelzro/p6-linenoise
Yeah, that fixes the readline situation. Still, if has to type everything in one line for it to evaluate, the REPL isn't of much use is it?
I use rlwrap instead.
The REPL is one of the features that hasn't gotten as much attention as it should. It was much more important to spend the time getting the rest of the language into shape.
That said I use the REPL for 90% of my coding. Including temporarily replacing parts of the runtime while trying to fix them.
The REPL is one of the features that hasn't gotten as much attention as it should. It was much more important to spend the time getting the rest of the language into shape.
That said I use the REPL for 90% of my coding. Including temporarily replacing parts of the runtime while trying to fix them.
No idea :) In my 16-year programming career I never used a REPL of any sort. Just pop up a temp file and edit it with $editor-of-choice? XD
I thought that way until I worked with iPython for a while (back when it was primarily a clever REPL, and didn't really have the "notebooks" feature at all, yet, I don't think...this was back when it was new). Having a really strong REPL when debugging is like having a rocket, when you're used to having a hot air balloon.
I've always been bothered by the weakness of Perl REPLs. It's only recently started to improve (in the past five years or so) for Perl 5, but there are some decent ones, though nothing even in the same league as iPython.
I've always been bothered by the weakness of Perl REPLs. It's only recently started to improve (in the past five years or so) for Perl 5, but there are some decent ones, though nothing even in the same league as iPython.
Well there's also a debugger for Rakudo. One that will even step through grammar/regex as they parse which is really nice. https://github.com/jnthn/rakudo-debugger and https://github.com/jnthn/grammar-debugger
That looks really nice. And I like that it defaults to doing the right thing. I always have to read the docs when using gdb, as it happens so rarely that I forget the commands for doing things...and it definitely does not default to useful behaviors, certainly not just hitting "enter" to do the next obvious thing.
A debugger doesn't take the place of a good REPL, but it's a useful component of a good REPL.
A debugger doesn't take the place of a good REPL, but it's a useful component of a good REPL.
There is a lot of shifting around on the #perl6 chat room in recent months to get Perl6 interacting with Jupyter aka the iPython notebook. Which means you'd probably be able to use iPython command line as a command line client, just without all the Python bells and whistles. If you're interested in seeing that through I'd make some noise in the chat room. Even just saying you'd want it will go a long way! Timotimo looks to be the person to hi5 as he already has some code https://github.com/timo/iperl6kernel
Competent Jupyter integration would be amazing. I haven't had reason to work seriously in Python in many years, but iPython is just fantastic, so having that kind of capability for Perl 6 would make Perl 6 even more attractive for me. I think a lot of folks just don't realize how cool it is, until they actually work with it for a while.
Really? I always see a debugger > REPL. In what ways do you see a REPL as being more powerful?
Not necessarily just from a debugging perspective (though I did mention debugging, specifically, above), but from an exploratory programming perspective. The ability to start with a snippet of something, and then trying new things. I often don't know how to solve something until I've tried several ways of doing it. A REPL (a really functional one like iPython, or, I imagine the better Lisp or Smalltalk REPLs, though I've rarely used either language) is a really nice way of doing that.
A debugger, in my mind, is for running the program as it exists on disk and then inspecting it. A REPL is for interactively writing a new program. It is a different way of thinking about programming. On one hand it's something you do first in your editor and then you fix the bugs in the debugger. On the other hand, it's something you tinker with until you're happy and then you commit it to disk. Even when I worked in Python, I would mostly write the code in vim, but when I was trying to understand a new library or sort out the right data structure or algorithm for something I'd use the REPL.
I guess the lines are blurry. iPython is called a Python shell, or was when I was using it. So, saying "REPL" may be misleading, if your vision of a REPL is merely "it executes a statement". You can build up quite complex functions in iPython and execute them on arbitrary data. It doesn't restrict you to one-liners.
If the Perl 6 debugger allows defining new functions (and other stuff beyond merely tweaking data), then it's probably in a similar category, if still immature.
A debugger, in my mind, is for running the program as it exists on disk and then inspecting it. A REPL is for interactively writing a new program. It is a different way of thinking about programming. On one hand it's something you do first in your editor and then you fix the bugs in the debugger. On the other hand, it's something you tinker with until you're happy and then you commit it to disk. Even when I worked in Python, I would mostly write the code in vim, but when I was trying to understand a new library or sort out the right data structure or algorithm for something I'd use the REPL.
I guess the lines are blurry. iPython is called a Python shell, or was when I was using it. So, saying "REPL" may be misleading, if your vision of a REPL is merely "it executes a statement". You can build up quite complex functions in iPython and execute them on arbitrary data. It doesn't restrict you to one-liners.
If the Perl 6 debugger allows defining new functions (and other stuff beyond merely tweaking data), then it's probably in a similar category, if still immature.
I personally find REPLs overrated. Give me a step through debugger any day (something I see fewer and fewer new programmers using these days).
It is not either/or.
I think there is simply a miscommunication happening here, where folks unfamiliar with iPython are assuming it is a simple REPL (like the Perl debugger in REPL mode. I'm not talking about a dumb thing that executes one line of code and returns. iPython (and, again, I imagine the better Lisp and SmallTalk REPLs) is a full shell with your programming environment available, including the ability to use the debugger interactively, explore your data structures, etc. But, you can also create new functions, modify existing ones, and it has command history, etc. All the stuff you'd expect of a good shell, but in Python and with a complete picture of your program's execution environment.
I've simply never felt like I was able to get inside of a program like when working with iPython, and I'm not at all a good Python programmer.
I think there is simply a miscommunication happening here, where folks unfamiliar with iPython are assuming it is a simple REPL (like the Perl debugger in REPL mode. I'm not talking about a dumb thing that executes one line of code and returns. iPython (and, again, I imagine the better Lisp and SmallTalk REPLs) is a full shell with your programming environment available, including the ability to use the debugger interactively, explore your data structures, etc. But, you can also create new functions, modify existing ones, and it has command history, etc. All the stuff you'd expect of a good shell, but in Python and with a complete picture of your program's execution environment.
I've simply never felt like I was able to get inside of a program like when working with iPython, and I'm not at all a good Python programmer.
Thats pretty much the same things that I would do using an IDE and step through debugger. I find an IDE far more convinient to navigate, but maybe thats just familiarity.
In bash I use a few aliases (which load different libraries for DB and specific data structures) for perl -E
I have simple shell aliases to do SQL queries and pipe the output to shell aliases which transform that to perl data structures (along with some project specific data structures). And so on.
(The bash ctrl-R backward searches rarely interact between shell commands and searches for these one liners.)
Please stop shaking your head. :-)
I agree that the old lisps I used back at Uni was neater than this one liner craziness. I've thought of trying a REPL instead, but with one liners I can also use the bash functionality for processing files and so on.
I have simple shell aliases to do SQL queries and pipe the output to shell aliases which transform that to perl data structures (along with some project specific data structures). And so on.
(The bash ctrl-R backward searches rarely interact between shell commands and searches for these one liners.)
Please stop shaking your head. :-)
I agree that the old lisps I used back at Uni was neater than this one liner craziness. I've thought of trying a REPL instead, but with one liners I can also use the bash functionality for processing files and so on.
Variable names can contain dashes?
Then how do you know what this means:
Then how do you know what this means:
users=users-churn-rate*time
$users=$users-$churn-rate*$time
I could craft you unreadable code in any language. Someone removing all of the whitespace between their operators is not going to be producing code that I want to be responsible for maintaining... in any language.
Go has an interesting take on whitespace-around-operators -- it starts removing whitespace around binary operators if there are higher precedence operators in the same expression. So, for example, you get:
x = 2 * y
x = 2*y + 5
That's why Perl 5 is still an unbeaten champion in terms of managing the complexity of legacy code. Perl::Tidy (and Perl::Critic) is a super-configurable beast to the extent I've not yet seen in other languages.
You could probably do something similar in Javascript or Python, there are many tools that provide you access to the AST, it's just that no one has written such a tool on top of it (or maybe they have, but they never gained traction).
The funny thing is: most languages have a development philosophy completely opposed to TIMTOWTDI, so they are all trying to write a tool for the one perfect formatting style, not a universal tool with enough flexibility for the different styles. The former usually leads to enough segmentation for every effort to die in its infancy, the latter to Perl::Tidy.
This is especially apparent with Python with its PEP8 standard -- most formatting tools only deal with PEP8 compatibility and only in one direction. Especially with Python, automated code formatting is mistaken for beautification and thus there is a remark in PythonTidy's documentation "Python scripts are usually so good looking that no beautification is required".
I tend to think this is exactly the same thinking that has lead Perl into the mess that's slowly being fixed since about 2005 and I cherish the difference between a language community which has had its painful experience with insufficient tooling and learned from it and the one which hasn't.
This is especially apparent with Python with its PEP8 standard -- most formatting tools only deal with PEP8 compatibility and only in one direction. Especially with Python, automated code formatting is mistaken for beautification and thus there is a remark in PythonTidy's documentation "Python scripts are usually so good looking that no beautification is required".
I tend to think this is exactly the same thinking that has lead Perl into the mess that's slowly being fixed since about 2005 and I cherish the difference between a language community which has had its painful experience with insufficient tooling and learned from it and the one which hasn't.
Having programmed in Perl for a couple of years and later in Python and JavaScript, I really started to appreciate sigils. There is literally no ambiguity about what's a variable name and what not. Things like reserved words (think JavaScript's commonly used 'klass' monstrosity) are just a non-issue in Perl.
I found dashes are by far easier to type than underscores and I'd certainly have whitespace between operators in my code, so I'd never run into the problem you describe. It is possible to have variables without sigils and in that case, your first example would be a parse error about undeclared users-churn-rate. Also, apostrophes are valid in variable names as well.
your first example would be a parse error about undeclared users-churn-rate
You can either use U+2212 MINUS SIGN instead of a hyphen, too. Spaces would probably be preferable from a maintenance point of view, though.
Just use white space! (EDIT: Sorry, I hadn't refreshed for a while, and so didn't see that zoffix (https://news.ycombinator.com/item?id=10795739) beat me to the punch by quite a bit.)
Use the space, Luke ;)
Something I see no one mentioned, dashes (and apostrophes) aren't the only neat thing you can use in term names. You can use other languages too. $контрольная-работа is a valid variable name.
That's nice. Common Lisp implementations, too, allow any characters in symbol names, even spaces and the empty string. Javascript allows wide character set too. I think it's good that languages break out of [a-zA-Z_-]. That said, I'd use pretty limited charset in internationally developed multi-OS code base. People have different keyboards, input systems, knowledge etc.
That's something I wouldn't like to see in source code, as I wouldn't have a clue how to type it.
How do Russians see that issue? (Is it Russian?)
...or you could just put whitespace around - when you mean subtract.
It's not that common variable names use dash in the wild. Far more common is method names do. In part because of this clash but also to distinguish method names. Also jees use whitespace!! Assuming that was a serious question.
This should be changed to the permalink: https://perl6advent.wordpress.com/2015/12/25/christmas-is-he...
Perl6 example:
sub Σ(@array_to_sum) { return [+] @array_to_sum; }
say Σ (1,2,3,4); # It will display 10
sub Σ(@array_to_sum) { return [+] @array_to_sum; }
say Σ (1,2,3,4); # It will display 10
Some of the operators use non ASCII characters. Here is how you enter them: http://doc.perl6.org/language/unicode_entry
No risk, no fun.
No risk, no fun.
There are ASCII equivs for most, they're called 'Texas' operators.
Larry Wall is a linguist. I'm sure there has to be some reasoning behind making the language more complex. Do you know of a text by him explaining why there are two kind of writing the same operators? And why using non ASCII characters?
It's kind of obvious the reasoning behind it... The unicode is the mathematical or good choice for the operator character, but the majority of people have no idea how to type it. I have yet to see a keyboard with most of the unicode maths operators on.
I have a lot of fond memories of Perl from a decade or so ago, and would love to do something more than just installing and tinkering with Perl 6 and then forgetting all about it. I also conveniently have a little "weekend project" coming up where I can probably just choose whatever language seems most fun (and then rewrite it in something sensible later if it grows beyond "weekend" status).
If I chose Perl 6, what's a nice Sinatra-esque thing, and is there an ORM? And how do I deploy it and run it in production (copy it into cgi-bin?!)?
If I chose Perl 6, what's a nice Sinatra-esque thing, and is there an ORM? And how do I deploy it and run it in production (copy it into cgi-bin?!)?
The thing that excited me about Perl6 was Parrot (http://parrot.org), which is supposed to be this very ambitious VM targeting dynamic languages.
But unfortunately it seems that Perl6 is Rakudo and they've developed a Rakudo specific VM. Maybe that's best for Perl6 the language, but it also makes it less interesting for me.
But unfortunately it seems that Perl6 is Rakudo and they've developed a Rakudo specific VM. Maybe that's best for Perl6 the language, but it also makes it less interesting for me.
It's not a Rakudo specific VM, it's NQP specific VM, as I understand it. Rakudo is written using NQP and Perl 6. You can implement other languages using NQP same way as Rakudo is done.
https://github.com/perl6/nqp/tree/master/examples/rubyish
https://github.com/perl6/nqp/tree/master/examples/rubyish
Thanks, I haven't been up to date with the development of Perl6.
Perl6 is actually ROAST, but Rakudo is the first compiler that approaches implementing it. Parrot was unfortunately discontinued but Rakudo will not be the only compiler (hopefully!)
> Rakudo will not be the only compiler (hopefully!)
You're correcting people, but sort of wrong yourself.
Rakudo is written in NQP and Perl 6 AFAIK, but NQP can be implemented for different VMs. A while back it worked on Parrot, MoarVM and JVM. I'd say keep Rakudo, but add more backends such as CLR/.NET, WebAssembly/LLVM.
You're correcting people, but sort of wrong yourself.
Rakudo is written in NQP and Perl 6 AFAIK, but NQP can be implemented for different VMs. A while back it worked on Parrot, MoarVM and JVM. I'd say keep Rakudo, but add more backends such as CLR/.NET, WebAssembly/LLVM.
[deleted]
I like what I see. Now make it available at Godaddy, Namecheap and all hosting providers for it to dethrone PHP as the king of the web.
I think "king of the web" is gonna look a lot different in the future than it does today and did in the past. JavaScript will be, for the foreseeable future, the king of the web front end, and I suspect it'll also hold a strong role on the back end. It may even be unstoppable on both ends because of the incredible resources being thrown at it.
However, systems management, deployment, provisioning, data aggregation, log/event analysis, etc. on a large scale becomes more important by the day, and if there is an area where Perl is still quite popular, it is in those back end tasks. There are trendy tools in newer languages, but you'd be hard press to find very large deployments (at least on Linux or other UNIX) without a few hundred thousand lines of Perl running some elements.
Perl 6 with concurrency built-in, grammars and the most advanced regular expression engine in the world, seems very well-suited for that future. Being somewhat familiar for old school sysadmins who've always relied on Perl for their scripting tasks is a bonus (Python has made some inroads in that space in recent years, particularly with Red Hat and Ubuntu/Debian shipping many system utilities that are written in Python).
Anyway, on the web front, I think we need a reasonable database abstraction layer (e.g. Perl DBI/DBD), at the very least, before it gets elevated to "always available" on hosting providers. I'd say give it another year, and we'll have a pretty good Perl 6 web development ecosystem to work with.
However, systems management, deployment, provisioning, data aggregation, log/event analysis, etc. on a large scale becomes more important by the day, and if there is an area where Perl is still quite popular, it is in those back end tasks. There are trendy tools in newer languages, but you'd be hard press to find very large deployments (at least on Linux or other UNIX) without a few hundred thousand lines of Perl running some elements.
Perl 6 with concurrency built-in, grammars and the most advanced regular expression engine in the world, seems very well-suited for that future. Being somewhat familiar for old school sysadmins who've always relied on Perl for their scripting tasks is a bonus (Python has made some inroads in that space in recent years, particularly with Red Hat and Ubuntu/Debian shipping many system utilities that are written in Python).
Anyway, on the web front, I think we need a reasonable database abstraction layer (e.g. Perl DBI/DBD), at the very least, before it gets elevated to "always available" on hosting providers. I'd say give it another year, and we'll have a pretty good Perl 6 web development ecosystem to work with.
Perl 6 already has its own DBI and even a Slang DSL for writing SQL directly in Perl 6 as a loop construct. https://github.com/tony-o/perl6-slang-sql
[deleted]
How many times is it going to be posted on HN that Perl 6 is released?!
Once? This is the only time there has been a release of a versioned specification for the language compilers can target. That's what has been in development for 15 years! The specification of the actual language. It's like the difference between JavaScript existing as a language for a while and then one day ECMAScript 1 was defined. Apart from Perl 6 was always about the evolution of the spec with various implementations showing the way.
The first major implementation of Perl 6 back in the early/mid 00s was Pugs written in Haskell where Perl 6 picked up a tonne of functional heritage both in the compiler at the time and the language spec. The more recent Rakudo compiler has a lead architect who often works in C# where the compiler and the language spec picked up and redefined a reactive programming concurrency model with lots of nice new syntax like the react/whenever block.
Rakudo Perl 6 and Pugs and the host of other early implementations have been around a while and released often when they were worked on, monthly in the case of Rakudo with the first publicised release in 2010. Rakudo is also releasing a version of the compiler compliant with the newly frozen and released specification.
The first major implementation of Perl 6 back in the early/mid 00s was Pugs written in Haskell where Perl 6 picked up a tonne of functional heritage both in the compiler at the time and the language spec. The more recent Rakudo compiler has a lead architect who often works in C# where the compiler and the language spec picked up and redefined a reactive programming concurrency model with lots of nice new syntax like the react/whenever block.
Rakudo Perl 6 and Pugs and the host of other early implementations have been around a while and released often when they were worked on, monthly in the case of Rakudo with the first publicised release in 2010. Rakudo is also releasing a version of the compiler compliant with the newly frozen and released specification.
I think that the parent to your post is referring to this:
https://news.ycombinator.com/item?id=10793029
which already made the front-page.
https://news.ycombinator.com/item?id=10793029
which already made the front-page.
[deleted]
Well, it is the release of Perl 6, and the appetite appears insatiable, so have at it. But after this one, let's flag any more reposts.
This time it's for real!
Not quite too, it's a compiler release (Rakudo), but ordinary users should stick to a distribution with common modules (Rakudo Star). Usually comes a few days after.
Well, after all these years, I think that's okay. Some people probably need to hear it a couple of times for the good news to sink in. :-)
it's that important.
I don't even know what it means to say that Perl 6 has been released anymore.
Are there any good tutorials/introductions/blog posts/etc. on using Perl6 for language parsing/implementation?
For Perl6 proper, not that I'm aware of. For the NQP toolchain in which Rakudo Perl6 is implemented, there's https://github.com/edumentab/rakudo-and-nqp-internals-course
[deleted]
Anyone have an idea of how perl6 performs? All the performance articles I've read are really old.
It has some native typed features that mean one can speed up numeric or raw byte/bit operations to be faster, sometimes a lot faster than, say, Perl 5, but it's generally a whole lot slower, 10x and even 100x slower wasn't uncommon a few months ago. Some users claim it's worth trying it to see how it works out for the sort of code a given user writes.
This release is about nailing down the language with a compiler that passes a test suite. Next comes a focus on improving what they have -- nailing bugs, speeding it up and expanding the test suite while making sure it continues to pass the test suite and keeps users' code running.
I'd expect some benchmarks to be published on #perl6 in the next few weeks.
This release is about nailing down the language with a compiler that passes a test suite. Next comes a focus on improving what they have -- nailing bugs, speeding it up and expanding the test suite while making sure it continues to pass the test suite and keeps users' code running.
I'd expect some benchmarks to be published on #perl6 in the next few weeks.
Interesting, does poor performance hold true using JVM? I'd expect MoarVM to have some performance issues since its new.
Is the multi-vm approach anything more than a novelty or is this expected to be a feature, i.e. a common spec and intermediate layer with support for different backend VMs?
Is the multi-vm approach anything more than a novelty or is this expected to be a feature, i.e. a common spec and intermediate layer with support for different backend VMs?
First of all, no one can yet run 6.c code on the JVM. Maybe the JVM backend will get there by Christmas 2016.
The JVM's JIT is pretty awesome once it gets well warmed up. MoarVM's JITing is much less impressive so far but it's early days.
The JVM will almost certainly always underperform relative to MoarVM in these two ways:
* Much poorer startup time (unless an evalserver "cheat" is used)
* Using much more RAM (I recall a report of something like 5x or so for typical code running on recent versions of the JVM backend compared with the MoarVM backend)
My understanding is that the multi VM approach is strategic for Perl 6, for the Rakudo Perl 6 compiler, and for the underlying NQP compiler toolchain.
The JVM's JIT is pretty awesome once it gets well warmed up. MoarVM's JITing is much less impressive so far but it's early days.
The JVM will almost certainly always underperform relative to MoarVM in these two ways:
* Much poorer startup time (unless an evalserver "cheat" is used)
* Using much more RAM (I recall a report of something like 5x or so for typical code running on recent versions of the JVM backend compared with the MoarVM backend)
My understanding is that the multi VM approach is strategic for Perl 6, for the Rakudo Perl 6 compiler, and for the underlying NQP compiler toolchain.
Expected very much to be a feature. Someone is working on emitting JavaScript from Rakudo too for Perl 6 in the browser :)
As if to confirm Perl's descent into obscurity they give the release a name that 95% of the people of the world can't read.
The cherry on top of the public relations disaster that the introduction of Perl6 has been...
The cherry on top of the public relations disaster that the introduction of Perl6 has been...
It's impressive how different the languages Perl (5 -> 6), PHP (5 -> 7; no 6) and Python (2 -> 3) developed in the last 10 years. And how their community reacted and their transition to newer releases.
Didn't quite make it by Christmas
You might want to read the date on the article...
I can vouch that that there was plenty of Christmas left in my timezone when I uploaded the tarballs and posted the release notice. :)
In about half of the countries in Europe, Christmas is generally taken to mean the Christmas Eve, i.e. the 24th.
Traditionally, Christmas starts on Christmas Eve (and ends quite a lot later, on Epiphany, or thereabouts.)
Colloquially, sure. More properly, that's 'Christmas Eve', 'Heiligabend', ..., ie the day before Christmas; the 'first day of Chrismas' ('erster Weihnachtsfeiertag') is the 25th.
So there :p
So there :p
Too little, too late, IMO. The world has moved to Ruby and Go for the web/cloud and Python for data analysis/scientific computing.
The 20-year-old Ruby and Python were brand new at some point in time too. It's a bit silly to declare the current crop of languages to be with us forever. I can already notice where being a brand new language makes Perl 6 address new inventions in the past 20 years much better: superb Unicode support and getting concurrency by simply using .hyper/.race methods, not to mention grammars and autothreaded junctions. This looks pretty revolutionary to me.
Stackoverflow was written in C# when the rest of the world had moved on to Ruby.
WhatsApp had clients written in Java against J2ME.
JaneStreet is (apparently) killing it with OCaml.
iOS apps were written in Objective-C when the rest of the world hardly even heard of that language.
This site is written in a niche dialect of Lisp.
WhatsApp had clients written in Java against J2ME.
JaneStreet is (apparently) killing it with OCaml.
iOS apps were written in Objective-C when the rest of the world hardly even heard of that language.
This site is written in a niche dialect of Lisp.
The world is not a monoculture, yes. Not sure why that should mean people will start using this new version of a language that has been dormant for fifteen years.
As you'll hear from any advocate, Perl 6 is fundamentally a new language, not just a new version of Perl 5; but, even if you want to think of it as a new version of Perl 5, then it's hardly true that Perl 5 has been dormant all this time. See https://en.wikipedia.org/wiki/Perl#2000.E2.80.93present , for example.
I just don't see why that means people will use it. That's probably a negative, don't you think? The people who have been writing Perl have to learn a new language, and people who haven't been using Perl have so many others to choose from already.
I'm glad it's finished and all, but this has just seemed like a slow-moving disaster to me.
I'm glad it's finished and all, but this has just seemed like a slow-moving disaster to me.
> I just don't see why that means people will use it.
I wasn't arguing for or against that position, just responding to the claim that it (Perl 6) was a new version of a language that had been dormant for 15 years. In fact I don't know what to expect for Perl 6; as an old lover of Perl 5, who hasn't done any Perl programming for a while, I would love to see a modern successor, but I'm not sure that I totally disagree with the people who think that the name now has too many possibly negative connotations.
> The people who have been writing Perl have to learn a new language, and people who haven't been using Perl have so many others to choose from already.
The same is true for any new language, though, whether or not it has 'Perl' in its name, and some of them do get adopted!
I wasn't arguing for or against that position, just responding to the claim that it (Perl 6) was a new version of a language that had been dormant for 15 years. In fact I don't know what to expect for Perl 6; as an old lover of Perl 5, who hasn't done any Perl programming for a while, I would love to see a modern successor, but I'm not sure that I totally disagree with the people who think that the name now has too many possibly negative connotations.
> The people who have been writing Perl have to learn a new language, and people who haven't been using Perl have so many others to choose from already.
The same is true for any new language, though, whether or not it has 'Perl' in its name, and some of them do get adopted!
I know literally hundreds of Perl developers in London alone. CPAN gets > 1,000 uploads a month. There have been regular releases that add features for years. The OO system provided by Moose puts most languages to shame... You have some odd definition of dormant.
I don't know, maybe because people like change and/or want to just try something new.
I came into programming little too late to even consider perl5. It's just something I've read through as part of setting up irssi script(s).
To me Perl6 seems fun based on the few things I've read and I don't see any reason not to give it a go. Sure I won't be using it in any "production" build anytime soon, but hey maybe its setup beats the hassle that ruby/rvm brings with it and maybe it's more fun than python.
I came into programming little too late to even consider perl5. It's just something I've read through as part of setting up irssi script(s).
To me Perl6 seems fun based on the few things I've read and I don't see any reason not to give it a go. Sure I won't be using it in any "production" build anytime soon, but hey maybe its setup beats the hassle that ruby/rvm brings with it and maybe it's more fun than python.
Perl is still among the top 10 languages, according to TIOBE. Even if we discount that index, other indices have it in at least the top fifteen.
https://www.google.com/search?q=top+50+programming+languages
https://www.google.com/search?q=top+50+programming+languages
> Stackoverflow was written in C# when the rest of the world had moved on to Ruby.
How are they feeling about that decision now?
> WhatsApp had clients written in Java against J2ME.
Sure, because Java is the only option on those platforms.
> JaneStreet is (apparently) killing it with OCaml.
OCaml hasn't hit its peak yet, it's still on the way (slowly) up.
> iOS apps were written in Objective-C when the rest of the world hardly even heard of that language.
Again, because it's the only option on the platform.
> This site is written in a niche dialect of Lisp.
How're they feeling about that decision now?
How are they feeling about that decision now?
> WhatsApp had clients written in Java against J2ME.
Sure, because Java is the only option on those platforms.
> JaneStreet is (apparently) killing it with OCaml.
OCaml hasn't hit its peak yet, it's still on the way (slowly) up.
> iOS apps were written in Objective-C when the rest of the world hardly even heard of that language.
Again, because it's the only option on the platform.
> This site is written in a niche dialect of Lisp.
How're they feeling about that decision now?
Few hipsters is not a "world", world is much bigger.
Ruby and Go for the web?? Really? Not JavaScript and PHP (still). Python is old hat too it's all about Julia now :P and R is making a come back in some weird computing renaissance.
Ruby is very popular with the excellent Rails framework. Also Sinatra as a DSL if the power of Rails isn't needed.
Imagine what DSL would look like in a programming language that is itself defined as several DSLs. That is signatures, immediate strings, regular expressions are all separate domain specific languages that share parts of the same grammar but with certain domain specific modifications.
There is a thing called a Slang where you can replace the Perl 6 grammar with a different one entirely. So you could write a Ruby slang and write Ruby in Perl 6. Unfortunately the design for slangs wasn't quite good enough yet for the Christmas release of ROAST the specification testsuite.
There is a thing called a Slang where you can replace the Perl 6 grammar with a different one entirely. So you could write a Ruby slang and write Ruby in Perl 6. Unfortunately the design for slangs wasn't quite good enough yet for the Christmas release of ROAST the specification testsuite.
I'm fairly disappointed with this release. My read through of a tutorial in it went something like this:
* Oh you're sticking with that confusing % for hashes, @ for arrays then $ for everything else... maybe maybe classes have been sorted out though.
* Hmm, why is the syntax for defining a class totally different to defining functions and variables everywhere else
* Well they can't have made anything WORSE. Oh fields can have minuses in them?? Packages exist and you can define them but you're not supposed to anymore?
* Well at least you can't totally rewrite the language in some arcane way which means every bit of perl you come across is totally different and unreadable for 45min while you work out what the custom DSL does. looks at phasers, Meta operators, fix'es sigh
Great that this has finally been released, but it really doesn't solve the problems that Perl always had that it is TOO expressive and too customisable, meaning it'll always be vastly different project to project. On top of that it doesn't have the things that people are really excited about now, which is channels, selects and other things that make async easy. I think that this would have been an amazing release when Ruby was getting popular, but I think it's a few years too late.
* Oh you're sticking with that confusing % for hashes, @ for arrays then $ for everything else... maybe maybe classes have been sorted out though.
* Hmm, why is the syntax for defining a class totally different to defining functions and variables everywhere else
* Well they can't have made anything WORSE. Oh fields can have minuses in them?? Packages exist and you can define them but you're not supposed to anymore?
* Well at least you can't totally rewrite the language in some arcane way which means every bit of perl you come across is totally different and unreadable for 45min while you work out what the custom DSL does. looks at phasers, Meta operators, fix'es sigh
Great that this has finally been released, but it really doesn't solve the problems that Perl always had that it is TOO expressive and too customisable, meaning it'll always be vastly different project to project. On top of that it doesn't have the things that people are really excited about now, which is channels, selects and other things that make async easy. I think that this would have been an amazing release when Ruby was getting popular, but I think it's a few years too late.
Yeah I can tell you've now learnt enough of the language to judge it at all... Or perhaps not at all! http://docs.perl6.org/type/Channel Though supplies with react/whenever is a lot more exciting than channels.
Confusing? How would you signify context then? A keyword?
> Oh you're sticking with that confusing % for hashes, @ for arrays then $ for everything else...
The claim is something like:
Some folk like distinguishing singular ($foo) and plural (%dict, @array) nouns even if some others dislike it.
Many human languages make the same sorts of distinctions to good effect which may give you pause for thought, especially given recent neuroscience emphasizing the apparent central role of natural language processing rather than math processing when folk comprehend code (the study I saw involved Java code fwiw).
Note that you can bind a name to avoid sigils:
The claim is something like:
Perl / Perl 6 are more serious than most other langs about variable scoping. Classes aren't closures and object lifetimes are different from lexical variables'.
> Oh fields can have minuses in them??
The claim is something like:
Many folk love that, eg lispers, and Perl isn't about telling experienced coders that they can not do things they consider elegant or useful.
> Packages exist and you can define them but you're not supposed to anymore?
The claim is something like:
You generally don't need to use the 'package' keyword because keywords like 'class' and 'module' are themselves variants on 'package' and do the necessary work of the 'package' keyword for you.
Perhaps you've read some doc that was written by someone who was learning Perl 6 and for whom English is a second language such as the learnXinY?
> Well at least you can't totally rewrite the language in some arcane way which means every bit of perl you come across is totally different and unreadable for 45min while you work out what the custom DSL does. looks at phasers, Meta operators, fix'es sigh
The claim is something like:
Perl 6 is a granularly malleable language. The features for empowering users to use this have been carefully designed to be sane but they can be abused.
> On top of that it doesn't have the things that people are really excited about now, which is ... things that make async easy.
The claim is something like:
Perl 6 has the things that people are really excited about now, including things that make async easy.
Perl 6 includes sweet concurrency, parallel, and async constructs.
I think you've read poor material or misinterpreted it.
> I think that this would have been an amazing release when Ruby was getting popular, but I think it's a few years too late.
Fair enough. Time will tell.
The claim is something like:
Some folk like distinguishing singular ($foo) and plural (%dict, @array) nouns even if some others dislike it.
Many human languages make the same sorts of distinctions to good effect which may give you pause for thought, especially given recent neuroscience emphasizing the apparent central role of natural language processing rather than math processing when folk comprehend code (the study I saw involved Java code fwiw).
Note that you can bind a name to avoid sigils:
my \foo = %; # bind foo to an empty dict
foo = :bar, :baz # foo now has two key/val pairs
The claim is something like:
Perl / Perl 6 are more serious than most other langs about variable scoping. Classes aren't closures and object lifetimes are different from lexical variables'.
> Oh fields can have minuses in them??
The claim is something like:
Many folk love that, eg lispers, and Perl isn't about telling experienced coders that they can not do things they consider elegant or useful.
> Packages exist and you can define them but you're not supposed to anymore?
The claim is something like:
You generally don't need to use the 'package' keyword because keywords like 'class' and 'module' are themselves variants on 'package' and do the necessary work of the 'package' keyword for you.
Perhaps you've read some doc that was written by someone who was learning Perl 6 and for whom English is a second language such as the learnXinY?
> Well at least you can't totally rewrite the language in some arcane way which means every bit of perl you come across is totally different and unreadable for 45min while you work out what the custom DSL does. looks at phasers, Meta operators, fix'es sigh
The claim is something like:
Perl 6 is a granularly malleable language. The features for empowering users to use this have been carefully designed to be sane but they can be abused.
> On top of that it doesn't have the things that people are really excited about now, which is ... things that make async easy.
The claim is something like:
Perl 6 has the things that people are really excited about now, including things that make async easy.
Perl 6 includes sweet concurrency, parallel, and async constructs.
I think you've read poor material or misinterpreted it.
> I think that this would have been an amazing release when Ruby was getting popular, but I think it's a few years too late.
Fair enough. Time will tell.
It would take a ridiculously advanced language to counter that turning of the tides. Luckily (or, I guess, not due to luck but because Perl 6 developers realized they had to deliver something amazing to justify the time lost in the wilderness), Perl 6 is a ridiculously advanced language.
I haven't started a new project in Perl in several years (though my primary projects, which have existed for 9-17 years, are in Perl), but I'm strongly considering making my next project a Perl 6 project. It looks like a really fun language. All the stuff I like about Perl, with almost none of the stuff I don't, plus some advanced stuff that I don't even know enough to know why I might want it. But, I know that Higher Order Perl for Perl 5 (which I actually read while I was mostly working in Python) was a lot of fun and made me a better programmer, so I assume Perl 6 and its new paradigms will be similarly eye-opening.