101–110 of 166 posts
Earlier quoted context omitted.
I'm not so sure every design pattern corresponds to a missing feature. For example, what feature would the Observer design pattern correspond to?
events/reactive programming?
I’m not sure this page loaded properly for me, half of it is arbitrary punctuation characters assembled in bizarre nonsensical ways.
The greatest trick the Devil ever played was renaming Perl 6 to Raku.
I don't understand why we want to use some language feature like Junctions, instead of using lists explicitly?
And yes, this feature is annoying and arguably is a mis-feature: containers shall not explode when you touch them.
The most important Raku features are Command Line Interface (CLI) and grammars.
CLI support is a _usual_ feature -- see "docopt" implementations (and adoption), for example. But CLI is built-in in Raku and nice to use.
As for the grammars -- it is _unusual_ a programming language to have grammars as "first class citizens" and to give the ability to create (compose) grammars using Object-Oriented Programming.
Earlier quoted context omitted.
"Actual parsers" aren't powerful enough to be used to parse Raku. Raku regular expressions combined with grammars are far more powerful, and if written well, easier to understand than any "actual parser". In order to parse Raku with an "actual parser" it would have to allow you to add and remove things from it as it is parsing. Raku's "parser" does this by subclassing the current grammar adding or removing them in th…
I imagine this could be understood as making use of a monad. Right? The main problem with generalised regexes is that you can't match them in linear time worst-case. I'm wondering if this is addressed at all by Raku.
Can you clarify what do you mean?
Do expect the concept of "monad" to help explaining Raku grammars?
Earlier quoted context omitted.
I imagine this could be understood as making use of a monad. Right? The main problem with generalised regexes is that you can't match them in linear time worst-case. I'm wondering if this is addressed at all by Raku.
> I imagine this could be understood as making use of a monad. Right? Can you clarify what do you mean? Do expect the concept of "monad" to help explaining Raku grammars?
Earlier quoted context omitted.
"Actual parsers" aren't powerful enough to be used to parse Raku. Raku regular expressions combined with grammars are far more powerful, and if written well, easier to understand than any "actual parser". In order to parse Raku with an "actual parser" it would have to allow you to add and remove things from it as it is parsing. Raku's "parser" does this by subclassing the current grammar adding or removing them in th…
I imagine this could be understood as making use of a monad. Right? The main problem with generalised regexes is that you can't match them in linear time worst-case. I'm wondering if this is addressed at all by Raku.
There is probably a monad you could understand this as being, a specific one, but "monad" itself is not a way to understand it.
And just as you can understand any given Iterator by simply understanding it directly, whatever "monad" you might use to understand this process can be simply understood directly without reference to the "monad" concept.
Earlier quoted context omitted.
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 th…
I'm not so sure every design pattern corresponds to a missing feature. For example, what feature would the Observer design pattern correspond to?
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.
Wow. Sign me up for leaving the industry before I ever have to maintain a Raku codebase.
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.