12 ms·

This has been a huge deal for the Perl community. First, it was thought that Perl 6 would be the replacement for Perl 5. But it was long ago recognized that t

• lliamander 7y ago
  >including being one of the few dynamic languages with a working concurrency model... Elixir is worth a look. It's a pretty productive little language with a great concurrency model.
  • tombert 7y ago
    For that matter, Erlang has been around for like almost 30 years and has had multicore support since 2007, and has always been dynamic.
    • zzzcpan 7y ago
      In fact Elixir and Erlang are the only reasonably known dynamic languages that differentiate on concurrency. The rest either do higher order event loop concurrency, which is ok, but not a differentiator, or do worse, shared memory multithreading (threads, coroutines with synchronous channels, mutexes, etc.)
      • tombert 7y ago
        I don't really know what "differentiate" means, but Clojure has support for CSP-channel style with core.async, shared-memory with transactions using atoms/refs, and actor-ish style with the agents.
        • cstrahan 7y ago
          > I don't really know what "differentiate" means [...] Probably “set themselves apart from others”.
    • davidw 7y ago
      Erlang is great, and I miss working with it, but I'd never want to write much in the way of 'quick scripts' with it. Something like Ruby feels much more productive for that.
      • tombert 7y ago
        Heh, escript isn't so bad once you get used to it. Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support. I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.
        • jdminhbg 7y ago
          GraalVM does in fact fix that. There's a (new-ish) project called babashka that lets you do some basic scripting for example: https://github.com/borkdude/babashka https://github.com/borkdude/babashka
        • didibus 7y ago
          Ya, GraalVM fixes it. But it requires a compile step, so it's not as nice for scripts. My favourite for scripting right now is Joker: https://github.com/candid82/joker https://github.com/candid82/joker Joker is a Clojure dialect which is interpreted, thus it starts super fast (but runs slower, but fast enough for scripts). Its design is to be batteries included for all things scripting. So it's just a self contained executable with everything you need for scripting. It's implemented in Go. I use it wherever I would have used bash or powershell prior. There is also Babashka: https://github.com/borkdude/babashka https://github.com/borkdude/babashka which is a similar idea, it's an interpreted dialect of Clojure with fast start times designed for scripting. The difference with Joker is that it is newer and more experimental, and it is implemented in JVM Clojure, compiled with GraalVM and has no Windows support for now. Anyways, I really recommend the use of Joker. Its awesome for scripting. I just put its binary in all my bin folders and script with it. It's great.
        • cutler 7y ago
          Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason - standard libraries for file, dir and pathname manipulation written in a concise language. Scripting is a style of coding, not just a means to an end. It is here that dynamic languages excel. Clojure is the leanest of the JVMs but doesn't it still rely on Java for file, dir and pathname manipulation?
    • lliamander 7y ago
      Oh certainly. I've done production work with Erlang, and it's great for building systems. I also love the Prolog syntax (I've also since done some side projects in Prolog for great fun). Why I suggested Elixir is because it has all the strengths of Erlang but is also a better scripting language, and would compete better with Raku on a more equal footing in that respect.
  • 7thaccount 7y ago
    When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.
    • weff_ 7y ago
      I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?
      • Grinnz 7y ago
        I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
        • weff_ 7y ago
          I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
          • karmakaze 7y ago
            It's not just CPU bound problems, handling multiple overlapping i/o operations is more trouble than it ought to be.
            • weff_ 7y ago
              Can you expand a bit on that? I'm not familiar with the issue you're describing.
          • Grinnz 7y ago
            Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.
• dimitar 7y ago
  Clojure has a focus on concurrency, is functional and it embraces JS and Java, the dominant platforms.
• jolmg 7y ago
  > Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way. I hope that doesn't mean that when Perl needs a major number version change again, they'll chose 6. It would be pretty confusing to have 2 Perl 6.
  • sigzero 7y ago
    They'll probably skip to 7.
    • dwaltrip 7y ago
      That is probably the best solution, but at the same time it is such a hilarious thing.
    • KSS42 7y ago
      Why not Perl 10 or Perl X?
    • rurban 7y ago
      no, it's called cperl now. perl5 didn't see not much improvements for the last 20 years, the development happens only in cperl, which is the perl5 successor.
      • ether_at_cpan 7y ago
        bwahahahahaha
    • b2gills 7y ago
      I think it would be a better idea to make the minor number be the major number. So skip to 32.
  • joshlemer 7y ago
    It's not uncommon to leap frog versions in such cases. PHP went from 5 to 7, for instance.
• msla 7y ago
  And this might save Raku. Lisp has a social problem: It's been called Lisp too long. People look at some simplified LISP 1.5-esque thing in a programming languages textbook and see a "pure" language (which isn't so pure compared to Haskell, but the creep of what "functional programming" means is its own post) which is completely useless. They don't see modern Common Lisp with its package management facility and its packages which you can manage which provide actual functionality and its FFI bindings to external libraries and the fact it compiles to optimized machine code... no, they only see some parentheses thing which is interpreted-and-therefore-slow (you know... like Javascript on V8... ) and is too elegantly pure to be bound to the outside world. Meanwhile, all the Foogols get new names every couple decades (PL/I to Ada to C to C++ to Java to C#... ) so everyone knows they're completely up to date. My point is, Perl is a tainted name, because everyone knows Perl is dead and Perl 6 is the Duke Nukem Forever of programming languages. Calling it Raku is a chance to get what the Perl 6 team actually did out into the world without the stench of death following it.
  • ddaa10 7y ago
    > Foogols get new names every couple decades (PL/I to Ada to C to C++ to Java to C#... ) +1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?
    • msla 7y ago
      > +1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol? Yes, even though I don't dislike Algol and the Algol syntax style, necessarily, I just wish they'd imported more Lisp influence sooner.
  • Jach 7y ago
    The social problem of the name is less similar to Lisp than I think you're making it, but I do agree it is probably not a terrible thing in the end and could be considered good. I don't think it's going to be impactful enough to "save" or not save the language (as someone mentioned elsewhere, if you called Betamax by a different name, it's unlikely the ultimate outcome would have changed). The reason I think it's not related to the Lisp issue is because the relation of Perl 5 and Perl 6 was like an unofficial successor with a compatibility mode, like C and C++, whereas the relations between Lisps that create the social problem you highlight of people not knowing about "Real Lisp" are the relations of very incompatible forks with varied functionality running around calling themselves "Lisps" or "members of the Lisp family" and people confusing that with "Lisp". (There were some "Perl 5/6, C/C++" types of relations in the path to Common Lisp like Flavors/CLOS but no one remembers or cares about those outside of Lisp users...) Another reason is the timing, why the name change now, years later -- it turns out Perl (5) is less dead or possessing a stench of death as you put it than people might want, it's still vigorous in its own rights, and so really it makes most sense to just call the new thing by a new name and not destroy both. (Larry's wineskin comment is nice.) The Python 2/3 situation is a closer analog if we counterfactually imagine Python 3000 came out with the current 3.7 feature set, syntax updates, and backwards incompatibility. Python 2 users (me among them) would still have dragged their feet, since Python 2 would still have been useful, still had its own vigor, the same as presently, but it might have resulted in renaming some later version of Python 3 instead of the current situation of renaming the continuation of Python 2 (Tauthon). Going back to the lisp issue to further elaborate why I think it's not very related to this one, the languages that called themselves Lisp (not a Lisp, but Lisp or Some Lisp) shared a heritage going back to the original McCarthy Lisp. The merely "a lisp" languages used that for marketing, but were actually called something different (Clojure, Scheme, even Racket which has to further distinguish itself from Scheme). You see the heritage in the actual Lisp 1.5 manual, where one of the earliest examples should quickly dispel any illusions today about "Lisp's" supposed purity when they show the function 'length implemented with a program block and goto. By only modifying the top-level function define format and substituting ADD1 with 1+, the program works to this day in Common Lisp. For members of the lisp family that don't call themselves lisp, you're not going to be able to make such a trivial transformation, because there's no shared code heritage, just a vaguely shared s-exp-ness to the syntax. And right after that the manual describes the "pseudo-function" 'trace, which to this day is lacking in supposedly modern languages or requires a bunch of IDE ceremony to set up. It's present in CL and behaves the same, though. Continuing to call CL as simply Lisp seems pretty well-deserved. The Lisp social problem then is that people run into members of the vaguely defined lisp family like Scheme (especially with SICP formerly being a common gateway for freshmen or HS students) or Clojure and confuse "a lisp" with "Lisp". They can spread their confusion further by releasing a project/blog like "let's write a lisp interpreter!" that can be understood correctly as "let's make a program that interprets code for a lisp¹" but tends to be misunderstood (sometimes even by the author) as "let's make a program that interprets code for Lisp". Of course I also think this "social problem" is way overstated, especially these days when it's so trivial to dispel the old myths and when the gateways via Clojure or Racket are actually good in their own right and so don't leave the same impressions of "Lisp's a neat toy" that only seeing SICP Scheme could. But if people keep talking about the problem as if it is big, perhaps it will become self-fulfilling, hence my long comment in disagreement. ;) ¹ aka a member of the lisp family based on my vague membership criteria that probably don't even pass Steele's 3-part acceptance test in https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf that requires as its final step (atanh -2) to return a complex number. (Bonus if the correct complex number.)
• bborud 7y ago
  > This has been a huge deal for the Perl community. I wasn't aware that there was one beyond the poor sods charged with maintaining my youthful sins.
  • Ovid 7y ago
    I get hired all the time to fix legacy systems in Perl or to build new systems in Perl. We're still out there, but it's not "cool" to talk about.
    • bborud 7y ago
      I hope you are not working on my old sins. But if you are, can I watch? :-)
      • sjn 7y ago
        I'm pretty sure Ovid's hair would turn grey if he did! ;-)
• 7thaccount 7y ago
  Hey Ovid. I'm curious...if P6 had been performant and production worthy enough for your tau-station game, how much easier would the project be than with P5 + Moose? Just curious...I remember you saying years ago that you would've used it if you could've at the time.
  • Ovid 7y ago
    The https://taustation.space/ https://taustation.space/ game runs great on Perl 5, but yes, with a robust Perl 6, many things would have been easier to implement. But by "robust" I don't mean just the language—I also mean the ecosystem. There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis). On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out. And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose: package Point { use Moose; use overload '""' => \&Str, fallback => 1; use Moose::Util::TypeConstraints; subtype "PointLimit" => as 'Num' => where { $_ >= -10 && $_ <= 10 } => message { "$_ must be a Num between -10 and 10, inclusive" }; has [qw/x y/] => ( is => 'rw', isa => 'PointLimit', required => 1, ); sub Str { my $self = shift; return sprintf "[%f,%f]" => $self->x, $self->y; } } raku: class Point { subset PointLimit of Rat where -10.0 .. 10.0; has PointLimit $.x is rw is required; has PointLimit $.y is rw is required; } And for those who don't "grok" the above, here it is in Python 3, just so you can see how clean raku's OO syntax is: class PointLimit: def __init__(self, name): self.name = name def __get__(self, point, owner): return point.__dict__.get(self.name) def __set__(self, point, value): if not -10 < value < 10: raise ValueError('Value %d is out of range' % value) point.__dict__[self.name] = value class Point: x = PointLimit('x'); y = PointLimit('y'); def __init__(self, x, y): self.x = x self.y = y def __str__(self): return "[%f,%f]" % (self.x, self.y)
• Causality1 7y ago
  Rather reminds me of what happened with Palm OS 5 and Palm OS 6. Both ended up adopting separate names but because OS 6 wasn't backwards compatible the sheer weight of legacy software kept it from ever catching on.
• rolltiide 7y ago
  If only the Python community could learn something here