From Linux Voice: “Perl 6 has been 15 years in the making, and is now due to be released at the end of this year. We speak to its creator to find out what’s going on.”
From Linux Voice: “Perl 6 has been 15 years in the making, and is now due to be released at the end of this year. We speak to its creator to find out what’s going on.”
I thought Perl 6 was just a specification and there were quite a few implementations of it which, to my knowledge, almost nobody was using. Is this not the case? Or is something changing?
Edited 2015-07-15 00:39 UTC
There is a reference grammar. He will freeze it.
For now, Perl 6 is quite a moving ground for any implementation. And, indeed, that’s why nobody is using any implementation of it on production systems (AFAIK), despite the reference implementation of it being quite stable by now.
That, and the fact that it comes too late. Perl 6 has been a work in progress for fifteen years, and in that time, the world has moved on somewhat.
Fifteen years ago, I’d have used Perl for almost everything – now, I’d use Python for most of the same tasks, or sometimes Node. Perl is a powerful language, but compared to newer rivals, it’s a pain in the ass to work with… and from what I’ve seen, Perl 6 doesn’t offer enough improvement to win people back.
Somewhat Perl 6 lost his reason to be since Perl 5 got his development resumed few years back.
So, Perl 5 himself evolved quite a bit these last fifteen years. Several features from Perl 6 ended being backported to Perl 5, and new ones was implemented, to the point that both languages now evolves in parallel. In many ways, Perl 6 got so long to be usable that Perl 5 got a life of his own.
Now we are in the odd situation of the old language supplanting the new one.
I have a hard time figuring out why somebody would use Perl since we have Python.
Brackets. Seriously. And CPAN
Sorry, pypi beats CPAN by miles.
It’s great if you love to solve every problem using a regex
Perl – the language that looks exactly the same before and after encryption
It’s 2015.
Languages are mostly fast enough. Loads are portable. Many are general purpose enough.
So given these luxuries .. Why would you not use a language that was easy to learn, easy to code, easy to read, easy to explain?
Niche stuff – sure use assmebler or C or whatever.
What’s the reason to use perl? It doesn’t have a monopoly on regex.
I can only speak from a personal point of view – I still code (professionally) in Perl from time to time.
I just love the language, mostly because there are 1000s of (perfectly good) ways to get the same thing done. That means that your own style and expression of coding are more important than in other languages.
When I started coding in Perl I was cursing it like anyone else, but I have come to appreciate the flexibility of the language and its versatility. For instance, it’s quite an achievement that Perl supports Object Oriented Programming with a minimal change to the language.
I actually really like the language: hashes and arrays our of the box with all the manipulation functions, auto-vivification, interpolation of strings, file handling. Yes you can screw it up the readability royally and the language requires discipline but at least everything is possible.
I also like the gigantic library of useful code called CPAN and the extremely knowledgeable and friendly Perl community. See http://www.perlmonks.org
And I also really like the really good builtin documentation (perldoc), character and language support, package managers and mostly the builtin debugger.
It’s just awesome!
That’s funny as it’s the complete opposite of the Zen of Python: “There should be one– and preferably only one –obvious way to do it.”
https://www.python.org/dev/peps/pep-0020/
It’s funny because Perl and Python are languages that have very similar use cases but have a very distinct ideology and approach.
I personally prefer Python’s way. The expression is in the structure of your data and the architecture built around it, not in the code that is derived from it. Get your data structures right and the code should write itself.
That’s nice about having the choice. We’re all different and what doesn’t work for me, might just work all the better for you. So let Perl flourish!
Edited 2015-07-15 12:02 UTC
cfqr,
There’s a bewildering array of similar yet different solutions for everything. You really need to look at CPAN to appreciate the scope of the problem.
http://search.cpan.org/search?query=time&mode=module
http://search.cpan.org/search?query=date&mode=module
http://search.cpan.org/search?query=socket&mode=module
http://search.cpan.org/search?query=ipc&mode=module
http://search.cpan.org/search?query=sql&mode=module
http://search.cpan.org/search?query=cgi&mode=module
When I write perl, I find this extremely discouraging, I’d rather have a much more standardized framework with fewer & better solutions. Maybe I need to build my own.
/sarcasm
Yep, that’s one of the two main reasons I don’t really like Perl. The other being that Perl’s syntax is just too cryptic and ugly.
Personal styles usually suck anyway. I’ve always followed a very clean coding style, or so I thought, until I threw my (python) code through a PEP8 linter. I didn’t believe it would make much difference, but the readability and consistency definitely improved. Some very smart people gave those things a lot of thought, why would my gut feeling be any better?
But then, I guess everyone’s got different preferences and who am I to deny others having fun. Some people love puzzling. Let them enjoy it! As long as they stay away from my work.
As a side note, the above is also a bit why I’m not a huge fan of templating inside languages (such as Clojure). It again provides too many ways in which you can express the same thing. I’d rather have more explicit templating outside the language (i.e. strings or different files).
Edited 2015-07-15 15:46 UTC
PEP8 is one of the best things about Python.
IMHO the fact that there are 15 different Date modules in CPAN isn’t a big problem at all, it is a feature.
Just like the 10s of Desktop managers, init systems, file systems, distributions in Linux, this is what makes it strong. It means you aren’t coerced into using some shitty API but can pick what suits you.
Edited 2015-07-15 15:59 UTC
Had you ever worked with maintenance of code of someone else besides you ? If you had, chances are that you wished the coder had stick with standardized libraries instead of picking some random he thought were great and that didn’t receive maintenance for a long time (i.e. is close to an abandoned carcass by then).
Anyway, I am not sure if my sarcasm detector is waning.
Edited 2015-07-15 16:34 UTC
I do maintain code written by others but the problems we solve aren’t in the league of extremely complicated algorithms or problems and as such most code is still readable, just not my taste.
But yeah in Perl this is a bigger problem than in other languages but if you program often in Perl I don’t think it is a big issue at all. I am certainly not a proponent of using exotic language features unless it is required.
That said: I don’t think libraries are a particular problem of Perl. Just compare with Java where you have Log4j, SL4J, Logback just to name a few logging frameworks. Nowadays knowing your library is half the work, but that applies to many languages.
Wondercool,
Certainly this is true to an extent, but at least the standard Java libraries are designed under collaboration with the developers of the rest of the framework.
Perl modules are strewn together with no evidence of coordination at all. This wasn’t so bad in the early days of programming when projects were self contained and the end result was all that mattered. But today’s software is complex, requiring mashups of independent projects with many different subsystems working together. The absence of standard framework foundations can lead to unnecessary complexity and frustration when different pieces of the project use different abstraction libraries to represent the exact same data.
As you say, this problem isn’t always unique to perl, but it is magnitudes worse. As cfqr pointed out above, some language designers explicitly aim to build a strong standardized foundation. Perl never had this goal, which is why it never achieved it.
IMHO perl is fine for small utilities and scripting, which is how I use it; I even prefer perl to bash any day! But I think the general consensus would be to avoid it for general large scale application development.
Sure Perl isn’t a good fit for large scale application development at the moment. We don’t use it as such (max is about 5000 lines, typically only a few 100 lines).
I find the libraries in CPAN in general of high quality and don’t really miss that many of them weren’t build in the open with lots of feedback from other people.
As you say, it is more for short and sweet scripts but with the impressive improvements in the last years in Perl 5 and now in 6 and some superb frameworks like Moose and new web frameworks like Dancer and Catalyst, I think Perl is on the up again, well at least I hope so, and maybe it will become a fine general purpose language
You have a VERY strong point here!!!
If you are an unix admin you cannot relay on Bash to create your script because Bash is only used by default in Linux (and Solaris 11). BSDs, HP-UX, AIX don’t use Bash by default (much of them don’t have Bash even installed!!)
Linux people think that the world ends with Linux and everything is Python… well, that’s not true at all.
Perl is the only tool that allows you to write real multiplatform scripts, that’s why almost every Unix admin in the world use it every day.
People who say “Perl is useless” have no idea of what they are talking about. It doesn’t surprise me btw.
Ever heard of ksh?
In natural language you wouldn’t expect people to all speak the same sentence for the same situation or even the same language.
How boring would it be if all would always say ‘Good day’ instead of ‘Hi’, ‘How are you?’, ‘Nice day’, ‘Bonjour’
The exercise of a computer language is to create a language that is understandable by humans while still possible to compile into something the machine understands.
I don’t like forcing people into a certain format.
An example would be:
if ($opt_v) {
print “Some verbose message \nâ€;
}
Vs.
$opt_v && print “Some verbose message\nâ€;
Vs.
print “Some verbose message\n†unless !$opt_v
Vs.
print “Some verbose message\n†if $opt_v
Why would I force a programmer to use exactly one of these methods? The more expressive the language, the greater chance of creating beauty, IMHO.
It’s a programming language, not a human one. It’s not supposed to be beautiful – it’s supposed to be functional, and it’s supposed to be maintainable. Beauty is a bonus.
I strongly disagree with that sentiment. If that’s the case why aren’t we all programming in Fortran or Cobol? Both are perfectly functional and Cobol particularly is quite maintainable and easy to read.
Also – and this is hard to define, it is a subjective feeling – it seems to me that elegant, pleasant, concise, well formatted, ‘beautiful’ code is easy to maintain rather than the stuff that just fits the coding standards of the company.
I think you have that around the wrong way. The purpose of writing concise, well-formatted code is to ensure that the next person to maintain it (possibly yourself) can read it. Maintainability is the driver – any aesthetic quality is a side-effect of something well suited to purpose…
Personally, I’ll take readability over beauty any day. I don’t give a damn if it looks ‘boring’ or not.
Yes, I agree. And yes its difficutl to get more than a few people to share the required discipline.
Yeah. I’ve (unfortunately) had to maintain some perl code and quickly realized that out of the 9,000 different ways there are to do one thing in perl, perl coders usually gravitate to the most cryptic and hard to read way, because they seem more interested in showing off than actually writing readable code. And you know what I’m talking about too… the kind of code that looks like modem line noise, without a comment in sight.
And I think they do it on purpose too. If you ask me, they’ve gotta be compensating for something. Penis size, perhaps
Edited 2015-07-15 15:20 UTC
The modem static noise style is great, but it takes too long to load up all that parsing logic in your head unless you do it on a daily basis. I deal with output that’s as crazy as that regularly. But it just becomes second nature. But yeah, I’ve turned down perl jobs because its just too much to maintain.
It’s been a long time since most of those features were considered to be anything more than *absolute minimum* functionality for any popular scripting language.
You would think so, I tried to learn Ruby lately but it isn’t easy. I couldn’t understand why it wouldn’t accept constructs like my_array[][] and it turns out that you have to create your own overloading to do auto-vivification. I just couldn’t believe it.
“Most” of those features, I said. Auto-vivification isn’t supported by many other languages, but you’re also citing such basic things as arrays, maps, and file handling. These aren’t exactly unusual features in a scripting language…
As to auto-vivification, it *is* a nice feature, particularly for nested map structures, but not so nice as to outweigh all the other issues with the language…
Autovivication causes headache and bugs. I’d rather initialise an object explicitly. It’s just too error prone and it takes too long to figure out what’s going on: “are we accessing something that is already initialised or did the author intend to initialise it here? Or did the author make a mistake by accessing something that he forgot to initialise somewhere?”
There is also no coherence, some functions do it, others do not. It consumes more brainpower than necessary, energy that could be used for more important things.
Edited 2015-07-16 08:14 UTC
Availability and compatibility. It’s very useful today for all unix admins.
I still use Perl because it’s installed by default in almost all unix flavors (even the very old ones).
If I create a Perl script I know it will run in Solaris, AIX, HP-UX and Linux without the need of installing anything. That’s a bless if you support heterogeneous unix environments.
Python is very popular in the Linux world and It’s a pretty language yes, but it’s not so common in the Unix world. I don’t like Perl, but It saved my ass so many times.