Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unusual Raku Features

buttondown.com

Post reply on HN
Print view View original

91–100 of 166 posts

Re: Unusual Raku Features

#91

Post by lizmat »

b2gills wrote: post #77
kamaal wrote: post #61

Earlier quoted context omitted.

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.

I once heard of a merger between a company that used Java, and another one that used Perl. After that merger, both teams were required to make a similar change. If I remember right, the Perl team was done before the Java team finished the design phase. Or something like that. The best aspect of Java is that it is difficult to write extremely terrible code. The worst aspect is that it is difficult to write extremely a…

If this was about my former $work:

The company using Perl was able to double its turnover in 3 weeks.

The company using Java was still in the design phase.

Companies choose their tools depending on their internal culture. The company using Perl at the time was simply more agile.

FWIW, the company that was using Perl is now using Java mostly. And yes, the culture of the company has changed. Not sure about cause and effect.

Re: Unusual Raku Features

#92

Post by [deleted] »

tail_exchange wrote: post #20

# Does weird things with nested lists too > [1, [2, 3], 4, 5] > [10, 20] [11 [22 23] 14 25] This article makes me feel like I'm watching a Nao Geo/Animal Planet documentary. Beautiful and interesting to see these creatures in the wild? Absolutely. Do I want to keep my distance? As far away as possible.

[deleted]

Re: Unusual Raku Features

#93

Post by mst »

quink wrote: post #4
jddj wrote: post #2

> (2,4,8...*)[17] 262144 This one genuinely surprised me

My brain immediately reached for the word 'horrifying', with phrases 'terrible consequences' and 'halting problem' soon after, but to each their own.

You get either a compile time instantiated infinite lazy sequence, or a compilation error.

My personal bar for "amount of clever involved" is fairly high when the clever either does exactly what you'd expect or fails, and even higher when it does so at compile time.

(personal bars, and personal definitions of "exactly what you'd expect" will of course vary, but I think your brain may have miscalibrated the level of risk before it got as far as applying your preferences in this particular case)

Re: Unusual Raku Features

#94

Post by mst »

emmelaich wrote: post #59
Spivak wrote: post #55

Earlier quoted context omitted.

I… love it? It's so elegant it's infuriating.

It also seems slowish, but seems the problem is the startup cost. So probably pretty smart? The following shows fairly stable times. > for i in $(seq 20); do time raku -e "say (1, 1, + ... *)[0..$i]"; done

raku kinda puts a bunch of parts of itself together during startup, not entirely unlike Julia.

The sheer dynamism of the thing makes pre-baking that non-trivial, also not entirely unlike Julia.

I seem to recall chatting with the devs on IRC a few years and there seeming to be more than one viable way to potentially fix it, but they all seemed to me to share the property of needing a lot of effort during which nothing would work at all before you got something to show for it - and a decent chance of what you got to show after all that time was "welp, here's why which one can't work" - which is a really heavy lift in terms of somebody finding motivation to try it in the first place.

So tl;dr "yes, I dislike the startup cost, no, I don't expect it to change soon and I don't think it's a black mark against the team that it probably won't."

Re: Unusual Raku Features

#95

Post by orbisvicis »

b2gills wrote: post #74
TOGoS wrote: post #51

Earlier quoted context omitted.

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 an…

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?

Re: Unusual Raku Features

#96

Post by mst »

dragonwriter wrote: post #14
broodbucket wrote: post #7

It is absolutely mindbending to me that all of this language development has happened on top of Perl, of all things.

Wasn’t Raku/Perl6 basically a ground-up reconception more than a building-on-top of existing Perl5?

Yes, though perl5 is also an incredibly bendable language syntax wise - you can add keywords and operators to the compiler via CPAN modules (our async/await syntax is provided simply by doing 'use Future::AsyncAwait' for example).

Re: Unusual Raku Features

#97

Post by kasey_junk »

b2gills wrote: post #74
TOGoS wrote: post #51

Earlier quoted context omitted.

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 an…

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…

If you mean Design Patterns: Elements of Reusable OO software by Gamma et al, it was published in 1994. Java came out in 1995.

The Patterns book was originally a C++ text.

All programming languages have design patterns, they aren’t patterns as in “templates you should follow”, they are patterns as in “concepts you will see frequently for solving classes of problems”.

The Design Patterns book was a bestiary not a guide to replacement features.

Re: Unusual Raku Features

#98

Post by ogogmad »

b2gills wrote: post #68
tolmasky wrote: post #48

I implemented something similar to the compositional regular expressions feature described here for JavaScript a while ago (independently, so semantics may not be the same), and it is one of the libraries I find myself most often bringing into other projects years later. It gets you a tiny bit closer to feeling like you have a first-class parser in the language. Here is an example of implementing media type parsing w…

"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.

Re: Unusual Raku Features

#99

Post by Pannoniae »

orbisvicis wrote: post #95
b2gills wrote: post #74

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?

events/reactive programming?

Re: Unusual Raku Features

#100

Post by ab5tract »

postepowanieadm wrote: post #88

Ahh, perl operators! My favorite was goatse operator: =()= that assigned(no pun intended) length of an array if I recall correctly.

I dream of a day where one can post a Raku article on HNN and not encounter a comments section full of digressions into discussing Perl.

There is some sense to it by means of comparison, but the constant conflation of the two becomes tiresome.

But in that spirit, let's compare:

The =()= "operator" is really a combination of Perl syntax[^1] that achieves the goal of converting list context to scalar context. This isn't necessary to determine the length of an array (`my $elems = @array` or, in favor of being more explicity, `my $elems = 0+@array`). It is, however, useful in Perl for the counting of more complex list contexts on the RHS.

Let's use some examples from it's documentation to compare to Raku.

Perl:

    my $n =()= "abababab" =~ /a/g;
    # $n == 4
Raku:

    my $n = +("abababab" ~~ m:g/'a'/);
    # $n == 4
    # Alternatively...
    my $n = ("abababab" ~~ m:g/'a'/).elems;
That's it. `+` / `.elems` are literally all you ever need to know for gathering a count of elements. The quotes around 'a' in the regex are optional but I always use them because I appreciate denoting which characters are literal in regexes (Note also that the regex uses the pair syntax mentioned in OP via `m:g`. Additional flags are provided as pairs, eg `m:g:i`).

Another example.

Perl:

    my $count =()= split /:/, "ab:ab:ab";
    # $count == 3
Raku:

    my $count = +"ab:ab:ab".split(':');
    # $count == 3
While precedence can at times be a conceptual hindrance, it's also nice to save some parentheses where it is possible and legible to do so. Opinions differ on these points, of course. Note also that `Str.split` can take string literals as well as regexes.

[1]: See https://github.com/book/perlsecret/blob/master/lib/perlsecre...

Post reply on HN