4 ms·

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 o

by 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
      and further down the research path, chemical programming (forgot the name of the languages)
  - jerf 2y ago
    The feature that Observer would correspond to is simply Observers. Some of the patterns may happen to correspond to different names, but they don't all need different names or weird mappings, many of them are just "and now it's a feature instead of a set of classes". That said, while the point "a design pattern is a feature missing from a language" has some validity on its own terms, the implied "and therefore a language is deficient if it has design patterns because those could be features" is nonsense. A language has some set of features. These features have an exponential combination of possibilities, and a smaller, but still exponential, set of those are useful. For every feature one lifts from "design pattern" and tries to put into the language, all that happens is an exponential number of other "features" are now closer to hand and are now "design patterns". This process does not end, and this process does not even complete enumerating all the possible useful patterns before the language has passed all human ability to understand it... or implement it. Moreover, the argument that "all design patterns should be lifted to features" ignores the fact that features carry costs. Many kinds of costs. And those costs generally increase the cost of all the features around them. The costs become overwhelming.
  - chucksmash 2y ago
    "Design patterns are really Band-Aids for missing language features" comes from a 1996 Peter Norvig presentation[0][1]: > Some suggest that design patterns may be a sign that features are missing in a given programming language (Java or C++ for instance). Peter Norvig demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan. [0]: https://en.wikipedia.org/wiki/Software_design_pattern#Criticism https://en.wikipedia.org/wiki/Software_design_pattern#Critic... [1]: slide 9 of PDF https://www.norvig.com/design-patterns/design-patterns.pdf https://www.norvig.com/design-patterns/design-patterns.pdf
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.

by TOGoS 2y ago

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
    and further down the research path, chemical programming (forgot the name of the languages)
- jerf 2y ago
  The feature that Observer would correspond to is simply Observers. Some of the patterns may happen to correspond to different names, but they don't all need different names or weird mappings, many of them are just "and now it's a feature instead of a set of classes". That said, while the point "a design pattern is a feature missing from a language" has some validity on its own terms, the implied "and therefore a language is deficient if it has design patterns because those could be features" is nonsense. A language has some set of features. These features have an exponential combination of possibilities, and a smaller, but still exponential, set of those are useful. For every feature one lifts from "design pattern" and tries to put into the language, all that happens is an exponential number of other "features" are now closer to hand and are now "design patterns". This process does not end, and this process does not even complete enumerating all the possible useful patterns before the language has passed all human ability to understand it... or implement it. Moreover, the argument that "all design patterns should be lifted to features" ignores the fact that features carry costs. Many kinds of costs. And those costs generally increase the cost of all the features around them. The costs become overwhelming.
- chucksmash 2y ago
  "Design patterns are really Band-Aids for missing language features" comes from a 1996 Peter Norvig presentation[0][1]: > Some suggest that design patterns may be a sign that features are missing in a given programming language (Java or C++ for instance). Peter Norvig demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan. [0]: https://en.wikipedia.org/wiki/Software_design_pattern#Criticism https://en.wikipedia.org/wiki/Software_design_pattern#Critic... [1]: slide 9 of PDF https://www.norvig.com/design-patterns/design-patterns.pdf https://www.norvig.com/design-patterns/design-patterns.pdf

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.