4 ms·

Wow. Sign me up for leaving the industry before I ever have to maintain a Raku codebase.

agumonkey 2y ago
Funny, cause reading that blog post made me want to quit my job and find a raku team to work with. Maybe I'm still too naive :)
- fuzztester 2y ago
  yeah, you're right. your entire comment is syntactically valid raku, or can be made so, because raku syntax is so powerful and flexible. raku grammars ftw! https://docs.raku.org/language/grammars https://docs.raku.org/language/grammars https://docs.raku.org/language/grammar_tutorial https://docs.raku.org/language/grammar_tutorial ;) even that last little fella above, is or can be made syntactically valid.
- TOGoS 2y ago
  Same. And it's a bit funny because I'm usually against unnecessary complexity, and here's a language that seems to have embraced it and become a giant castle of language features that I could spend weeks studying. Maybe it's because Raku's features were actually well thought-out, unlike the incidental "doesn't actually buy me anything, just makes the code hard to deal with" complexity I have to deal at work day in and day out. Maybe if Java had a few of these features back in the day people wouldn't've felt the need to construct these monstrous annotation soup frameworks in it.
  - redrobein 2y ago
    I think it has to do more with familiarity than complexity. You could have a good understanding of features like the ones showcased in the blogpost, but it could take you a minute of staring at a line to parse it if someone uses it in a way you're unfamiliar with. Doing that for potentially hours on end would be a pain. It's definitely something I'd write for fun/personal projects but can't imagine working with other people in. On a side note, I believe this is where go's philosophy of having a dead simple single way of doing things is effective for working with large teams.
  - b2gills 2y ago
    Java inspired the Design Patterns book. Every Design Pattern is a workaround for a missing feature. What that missing feature is, isn't always obvious. For example the Singleton Design Pattern is a workaround for missing globals or dynamic variables. (A dynamic variable is sort of like a global where you get to have your own dynamic version of it.) If Raku has a missing feature, you can add it by creating a module that modifies the compiler to support that feature. In many cases you don't even need to go that far. Of course there are far fewer missing features in Raku than Java. If you ever needed a Singleton in Raku (which you won't) you can do something like this: role Singleton { method new (|) { once callsame } } class Foo does Singleton { has $.n is required } say Foo.new( n => 1 ).n; say Foo.new( n => 2 ).n; That prints `1` twice. The way it works is that the `new` method in Singleton always gets called because it is very generic as it has a signature of `:(|)`. It then calls the `new` method in the base class above `Foo` (`callsame` "calls" the next candidate using the "same" arguments). The result then gets cached by the `once` statement. There are actually a few limitations to doing it this way. For one, you can't create a `new` method in the actual class, or any subclasses. (Not that you need to anyway.) It also may not interact properly with other roles. There are a variety of other esoteric limitations. Of course none of that really matters because you would never actually need, or want to use it anyway. Note that `once` basically stores its value in the next outer frame. If that outer frame gets re-entered it will run again. (It won't in this example as the block associated with Foo only gets entered into once.) Some people expect `once` to run only once ever. If it did that you wouldn't be able to reuse `Singleton` in any other class. What I find funny is that while Java needs this Design Pattern, it is easier to make in Raku, and Raku doesn't need it anyway.
    - orbisvicis 2y ago
      I'm not so sure every design pattern corresponds to a missing feature. For example, what feature would the Observer design pattern correspond to?
      - Pannoniae 2y ago
        events/reactive programming?
  - agumonkey 2y ago
    What captures my mind is a little blend of radical language design that I only find in Haskell for instance, without the type theoretic bagage, and a bit of 'thats just a fun perl idiom' when you used to hack around your old linux box.
- IshKebab 2y ago
  Some of them seem ok, e.g. ignoring whitespaces in regex by default is a great move, and the `` as a shorthand single lambda argument is neat. But trust me if you ever have to actually work* with them you will find yourself cursing whoever decided to riddle their code with <<+>>, or the person that decided `* + ` isn't the same as `2 *` (that parser must have been fun to write!)
rjh29 2y ago
Same as Perl, nobody wants to maintain it, but it's extremely fun to write. It has a lot of expression. You can see that in Raku's ability to define keyword arguments with a shorthand (e.g. :global(:$g)' as well as assuming a value of 'True', so you can just call match(/foo/, :g) to get a global regex match). Perl has tons of this stuff too, all aimed at making the language quicker and more fun to write, but less readable for beginners.
- calvinmorrison 2y ago
  its not that reading perl is hard, the _intent_ of the operations of often hard/unclear. Yes its nice to write dense fancy code, however, something very boring to write like PHP is a lot of "loop over this bucket and do something with the fish in the bucket, afterwards, take the bucket and throw it into the bucket pile" that mirrors a 'human follows these steps' type.
  - kjellsbells 2y ago
    Frankly I'm on Team Fish Bucket. I am not totally convinced--well, not at all convinced, really-- that the OOP revolution made programming code better, simpler, easier to follow, than procedural code. I suppose the argument ended up being a philosophical discussion about where State was held in a running program (hard to tell in procedural code, perhaps, and easier to tell in OOP), but after 20+ years of Java I wonder if baby hadnt disappeared down the plughole with the bathwater.
  - kamaal 2y ago
    In the intent department, I have had more troubles with AbstractClassFactorySingletonDispatcher type Java code, add to that dependency injection magic/madness. I'd rather maintain Perl any day than 30 classes of Java code just to build a string.
    - wruza 2y ago
      I’d rather have a compiler+ide-supported testing framework that doesn’t require a tested code to be prepared for being tested in any way. Almost all boring languages are fine at writing straightforward code without ceremony, even Java.
kamaal 2y ago
Its strange that people are saying the same about maintaining code bases written using AI assistance. Im guessing its going to be a generational thing now. A whole older generation of programmers will just find themselves out of place in what is like a normal work set up for the current generation.
7thaccount 2y ago
That's a fair reaction to the post if you haven't looked at any normal Raku code. If you look at any of the introductory Raku books, it seems a LOT like Python with a C-like syntax. By that I mean the syntax is more curly-brace oriented, but the ease of use and built-in data structures and OO features are all very high level stuff. I think if you know any other high level scripting language that you would find Raku pretty easy to read for comparable scripts. I find it pretty unlikely that the majority of people would use the really unusual stuff in normal every day code. Raku is more flexible (more than one way to do things), but it isn't arcane looking for the normal stuff I've seen. I hope that helps.
- maleldil 2y ago
  Sure, but the fact that weird stuff is possible means that someone, at some point, will try to use it in your codebase. This might be prevented if you have a strong code review culture, but if the lead dev in the project wants to use something unusual, chances are no one will stop them. And once you start...
  - jjnoakes 2y ago
    If you suggest a language here where nothing weird can be done, I bet someone will reply with something weird done in that language.
    - christophilus 2y ago
      This is true. I’ve written overly-clever, indecipherably dense code in many different languages. But some languages seem to practically encourage that kind of thing. Compare a random sampling of code from APL, Scala, Haskell, Perl, Clojure, C, and Go. You’ll probably find that average inscrutability varies widely between various language pairs.
      - kqr 2y ago
        Inscrutability to whom? I'm confident someone with 10 years of production Haskell experience will do a better job of reading production Haskell code than a comparable situation with C. But then again, maybe that was what you were saying.
zokier 2y ago
I don't think Raku is intended for "the industry".

Funny, cause reading that blog post made me want to quit my job and find a raku team to work with. Maybe I'm still too naive :)

fuzztester 2y ago
yeah, you're right. your entire comment is syntactically valid raku, or can be made so, because raku syntax is so powerful and flexible. raku grammars ftw! https://docs.raku.org/language/grammars https://docs.raku.org/language/grammars https://docs.raku.org/language/grammar_tutorial https://docs.raku.org/language/grammar_tutorial ;) even that last little fella above, is or can be made syntactically valid.
TOGoS 2y ago
Same. And it's a bit funny because I'm usually against unnecessary complexity, and here's a language that seems to have embraced it and become a giant castle of language features that I could spend weeks studying. Maybe it's because Raku's features were actually well thought-out, unlike the incidental "doesn't actually buy me anything, just makes the code hard to deal with" complexity I have to deal at work day in and day out. Maybe if Java had a few of these features back in the day people wouldn't've felt the need to construct these monstrous annotation soup frameworks in it.
- redrobein 2y ago
  I think it has to do more with familiarity than complexity. You could have a good understanding of features like the ones showcased in the blogpost, but it could take you a minute of staring at a line to parse it if someone uses it in a way you're unfamiliar with. Doing that for potentially hours on end would be a pain. It's definitely something I'd write for fun/personal projects but can't imagine working with other people in. On a side note, I believe this is where go's philosophy of having a dead simple single way of doing things is effective for working with large teams.
- b2gills 2y ago
  Java inspired the Design Patterns book. Every Design Pattern is a workaround for a missing feature. What that missing feature is, isn't always obvious. For example the Singleton Design Pattern is a workaround for missing globals or dynamic variables. (A dynamic variable is sort of like a global where you get to have your own dynamic version of it.) If Raku has a missing feature, you can add it by creating a module that modifies the compiler to support that feature. In many cases you don't even need to go that far. Of course there are far fewer missing features in Raku than Java. If you ever needed a Singleton in Raku (which you won't) you can do something like this: role Singleton { method new (|) { once callsame } } class Foo does Singleton { has $.n is required } say Foo.new( n => 1 ).n; say Foo.new( n => 2 ).n; That prints `1` twice. The way it works is that the `new` method in Singleton always gets called because it is very generic as it has a signature of `:(|)`. It then calls the `new` method in the base class above `Foo` (`callsame` "calls" the next candidate using the "same" arguments). The result then gets cached by the `once` statement. There are actually a few limitations to doing it this way. For one, you can't create a `new` method in the actual class, or any subclasses. (Not that you need to anyway.) It also may not interact properly with other roles. There are a variety of other esoteric limitations. Of course none of that really matters because you would never actually need, or want to use it anyway. Note that `once` basically stores its value in the next outer frame. If that outer frame gets re-entered it will run again. (It won't in this example as the block associated with Foo only gets entered into once.) Some people expect `once` to run only once ever. If it did that you wouldn't be able to reuse `Singleton` in any other class. What I find funny is that while Java needs this Design Pattern, it is easier to make in Raku, and Raku doesn't need it anyway.
  - orbisvicis 2y ago
    I'm not so sure every design pattern corresponds to a missing feature. For example, what feature would the Observer design pattern correspond to?
    - Pannoniae 2y ago
      events/reactive programming?
- agumonkey 2y ago
  What captures my mind is a little blend of radical language design that I only find in Haskell for instance, without the type theoretic bagage, and a bit of 'thats just a fun perl idiom' when you used to hack around your old linux box.
IshKebab 2y ago
Some of them seem ok, e.g. ignoring whitespaces in regex by default is a great move, and the `` as a shorthand single lambda argument is neat. But trust me if you ever have to actually work* with them you will find yourself cursing whoever decided to riddle their code with <<+>>, or the person that decided `* + ` isn't the same as `2 *` (that parser must have been fun to write!)

rjh29 2y ago

Same as Perl, nobody wants to maintain it, but it's extremely fun to write. It has a lot of expression. You can see that in Raku's ability to define keyword arguments with a shorthand (e.g. :global(:$g)' as well as assuming a value of 'True', so you can just call match(/foo/, :g) to get a global regex match). Perl has tons of this stuff too, all aimed at making the language quicker and more fun to write, but less readable for beginners.

calvinmorrison 2y ago
its not that reading perl is hard, the _intent_ of the operations of often hard/unclear. Yes its nice to write dense fancy code, however, something very boring to write like PHP is a lot of "loop over this bucket and do something with the fish in the bucket, afterwards, take the bucket and throw it into the bucket pile" that mirrors a 'human follows these steps' type.
- kjellsbells 2y ago
  Frankly I'm on Team Fish Bucket. I am not totally convinced--well, not at all convinced, really-- that the OOP revolution made programming code better, simpler, easier to follow, than procedural code. I suppose the argument ended up being a philosophical discussion about where State was held in a running program (hard to tell in procedural code, perhaps, and easier to tell in OOP), but after 20+ years of Java I wonder if baby hadnt disappeared down the plughole with the bathwater.
- kamaal 2y ago
  In the intent department, I have had more troubles with AbstractClassFactorySingletonDispatcher type Java code, add to that dependency injection magic/madness. I'd rather maintain Perl any day than 30 classes of Java code just to build a string.
  - wruza 2y ago
    I’d rather have a compiler+ide-supported testing framework that doesn’t require a tested code to be prepared for being tested in any way. Almost all boring languages are fine at writing straightforward code without ceremony, even Java.

kamaal 2y ago

Its strange that people are saying the same about maintaining code bases written using AI assistance. Im guessing its going to be a generational thing now. A whole older generation of programmers will just find themselves out of place in what is like a normal work set up for the current generation.

7thaccount 2y ago

That's a fair reaction to the post if you haven't looked at any normal Raku code. If you look at any of the introductory Raku books, it seems a LOT like Python with a C-like syntax. By that I mean the syntax is more curly-brace oriented, but the ease of use and built-in data structures and OO features are all very high level stuff. I think if you know any other high level scripting language that you would find Raku pretty easy to read for comparable scripts. I find it pretty unlikely that the majority of people would use the really unusual stuff in normal every day code. Raku is more flexible (more than one way to do things), but it isn't arcane looking for the normal stuff I've seen. I hope that helps.

maleldil 2y ago
Sure, but the fact that weird stuff is possible means that someone, at some point, will try to use it in your codebase. This might be prevented if you have a strong code review culture, but if the lead dev in the project wants to use something unusual, chances are no one will stop them. And once you start...
- jjnoakes 2y ago
  If you suggest a language here where nothing weird can be done, I bet someone will reply with something weird done in that language.
  - christophilus 2y ago
    This is true. I’ve written overly-clever, indecipherably dense code in many different languages. But some languages seem to practically encourage that kind of thing. Compare a random sampling of code from APL, Scala, Haskell, Perl, Clojure, C, and Go. You’ll probably find that average inscrutability varies widely between various language pairs.
    - kqr 2y ago
      Inscrutability to whom? I'm confident someone with 10 years of production Haskell experience will do a better job of reading production Haskell code than a comparable situation with C. But then again, maybe that was what you were saying.

zokier 2y ago

I don't think Raku is intended for "the industry".