[HN Gopher] Raku: A Language for Gremlins
___________________________________________________________________
Raku: A Language for Gremlins
Author : azhenley
Score : 131 points
Date : 2023-08-07 20:42 UTC (2 hours ago)
(HTM) web link (buttondown.email)
(TXT) w3m dump (buttondown.email)
| cjm42 wrote:
| Let's face it, the Perl 5/PCRE regex syntax is atrocious. The
| only reason it exists is that (? was a syntax error in earlier
| regex syntaxes, so it could be redefined to mean anything.
|
| Raku is an attempt to design a sane regular expression language
| from first principles, now that we know what we want them to be
| able to express. The alternative is being stuck with
| (?:this|(?>or that)) for the next 30 years.
| pdntspa wrote:
| Awful? It is inscrutable black magic and it is _wonderful_ once
| you get it.
|
| I haven't touched perl in years but I still find myself writing
| regex often!
| justinator wrote:
| _> Let's face it, the Perl 5/PCRE regex syntax is atrocious._
|
| Agreed, but god-damn is it useful.
| munificent wrote:
| One way you might arranging programming languages in a 2D space
| is with two axes:
|
| 1. How much should the language surprise you?
|
| 2. When the language does surprise you, should it delight you or
| horrify you? surprising
| ^ | |
| | delight <------+------> horrify
| | | |
| v unsurprising
|
| Only a sadist would deliberately design a language for the top
| right quadrant, but there are many esoteric languages in there. I
| think most people tacitly assume that all well-behaved languages
| belong on the bottom left: the language should rarely suprise you
| but in the rare case it does, hopefully it's a delight.
|
| Raku seems to overtly aim for the mostly-unoccupied top left.
| It's like the designers and users (two sets with apparently very
| large overlap) all think, "Yes, it's weird. Isn't that grand!"
| eddd-ddde wrote:
| I found about raku one time I had an assignment for college
| where I needed to create a parser. I found raku's grammar
| features really interesting and used it for my project, it felt
| almost like cheating since it did pretty much every thing for
| me (actually it was probably just cheating but it was still
| fun).
| db48x wrote:
| That's exactly what you want in a language. It should always
| feel like cheating!
|
| Also debuggers. Give RR a try some time :)
| eddd-ddde wrote:
| I imagine you are referring to https://rr-project.org/ ?
|
| Had never heard of it, looks pretty amazing, I might
| actually enjoy debugging now!
| toast0 wrote:
| The problem is those are subjective axes. And things can both
| delight and horrify; I wrote some javascript once where I did
| document.write = function ... which is kind of delightful in
| that I was able to do what I needed as a result, but also
| pretty horrifying :)
|
| Other people I showed it to felt it was more on the horrifying
| side, but like I said, it's subjective.
| shagie wrote:
| Then a 3d chart with "likelihood of" being a point or region
| in the space. The axises would then be "Surprise", "Delight",
| and "Horrify".
| Kwpolska wrote:
| In my view, Raku was venturing further and further into the
| top-right corner with every subsequent paragraph.
| cogman10 wrote:
| I mean, it was "Perl 6" so is it really surprising that Perl
| devs wanted a language that looks nothing like any other
| language?
|
| Perl has it's own healthy share of "delightful surprises" and
| Raku was mostly designed to eliminate perl's horrifying
| surprises.
| actionfromafar wrote:
| I'm very interested in bottom right langs.
| zukzuk wrote:
| Absolutely JavaScript, in that it is easy to accidentally do
| horrifying things, but absolutely not surprising if you've
| spent any time working with it, as you quickly get used to
| how awful it is.
| jonathrg wrote:
| Languages where there has been significant modernization and
| progress, but where codebases and online resources lag
| behind: CMake, PHP, CSS
| the_af wrote:
| COBOL?
| grotorea wrote:
| It's just the languages everyone knows are bad.
| pravus wrote:
| I think my vote goes to ColdFusion.
| netr0ute wrote:
| C++!
| Qworg wrote:
| Only old C++, new C++ creeps up the y axis.
| actionfromafar wrote:
| Interesting perspective. It surprises you in exactly
| _how_ , but not very in that it _will_. (Horrify you. But
| it also delights sometimes. We need more dimensions?)
| aldanor wrote:
| To put it differently, the new C++ is delightfully
| horrific at times.
| ModernMech wrote:
| C++ occupies a region of the space rather than a singular
| point, since old C++ is part of new C++.
| munificent wrote:
| Maybe C?
| actionfromafar wrote:
| You can definitely get there with C but the language isn't
| actively pushing you into horror.
| segfaultbuserr wrote:
| It's the "unsurprising" part in "unsurprising &
| horrifying" - if you manipulate raw pointers incorrectly,
| of course it will crash or be vulnerable, to the surprise
| of no one by design.
| actionfromafar wrote:
| This rings true the more I think about it. Any large code
| base gets there with size, but with C one gets there
| pretty reliably after a certain heft of code.
| segfaultbuserr wrote:
| That being said, while C's surprises are certainly fewer
| than other languages, it still does have a few surprising
| corner cases in contrary to its usual "portable assembly"
| character (without compiler optimization) - implicit type
| promotion in expressions with mixed data types, potential
| malloc() in printf(), possibility of Duff's device, and
| the likes. A Sun engineer Peter van der Linden has a book
| _Expert C Programming, Deep C Secrets_ that explores
| these topics.
| [deleted]
| flir wrote:
| > You check set membership with [?]
|
| Yeah, ok, I see what you mean.
|
| >> 0,2,4...10
|
| > (0 2 4 6 8 10)
|
| >> 1,2,4...10
|
| > (1 2 4 8)
|
| Wait... _what_? Is it looking the next number up in OEIS or
| something?
| anthk wrote:
| Damn, that made me laugh.
| kragen wrote:
| Unable to deduce arithmetic or geometric sequence from: 1,2,5
| Did you really mean '..'?
| flir wrote:
| > arithmetic or geometric
|
| See, that doesn't delight me. OEIS is what's needed here.
| nerdponx wrote:
| Maybe there's some way to extend the compiler to use
| OEIS. Is there a "liboeis" that lets you download and
| interact with the OEIS database offline?
| hwayne wrote:
| Welp now I know what "using it in anger" is gonna look
| like
| UncleOxidant wrote:
| Oh, the language formerly known as Perl 6. I thought I'd heard of
| it somewhere.
| chungy wrote:
| 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. :)
| gunapologist99 wrote:
| FTA: "The regex syntax isn't backwards compatible with Perl 5.
| For thirty years languages followed the PCRE "standard" and
| Perl 6 just... threw it all away."
|
| so it looks like the author has at least passing familiarity.
| hardburn wrote:
| Which also gives away some gaps in the author's knowledge.
|
| Perl wasn't following the PCRE standard. It _was_ the PCRE
| standard. Everything else was following it. Usually with some
| piece missing--far more implementations should have the /x
| modifier.
|
| The Perl 6 design process didn't throw it away after 30
| years. It threw it away with less than 10 years. There was
| already widespread knowledge that Perl had gone beyond
| "regular expressions", and IIRC, that was even before it had
| implemented recursive expressions. Perl 6 would be
| "patterns", and they would be good enough to be used as a
| full grammar. The language itself could be parsed in it, and
| Raku sometimes is, depending on the implementation.
| gunapologist99 wrote:
| > It was the PCRE standard
|
| haha true
|
| > The language itself could be parsed in it, and Raku
| sometimes is, depending on the implementation.
|
| That's fantastic, didn't realize.
| afiori wrote:
| > For thirty years languages followed the PCRE "standard"
|
| It says that (most) other languages followed the standard
| set by Perl 5, not that Perl followed the PCRE standard
| db48x wrote:
| Technically Perl 5 is parsable using Perl 5 regexes:
| https://www.youtube.com/watch?v=e1T7WbKox6s
|
| But it is also true that Raku's grammars were designed from
| the start to write real parsers in, whereas Perl 5's
| regexes sort of gradually got that way.
| gerikson wrote:
| The first footnote says that Raku was formerly known as Perl 6.
| zem wrote:
| pyret has kebab-case and infix subtraction too, but it has an
| easy time doing so because it made the decision that infix
| operators have to be surrounded by whitespace. i guess that
| wouldn't really be in keeping with raku's anything-goes
| philosophy though.
| no_wizard wrote:
| Raku is interesting as a language indeed.
|
| I can't get over some of the idioms, they just don't map nicely
| in my head. The same reason AppleScript struck me as weird, it
| trys to use natural language on one hand (e.g. `my`, `say`,
| `sub`, `gather`) with some oddities like `@` being used for
| (assuming?) scoped iterations or declaring modules[0] and some
| other from-an-outsider byzantine syntax decisions. For instance,
| I can logic this out, mostly, but it would not feel intuitive to
| me to "discover":
|
| ``` my @bottles = (flat ((99...2) X~ '
| bottles'), '1 bottle', 'no
| more bottles', '99 bottles'); my
| @actions = (flat 'Take one down and pass it around' xx 99,
| 'Go to the store and buy some more'); for flat
| @bottles Z @actions Z @bottles[1..*] { say "$^a of
| beer on the wall, $^a of beer. $^b, $^c of beer on the
| wall.\n".tc; }
|
| ```
|
| These idioms don't click for me intuitively. Its a very symbol
| heavy language and the symbols often appear to be overloaded by
| context.
|
| All to say, its okay! different languages isn't a bad thing,
| however I can't say that I'd use Raku even if it was the best fit
| for something, like say, a natural language parser (which based
| on all evidence Perl / Raku is really good at building parsers)
|
| [0]: https://examples.raku.org/categories/module-
| management/Fletc...
| BaseballPhysics wrote:
| Let me guess, you were never a Perl programmer? Trust me, if
| you have a Perl background, a lot of that syntax looks pretty
| familiar (the @ sigil in particular denotes an array).
| no_wizard wrote:
| Yes. Though that's my point, _to me_ it doesn 't feel the
| most welcoming to others who know another language (or
| languages).
|
| By all means though, if folks like it, carry on. I am sure
| Raku as a runtime is well engineered, I respect that.
|
| I don't know what lineage Raku shares other than Perl, but it
| seems to be on its own plane if you will, and thats cool.
| cassepipe wrote:
| I actually feel the same about bash
| Joker_vD wrote:
| I sometimes idly wondered what would a programming language look
| like if it were filled to the brims with syntactic sugar. Now I
| know. It has this "it's horrifying but in a weirdly enticing kind
| of way, I can't make myself look away, show me more, please" kind
| of feeling.
| justinator wrote:
| Wait until you learn about Raku's Grammars.
| devit wrote:
| It's just Perl 6 renamed.
| frou_dh wrote:
| When I was looking at the language, I didn't find the
| documentation "really poor". In fact I was impressed at how much
| of a one-stop-shop the official docs site was for both conceptual
| docs and API docs.
|
| https://docs.raku.org/
|
| Look at the following page as a jumping off point for conceptual
| stuff. Absolutely top class:
|
| https://docs.raku.org/language
| layer8 wrote:
| The Perl man pages were always excellent.
| pie_flavor wrote:
| My favorite feature of Raku: Integer division _and_ decimal
| literals both return `Rat`, a rational fraction type. Even though
| everyone knows floats suck, nobody is actually moving away from
| them except Raku. If you want a float literal you specifically
| have to use scientific notation.
| moonchild wrote:
| It's actually an awful misfeature, because those Rats will
| automatically turn into floats when the rational representation
| gets to big: > WHAT 1/10 (Rat) >
| WHAT 1/100000000000000000000 (Num)
|
| (There is FatRat, which does not so 'promote', but it is not
| the default.)
| cosmojg wrote:
| Ha, it's like best-effort typing. The interpreter gives you a
| precise rational if it can, and it throws you a float if it
| can't. I suppose that, in a language as dynamic as Raku, the
| idea is that you should never need to keep track of types
| anyhow, but this might be nicer if this value ends up being
| your user-facing output, depending on the application.
| moonchild wrote:
| There is no reason why it could not continue to use the
| exact representation and operations if it wished (and
| that's what FatRat does). It's just an ill-conceived
| concession to performance.
| kstrauser wrote:
| I'm not sure what I think about that. I know when to use
| decimal/rational types vs floats, but my own Python code has a
| whole lot more float() calls than Decimal()s. Floats are almost
| always what I want Unless I'm directly working with money.
| zelphirkalt wrote:
| Are they almost always what you want? Like, what kind of code
| do you work on? I personally find, that I need floats quite
| rarely and rationals usually are just fine, when I write
| Scheme. And when I write Python, floats also don't come up
| that often, except for in places where I would rather like to
| ha e exact numbers than inexact ones, als ways making me
| doubt, whether what I calculate here might have too big error
| in it.
| kstrauser wrote:
| It's mostly in calculating percentages, measuring timing,
| computing the interval to wait to satisfy a rate limit,
| that sort of thing. None of those require the extra
| overhead of an exact datatype in the contexts I'm using
| them.
| dragonwriter wrote:
| > My favorite feature of Raku: Integer division and decimal
| literals both return `Rat`, a rational fraction type. Even
| though everyone knows floats suck, nobody is actually moving
| away from them except Raku.
|
| Scheme's numeric tower has a handled exact expressions with
| exact representations correctly for decades, so I guess its
| true that is not "moving away from" unnecessary and error-prone
| use of inexact floats where not explicitly requested, but only
| because it was never there to move away from.
| db48x wrote:
| There are older languages just waiting for the people who
| dislike IEEE 754 floats to notice them too, like Common Lisp
| and Scheme. They have a numeric tower which includes both
| rational and complex rational numbers: > (+
| 5/3 4/5) 37/15 > (expt #C(0 1) 2) -1
| > (expt #C(3/2 1/2) 2) #C(2 3/2)
|
| And of course they all support arbitrary precision numbers as
| well: > (complex (fact 10) (fact 20))
| #C(3628800 2432902008176640000) > (/ (complex (fact 10)
| (fact 20)) 29) #C(3628800/29 2432902008176640000/29)
|
| Composition is a wonderful thing.
| unixhero wrote:
| I for one welcome our Raku wielding overlords.
| justinator wrote:
| There's literally dozens of them!
| beeslol wrote:
| > Raku has no qualms about using Unicode operators. You check set
| membership with [?]. There's also [?], [?], and [?].
|
| Something to note is that there are ASCII equivalents[0] for
| every cool Unicode operator found in Raku. For example, the
| equivalents for [?], [?], [?], [?] are (elem), !(elem), (cont),
| !(cont).
|
| [0]
| https://docs.raku.org/language/unicode_ascii#Other_acceptabl...
| sigzero wrote:
| I would definitely use the ASCII versions.
___________________________________________________________________
(page generated 2023-08-07 23:00 UTC)