11 ms·

Perl and Undecidability (2008)

67 points by gfredtech 9y ago

grabcocque 9y ago
You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.
- psergeant 9y ago
  Perl is disliked because it has a very shallow learning curve to do badly, and a high learning curve to do well. Therefore, lots of people see a lot of bad code, but also people don’t understand a lot of good code.
  - Ultimatt 9y ago
    Its the main reason any language is hated. JavaScript now is less hated because the tooling got there and people were educated at university to program in it well. PHP and Ruby are on the list of disliked on the SO analysis. Which is basically nonsense for modern versions of both languages. I really wish these stats would state "Perl 5" too, as Perl 6 is really modern in semantics and syntax and is nice to code in.
    - carlmr 9y ago
      I agree that Perl 6 is the first readable version of Perl. It might actually be considered a nice language. Yet all the tools that are newly rewritten by our Perl guys are in Perl 5 because that's what they know.
      - Ultimatt 9y ago
        Well not just what they know, but what all their existing stuff is written in. Makes sense too. The two Perls aren't really that compatible, far worse than migrating Python 2 to 3 and companies struggled with that manoeuvre. You can run and call each language from the other, with some in memory wrangling between https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5 But the same is true for Python and Java objects.
  - ionforce 9y ago
    This is one of the most well-reason and true responses I've ever read about Perl. Who are you?
    - deleted 9y ago
      [deleted]
    - psergeant 9y ago
      https://perl.careers/ https://perl.careers/
- mhd 9y ago
  People don't really care about how hard it is to parse a language, and complex grammers might actually be due to making it easier for humans. One of the bigger differences is IDE support, but more regular languages that compete with Perl had about the same issue here... Perl derives its dislike from about the same source as BASIC (and arguably PHP): Early errors/preconceptions and plenty of non-programmers writing code (home computer users, sysadmins). Perl4 was used for some pretty hacky jobs, replacing sed/awk/shell combinations (which were horribly fragmented across the unices of that time). Modular Perl5 code had little to do with that, but by then the damage was done. Early CGI scripts didn't exactly help, either. Modern Perl is a step further than that, but when Moose and the like became popular, people already moved away to PHP or Ruby, both being part of the same family.
- ceronman 9y ago
  Perl is a very practical language. But this practicality has been achieved by building features on top of bad design. The result is a big, complex and quirky language. To make this worse, the community decided to "fix" this re designing the whole language from scratch. They created Perl 6 which has a much better design, but it's incompatible. The community now it's broken in two and the future doesn't look that good.
  - zbentley 9y ago
    I think the word "big" above is often overlooked when discussing Perl (5). For a scripting language, there are an incredibly huge number of core language features. Even compared to something like Ruby or a lisp-like language with a true templating/macro system. It's easily up there with c++ in terms of "number of (sometimes crazy) things you can do with the core language/distribution out of the box". And that's not even a statement about how many ways there are to the same/similar things things; these features all are intended to facilitate different stuff. I think it is the biggest language I've ever programmed in, fighting for top spot with C++. I think core-language-feature counts are something it's better to have in moderation. JavaScript of ~2010 was far too small a language, so it had crazy library/cargo-cult utility bloat. Lisp is somewhat similar: it's elegance in its small size and simplicity, but that results in a lot of beginners (re)writing a lot of unnecessary code. Perl and C++ have too many core-language features; everything else is somewhere in the middle. ...and all that is without even getting into some of the insane language extensions you can find in third-party libraries. There's an on-after-module-load hook someone wrote that's implemented in terms of a syntax extension to the language, that isn't quite an operator or a statement. There's a coroutine library which is written mostly inside to the fatal-killsignal core dump handler I think (or something similar). And the list goes on.
    - kazinator 9y ago
      > I think core-language-feature counts are something it's better to have in moderation. If an app needs something, it will either get it from there, or failing that, from add-on packages. That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required. Due to inter-package dependencies, that plan can easily be foiled. In the end, it's better to have a big, "batteries included" language. For one thing, it is all released at once. No separate versioning for one hundred different packages. The regression test suite for the language can cover that functionality which would otherwise be in packages. No nonsense of releasing a new version of the language and then relying on field reports about broken packages.
- jasode 9y ago
  >how Perl managed to become quite so profoundly disliked I'm guessing the reasons are actually more conspicuous than computer science concepts of "undecidability" since most working programmers don't read academic papers to judge whether they like/disklike a programming language. The conspicuous reasons seem to be a combination of: 1) PERL's usage of sigils.[1] One the one hand, it makes code compact and terse. On the other hand, many perceive the source code as "line noise" or "sigil hell". This is the opposite problem of other disliked languages like Objective-C where people complain it's too verbose. 2) PERL not having a constantly updated ecosystem that keeps up with new trends in computing. PERL was great for text munging (alternative to sed & awk). However, PERL wasn't extended as the driving language for dynamic web pages (Brendan Eich created Javascript instead of embedding Perl interpreter in Netscape browser), or GUI data entry forms programming (Java and C# gained popularity), or machine learning (Google developers designed Python to be 1st class in Tensorflow), etc. tldr: PERL is perceived as "legacy" with ugly syntax [1] https://en.wikipedia.org/wiki/Sigil_(computer_programming) https://en.wikipedia.org/wiki/Sigil_(computer_programming)
  - Ultimatt 9y ago
    Point 2 is kind of nonsense. The ecosystem is incredibly big and keeps up with most things. Name something then search here https://metacpan.org/ https://metacpan.org/ The main missing stuff is anyone marketing heavily their libraries and there being communities around them etc. Like probably no one knows what PDL is, even though it was around long before numpy+scipy etc. Before data science trended in the mind of hipster VCs and coders. The naming was to try and win over people from the IDL language, used mostly in image analysis in physics/geography. A niche crowd to be sure. Perl sort of never caught on to the modern style of advertising what its got. In the same way no one really advertises grep, awk or sed but lots of people still learn and use them.
    - jasode 9y ago
      >ecosystem is incredibly big I wasn't talking about the size of cpan because it's not relevant to my point. I was talking about Perl not being at the forefront of everyone's minds and being used as a 1st-class environment as computing entered new domains. E.g. instead of Sun or Microsoft taking an existing language like Perl and giving it a canonical IDE to let programmers write data entry GUI applications, they create Java & C# instead. When Google/Android decided on a development language for their smartphone SDK, they chose Java instead of Perl. It doesn't matter if cpan has mobile phone libraries now. You seem to be taking my observations about Perl as some sort of veiled attack. I'm just reporting why and how Perl got to the state of being "disliked" today in programmer surveys. It's not about the "undecidability".
- hultner 9y ago
  It's actually quite interesting, from what I've understood it's one of few well adopted programming languages that's designed by a linguist and made primarily to be easily understood and written by humans. At the time of inception and around the peak of popularity I do believe it was a quite innovative language. But by now we have a much larger set of languages aimed for the same target group, many of which have gained larger adoption among developers of this time. In a way I can almost see Node as "the new Perl" in the sense that it's a widely used language across platforms praised for it's large set of available libraries and ease of creating "quick n' dirty"-hacks.
- pjc50 9y ago
  Perl used to have fans with meetups and so on. I've not heard of these for a long time. IMO three things killed Perl, leaving it as an unpopular legacy husk: - loss of ecosystem. The high points for Perl were CGI.pm and its use as a "super awk" by sysadmins. The first was obliterated by other ecosystems, better and worse: PHP, Rails, Node, Go, and so on. The second was obliterated by "servers are cattle not pets": people have moved from meticulous hand-administration to the use of containers, Ansible, etc - or away from systems administration altogether to AWS or "serverless". - Perl 6 transition. Second-system effect at its highest. The long wait for this to be completed absolutely destroyed incremental improvement because everyone was waiting for a big bang that came very late. Python managed to avoid this level of community damage but has still split into two languages, Python 2 and Python 3. - the "two Perls" of style; one was the Wall-influenced style that looked a bit like English. The other was sigil-heavy and incomprehensible. Eventually people decided that it was easier to put up with syntactic whitespace than remember all the $? and $| and so on, so a lot of the Perl audience moved to Python.
  - oblio 9y ago
    > Python managed to avoid this level of community damage but has still split into two languages, Python 2 and Python 3. The fracture is very slowly healing. Outside of some huge corporate hold outs with a lot of Python 2 code (Google & co.), Python 3 will win out. Perl 6 vs Perl 5, on the other hand, I don't even know if you can call it a fracture. A new start would be more fitting.
    - yellowapple 9y ago
      It's definitely a new start, but both Perl 5 and Perl 6 each have various modules bridging the gap between the two. Yeah, they're definitely separate languages, but (at least in theory) they're very much interoperable. I don't know much about the Python ecosystem, but my impression is that besides the 2to3 program there wasn't really much of an effort to make them work together.
  - rurban 9y ago
    It's more caused by the toxic climate amongst it's maintainers, paired with technical and management incompetence. When Larry Wall was still the lead a lot of progress was made, but then it reversed course in the last 20 years. Every single competent developer left or was booted, and not a single of the many designed features for Perl6 were properly implemented in perl5. Perl5 is now purely a religion, with the heresy to express of loss of faith in the supreme leaders gets you booted, whilst uncivil name-calling and technical destruction by wannabe middle-managers took over. The undecidedability problem is caused by the dynamic lexer. It's actually a feature to drive the static parsing rules dynamically.
- GuB-42 9y ago
  Perl is designed to make life easier for the guy who writes the code, not the one who reads it. The motto "there is more than one way to do it" is telling. It allows beginners to write code the way they are most familiar with and give experts a large toolbox to be most efficient in many situations. The trouble is that while the writer only needs to know a subset of the language, the reader has to know everything in order to read other people code. This philosophy make it very suitable for quick hacks, and that's its primary use. The problem is that quick hacks have a tendency to stay, and some poor guy need to maintain that mess. And when your experience with the language is to maintain the unmaintainable, hate is totally justified. Note that is is possible to write clean Perl, but it requires effort, and unless you are writing Perl modules, there are probably better languages for that. Compiler undecidablity is not a problem. Sure, it is not intellectually satisfying, and it may be troublesome for some application where formal proofs are required, but for a language like Perl that is all about practicality, no one really care.
  - dozzie 9y ago
    > The motto "there is more than one way to do it" is telling. The more telling is you omitting the other half of the motto. TIMTOWTDIBSCINABTE
    - virgilp 9y ago
      > TIMTOWTDIBSCINABTE That's an apt motto for perl. One doesn't even need to know what it means.
      - jwilk 9y ago
        There's more than one way to do it, but sometimes consistency is not a bad thing either.
        bshimmin 9y ago
        Has anyone been able to do this for PHP's T_PAAMAYIM_NEKUDOTAYIM yet? (I know it's not an acronym, but I wish it were.)
- dmytrish 9y ago
  Perl has a lot of crappy language design decisions (which make it "fun" and a tire fire waiting to happen in any large-ish codebase): - interpretation of a variable (is it a list, a number, a string, a hash?) depends on the context in which it's used, and the context depends on, um, its context; - pervasive global state (`$_` and friends); - you can mess with compile-time operations, patch the language on the fly, e.g. during module imports; - autovivification: a single read by key from a hash is enough to actually create this key; variables are a number and a string at once, but the number will not be computed until you need this variable in number context. Reading a non-existing key in a hash as a hash actually creates a new subhash. - ties: you can override access to any variable by your methods; - the built-in data structures are special, there is no sane way to emulate and extend them (but, as usual, for sure there are insane ways); - the built-in `sort` takes a code block (not a closure with parameters), that has magic variables `$a` and `$b` appearing out of thin air. It looks like a closure, but it's not. - features are often added in a convoluted way. E.g. there was a (now deprecated) feature that allowed `push` and `shift` to take a reference to a hash instead of a hash directly. How was it implemented internally? Basically by backpatching the error condition when the existing `push`/`shift` choked on a reference. - the language design principle is "Do What I Mean" (where the "I" part varies). It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic. On the other hand, if your business brings enough income to pay good developers with strong discipline, you can still have a big codebase in Perl and sustain it for years: it's better to have a terrible language and good engineers than bad engineers and a good language.
  - carlmr 9y ago
    >It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic. It's not like having a fascination with weird language quirks makes you have good taste in languages. Especially because weird quirks are the end of usability.
    - daotoad 9y ago
- lazyloop 9y ago
  Perl being a dead and disliked language has become a meme. But the community is still very much alive and a lot of cool stuff is being built with Modern Perl. http://mojolicious.org http://mojolicious.org
c0m0 9y ago
For the people out there that's not so into CS, and does not understands it's implications. It basically means you could write a perl program that could cause an infinite loop in the interpreter (or compiler). This I would presume independant of the actual implementation of the compiler and intrepreter as that would only mean this is a bug report for the specific implementation, and not a problem with the language design.
- c0m0 9y ago
  Actually the problem has more implications, as it's an effect of parsing the code. Any IDE:s that have advanced features that rely on parsing and analysis of the code can be caught in an infinite loop and stop responding. The sad part is, in the general case it's impossible for the parser (or any other process overviewing it) to decide if it's actually caught in an infinite loop or not, that's why they call it undecidability.
  - eru 9y ago
    In theory, yes. Of course in practice, it's not so bad: they can run the parser in a different thread, they can put hard limits on how long they run, etc. (The hard limit is how C++ gets parsed, I think. Since parsing C++ is also undecidable thanks to weird interactions with template metaprogramming.)
    - knome 9y ago
      Yes, templates are turing complete. https://github.com/knome/metabrainfuck/blob/master/bf.cpp https://github.com/knome/metabrainfuck/blob/master/bf.cpp Does attempting to autocomplete such a template cause issues for IDEs? I used emacs when writing it, so I've never tested such a thing.
      - eru 9y ago
        For simpler languages you can implement logic in the editor / IDE for things like precise autocomplete and parsing. For C++ even precise syntax colouring would be undecidable---and just hard to get the logic right. There are two ways out: (1) implement an approximation and the occasional impression, (2) ask the compiler for help. I think the llvm project helps with the latter. (What does emacs have to do with things? Or do you mean you are using emacs without any special support for C++? With the right modes you can turn your emacs (or vim etc) into basically a fully fledged IDE.)
jwilk 9y ago
It's worse than that. You can't parse Perl without running arbitrary Perl code: https://www.perlmonks.org/?node_id=663504 https://www.perlmonks.org/?node_id=663504
- pwdisswordfish 9y ago
  http://www.perlmonks.org/?node_id=663504 http://www.perlmonks.org/?node_id=663504 Site's not ready for 21st century.
  - dozzie 9y ago
    Indeed it's not ready. It loads and reacts to clicks too fast and doesn't use two megabytes of JavaScript.
    - werdnapk 9y ago
      ie. A misconfigured webserver for ssl.
    - pwdisswordfish 9y ago
      https://i.imgur.com/ImKOkpH.png https://i.imgur.com/ImKOkpH.png https://i.imgur.com/ih1mK80.png https://i.imgur.com/ih1mK80.png I guess it's time to love JavaScript, because with 2mb bundles it keeps people with literally no clue like you from not being my colleagues.
  - draw_down 9y ago
    Neither am I.
- arnsholt 9y ago
  So? It's not that uncommon for highly dynamic languages to do this. Lisp macros for example depend on being able to run arbitrary code at compile-time.
  - jerf 9y ago
SonOfLilit 9y ago
C++ is also undecidable, by the way: http://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html http://blog.reverberate.org/2013/08/parsing-c-is-literally-u... Perl was a great language design lab experiment. They gave people 20 ways to do any simple thing, and then Matz and Guido looked to see which ways became popular and designed great languages that allow only those ways and maybe 1-2 more that are highly frowned upon. I'm almost as glad Perl exists as I am that I never needed to learn it.
- chrismorgan 9y ago
  Going off on a tangent: I dislike standard sluggification algorithms; they’re far too fond of throwing away useful parts of the title, like small words in some or turning C++ into just c in almost all cases. parsing-c-is-literally-undecidable would be so much better as parsing-c++-is-literally-undecidable (but note that Amazon S3’s HTTP server has a broken implementation of + in file names that they refuse to fix; with that exception, using + in the URL is perfectly safe everywhere I know of) or even parsing-cpp-is-literally-undecidable (you might choose this manually) or parsing-c-plus-plus-is-literally-undecidable (a sluggifier might produce this).
- eesmith 9y ago
  I don't think the language design influence of Perl on Python was as strong as you imply. (Not that there's no influence.) Certainly the influence on Ruby was larger. Also, I seem to recall the Perl5 object model was influenced by Python.
  - deleted 9y ago
    [deleted]
  - dagw 9y ago
    I don't think the language design influence of Perl on Python was as strong as you imply. I think the influence was mainly in Guido looking at Perl and realizing he wanted a language that didn't look like that. I'm pretty sure the Guido has said that ALGOL 68 and Pascal was probably the biggest positive outside influences (together with some in-house language called ABC that he was using at the time)
hpcjoe 9y ago
[not trying to hijack the discussion, but I think a meta-discussion is in order based on comments I've seen on this article] The article is about whether or not you can actually parse Perl without running Perl to parse itself. One of the benefits/drawbacks to Perl is that it lets you run the interpreter at compile time, thus resulting in the possibility of an infinite loop preventing compilation. Which makes some people unhappy. Oddly enough, this reminds me of the whole strongly/weakly typed discussion, with people weighing in and asserting one position or another, without really adequately comprehending the opposing position. The meta-discussion here repeats almost every other discussion of Perl I see on HN and elsewhere. First there is a claim of death, either in the past, or present. Then there are claims that death was by sigil, line noise, etc. Further, additional claims are that other tools have taken over its space. The data used as evidence are StackOverflow analyses, or Tiobe scores, or, insert additional popular, and often self-selected, data sets. You have to make specific assumptions about some of the data presented to be able to accept it, such that each community has about the same rate of people searching for answers on SO, or other places. Or that the searches will have relevant terms in the in each case. This is a stretch to put it mildly. If I google for DBIx::Simple, and this search is caught by one of these filters, will it show up in Perl or not? I can't actually answer this. I have to refer to what the collectors of the data say on their own methodology [1][2]. I am not saying that there are not secular changes throughout the industry, or that various observed gross trends are "wrong". What I am saying is be careful reading into these analyses too strongly, as they may not be measuring what you think they are measuring. In many cases, over the last 20 years or so, I've seen folks pushing Python happily talking up why they left or abhor Perl, usually saying/quoting things they've heard. From my own experience, Perl 4 and onward, much of what they complain about was Perl 4 or before. Likely before many of them started programming. That is speculation on my part, but it does appear to fit what I've observed. If I extend this out to operating systems, I have people tell me how horrible Linux is and how much better anything-other-than-linux is than it on a very regular basis. They like to list (what they perceive to be) the faults, quote SO and other random websites as examples, and often make pronouncements not backed up by objective fact ... in many cases contradicted by objective fact. We as a society of technologists seem to like our tools to the point where we feel that we can and should break into tribes with tags of honor around our necks, and nasty comments about alternative tools, and users of said tools. I've personally heard many an anecdote and critique of various tools from otherwise smart technologists that were, at best, badly misinformed, and at worst ... not simply disingenuous, but dishonest. Look, it is great you like your tools, your operating system, your language. It does not mean that you are "better" or "smarter" than someone else because you use such things. And yes, I've had professional discussions as recently as last week on exactly this issue. Which is insane. Maybe I've spent too many years on the business side, as I look at all of these things as tools to accomplish a goal, and as engineers, our jobs are to select the right combination of tools to a) minimize effort, b) maximize the possibility of success, c) enable debugging, observability, supportability. No single tool, OS, editor (yes, I went there) has this. Moreover, if you need to bash what someone else is using simply for self gratification, then there are deeper issues afoot than simply a technological consideration. Finally, I've been a user of Perl, and contributor to (CPAN) for more 20 years. Rumors of its demise, are greatly exaggerated. It is not my be-all/end-all language ... I am comfortable and competent in 5-6 at any one time, and can easily work in Python, C, Julia, Node, etc. w/o major issue (though with google nearby for things I don't have on the tip of my memory). I don't use Perl for machine learning (though I could). I don't use it for numerics (though, again, I could). I don't use node for either of these. You pick the right tool for the right job. And you need to keep an open mind throughout the process on what the right tool is. If you feel a need to bash on others choices, it might be worth reflecting why you think this course of action actually adds any light to a discussion. From what I've seen, it only adds heat. [1] http://blog.codeeval.com/codeevalblog/2016/2/2/most-popular-coding-languages-of-2016 http://blog.codeeval.com/codeevalblog/2016/2/2/most-popular-... [2] https://stackoverflow.blog/2017/05/09/introducing-stack-overflow-trends/ https://stackoverflow.blog/2017/05/09/introducing-stack-over... [edit: fixed ref spacing]
jerianasmith 9y ago
As far as undesirability is concerned, there are other languages, perl is not the only one. But it's possible to write clean perl.
rurban 9y ago
The same holds for every better dynamic language with compile-time evaluation. E.g. LISP with its reader macros. Even if LISP is trivially parsable, it still provides parse-time hooks which can lead to undecidability. It's a feature, not a problem.
esaym 9y ago
Perl is awesome. I bring in 90k+ a year making a living on perl while only working remotely ( and living in a small city where the avg household income is <$50k year). Honestly, the only reason python "won" was because google picked it up for internal use (and that was only because of the perl5/6 debacle since why pick perl5 since 6 would be coming out by next Christmas?) As far as "undecidable", its a feature and one of the reasons why it still remains faster than most other dynamic scripting languages.
- jandrese 9y ago
  IMHO, Perl was hurt more by its sigils than the protracted P6 development. There was a lot of revulsion to sprinkling your code liberally with $, @, and %. Many many comments about writing unreadable line noise when programming Perl. Python's genius was to force programmers to indent their code, making sure it had at least a modicum of structure.
  - yellowapple 9y ago
    I still don't understand that revulsion. Yeah, it looks "ugly", maybe (a valid but very subjective opinion), but it also makes it obvious that something is a variable and - specifically - whether that variable is singular or plural at a given moment. The "Perl is indistinguishable from line noise" meme came about from folks equating JAPH-style Perl Golf one-liners with all of Perl. It had very little to do with the use of sigils specifically; such "line noise" is perfectly possible in Ruby and Python. If anything specific to Perl contributed to the "Perl is line noise" meme, it's probably the fact that a bunch of special variables have names consisting of punctuation marks. Nothing stopping the programmer from doing a "use English;", though.
chubot 9y ago
Related: Parsing Bash is Undecideable http://www.oilshell.org/blog/2016/10/20.html http://www.oilshell.org/blog/2016/10/20.html Parsing POSIX shell is not undecideable, but bash adds a construct that relies on dynamic parsing, much like Perl. (I cite this Perl article and the C++ one in this thread. And there is another one about parsing GNU Make.) FWIW, Larry Wall has mentioned many times that Perl 6 fixes this problem. So he very much views it as a language design flaw. I don't think you can argue that it's not. I watched 3 or more videos on Perl 6 and he's mentioned it at least twice.
cutler 9y ago
It's almost 2 years since Perl 6 was released and it's still dog slow at what Perl 5 was famous for - string parsing with regular expressions. A 19Mb Apache log file on my 2010 quad core Mac takes Perl 6 21 secs. to search for lines containing 15-character words compared with Ruby: 4secs, Perl 5: 2.4 secs. and PHP7: 0.8 secs. We keeping hearing how the optimisations are coming but I haven't seen any significant improvements in string parsing since Perl 6 was released in December 2015. How can you market the advantages of a new version of a language when it can't even match its predecessor?
- Ultimatt 9y ago
  Because its faster at OO than Perl 5 and has a tonne of other builtins that make it easier to write algorithmically performant code. Not to mention its trivial to write parallel code. I dont think there have been any optimisations in the regex engine in the time you're discussing. The raw IO however has seen huge improvement, especially if you state you arent using unicode and don't want grapheme normalisation. In 2011 just my tests took 35s to execute. Now that's 1s and startup time is 2/3 of that. Something like CSV parsing or even log parsing where you split instead of regex is competitive. Last I checked faster than Ruby but slower than C. But yeah you do still have to work around the slow bits, or be explicit with what you want like ascii IO.
  - cutler 9y ago
    Faster OO but dog slow regexes? This is Perl, right? The Practical Extraction and Reporting Language where extraction is largely the work of regular expressions and, now, grammars. OO languages are a dime a dozen so how can OO be Perl 6's main priority?
    - b2gills 9y ago
      To be fair Perl 6 returns structured data from regexes, whereas Perl 5 returns flat data. That has huge implications on how different the regex sub-languages gets parsed. It also has a significantly different syntax, and integrates more into the rest of the language. Basically it had to be created from scratch, so that would mean that it couldn't benefit from the already existing optimizations of the Perl 5 regex engine. Perl 6 is also a mostly unpaid volunteer effort. So everybody gets to choose what they work on, and very few people are brave enough to work on that aspect of the compiler. Also I would say that the main priority of Perl 6 is to integrate many ideas from many languages and bring them together in such a way that it seems as if all of these ideas always belonged together. The reason why the object system sees more optimizations is because everything is, or can be seen as, an object. A big improvement there, can for example make regexes faster.

67 points by gfredtech 9y ago

You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.

psergeant 9y ago
Perl is disliked because it has a very shallow learning curve to do badly, and a high learning curve to do well. Therefore, lots of people see a lot of bad code, but also people don’t understand a lot of good code.
- Ultimatt 9y ago
  Its the main reason any language is hated. JavaScript now is less hated because the tooling got there and people were educated at university to program in it well. PHP and Ruby are on the list of disliked on the SO analysis. Which is basically nonsense for modern versions of both languages. I really wish these stats would state "Perl 5" too, as Perl 6 is really modern in semantics and syntax and is nice to code in.
  - carlmr 9y ago
    I agree that Perl 6 is the first readable version of Perl. It might actually be considered a nice language. Yet all the tools that are newly rewritten by our Perl guys are in Perl 5 because that's what they know.
    - Ultimatt 9y ago
      Well not just what they know, but what all their existing stuff is written in. Makes sense too. The two Perls aren't really that compatible, far worse than migrating Python 2 to 3 and companies struggled with that manoeuvre. You can run and call each language from the other, with some in memory wrangling between https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5 But the same is true for Python and Java objects.
- ionforce 9y ago
  This is one of the most well-reason and true responses I've ever read about Perl. Who are you?
  - deleted 9y ago
    [deleted]
  - psergeant 9y ago
    https://perl.careers/ https://perl.careers/
mhd 9y ago
People don't really care about how hard it is to parse a language, and complex grammers might actually be due to making it easier for humans. One of the bigger differences is IDE support, but more regular languages that compete with Perl had about the same issue here... Perl derives its dislike from about the same source as BASIC (and arguably PHP): Early errors/preconceptions and plenty of non-programmers writing code (home computer users, sysadmins). Perl4 was used for some pretty hacky jobs, replacing sed/awk/shell combinations (which were horribly fragmented across the unices of that time). Modular Perl5 code had little to do with that, but by then the damage was done. Early CGI scripts didn't exactly help, either. Modern Perl is a step further than that, but when Moose and the like became popular, people already moved away to PHP or Ruby, both being part of the same family.
ceronman 9y ago
Perl is a very practical language. But this practicality has been achieved by building features on top of bad design. The result is a big, complex and quirky language. To make this worse, the community decided to "fix" this re designing the whole language from scratch. They created Perl 6 which has a much better design, but it's incompatible. The community now it's broken in two and the future doesn't look that good.
- zbentley 9y ago
  I think the word "big" above is often overlooked when discussing Perl (5). For a scripting language, there are an incredibly huge number of core language features. Even compared to something like Ruby or a lisp-like language with a true templating/macro system. It's easily up there with c++ in terms of "number of (sometimes crazy) things you can do with the core language/distribution out of the box". And that's not even a statement about how many ways there are to the same/similar things things; these features all are intended to facilitate different stuff. I think it is the biggest language I've ever programmed in, fighting for top spot with C++. I think core-language-feature counts are something it's better to have in moderation. JavaScript of ~2010 was far too small a language, so it had crazy library/cargo-cult utility bloat. Lisp is somewhat similar: it's elegance in its small size and simplicity, but that results in a lot of beginners (re)writing a lot of unnecessary code. Perl and C++ have too many core-language features; everything else is somewhere in the middle. ...and all that is without even getting into some of the insane language extensions you can find in third-party libraries. There's an on-after-module-load hook someone wrote that's implemented in terms of a syntax extension to the language, that isn't quite an operator or a statement. There's a coroutine library which is written mostly inside to the fatal-killsignal core dump handler I think (or something similar). And the list goes on.
  - kazinator 9y ago
    > I think core-language-feature counts are something it's better to have in moderation. If an app needs something, it will either get it from there, or failing that, from add-on packages. That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required. Due to inter-package dependencies, that plan can easily be foiled. In the end, it's better to have a big, "batteries included" language. For one thing, it is all released at once. No separate versioning for one hundred different packages. The regression test suite for the language can cover that functionality which would otherwise be in packages. No nonsense of releasing a new version of the language and then relying on field reports about broken packages.
jasode 9y ago
>how Perl managed to become quite so profoundly disliked I'm guessing the reasons are actually more conspicuous than computer science concepts of "undecidability" since most working programmers don't read academic papers to judge whether they like/disklike a programming language. The conspicuous reasons seem to be a combination of: 1) PERL's usage of sigils.[1] One the one hand, it makes code compact and terse. On the other hand, many perceive the source code as "line noise" or "sigil hell". This is the opposite problem of other disliked languages like Objective-C where people complain it's too verbose. 2) PERL not having a constantly updated ecosystem that keeps up with new trends in computing. PERL was great for text munging (alternative to sed & awk). However, PERL wasn't extended as the driving language for dynamic web pages (Brendan Eich created Javascript instead of embedding Perl interpreter in Netscape browser), or GUI data entry forms programming (Java and C# gained popularity), or machine learning (Google developers designed Python to be 1st class in Tensorflow), etc. tldr: PERL is perceived as "legacy" with ugly syntax [1] https://en.wikipedia.org/wiki/Sigil_(computer_programming) https://en.wikipedia.org/wiki/Sigil_(computer_programming)
- Ultimatt 9y ago
  Point 2 is kind of nonsense. The ecosystem is incredibly big and keeps up with most things. Name something then search here https://metacpan.org/ https://metacpan.org/ The main missing stuff is anyone marketing heavily their libraries and there being communities around them etc. Like probably no one knows what PDL is, even though it was around long before numpy+scipy etc. Before data science trended in the mind of hipster VCs and coders. The naming was to try and win over people from the IDL language, used mostly in image analysis in physics/geography. A niche crowd to be sure. Perl sort of never caught on to the modern style of advertising what its got. In the same way no one really advertises grep, awk or sed but lots of people still learn and use them.
  - jasode 9y ago
    >ecosystem is incredibly big I wasn't talking about the size of cpan because it's not relevant to my point. I was talking about Perl not being at the forefront of everyone's minds and being used as a 1st-class environment as computing entered new domains. E.g. instead of Sun or Microsoft taking an existing language like Perl and giving it a canonical IDE to let programmers write data entry GUI applications, they create Java & C# instead. When Google/Android decided on a development language for their smartphone SDK, they chose Java instead of Perl. It doesn't matter if cpan has mobile phone libraries now. You seem to be taking my observations about Perl as some sort of veiled attack. I'm just reporting why and how Perl got to the state of being "disliked" today in programmer surveys. It's not about the "undecidability".
hultner 9y ago
It's actually quite interesting, from what I've understood it's one of few well adopted programming languages that's designed by a linguist and made primarily to be easily understood and written by humans. At the time of inception and around the peak of popularity I do believe it was a quite innovative language. But by now we have a much larger set of languages aimed for the same target group, many of which have gained larger adoption among developers of this time. In a way I can almost see Node as "the new Perl" in the sense that it's a widely used language across platforms praised for it's large set of available libraries and ease of creating "quick n' dirty"-hacks.
pjc50 9y ago
Perl used to have fans with meetups and so on. I've not heard of these for a long time. IMO three things killed Perl, leaving it as an unpopular legacy husk: - loss of ecosystem. The high points for Perl were CGI.pm and its use as a "super awk" by sysadmins. The first was obliterated by other ecosystems, better and worse: PHP, Rails, Node, Go, and so on. The second was obliterated by "servers are cattle not pets": people have moved from meticulous hand-administration to the use of containers, Ansible, etc - or away from systems administration altogether to AWS or "serverless". - Perl 6 transition. Second-system effect at its highest. The long wait for this to be completed absolutely destroyed incremental improvement because everyone was waiting for a big bang that came very late. Python managed to avoid this level of community damage but has still split into two languages, Python 2 and Python 3. - the "two Perls" of style; one was the Wall-influenced style that looked a bit like English. The other was sigil-heavy and incomprehensible. Eventually people decided that it was easier to put up with syntactic whitespace than remember all the $? and $| and so on, so a lot of the Perl audience moved to Python.
- oblio 9y ago
  > Python managed to avoid this level of community damage but has still split into two languages, Python 2 and Python 3. The fracture is very slowly healing. Outside of some huge corporate hold outs with a lot of Python 2 code (Google & co.), Python 3 will win out. Perl 6 vs Perl 5, on the other hand, I don't even know if you can call it a fracture. A new start would be more fitting.
  - yellowapple 9y ago
    It's definitely a new start, but both Perl 5 and Perl 6 each have various modules bridging the gap between the two. Yeah, they're definitely separate languages, but (at least in theory) they're very much interoperable. I don't know much about the Python ecosystem, but my impression is that besides the 2to3 program there wasn't really much of an effort to make them work together.
- rurban 9y ago
  It's more caused by the toxic climate amongst it's maintainers, paired with technical and management incompetence. When Larry Wall was still the lead a lot of progress was made, but then it reversed course in the last 20 years. Every single competent developer left or was booted, and not a single of the many designed features for Perl6 were properly implemented in perl5. Perl5 is now purely a religion, with the heresy to express of loss of faith in the supreme leaders gets you booted, whilst uncivil name-calling and technical destruction by wannabe middle-managers took over. The undecidedability problem is caused by the dynamic lexer. It's actually a feature to drive the static parsing rules dynamically.
GuB-42 9y ago
Perl is designed to make life easier for the guy who writes the code, not the one who reads it. The motto "there is more than one way to do it" is telling. It allows beginners to write code the way they are most familiar with and give experts a large toolbox to be most efficient in many situations. The trouble is that while the writer only needs to know a subset of the language, the reader has to know everything in order to read other people code. This philosophy make it very suitable for quick hacks, and that's its primary use. The problem is that quick hacks have a tendency to stay, and some poor guy need to maintain that mess. And when your experience with the language is to maintain the unmaintainable, hate is totally justified. Note that is is possible to write clean Perl, but it requires effort, and unless you are writing Perl modules, there are probably better languages for that. Compiler undecidablity is not a problem. Sure, it is not intellectually satisfying, and it may be troublesome for some application where formal proofs are required, but for a language like Perl that is all about practicality, no one really care.
- dozzie 9y ago
  > The motto "there is more than one way to do it" is telling. The more telling is you omitting the other half of the motto. TIMTOWTDIBSCINABTE
  - virgilp 9y ago
    > TIMTOWTDIBSCINABTE That's an apt motto for perl. One doesn't even need to know what it means.
    - jwilk 9y ago
      There's more than one way to do it, but sometimes consistency is not a bad thing either.
      - bshimmin 9y ago
        Has anyone been able to do this for PHP's T_PAAMAYIM_NEKUDOTAYIM yet? (I know it's not an acronym, but I wish it were.)
dmytrish 9y ago
Perl has a lot of crappy language design decisions (which make it "fun" and a tire fire waiting to happen in any large-ish codebase): - interpretation of a variable (is it a list, a number, a string, a hash?) depends on the context in which it's used, and the context depends on, um, its context; - pervasive global state (`$_` and friends); - you can mess with compile-time operations, patch the language on the fly, e.g. during module imports; - autovivification: a single read by key from a hash is enough to actually create this key; variables are a number and a string at once, but the number will not be computed until you need this variable in number context. Reading a non-existing key in a hash as a hash actually creates a new subhash. - ties: you can override access to any variable by your methods; - the built-in data structures are special, there is no sane way to emulate and extend them (but, as usual, for sure there are insane ways); - the built-in `sort` takes a code block (not a closure with parameters), that has magic variables `$a` and `$b` appearing out of thin air. It looks like a closure, but it's not. - features are often added in a convoluted way. E.g. there was a (now deprecated) feature that allowed `push` and `shift` to take a reference to a hash instead of a hash directly. How was it implemented internally? Basically by backpatching the error condition when the existing `push`/`shift` choked on a reference. - the language design principle is "Do What I Mean" (where the "I" part varies). It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic. On the other hand, if your business brings enough income to pay good developers with strong discipline, you can still have a big codebase in Perl and sustain it for years: it's better to have a terrible language and good engineers than bad engineers and a good language.
- carlmr 9y ago
  >It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic. It's not like having a fascination with weird language quirks makes you have good taste in languages. Especially because weird quirks are the end of usability.
  - daotoad 9y ago
lazyloop 9y ago
Perl being a dead and disliked language has become a meme. But the community is still very much alive and a lot of cool stuff is being built with Modern Perl. http://mojolicious.org http://mojolicious.org

c0m0 9y ago

For the people out there that's not so into CS, and does not understands it's implications. It basically means you could write a perl program that could cause an infinite loop in the interpreter (or compiler). This I would presume independant of the actual implementation of the compiler and intrepreter as that would only mean this is a bug report for the specific implementation, and not a problem with the language design.

c0m0 9y ago
Actually the problem has more implications, as it's an effect of parsing the code. Any IDE:s that have advanced features that rely on parsing and analysis of the code can be caught in an infinite loop and stop responding. The sad part is, in the general case it's impossible for the parser (or any other process overviewing it) to decide if it's actually caught in an infinite loop or not, that's why they call it undecidability.
- eru 9y ago
  In theory, yes. Of course in practice, it's not so bad: they can run the parser in a different thread, they can put hard limits on how long they run, etc. (The hard limit is how C++ gets parsed, I think. Since parsing C++ is also undecidable thanks to weird interactions with template metaprogramming.)
  - knome 9y ago
    Yes, templates are turing complete. https://github.com/knome/metabrainfuck/blob/master/bf.cpp https://github.com/knome/metabrainfuck/blob/master/bf.cpp Does attempting to autocomplete such a template cause issues for IDEs? I used emacs when writing it, so I've never tested such a thing.
    - eru 9y ago
      For simpler languages you can implement logic in the editor / IDE for things like precise autocomplete and parsing. For C++ even precise syntax colouring would be undecidable---and just hard to get the logic right. There are two ways out: (1) implement an approximation and the occasional impression, (2) ask the compiler for help. I think the llvm project helps with the latter. (What does emacs have to do with things? Or do you mean you are using emacs without any special support for C++? With the right modes you can turn your emacs (or vim etc) into basically a fully fledged IDE.)

jwilk 9y ago

It's worse than that. You can't parse Perl without running arbitrary Perl code: https://www.perlmonks.org/?node_id=663504 https://www.perlmonks.org/?node_id=663504

pwdisswordfish 9y ago
http://www.perlmonks.org/?node_id=663504 http://www.perlmonks.org/?node_id=663504 Site's not ready for 21st century.
- dozzie 9y ago
  Indeed it's not ready. It loads and reacts to clicks too fast and doesn't use two megabytes of JavaScript.
  - werdnapk 9y ago
    ie. A misconfigured webserver for ssl.
  - pwdisswordfish 9y ago
    https://i.imgur.com/ImKOkpH.png https://i.imgur.com/ImKOkpH.png https://i.imgur.com/ih1mK80.png https://i.imgur.com/ih1mK80.png I guess it's time to love JavaScript, because with 2mb bundles it keeps people with literally no clue like you from not being my colleagues.
- draw_down 9y ago
  Neither am I.
arnsholt 9y ago
So? It's not that uncommon for highly dynamic languages to do this. Lisp macros for example depend on being able to run arbitrary code at compile-time.
- jerf 9y ago

SonOfLilit 9y ago

C++ is also undecidable, by the way: http://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html http://blog.reverberate.org/2013/08/parsing-c-is-literally-u... Perl was a great language design lab experiment. They gave people 20 ways to do any simple thing, and then Matz and Guido looked to see which ways became popular and designed great languages that allow only those ways and maybe 1-2 more that are highly frowned upon. I'm almost as glad Perl exists as I am that I never needed to learn it.

chrismorgan 9y ago
Going off on a tangent: I dislike standard sluggification algorithms; they’re far too fond of throwing away useful parts of the title, like small words in some or turning C++ into just c in almost all cases. parsing-c-is-literally-undecidable would be so much better as parsing-c++-is-literally-undecidable (but note that Amazon S3’s HTTP server has a broken implementation of + in file names that they refuse to fix; with that exception, using + in the URL is perfectly safe everywhere I know of) or even parsing-cpp-is-literally-undecidable (you might choose this manually) or parsing-c-plus-plus-is-literally-undecidable (a sluggifier might produce this).
eesmith 9y ago
I don't think the language design influence of Perl on Python was as strong as you imply. (Not that there's no influence.) Certainly the influence on Ruby was larger. Also, I seem to recall the Perl5 object model was influenced by Python.
- deleted 9y ago
  [deleted]
- dagw 9y ago
  I don't think the language design influence of Perl on Python was as strong as you imply. I think the influence was mainly in Guido looking at Perl and realizing he wanted a language that didn't look like that. I'm pretty sure the Guido has said that ALGOL 68 and Pascal was probably the biggest positive outside influences (together with some in-house language called ABC that he was using at the time)

hpcjoe 9y ago

[not trying to hijack the discussion, but I think a meta-discussion is in order based on comments I've seen on this article] The article is about whether or not you can actually parse Perl without running Perl to parse itself. One of the benefits/drawbacks to Perl is that it lets you run the interpreter at compile time, thus resulting in the possibility of an infinite loop preventing compilation. Which makes some people unhappy. Oddly enough, this reminds me of the whole strongly/weakly typed discussion, with people weighing in and asserting one position or another, without really adequately comprehending the opposing position. The meta-discussion here repeats almost every other discussion of Perl I see on HN and elsewhere. First there is a claim of death, either in the past, or present. Then there are claims that death was by sigil, line noise, etc. Further, additional claims are that other tools have taken over its space. The data used as evidence are StackOverflow analyses, or Tiobe scores, or, insert additional popular, and often self-selected, data sets. You have to make specific assumptions about some of the data presented to be able to accept it, such that each community has about the same rate of people searching for answers on SO, or other places. Or that the searches will have relevant terms in the in each case. This is a stretch to put it mildly. If I google for DBIx::Simple, and this search is caught by one of these filters, will it show up in Perl or not? I can't actually answer this. I have to refer to what the collectors of the data say on their own methodology [1][2]. I am not saying that there are not secular changes throughout the industry, or that various observed gross trends are "wrong". What I am saying is be careful reading into these analyses too strongly, as they may not be measuring what you think they are measuring. In many cases, over the last 20 years or so, I've seen folks pushing Python happily talking up why they left or abhor Perl, usually saying/quoting things they've heard. From my own experience, Perl 4 and onward, much of what they complain about was Perl 4 or before. Likely before many of them started programming. That is speculation on my part, but it does appear to fit what I've observed. If I extend this out to operating systems, I have people tell me how horrible Linux is and how much better anything-other-than-linux is than it on a very regular basis. They like to list (what they perceive to be) the faults, quote SO and other random websites as examples, and often make pronouncements not backed up by objective fact ... in many cases contradicted by objective fact. We as a society of technologists seem to like our tools to the point where we feel that we can and should break into tribes with tags of honor around our necks, and nasty comments about alternative tools, and users of said tools. I've personally heard many an anecdote and critique of various tools from otherwise smart technologists that were, at best, badly misinformed, and at worst ... not simply disingenuous, but dishonest. Look, it is great you like your tools, your operating system, your language. It does not mean that you are "better" or "smarter" than someone else because you use such things. And yes, I've had professional discussions as recently as last week on exactly this issue. Which is insane. Maybe I've spent too many years on the business side, as I look at all of these things as tools to accomplish a goal, and as engineers, our jobs are to select the right combination of tools to a) minimize effort, b) maximize the possibility of success, c) enable debugging, observability, supportability. No single tool, OS, editor (yes, I went there) has this. Moreover, if you need to bash what someone else is using simply for self gratification, then there are deeper issues afoot than simply a technological consideration. Finally, I've been a user of Perl, and contributor to (CPAN) for more 20 years. Rumors of its demise, are greatly exaggerated. It is not my be-all/end-all language ... I am comfortable and competent in 5-6 at any one time, and can easily work in Python, C, Julia, Node, etc. w/o major issue (though with google nearby for things I don't have on the tip of my memory). I don't use Perl for machine learning (though I could). I don't use it for numerics (though, again, I could). I don't use node for either of these. You pick the right tool for the right job. And you need to keep an open mind throughout the process on what the right tool is. If you feel a need to bash on others choices, it might be worth reflecting why you think this course of action actually adds any light to a discussion. From what I've seen, it only adds heat. [1] http://blog.codeeval.com/codeevalblog/2016/2/2/most-popular-coding-languages-of-2016 http://blog.codeeval.com/codeevalblog/2016/2/2/most-popular-... [2] https://stackoverflow.blog/2017/05/09/introducing-stack-overflow-trends/ https://stackoverflow.blog/2017/05/09/introducing-stack-over... [edit: fixed ref spacing]

jerianasmith 9y ago

As far as undesirability is concerned, there are other languages, perl is not the only one. But it's possible to write clean perl.

rurban 9y ago

The same holds for every better dynamic language with compile-time evaluation. E.g. LISP with its reader macros. Even if LISP is trivially parsable, it still provides parse-time hooks which can lead to undecidability. It's a feature, not a problem.

esaym 9y ago

Perl is awesome. I bring in 90k+ a year making a living on perl while only working remotely ( and living in a small city where the avg household income is <$50k year). Honestly, the only reason python "won" was because google picked it up for internal use (and that was only because of the perl5/6 debacle since why pick perl5 since 6 would be coming out by next Christmas?) As far as "undecidable", its a feature and one of the reasons why it still remains faster than most other dynamic scripting languages.

jandrese 9y ago
IMHO, Perl was hurt more by its sigils than the protracted P6 development. There was a lot of revulsion to sprinkling your code liberally with $, @, and %. Many many comments about writing unreadable line noise when programming Perl. Python's genius was to force programmers to indent their code, making sure it had at least a modicum of structure.
- yellowapple 9y ago
  I still don't understand that revulsion. Yeah, it looks "ugly", maybe (a valid but very subjective opinion), but it also makes it obvious that something is a variable and - specifically - whether that variable is singular or plural at a given moment. The "Perl is indistinguishable from line noise" meme came about from folks equating JAPH-style Perl Golf one-liners with all of Perl. It had very little to do with the use of sigils specifically; such "line noise" is perfectly possible in Ruby and Python. If anything specific to Perl contributed to the "Perl is line noise" meme, it's probably the fact that a bunch of special variables have names consisting of punctuation marks. Nothing stopping the programmer from doing a "use English;", though.

chubot 9y ago

Related: Parsing Bash is Undecideable http://www.oilshell.org/blog/2016/10/20.html http://www.oilshell.org/blog/2016/10/20.html Parsing POSIX shell is not undecideable, but bash adds a construct that relies on dynamic parsing, much like Perl. (I cite this Perl article and the C++ one in this thread. And there is another one about parsing GNU Make.) FWIW, Larry Wall has mentioned many times that Perl 6 fixes this problem. So he very much views it as a language design flaw. I don't think you can argue that it's not. I watched 3 or more videos on Perl 6 and he's mentioned it at least twice.

cutler 9y ago

It's almost 2 years since Perl 6 was released and it's still dog slow at what Perl 5 was famous for - string parsing with regular expressions. A 19Mb Apache log file on my 2010 quad core Mac takes Perl 6 21 secs. to search for lines containing 15-character words compared with Ruby: 4secs, Perl 5: 2.4 secs. and PHP7: 0.8 secs. We keeping hearing how the optimisations are coming but I haven't seen any significant improvements in string parsing since Perl 6 was released in December 2015. How can you market the advantages of a new version of a language when it can't even match its predecessor?

Ultimatt 9y ago
Because its faster at OO than Perl 5 and has a tonne of other builtins that make it easier to write algorithmically performant code. Not to mention its trivial to write parallel code. I dont think there have been any optimisations in the regex engine in the time you're discussing. The raw IO however has seen huge improvement, especially if you state you arent using unicode and don't want grapheme normalisation. In 2011 just my tests took 35s to execute. Now that's 1s and startup time is 2/3 of that. Something like CSV parsing or even log parsing where you split instead of regex is competitive. Last I checked faster than Ruby but slower than C. But yeah you do still have to work around the slow bits, or be explicit with what you want like ascii IO.
- cutler 9y ago
  Faster OO but dog slow regexes? This is Perl, right? The Practical Extraction and Reporting Language where extraction is largely the work of regular expressions and, now, grammars. OO languages are a dime a dozen so how can OO be Perl 6's main priority?
  - b2gills 9y ago
    To be fair Perl 6 returns structured data from regexes, whereas Perl 5 returns flat data. That has huge implications on how different the regex sub-languages gets parsed. It also has a significantly different syntax, and integrates more into the rest of the language. Basically it had to be created from scratch, so that would mean that it couldn't benefit from the already existing optimizations of the Perl 5 regex engine. Perl 6 is also a mostly unpaid volunteer effort. So everybody gets to choose what they work on, and very few people are brave enough to work on that aspect of the compiler. Also I would say that the main priority of Perl 6 is to integrate many ideas from many languages and bring them together in such a way that it seems as if all of these ideas always belonged together. The reason why the object system sees more optimizations is because everything is, or can be seen as, an object. A big improvement there, can for example make regexes faster.