43 ms·

Perl 11

totalperspectiv 8y ago
I had no idea any of these existed. And it looks like RPerl recently hit its 4.0 release... kind of looks like Nim.
Insanity 8y ago
So is this by the same people behind 'vanilla' perl (Larry etc)? I am assuming not but could not immediately find the information on the (mobile) website.
- totalperspectiv 8y ago
  I don't think so. It seems to be those that are not the current perl5 maintainers (perl 5 porters), or the perl6 devs. But I could be wrong.
  - karavelov 8y ago
    Yes, I think it's mainly one dev trying to make it best fit their own use case.
    - totalperspectiv 8y ago
      Well, each of the projects on that page have separate, but slightly overlapping contributors based on github. I was amazed that: A) Many of the projects on that page are alive and have commits within the last few days. B) They actually seem to be doing what they set out to do. Especially cperl. C) The existence of Rperl, which looks likey pypy for perl.
    - SwellJoe 8y ago
      The two most usable examples (aside from MoarVM, which isn't really connected in any clear way, as it is the current mainline VM implementation for Perl 6), cperl and RPerl, are by two different developers, with different but occasionally overlapping goals. The author of cperl posts on HN frequently, so it seems likely he'd have interesting thoughts on this. The concept of calling a bunch of marginally related and only partly compatible projects "Perl 11" is kinda weird marketing, IMHO. It's been around for a while, and I think it's the author of RPerl's thing. But, I think it's definitely a situation where the projects are developers scratching their own itch, and diverging in not insignificant ways from mainline Perl 5 (and Perl 6 is not really in the picture for either cperl or RPerl). I don't know that it's a bad thing; Ruby and Python both have forks or implementations that are weird and non-mainline and no one considers them detracting from the Ruby or Python community, in general. Though, none of those projects called themselves Python 5, or whatever.
      - rurban 8y ago
        perl 11 came from 5+6=11, which was Ingy's idea. Will (rperl) and I (cperl, parrot) liked it, so we sticked to it. We are three. The idea was to come up with something like pypy performance-wise (i.e. parrot done right without all the destruction done later) and perl6 feature-wise. perl6 is THE picture for cperl, because it has a proper spec for the useful features, to void the usual bike shedding, plaguing p5p since day 10. The picture for RPerl is not perl6 but performance, proper mapping of perl5 code to C++ data and algos, eliminating run-time magic. The other projects are doing their thing also, which is fine and encouraging.
        SwellJoe 8y ago
        Thanks for the clarification. I know Will, as we currently live in the same city, but I haven't followed development of any of the projects mentioned very closely.
- obrajesse 8y ago
  It is not.
- mst 8y ago
  Not at all - and Larry has been working on perl6 for years, so the people behind vanilla perl5 are a different group again. The perl11 people are mostly disgruntled kooks who got kicked out of perl5/perl6 development after yelling at everybody for not instantly believing everything they said. Meanwhile, actual perl5 and rakudo continue to progress.
  - willthechill 8y ago
    This claim by mst is patently false. While it may be true that some people in the Perl community disagree with Reini Urban (AKA rurban, creator of cperl and co-founder of Perl 11), by no means does Reini alone constitute "most" of the Perl 11 team. In fact, Reini is only 1/3 of the co-founding Perl 11 team, which includes Ingy döt Net and myself. At this time, we have a significantly larger number of people involved in various Perl 11 projects, including my own RPerl compiler. SO LET'S BE CLEAR! mst does NOT speak for the Perl community in any official way, and his opinion is (in this case) grossly inaccurate.
  - pawelmurias 8y ago
    Aren't the perl11 projects an umbrella name for a bunch of different projects? A large part of them aren't done by disgruntled kooks. Only rurban seems to have some bad blood with parts of the Perl 6 community after his claims about threads that don't interact with each others where mocked as magical by people who didn't notice what he was trying to sell.
    - rurban 8y ago
      It was niner's project. His threads project was being wrongly attacked, and nobody cared. It was a very strange and calculated attack, when they launched their competing VM. I completely agreed with most of the criticism. But I still think lockless threading would be great to have, as waiting for locks by far outnumbers all CPU disadvantages with the broken parrot calling convention and general problems there. People are still fond of Erlang also, and parrot threading model and implementation is much better than Erlang threads or Go threads and everything else but Pony's. It's no bad blood though. Hype-driven development has it's place, see rust and javascript. Throwing away unique technical advantages for pure marketing reasons to unite the community against someone else didn't go fine with me. It was no vilification as in p5p though. It was just silly.
CJefferson 8y ago
I'm always worried when a system seems to have no drawbacks. The strengths of Perl 5 and Perl 6 and the speed of C? That sounds strictly harder than either writing Perl 6, or the decades of work put into optimising Perl 5. What are the limitations which make this achievable?
- hardwaresofton 8y ago
  It's a little bit ridiculous, but you could actually have this if you transpiled perl to rust :)
  - sdegutis 8y ago
    Could you though? I mean the semantics are so different that the code you generate is probably going to need to be the equivalent of Perl's VM at that point anyway.
    - hardwaresofton 8y ago
      I think you could -- you'd have to just translate all those semantics down to rust as well. I can't think of any perl semantics/sugar that can't be compiled out. Even the famous default variable ($_) could be naively transpiled out with just a variable binding. Also, if I'm understanding the original post right, they want the VM itself to be swappable -- that with the desire to reach C speed makes me think that they want to make it optional all-together.
      - tasty_freeze 8y ago
        Your reasoning is kind of like saying we only need a 6502 and a large bank of ram because, hey, that is turing equivalent, and a modern x86 with the same amount of ram is turing equivalent, so it should be complete. Imagine a perl program which asks the user for input. Based on the user's input, the perl program does "do a.pl" or "do b.pl". Hell, maybe the user's input is actually executable code that is thrown in the mix too. Then the original program does "print $a + $b;". What should the rust transpiler do? Are they floats? Are they ints? Or strings? Do they have values already? Yes, you could create a transpiled version that used hashes to look up symbols, and based on what the hash returned it would execute code to add two (boxed) ints, or floats, or float and int, or throw an error, but then what you've done is rewritten the perl interpreter in rust.
sdegutis 8y ago
The "Pluggable VMs" goal is just a bad idea IMO. The more generic you make an interface, the more you ruin it. Tight integration may make certain things harder, but it allows better control over the pathways for performance optimizations, and keeps the implementation simple which inherently increases maintainability. And in practice, only one of these VMs is going to actually be used by 97% of people, and the other 3% can do the extra legwork themselves in a maintained fork if it's really that important/beneficial to their niche.
- coliveira 8y ago
  Smalltalk has been able to achieve the goal of pluggable VMs. If you check the Squeak project, you can choose VMs according to your desired performance/stability.
- SwellJoe 8y ago
  I think the Perl 6 developers figured that out a few years ago, and ended up implementing MoarVM, instead of using or building a more generic VM. One can implement other languages in MoarVM, but it's been built for Perl 6, so it fits Perl 6 best. Maybe it isn't a super "tight" integration, but it's much tighter than something like Perl 6 on the JVM could ever be.
  - Ultimatt 8y ago
    It's more very tight semantic alignment across the entire stack of abstractions. Which is actually the important part, things like a "string" being the same conceptual object from top to bottom.
- laveur 8y ago
  Personally when I saw JVM as a VM for this I lost interest. JVM is not how you make something as fast as C/C++. You want to make it that fast you should be running it directly on a C/C++ code base. Thats pretty much how Python, PHP, and other scripting languages work.
  - deleted 8y ago
    [deleted]
i_phish_cats 8y ago
Never heard of webperl... I am consistently amazed every time I hear about an ultra-complex C/C++ project being made runnable in a browser with emscripten and wasm.
snazz 8y ago
The third goal in particular looks like a bit of a moonshot... they offer little technical information for how they’d actually achieve it.
- sdegutis 8y ago
  What, "Runtime Performance Of C/C++ Or Faster" ? Obviously they can't rival the speed of "C/C++" so they're probably going to go with "Faster", which isn't a real language so it's going to be easy to beat.
  - koolba 8y ago
    I’m not familiar with the details but I’d wager they’re referring to JIT compilation which can exceed precompiled native code as it can (in theory) account for actual usage patterns.
    - jerf 8y ago
      That was a fun theory 15-20 years ago. We've now got piles of evidence it doesn't work that way. JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. Claims to the contrary at this point will require concrete demonstration. Starting from the union of Perl 5 and Perl 6 is just about the worst starting point for that goal I can imagine. (Not necessarily because "Perl sucks", but because any such solution to that problem is probably going to require writing the language with that goal from day 1, not taking existing languages as a given. Or, like LuaJIT, cutting things that don't fit. And between Perl 5 and Perl 6, there are sooooo many "things"....)
      - hyperpape 8y ago
        I'm with you about the overall point that Perl5/6 are not going to get C/C++ speed. However, on the specific point, why do you think the JIT forces high memory usage? In the case of Java, my perception is that it's the pervasive use of boxed types everywhere and a standard library that's past its sell-by-date that drives bloated memory usage. Maybe my sense of things is a little skewed by my work: I work on server processes that use gigs of memory. There, the resources for the JVM/JIT itself usually use vastly less memory than the java objects contained in the heap (probably 10x, and this is for a monolith with thousands of classes).
make3 8y ago
any reason to script with this over python/pypy/node/julia/R/ruby ?
- SwellJoe 8y ago
  If you like Perl better than python/pypy/node/julia/R/ruby, perhaps would be a reason.
- dsr_ 8y ago
  Such a reason would probably start with "I like Perl and have a lot of stuff written in Perl that I would like to run faster."
nickysielicki 8y ago
Whenever I need to write a tiny script that tests the bounds of what is easily done with just awk and Bourne shell, the tool that I next reach for nowadays is Python. A few years back it was Perl5. I'm not exactly sure why I started reaching for Python instead. It's so much easier with perl to do things like backticks to call some utility, or to use system() and easily deal with its stdout and stdin, and I never have to do a Google search to figure out how to use a regular expression to process the output (whereas I almost always need to bring up the doc page for Python's re). I think what it ultimately comes down to is tooling and the availability of good libraries. I call "python3 -m venv venv", do an I'm Feeling Lucky google search for "XXX library inurl:pypi", and the sky is the limit with how easily I can make a script that does something relatively complicated. Comparing this with perl5 isn't even fair. You might find a cpan module that does what you want, and it might still be maintained, and you maybe can be bothered to figure out cpanminus, but anyone who has used perl in the last 5 years will agree, it's nowhere near as easy as it is with python. Something that makes me optimistic about newer languages is that tooling is improving a great deal. It also makes me somewhat pessimistic about newer languages, though, if tooling is the primary aspect of a language that makes it popular. I've never seriously tried perl6 but I've seen enough of the language features to know that I was really excited about it, at least at one point. I hope that some derivative of perl can rise from the ashes, because I'm too stupid to write actual lisp programs, but perl allows me to emulate what I imagine lisp programmers must feel.
- crusso 8y ago
  I'm exactly the same way about Perl vs Python. After years of using Perl 5 and due to what I also think is the simplicity of the language, I know I could do most small tasks more easily in Perl. But Python feels more like "the future". When I need to write a script-like solution, I reach for Python because I need to practice with it and because I figure that the modules will be better maintained. You're right, though. I always need to look up simple things like system calls and often have to remind myself of exactly how the re module works. But I slog through it. Don't get me started on the Python 2 -> 3 glacial migration, though. That almost makes me want to switch back to writing my scripts in Ruby.
- fouc 8y ago
btilly 8y ago
My perspective is that I'm glad that they are entertaining themselves, but they aren't going to succeed. It is easy to run a subset of Perl 5 faster than Perl 5. But when you add in all of the features, beating Perl 5 on speed becomes hard. It always was the dream to integrate Perl 5 and Perl 6. But cleaning up the internals of Perl 5 until general people could work on it would be a several month project that only a handful of people in the world have the expertise to do. And even if you did that, how do you reconcile Perl 5 reference counting with Perl 6 true garbage collection? The two do not cooperate very well, and a lot more Perl 5 code than you would think relies on things like reliable timing of destruction. On this issue the community has generally been divided into people who think that this won't be doable, and people who think that some day a smart solution will be produced. To date, no smart solution has emerged. Also Perl 6 was a wonderful dream to entertain people, but its real world adoption is..limited. Like it or not, Perl 6 is effectively here and is named Python 3. No, it doesn't look like the Perl 6 people thought it would, but sometimes that is life.
- totalperspectiv 8y ago
  I'm pretty sure cperl is doing exactly that though: http://perl11.org/cperl/STATUS.html http://perl11.org/cperl/STATUS.html
  - mst 8y ago
    cperl is a trainwreck that only exists because the author forked perl5 because he was removed from the maintainance list because he couldn't stop insulting people. Don't bother pretending it'll ever be a viable project - periodically he sends patches trying to force perl5 modules to change their code because his type checking code doesn't work, then follows it up with a volley of insults when the maintainers go "huh?"
    - rurban 8y ago
      cperl is not a trainwreck, only perl5 is. cperl exists because the perl5 maintainers are totally incapable of doing their job, and risking the jobs of thousands of fellow perl5 developers. Most of them already switched to something else in the last years. cperl on the other hand implemented most missing features from the last 15 years in 2-3 years, fixed the worst mistakes, and is 10-30x faster and better developed than perl5. perl5 is dead, it is not going anywhere. You had your chance, but you failed. Now the only thing you have left is doing the culture war thing, throwing around CoC accusations. Having no faith, insulting the devs. Typechecking errors? There are occasional errors because of adding more strictness and warnings from perl6 (strict names, hashpairs, ...) and some internal test and bignum modules are typed for 2x faster performance and to catch typical errors at compile-time. There's an API, and the types reflect that. The problem is that the implementations and the users don't care about the API at all, and neither about typechecks catching these errors. There are no volleys of insults to any maintainers at all. You still don't get the difference between necessary technical and professional criticism and personal attacks. In fact p5p is throwing around personal attacks and insults all the time. E.g. you are one of the main examples of immature racism in your very public YAPC talks, accusing all Germans to be Assholes (in allcaps) for years. Thought about that once? Why do you think you were not accepted as pumpkin and again the technical most incapable person was elected? p5p had their chance to do anything with the language in the last 15 years, they had a proper design and spec and sister languages doing the same. They did nothing, all attempts failed and they blocked all improvements from outside. There's no proper management, no process. Either you are committer, then you can do what you want, or not, then you may not do anything. Well, in fact there are only 4-6 bad apples at the top. The rest is doing good, but silent. But the TPM board is protecting the bad apples, promoting the most incompetent, they are even collecting the worst of them. Only if you managed to completely fail a huge project you are the perfect member for the board. Only the most unsuccessful culture warriors are lining up there. perl5 is not recommended to be used in anything serious anymore. There are dozens of serious bugs and design errors not fixed, and errors and destruction being added every new release. I have no time to file all the CVE's, look at the cdelta's. 90% of the decisions are wrong. The new code of conduct is being misused to silence valid technical criticism, because perl5 is now a religion, and you may not distrust the leaders. This was literally the explanation.
deleted 8y ago
[deleted]
nopacience 8y ago
Perl5 is a great language. For internet and system related tasks it is great! It was created long time ago and evolved over the years. One thing is true, it had a lot of advantage over other languages for a lot of years. However, now in 2018, other languages have also evolved and gained a lot of traction. One example is javascript/node which is now being used more and more. For a lot of time, a lot of frontend focused developers didnt really want to try backend development... specially because backend development was usually done in another language which was not javascript. So some never really attempted to do backend development. However when node was released, that opened a lot of new opportunities for the front end developers. There are a lot of languages these days and many of them are capable enough to do many types of projects. The important thing is, some languages have a bigger concentration of more capable engineers. One of these languages is perl. The perl programmers are excelent. They have real close experience with the kernel and systems and usually have great experience in complex backend tasks. Many are not as great with front end development. Some are. Some projects can be done and deployed by 1 single perl developer. The same project if done in java for example might require more than 1 java developer. The microsoft language creates a bubble and their developers sometimes dont know universal technical terms, they only know the microsoftish terms. Ie. they might not know what a "web server" is, but they know what "IIS" is. They might now know what a "hash" is, but they know what a "dictionary" is. Perl developers use universal terms. Amazingly, javascript, especially ES6 is looking more and more like perl. Those that know both will agree sometimes it reminds of perl. There are many projects people dont know about that use perl behind the scenes. But of course there are not as many perl programmers as there are in other languages and thats one reason you dont hear much about these projects. Companies embrace more and more the modern perl development. Java, microsoft, node, python, ruby, etc are more popular of course. Specially because a lot of banks use java and they push java via universities. In the past I have seen labs with SUN machines on universities that teach Java. Microsoft also gives students free software licenses via universities. Thats another reason Microsoft and Java are very popular.
- deleted 8y ago
  [deleted]
- malkia 8y ago
User23 8y ago
For me Perl is (awk|sh)++. It's a great example of the Unix philosphy, which is, among other things, evolution based on practical experience rather than top down theoretical design.
- ryl00 8y ago
  I blame my rudimentary knowledge of sh on perl... As soon as the going gets tough when I'm writing sh, I immediately bail into perl. :)
- mst 8y ago
  I use perl5 like that, but honestly I sometimes script in Tcl because I'm too used to applications perl. For me perl5 is lexical scoping, closures, map/grep/reduce, and an OO model that steals the best of python (ignoring ruby's crippled OO which involved failing to steal from smalltalk properly) and then adds a first class attribute system so you can declare attributes once and not need to re-type the names to get a working constructor. ES6 isn't bad, mind - with 'use strict' and 'let' it's close to a usable perl5 apart from the fact that its errors are runtime instead of compile time (typescript helps there of course) and the OO is still relatively limited, but I have some ideas using decorators that should bring the best of perl5 OO to javascript since I've been unable to convince anybody else to steal our features already
  - User23 8y ago
    I like to Joke that Perl is the ugliest most usable lisp ever. The way it lets you play with the symbol table for all its various namespaces is extremely powerful. It also exposes dynamic and lexical scopes in a way reminiscent of Common Lisp.
    - mst 8y ago
      Co-signed. People often complain that I write lisp in everything. I mostly consider this a feature.
tronbabylove 8y ago
WebPerl looks cool. I wrote an interactive blog post [1] that guides the reader through an exercise in scraping log files using a series of Perl one-liners. I ended up delegating execution to a sandboxed Lambda function on the backend, but running it client-side would have been a lot simpler. [1] https://andrewstahlman.com/posts/ParetoPerl.html https://andrewstahlman.com/posts/ParetoPerl.html
- mst 8y ago
  WebPerl is fascinating, I'm hoping at some point the author talks to the rest of the perl community so we can compare notes.
  - pawelmurias 8y ago
    If we want to be extra crazy it should be possible to combine rakudo.js and WebPerl to have Inline::Perl5 working in the browser.
  - willthechill 8y ago
    I've already spoken with Hauke at great length on #perl11, and he has formally joined the Perl 11 development cooperative, as evidenced by the recent addition of WebPerl to the Perl11.org website.
bemeurer 8y ago
That is a _lot_ of yak shaving to be done
em-bee 8y ago
perl 5 and perl 6 unite. news at 11!
tokyodude 8y ago
I don't understand the love for Perl. I wrote maybe 10k-20k lines of Perl between maybe 1996 and 2003 and at the time I was happy it worked. But ... more than any other language I've used it seems the most hacked and confusing. Global variables abound. Crazy cryptic syntax. Ridiculous scoping rules with hacked on workarounds. I really don't get the continued love. Sometime around 2003 IIRC I got introduced to Python and never looked back. When someone hands me a perl script I don't look forward to trying to get it to work. Speaking of which tho even Python now makes me crazy. NPM might suck for various reasons but at least all deps are installed local to each project. I'm sure there are secret incantations for doing the same in perl and python but by default most stuff I download requires global libraries to be installed. If there is one thing I love about npm is that it defaults to project local installs and I have yet to run into a project that requires a global install
- Benjamin_Dobell 8y ago
  > I'm sure there are secret incantations for doing the same in perl and python but by default most stuff I download requires global libraries to be installed. I'm not a Python developer, just dabble, but I've had decent success with Pipenv[1] and Pipfiles. [1] https://github.com/pypa/pipenv https://github.com/pypa/pipenv
- nopacience 8y ago
  Best method to achieve that is one of 2 options: perlbrew local::lib Or, specify it when executing the module, ie: bash$ perl -I../project_modules/Module1/lib -I../project_modules/Module2/lib your_project.pl Or, specify it at the top of your_project.pl ie: use lib '../project_modules/Module1/lib'; use lib '../project_modules/Module2/lib'; Or, set enviroment var export PERL5LIB=/home/project_modules/ ; perl your_project.pl Or, make a BEGIN statement on top of your main project, ie: BEGIN { push @INC, glob "/home/project_modules/*/lib"; } You dont need to use anything global, and its better you dont. Never execute anything as root. You are able to execute local modules just like node, rvm, etc. Its all the same. Some linux installs come with perl/python installed. It is used by the system and is refered to as "system perl" or "system python" or "system ruby", etc.. and it is not recommended to make upgrade on those "system XXX". Only your system should upgrade the libraries it uses. That is why you should always use a local perl/python/ruby install. If you didnt like it, its good you moved on.
primer42 8y ago
why...... just let old languages die. We've taken lessons from them, and grown. I know there is of are a good amount of financial systems written in COBOL, but that's because no one has had the guts to rewrite them, not because COBOL is some amazing perfect language. And there are a plethora of other important, reliable systems that are still in perl because no one has had the guts to rewrite them. But I would guess that there are just as many that have been rewritten to python and ruby. And many more that have been written for the first time in those languages. And in the next few years we're going to be in the same place with those sacred cow scripts written in python and ruby. I'm not trying to say that code is wrong. But it isn't productive to claim that we can slap a new version number on a library and claim it's going to satisfy everyone's hopes and dreams. At some point, we need to let our cows die, even if they're sacred.
- snapdangle 8y ago
  Anyone claiming that Perl 6 is "slapping a new version number on a library" has little credibility with regards to programming language design and history. "Let the past die" might be a great line for Ben Skywalker in a Star Wars movie, but in practical terms you are screeding against a people (Perl programmers) continuing their to develop their culture (Perl). What on earth could this be doing that affects you negatively?
- mst 8y ago
  perl5 has more explicit and reliable scoping and more flexible and powerful OO than python or ruby, and has had for a decade now. If other languages would actually take the lessons, I'd've switched. Recent javascripts have 'use strict' and 'let' (perl5's 'my') but the errors are at runtime, not compile time, so in terms of maximising productivity perl5 is still my preference - though ES6 is almost an acceptable perl5, and I'm working on some libraries to bridge the remaining feature gaps since apparently nobody else actually wants working OO and proper DRY.
- Wwhite 8y ago
  s/guts to rewrite them/staff experienced in both languages, with access to the original requirements, and knowledge of said system, in addition to full support from management to swap out working code with fresh, potentially buggy replacements, instead of devoting time to other projects which may actually be profitable/g
picduniya 8y ago
When we think about positive things, how great the world is and how amazing our life is, we see more proof of it in the real world. What might be considered normal will be considered great in this point of view. The same way when we think about how bad everything is and how life is going against us, we see normal events as being negative and small problems as being gigantic.
zebraman 8y ago
Not sure if it is me, but for a long time I have kept away from anything perl of moderate complexity. Package management used to be atrocious - it would be slow, pull a ton of modules, compile them with the C toolchain, break for missing dependencies and leave you wondering where the log was. Maybe it's better now. But I wonder why on earth interpreted languages need mandatory C bindings.
- deleted 8y ago
  [deleted]
deleted 8y ago
[deleted]
xarope 8y ago
I used to/still love perl, as it taught me a lot about regexp and hashmaps, but I have to admit, going back to a perl script written perhaps several years ago, and I struggle to figure out why I wrote it, the way I did. Contrast with python (v3), my current preferred prototyping/scripting choice, and it's still pretty clear about logic builds and data structures. I'm now trying to decide if I should jump on the golang ship, but the library ecosystem compared to python seems rather spare at the moment.
- sacado2 8y ago
  You might like go, indeed. At first, when I tried go (just after 1.0 went out), I wrote a small program with it and thought "meh". Yeah, the program was doing its job, but the language was pretty boring. A year later, I decided to improve that program, and that's when I really fell in love with the language. I could understand everything I had written, even though I hadn't read any go code for a year, and update it without any hassle. Moreover, my beginner program was rather idiomatic in the first place. Pretty cool. But, yeah, python's ecosystem is way bigger, so I tend to use both, depending on the situation.
wscott 8y ago
Here is my unrelated to the article perl memory... I fell in love with perl at school because it seems easier that sh/awk/sed/etc... After I got a job I still used perl for everything. Perl5 came along and made a bunch of really needed improvements [1] My problem was that at work they used rs6000 machines running AIX for everything and perl5 didn't work on AIX. So I couldn't use the latest toys. So I took time out and fixed dynamic linking so perl5 worked correctly on AIX. http://web.mit.edu/darwin/src/modules/perl/perl/ext/DynaLoader/dl_aix.xs http://web.mit.edu/darwin/src/modules/perl/perl/ext/DynaLoad... Then later I got an email from Redhat offering me shares of stock when they went public. This was because of my perl contribution. That was clearly some shady scheme so I declared that email spam and threw it away. 1) But yes perl5 is quite a bit more complicated than perl4 and that bothered a lot of people.
collyw 8y ago
Wasn't one of the original goals of Perl 6 to be able to run Perl 5 code?
- lizmat 8y ago
  Yes, and in a way it still is. The Inline::Perl5 (https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE) module allows one to embed a Perl 5 interpreter in Perl 6 and transparently call Perl 5 functionality as if it were written in Perl 6: this basically makes 99.9% of CPAN available to programs written in Perl 6. Many Perl 5 modules from CPAN have gotten a native Perl 6 equivalent as well: https://modules.perl6.org/t/CPAN5 https://modules.perl6.org/t/CPAN5 . Earlier this year I tried to launch an idea: https://www.perl.com/article/an-open-letter-to-the-perl-community/ https://www.perl.com/article/an-open-letter-to-the-perl-comm... . But that met with much hostility https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter_to_the_perl_community/ https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter... , so I'm not really actively pursuing that.
willthechill 8y ago
Hello everyone, I am Will 'the Chill' Braswell, creator of the RPerl optimizing compiler and co-creator of Perl 11, along with Reini Urban and Ingy döt Net. I'd be happy to answer any serious questions about the RPerl technical designs or the Perl 11 project goals. Thanks for your lively interest and continuing support of the Perl community. Obviously, the rumors of Perl's death have been greatly exaggerated! :-)

I had no idea any of these existed. And it looks like RPerl recently hit its 4.0 release... kind of looks like Nim.

So is this by the same people behind 'vanilla' perl (Larry etc)? I am assuming not but could not immediately find the information on the (mobile) website.

totalperspectiv 8y ago
I don't think so. It seems to be those that are not the current perl5 maintainers (perl 5 porters), or the perl6 devs. But I could be wrong.
- karavelov 8y ago
  Yes, I think it's mainly one dev trying to make it best fit their own use case.
  - totalperspectiv 8y ago
    Well, each of the projects on that page have separate, but slightly overlapping contributors based on github. I was amazed that: A) Many of the projects on that page are alive and have commits within the last few days. B) They actually seem to be doing what they set out to do. Especially cperl. C) The existence of Rperl, which looks likey pypy for perl.
  - SwellJoe 8y ago
    The two most usable examples (aside from MoarVM, which isn't really connected in any clear way, as it is the current mainline VM implementation for Perl 6), cperl and RPerl, are by two different developers, with different but occasionally overlapping goals. The author of cperl posts on HN frequently, so it seems likely he'd have interesting thoughts on this. The concept of calling a bunch of marginally related and only partly compatible projects "Perl 11" is kinda weird marketing, IMHO. It's been around for a while, and I think it's the author of RPerl's thing. But, I think it's definitely a situation where the projects are developers scratching their own itch, and diverging in not insignificant ways from mainline Perl 5 (and Perl 6 is not really in the picture for either cperl or RPerl). I don't know that it's a bad thing; Ruby and Python both have forks or implementations that are weird and non-mainline and no one considers them detracting from the Ruby or Python community, in general. Though, none of those projects called themselves Python 5, or whatever.
    - rurban 8y ago
      perl 11 came from 5+6=11, which was Ingy's idea. Will (rperl) and I (cperl, parrot) liked it, so we sticked to it. We are three. The idea was to come up with something like pypy performance-wise (i.e. parrot done right without all the destruction done later) and perl6 feature-wise. perl6 is THE picture for cperl, because it has a proper spec for the useful features, to void the usual bike shedding, plaguing p5p since day 10. The picture for RPerl is not perl6 but performance, proper mapping of perl5 code to C++ data and algos, eliminating run-time magic. The other projects are doing their thing also, which is fine and encouraging.
      - SwellJoe 8y ago
        Thanks for the clarification. I know Will, as we currently live in the same city, but I haven't followed development of any of the projects mentioned very closely.
obrajesse 8y ago
It is not.
mst 8y ago
Not at all - and Larry has been working on perl6 for years, so the people behind vanilla perl5 are a different group again. The perl11 people are mostly disgruntled kooks who got kicked out of perl5/perl6 development after yelling at everybody for not instantly believing everything they said. Meanwhile, actual perl5 and rakudo continue to progress.
- willthechill 8y ago
  This claim by mst is patently false. While it may be true that some people in the Perl community disagree with Reini Urban (AKA rurban, creator of cperl and co-founder of Perl 11), by no means does Reini alone constitute "most" of the Perl 11 team. In fact, Reini is only 1/3 of the co-founding Perl 11 team, which includes Ingy döt Net and myself. At this time, we have a significantly larger number of people involved in various Perl 11 projects, including my own RPerl compiler. SO LET'S BE CLEAR! mst does NOT speak for the Perl community in any official way, and his opinion is (in this case) grossly inaccurate.
- pawelmurias 8y ago
  Aren't the perl11 projects an umbrella name for a bunch of different projects? A large part of them aren't done by disgruntled kooks. Only rurban seems to have some bad blood with parts of the Perl 6 community after his claims about threads that don't interact with each others where mocked as magical by people who didn't notice what he was trying to sell.
  - rurban 8y ago
    It was niner's project. His threads project was being wrongly attacked, and nobody cared. It was a very strange and calculated attack, when they launched their competing VM. I completely agreed with most of the criticism. But I still think lockless threading would be great to have, as waiting for locks by far outnumbers all CPU disadvantages with the broken parrot calling convention and general problems there. People are still fond of Erlang also, and parrot threading model and implementation is much better than Erlang threads or Go threads and everything else but Pony's. It's no bad blood though. Hype-driven development has it's place, see rust and javascript. Throwing away unique technical advantages for pure marketing reasons to unite the community against someone else didn't go fine with me. It was no vilification as in p5p though. It was just silly.

CJefferson 8y ago

I'm always worried when a system seems to have no drawbacks. The strengths of Perl 5 and Perl 6 and the speed of C? That sounds strictly harder than either writing Perl 6, or the decades of work put into optimising Perl 5. What are the limitations which make this achievable?

hardwaresofton 8y ago
It's a little bit ridiculous, but you could actually have this if you transpiled perl to rust :)
- sdegutis 8y ago
  Could you though? I mean the semantics are so different that the code you generate is probably going to need to be the equivalent of Perl's VM at that point anyway.
  - hardwaresofton 8y ago
    I think you could -- you'd have to just translate all those semantics down to rust as well. I can't think of any perl semantics/sugar that can't be compiled out. Even the famous default variable ($_) could be naively transpiled out with just a variable binding. Also, if I'm understanding the original post right, they want the VM itself to be swappable -- that with the desire to reach C speed makes me think that they want to make it optional all-together.
    - tasty_freeze 8y ago
      Your reasoning is kind of like saying we only need a 6502 and a large bank of ram because, hey, that is turing equivalent, and a modern x86 with the same amount of ram is turing equivalent, so it should be complete. Imagine a perl program which asks the user for input. Based on the user's input, the perl program does "do a.pl" or "do b.pl". Hell, maybe the user's input is actually executable code that is thrown in the mix too. Then the original program does "print $a + $b;". What should the rust transpiler do? Are they floats? Are they ints? Or strings? Do they have values already? Yes, you could create a transpiled version that used hashes to look up symbols, and based on what the hash returned it would execute code to add two (boxed) ints, or floats, or float and int, or throw an error, but then what you've done is rewritten the perl interpreter in rust.

sdegutis 8y ago

The "Pluggable VMs" goal is just a bad idea IMO. The more generic you make an interface, the more you ruin it. Tight integration may make certain things harder, but it allows better control over the pathways for performance optimizations, and keeps the implementation simple which inherently increases maintainability. And in practice, only one of these VMs is going to actually be used by 97% of people, and the other 3% can do the extra legwork themselves in a maintained fork if it's really that important/beneficial to their niche.

coliveira 8y ago
Smalltalk has been able to achieve the goal of pluggable VMs. If you check the Squeak project, you can choose VMs according to your desired performance/stability.
SwellJoe 8y ago
I think the Perl 6 developers figured that out a few years ago, and ended up implementing MoarVM, instead of using or building a more generic VM. One can implement other languages in MoarVM, but it's been built for Perl 6, so it fits Perl 6 best. Maybe it isn't a super "tight" integration, but it's much tighter than something like Perl 6 on the JVM could ever be.
- Ultimatt 8y ago
  It's more very tight semantic alignment across the entire stack of abstractions. Which is actually the important part, things like a "string" being the same conceptual object from top to bottom.
laveur 8y ago
Personally when I saw JVM as a VM for this I lost interest. JVM is not how you make something as fast as C/C++. You want to make it that fast you should be running it directly on a C/C++ code base. Thats pretty much how Python, PHP, and other scripting languages work.
- deleted 8y ago
  [deleted]

i_phish_cats 8y ago

Never heard of webperl... I am consistently amazed every time I hear about an ultra-complex C/C++ project being made runnable in a browser with emscripten and wasm.

snazz 8y ago

The third goal in particular looks like a bit of a moonshot... they offer little technical information for how they’d actually achieve it.

sdegutis 8y ago
What, "Runtime Performance Of C/C++ Or Faster" ? Obviously they can't rival the speed of "C/C++" so they're probably going to go with "Faster", which isn't a real language so it's going to be easy to beat.
- koolba 8y ago
  I’m not familiar with the details but I’d wager they’re referring to JIT compilation which can exceed precompiled native code as it can (in theory) account for actual usage patterns.
  - jerf 8y ago
    That was a fun theory 15-20 years ago. We've now got piles of evidence it doesn't work that way. JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. Claims to the contrary at this point will require concrete demonstration. Starting from the union of Perl 5 and Perl 6 is just about the worst starting point for that goal I can imagine. (Not necessarily because "Perl sucks", but because any such solution to that problem is probably going to require writing the language with that goal from day 1, not taking existing languages as a given. Or, like LuaJIT, cutting things that don't fit. And between Perl 5 and Perl 6, there are sooooo many "things"....)
    - hyperpape 8y ago
      I'm with you about the overall point that Perl5/6 are not going to get C/C++ speed. However, on the specific point, why do you think the JIT forces high memory usage? In the case of Java, my perception is that it's the pervasive use of boxed types everywhere and a standard library that's past its sell-by-date that drives bloated memory usage. Maybe my sense of things is a little skewed by my work: I work on server processes that use gigs of memory. There, the resources for the JVM/JIT itself usually use vastly less memory than the java objects contained in the heap (probably 10x, and this is for a monolith with thousands of classes).

make3 8y ago

any reason to script with this over python/pypy/node/julia/R/ruby ?

SwellJoe 8y ago
If you like Perl better than python/pypy/node/julia/R/ruby, perhaps would be a reason.
dsr_ 8y ago
Such a reason would probably start with "I like Perl and have a lot of stuff written in Perl that I would like to run faster."

nickysielicki 8y ago

Whenever I need to write a tiny script that tests the bounds of what is easily done with just awk and Bourne shell, the tool that I next reach for nowadays is Python. A few years back it was Perl5. I'm not exactly sure why I started reaching for Python instead. It's so much easier with perl to do things like backticks to call some utility, or to use system() and easily deal with its stdout and stdin, and I never have to do a Google search to figure out how to use a regular expression to process the output (whereas I almost always need to bring up the doc page for Python's re). I think what it ultimately comes down to is tooling and the availability of good libraries. I call "python3 -m venv venv", do an I'm Feeling Lucky google search for "XXX library inurl:pypi", and the sky is the limit with how easily I can make a script that does something relatively complicated. Comparing this with perl5 isn't even fair. You might find a cpan module that does what you want, and it might still be maintained, and you maybe can be bothered to figure out cpanminus, but anyone who has used perl in the last 5 years will agree, it's nowhere near as easy as it is with python. Something that makes me optimistic about newer languages is that tooling is improving a great deal. It also makes me somewhat pessimistic about newer languages, though, if tooling is the primary aspect of a language that makes it popular. I've never seriously tried perl6 but I've seen enough of the language features to know that I was really excited about it, at least at one point. I hope that some derivative of perl can rise from the ashes, because I'm too stupid to write actual lisp programs, but perl allows me to emulate what I imagine lisp programmers must feel.

crusso 8y ago
I'm exactly the same way about Perl vs Python. After years of using Perl 5 and due to what I also think is the simplicity of the language, I know I could do most small tasks more easily in Perl. But Python feels more like "the future". When I need to write a script-like solution, I reach for Python because I need to practice with it and because I figure that the modules will be better maintained. You're right, though. I always need to look up simple things like system calls and often have to remind myself of exactly how the re module works. But I slog through it. Don't get me started on the Python 2 -> 3 glacial migration, though. That almost makes me want to switch back to writing my scripts in Ruby.
fouc 8y ago

btilly 8y ago

My perspective is that I'm glad that they are entertaining themselves, but they aren't going to succeed. It is easy to run a subset of Perl 5 faster than Perl 5. But when you add in all of the features, beating Perl 5 on speed becomes hard. It always was the dream to integrate Perl 5 and Perl 6. But cleaning up the internals of Perl 5 until general people could work on it would be a several month project that only a handful of people in the world have the expertise to do. And even if you did that, how do you reconcile Perl 5 reference counting with Perl 6 true garbage collection? The two do not cooperate very well, and a lot more Perl 5 code than you would think relies on things like reliable timing of destruction. On this issue the community has generally been divided into people who think that this won't be doable, and people who think that some day a smart solution will be produced. To date, no smart solution has emerged. Also Perl 6 was a wonderful dream to entertain people, but its real world adoption is..limited. Like it or not, Perl 6 is effectively here and is named Python 3. No, it doesn't look like the Perl 6 people thought it would, but sometimes that is life.

totalperspectiv 8y ago
I'm pretty sure cperl is doing exactly that though: http://perl11.org/cperl/STATUS.html http://perl11.org/cperl/STATUS.html
- mst 8y ago
  cperl is a trainwreck that only exists because the author forked perl5 because he was removed from the maintainance list because he couldn't stop insulting people. Don't bother pretending it'll ever be a viable project - periodically he sends patches trying to force perl5 modules to change their code because his type checking code doesn't work, then follows it up with a volley of insults when the maintainers go "huh?"
  - rurban 8y ago
    cperl is not a trainwreck, only perl5 is. cperl exists because the perl5 maintainers are totally incapable of doing their job, and risking the jobs of thousands of fellow perl5 developers. Most of them already switched to something else in the last years. cperl on the other hand implemented most missing features from the last 15 years in 2-3 years, fixed the worst mistakes, and is 10-30x faster and better developed than perl5. perl5 is dead, it is not going anywhere. You had your chance, but you failed. Now the only thing you have left is doing the culture war thing, throwing around CoC accusations. Having no faith, insulting the devs. Typechecking errors? There are occasional errors because of adding more strictness and warnings from perl6 (strict names, hashpairs, ...) and some internal test and bignum modules are typed for 2x faster performance and to catch typical errors at compile-time. There's an API, and the types reflect that. The problem is that the implementations and the users don't care about the API at all, and neither about typechecks catching these errors. There are no volleys of insults to any maintainers at all. You still don't get the difference between necessary technical and professional criticism and personal attacks. In fact p5p is throwing around personal attacks and insults all the time. E.g. you are one of the main examples of immature racism in your very public YAPC talks, accusing all Germans to be Assholes (in allcaps) for years. Thought about that once? Why do you think you were not accepted as pumpkin and again the technical most incapable person was elected? p5p had their chance to do anything with the language in the last 15 years, they had a proper design and spec and sister languages doing the same. They did nothing, all attempts failed and they blocked all improvements from outside. There's no proper management, no process. Either you are committer, then you can do what you want, or not, then you may not do anything. Well, in fact there are only 4-6 bad apples at the top. The rest is doing good, but silent. But the TPM board is protecting the bad apples, promoting the most incompetent, they are even collecting the worst of them. Only if you managed to completely fail a huge project you are the perfect member for the board. Only the most unsuccessful culture warriors are lining up there. perl5 is not recommended to be used in anything serious anymore. There are dozens of serious bugs and design errors not fixed, and errors and destruction being added every new release. I have no time to file all the CVE's, look at the cdelta's. 90% of the decisions are wrong. The new code of conduct is being misused to silence valid technical criticism, because perl5 is now a religion, and you may not distrust the leaders. This was literally the explanation.

deleted 8y ago

[deleted]

nopacience 8y ago

Perl5 is a great language. For internet and system related tasks it is great! It was created long time ago and evolved over the years. One thing is true, it had a lot of advantage over other languages for a lot of years. However, now in 2018, other languages have also evolved and gained a lot of traction. One example is javascript/node which is now being used more and more. For a lot of time, a lot of frontend focused developers didnt really want to try backend development... specially because backend development was usually done in another language which was not javascript. So some never really attempted to do backend development. However when node was released, that opened a lot of new opportunities for the front end developers. There are a lot of languages these days and many of them are capable enough to do many types of projects. The important thing is, some languages have a bigger concentration of more capable engineers. One of these languages is perl. The perl programmers are excelent. They have real close experience with the kernel and systems and usually have great experience in complex backend tasks. Many are not as great with front end development. Some are. Some projects can be done and deployed by 1 single perl developer. The same project if done in java for example might require more than 1 java developer. The microsoft language creates a bubble and their developers sometimes dont know universal technical terms, they only know the microsoftish terms. Ie. they might not know what a "web server" is, but they know what "IIS" is. They might now know what a "hash" is, but they know what a "dictionary" is. Perl developers use universal terms. Amazingly, javascript, especially ES6 is looking more and more like perl. Those that know both will agree sometimes it reminds of perl. There are many projects people dont know about that use perl behind the scenes. But of course there are not as many perl programmers as there are in other languages and thats one reason you dont hear much about these projects. Companies embrace more and more the modern perl development. Java, microsoft, node, python, ruby, etc are more popular of course. Specially because a lot of banks use java and they push java via universities. In the past I have seen labs with SUN machines on universities that teach Java. Microsoft also gives students free software licenses via universities. Thats another reason Microsoft and Java are very popular.

deleted 8y ago
[deleted]
malkia 8y ago

User23 8y ago

For me Perl is (awk|sh)++. It's a great example of the Unix philosphy, which is, among other things, evolution based on practical experience rather than top down theoretical design.

ryl00 8y ago
I blame my rudimentary knowledge of sh on perl... As soon as the going gets tough when I'm writing sh, I immediately bail into perl. :)
mst 8y ago
I use perl5 like that, but honestly I sometimes script in Tcl because I'm too used to applications perl. For me perl5 is lexical scoping, closures, map/grep/reduce, and an OO model that steals the best of python (ignoring ruby's crippled OO which involved failing to steal from smalltalk properly) and then adds a first class attribute system so you can declare attributes once and not need to re-type the names to get a working constructor. ES6 isn't bad, mind - with 'use strict' and 'let' it's close to a usable perl5 apart from the fact that its errors are runtime instead of compile time (typescript helps there of course) and the OO is still relatively limited, but I have some ideas using decorators that should bring the best of perl5 OO to javascript since I've been unable to convince anybody else to steal our features already
- User23 8y ago
  I like to Joke that Perl is the ugliest most usable lisp ever. The way it lets you play with the symbol table for all its various namespaces is extremely powerful. It also exposes dynamic and lexical scopes in a way reminiscent of Common Lisp.
  - mst 8y ago
    Co-signed. People often complain that I write lisp in everything. I mostly consider this a feature.

tronbabylove 8y ago

WebPerl looks cool. I wrote an interactive blog post [1] that guides the reader through an exercise in scraping log files using a series of Perl one-liners. I ended up delegating execution to a sandboxed Lambda function on the backend, but running it client-side would have been a lot simpler. [1] https://andrewstahlman.com/posts/ParetoPerl.html https://andrewstahlman.com/posts/ParetoPerl.html

mst 8y ago
WebPerl is fascinating, I'm hoping at some point the author talks to the rest of the perl community so we can compare notes.
- pawelmurias 8y ago
  If we want to be extra crazy it should be possible to combine rakudo.js and WebPerl to have Inline::Perl5 working in the browser.
- willthechill 8y ago
  I've already spoken with Hauke at great length on #perl11, and he has formally joined the Perl 11 development cooperative, as evidenced by the recent addition of WebPerl to the Perl11.org website.

bemeurer 8y ago

That is a _lot_ of yak shaving to be done

em-bee 8y ago

perl 5 and perl 6 unite. news at 11!

tokyodude 8y ago

I don't understand the love for Perl. I wrote maybe 10k-20k lines of Perl between maybe 1996 and 2003 and at the time I was happy it worked. But ... more than any other language I've used it seems the most hacked and confusing. Global variables abound. Crazy cryptic syntax. Ridiculous scoping rules with hacked on workarounds. I really don't get the continued love. Sometime around 2003 IIRC I got introduced to Python and never looked back. When someone hands me a perl script I don't look forward to trying to get it to work. Speaking of which tho even Python now makes me crazy. NPM might suck for various reasons but at least all deps are installed local to each project. I'm sure there are secret incantations for doing the same in perl and python but by default most stuff I download requires global libraries to be installed. If there is one thing I love about npm is that it defaults to project local installs and I have yet to run into a project that requires a global install

Benjamin_Dobell 8y ago
> I'm sure there are secret incantations for doing the same in perl and python but by default most stuff I download requires global libraries to be installed. I'm not a Python developer, just dabble, but I've had decent success with Pipenv[1] and Pipfiles. [1] https://github.com/pypa/pipenv https://github.com/pypa/pipenv
nopacience 8y ago
Best method to achieve that is one of 2 options: perlbrew local::lib Or, specify it when executing the module, ie: bash$ perl -I../project_modules/Module1/lib -I../project_modules/Module2/lib your_project.pl Or, specify it at the top of your_project.pl ie: use lib '../project_modules/Module1/lib'; use lib '../project_modules/Module2/lib'; Or, set enviroment var export PERL5LIB=/home/project_modules/ ; perl your_project.pl Or, make a BEGIN statement on top of your main project, ie: BEGIN { push @INC, glob "/home/project_modules/*/lib"; } You dont need to use anything global, and its better you dont. Never execute anything as root. You are able to execute local modules just like node, rvm, etc. Its all the same. Some linux installs come with perl/python installed. It is used by the system and is refered to as "system perl" or "system python" or "system ruby", etc.. and it is not recommended to make upgrade on those "system XXX". Only your system should upgrade the libraries it uses. That is why you should always use a local perl/python/ruby install. If you didnt like it, its good you moved on.

primer42 8y ago

why...... just let old languages die. We've taken lessons from them, and grown. I know there is of are a good amount of financial systems written in COBOL, but that's because no one has had the guts to rewrite them, not because COBOL is some amazing perfect language. And there are a plethora of other important, reliable systems that are still in perl because no one has had the guts to rewrite them. But I would guess that there are just as many that have been rewritten to python and ruby. And many more that have been written for the first time in those languages. And in the next few years we're going to be in the same place with those sacred cow scripts written in python and ruby. I'm not trying to say that code is wrong. But it isn't productive to claim that we can slap a new version number on a library and claim it's going to satisfy everyone's hopes and dreams. At some point, we need to let our cows die, even if they're sacred.

snapdangle 8y ago
Anyone claiming that Perl 6 is "slapping a new version number on a library" has little credibility with regards to programming language design and history. "Let the past die" might be a great line for Ben Skywalker in a Star Wars movie, but in practical terms you are screeding against a people (Perl programmers) continuing their to develop their culture (Perl). What on earth could this be doing that affects you negatively?
mst 8y ago
perl5 has more explicit and reliable scoping and more flexible and powerful OO than python or ruby, and has had for a decade now. If other languages would actually take the lessons, I'd've switched. Recent javascripts have 'use strict' and 'let' (perl5's 'my') but the errors are at runtime, not compile time, so in terms of maximising productivity perl5 is still my preference - though ES6 is almost an acceptable perl5, and I'm working on some libraries to bridge the remaining feature gaps since apparently nobody else actually wants working OO and proper DRY.
Wwhite 8y ago
s/guts to rewrite them/staff experienced in both languages, with access to the original requirements, and knowledge of said system, in addition to full support from management to swap out working code with fresh, potentially buggy replacements, instead of devoting time to other projects which may actually be profitable/g

picduniya 8y ago

When we think about positive things, how great the world is and how amazing our life is, we see more proof of it in the real world. What might be considered normal will be considered great in this point of view. The same way when we think about how bad everything is and how life is going against us, we see normal events as being negative and small problems as being gigantic.

zebraman 8y ago

Not sure if it is me, but for a long time I have kept away from anything perl of moderate complexity. Package management used to be atrocious - it would be slow, pull a ton of modules, compile them with the C toolchain, break for missing dependencies and leave you wondering where the log was. Maybe it's better now. But I wonder why on earth interpreted languages need mandatory C bindings.

deleted 8y ago
[deleted]

deleted 8y ago

[deleted]

xarope 8y ago

I used to/still love perl, as it taught me a lot about regexp and hashmaps, but I have to admit, going back to a perl script written perhaps several years ago, and I struggle to figure out why I wrote it, the way I did. Contrast with python (v3), my current preferred prototyping/scripting choice, and it's still pretty clear about logic builds and data structures. I'm now trying to decide if I should jump on the golang ship, but the library ecosystem compared to python seems rather spare at the moment.

sacado2 8y ago
You might like go, indeed. At first, when I tried go (just after 1.0 went out), I wrote a small program with it and thought "meh". Yeah, the program was doing its job, but the language was pretty boring. A year later, I decided to improve that program, and that's when I really fell in love with the language. I could understand everything I had written, even though I hadn't read any go code for a year, and update it without any hassle. Moreover, my beginner program was rather idiomatic in the first place. Pretty cool. But, yeah, python's ecosystem is way bigger, so I tend to use both, depending on the situation.

wscott 8y ago

Here is my unrelated to the article perl memory... I fell in love with perl at school because it seems easier that sh/awk/sed/etc... After I got a job I still used perl for everything. Perl5 came along and made a bunch of really needed improvements [1] My problem was that at work they used rs6000 machines running AIX for everything and perl5 didn't work on AIX. So I couldn't use the latest toys. So I took time out and fixed dynamic linking so perl5 worked correctly on AIX. http://web.mit.edu/darwin/src/modules/perl/perl/ext/DynaLoader/dl_aix.xs http://web.mit.edu/darwin/src/modules/perl/perl/ext/DynaLoad... Then later I got an email from Redhat offering me shares of stock when they went public. This was because of my perl contribution. That was clearly some shady scheme so I declared that email spam and threw it away. 1) But yes perl5 is quite a bit more complicated than perl4 and that bothered a lot of people.

collyw 8y ago

Wasn't one of the original goals of Perl 6 to be able to run Perl 5 code?

lizmat 8y ago
Yes, and in a way it still is. The Inline::Perl5 (https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE https://modules.perl6.org/dist/Inline::Perl5:cpan:NINE) module allows one to embed a Perl 5 interpreter in Perl 6 and transparently call Perl 5 functionality as if it were written in Perl 6: this basically makes 99.9% of CPAN available to programs written in Perl 6. Many Perl 5 modules from CPAN have gotten a native Perl 6 equivalent as well: https://modules.perl6.org/t/CPAN5 https://modules.perl6.org/t/CPAN5 . Earlier this year I tried to launch an idea: https://www.perl.com/article/an-open-letter-to-the-perl-community/ https://www.perl.com/article/an-open-letter-to-the-perl-comm... . But that met with much hostility https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter_to_the_perl_community/ https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter... , so I'm not really actively pursuing that.

willthechill 8y ago

Hello everyone, I am Will 'the Chill' Braswell, creator of the RPerl optimizing compiler and co-creator of Perl 11, along with Reini Urban and Ingy döt Net. I'd be happy to answer any serious questions about the RPerl technical designs or the Perl 11 project goals. Thanks for your lively interest and continuing support of the Perl community. Obviously, the rumors of Perl's death have been greatly exaggerated! :-)