Live data from Hacker News

Raku: A language for gremlins

buttondown.email

211–220 of 257 posts

Re: Raku: A language for gremlins

#211
post #174
post #86

Earlier quoted context omitted.

I thought about that. I thought the compiler could error with "Insufficient data for meaningful answer" until you'd added enough digits that the sequence was unambiguous. Then I tried it in OEIS and as you say there are too many sequences that start [1,2,3,4,5,...] - I think we may be stuck with generators and yield. But they're not exactly delightful.

Convert https://trout.me.uk/data.jpg to sixels and have the compiler emit that?

> sixels

Thanks! My build scripts just got that little bit more entertaining (for me. not for the other devs).

Re: Raku: A language for gremlins

#212
post #3

It's worth remembering that Raku originated as "Perl 6" and a lot of design philosophies are derived from Perlisms in the first place. The author seems to be unfamiliar with both Perl and Raku's history, given that he immediately comments on the x operator for repeating strings. Which has been the case for many decades of Perl. :)

The "Perl6/Raku is nothing like Perl 5" hype has been hugely overstated. It wasn't called Perl 6 for nothing and it was developed by the same Perl team more or less. For anyone who worked with Perl 5 significantly the legacy in Perl6/Raku is obvious. Raku's whole object model is a slightly more capable version of Moose.pm, a Perl 5 module on CPAN.

Re: Raku: A language for gremlins

#213

Earlier quoted context omitted.

Having never written anything in Rust but read and “translated” some code (maybe 3k LOC?) from Rust to Ada, I can tell that I found Rust rather hard to read and harder than e.g. Ruby (which I also do not know how to write but translated to Java once). Here is what I guess makes it hard to read for me: There are many terse keywords (fn, mut) and symbols (&, [], ->) along with some things that look like Java annotation…

> To me Rust looks much like C++ with a twist and people rightfully complain about C++ often :) But would you put C++ next to Perl in terms of difficulty reading? I wouldn't have thought they were particularly close. (In terms of normal code at least, not the implementations of ultra-generic templates.)

The difficulty of reading Perl is probably overclaimed and overrepresented. Let's not forget that we are comparing a pretty darn low-level language to a fairly high-level one.

And regarding design principles, I think the comparison is clearly on point. These are languages where the motto is basically "if you can't do it (if you can do it but it's perceived too long that also counts) then the language needs to be horizontally extended to account for this use case".

My vague impression was that Rust is still a (significant) simplification over C++. (Ada is a funny case because it seems to be deliberately designed to be hard to read and hard to write, overall a pain in the arse, in the spirit of "if you never reach flow, you will always be very focused", I guess.)

Re: Raku: A language for gremlins

#214

Earlier quoted context omitted.

> To me Rust looks much like C++ with a twist and people rightfully complain about C++ often :) But would you put C++ next to Perl in terms of difficulty reading? I wouldn't have thought they were particularly close. (In terms of normal code at least, not the implementations of ultra-generic templates.)

The difficulty of reading Perl is probably overclaimed and overrepresented. Let's not forget that we are comparing a pretty darn low-level language to a fairly high-level one. And regarding design principles, I think the comparison is clearly on point. These are languages where the motto is basically "if you can't do it (if you can do it but it's perceived too long that also counts) then the language needs to be hori…

> "if you never reach flow, you will always be very focused"

That's how I stay alert in every language. :D

Re: Raku: A language for gremlins

#216

Earlier quoted context omitted.

Apparently by replacing them with new horrifying surprises, if this article is any indication. Good grief, I don't miss working in Perl.

Some of the Raku people think that showing of the most bizarre parts of the language makes it look good for some weird reason.

I guess that all depends on what you consider bizarre parts. You of all people must have your own weird reason to say this out of the blue, though.

Re: Raku: A language for gremlins

#217
post #210

There were so many claims in the first couple of years after Perl6/Raku's initial release in December 2015 about how it had the potential to be optimised due to its superior design but here we are nearly 8 years later and it's still takes 10 times as long as Perl 5 to parse a log file with a regex.

Yes, and those claims might have even been real (also, Perl still lags behind on Unicode stuff, or so I heard?)... the thing we like much less to talk about is that there just needs to be somebody to make those optimizations happen. Work on the actual bytecode VMs (or rather just MoarVM at this point) has been desperately lacking.

Re: Raku: A language for gremlins

#218

Earlier quoted context omitted.

Some of the Raku people think that showing of the most bizarre parts of the language makes it look good for some weird reason.

I guess that all depends on what you consider bizarre parts. You of all people must have your own weird reason to say this out of the blue, though.

Even from the perspective of long familiarity with Perl 5, the parts of Raku on show in this article are pretty damn bizarre. Maybe not by the standards of the Raku community, granted - but if this by them is ordinary, all the more reason for me to want to stay away.

Re: Raku: A language for gremlins

#219

I am definitely a gremlin, in a specific sense: I love tools that are quirky and complicated in a way that makes me more productive. But this idea of programming in The Large vs The Small: I disagree with that comparison. A less wise person might assume that means it makes a bad language for The Large work. On the contrary, it's probably just as good as any other language at it, maybe better. The problem, as it was w…

The notion/mindset that "This tool can only be used if you are good enough" is an enormous design smell in my opinion. Tooling exist to help you and your team do the required work as good or fast as possible. If you are using tools to gate keep juniors in your field, or that are unnecessary complex in order to stroke your own ego. Then the tool is more of a weapon against the rest of your organisation instead of some…

Have to agree with this one, and also, there is something that I think is easy to forget until you actually face code that has been worked on by dozens of people of completely random backgrounds, over decades: your wisdom doesn't necessarily coincide with someone else's wisdom. Context switching across people - and especially people who barely have anything in common - can be really troublesome. You have to know everything that somebody else you work with has ever used.

Re: Raku: A language for gremlins

#220
post #212
post #3

It's worth remembering that Raku originated as "Perl 6" and a lot of design philosophies are derived from Perlisms in the first place. The author seems to be unfamiliar with both Perl and Raku's history, given that he immediately comments on the x operator for repeating strings. Which has been the case for many decades of Perl. :)

The "Perl6/Raku is nothing like Perl 5" hype has been hugely overstated. It wasn't called Perl 6 for nothing and it was developed by the same Perl team more or less. For anyone who worked with Perl 5 significantly the legacy in Perl6/Raku is obvious. Raku's whole object model is a slightly more capable version of Moose.pm, a Perl 5 module on CPAN.

From what I heard, it half inspired Moose actually.
Post reply on HN