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

Raku: A language for gremlins

buttondown.email

Post reply on HN
Print view View original

181–190 of 257 posts

Re: Raku: A language for gremlins

#181

Post by giancarlostoro »

baq wrote: post #120
zukzuk wrote: post #27

Earlier quoted context omitted.

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.

I’ve been in some sort of web development since 2005 and am to this day surprised by just how much awful is packed in there. Most is deprecated - thank God and any other deities - but it’s still there lurking for newbies and unaware developers coming from sane languages.

Have you seen how people can write JavaScript within CSS yet? That's another fun one. :)

Re: Raku: A language for gremlins

#182

Post by Joker_vD »

CodesInChaos wrote: post #171
trealira wrote: post #82

Earlier quoted context omitted.

> The surprises are always the language's raw machinery showing through in unpleasant ways, and never a delightful bonus feature the designers added for you. I was reading "Writing Solid Code" by Steve Maguire (though it should really be called "how to write code in C without shooting yourself in the foot"). One thing that surprised me, but which made sense, was that pointers can overflow. It's unlikely, and ANSI non…

I'm not a C language lawyer, but I'd expect C to have a rule that calculating the one-past pointer will not overflow within an array object. So malloc would not be allowed to return such an allocation and this would be a bug in the caller, not in this function.

Yes, indeed it does. It's mostly ignored by most implementations but technically e.g. on architectures with 16-bit address space 0xFFFF isn't allowed to be part of an object (which makes 0x0000 an obvious choice for NULL).

Re: Raku: A language for gremlins

#183

Post by 2colours »

mst wrote: post #178
jsf01 wrote: post #163

This is a fascinating language! I am so curious: how does the “anything goes” matcher work? I struggle to imagine how one would implement that ~~ operator.

$lhs ~~ $rhs is mostly sugar for $rhs.ACCEPTS($lhs) and then method resolution (including multimethod handling, of course) figures out which ACCEPTS method to call and that does ... whatever the author of the type implemented. ('mostly' because ~~ actually aliases $lhs as $_ and passes $_ as the argument to ACCEPTS)

You probably know it well but let me elaborate a bit more "for the sake of the audience":

- the left handside is evaluated into a value (let's symbolize this value with $lhs) - this value is passed into the expression on the right handside as the $_ (topic) variable - the expression on the right handside gets evaluated, producing an $rhs value - now, $rhs.ACCEPTS($lhs) is called

The funky thing is that the right handside of this operator is an expression, not an evaluated value... it's like an invisible code block. The implementation calls this property of an operator "thunkiness", the expression on one side acting like a thunk rather than something that can be evaluated right away. This is akin to the short-circuiting behavior of && and ||.

Re: Raku: A language for gremlins

#184

Post by fuzztester »

eddd-ddde wrote: post #58
db48x wrote: post #45

Earlier quoted context omitted.

That’s exactly what you want in a language. It should always feel like cheating! Also debuggers. Give RR a try some time :)

I imagine you are referring to https://rr-project.org/ ? Had never heard of it, looks pretty amazing, I might actually enjoy debugging now!

Low contrast text site.

I know there are workarounds, but we shouldn't need them.

Re: Raku: A language for gremlins

#185

Post by throwanem »

fuzztester wrote: post #89
throwanem wrote: post #70

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.

>Good grief, I don't miss working in Perl. Good and grief in the same sentence about the same language ... Perl. Delighted and horrified? ;-)

Delighted that the screwing around I did in high school from a copy of the Camel Book my mom got me for my birthday gave me a skill I could parlay into a job that turned into a great career. Horrified once I finally got out into the industry proper and discovered all I'd been missing.

It's not that I regret ever having worked in Perl. It's just that I'm glad to have moved on to bigger and better things.

Re: Raku: A language for gremlins

#186

Post by nwellnhof »

librasteve wrote: post #159
moonchild wrote: post #46

Earlier quoted context omitted.

It's actually an awful misfeature, because those Rats will automatically turn into floats when the rational representation gets too big: > WHAT 1/10 (Rat) > WHAT 1/100000000000000000000 (Num) (There is FatRat, which does not so 'promote', but it is not the default.)

I disagree that graceful degradation from Rat to Num (ie double) when Real numbers over- or under-flow is a misfeature. We could (and have) debate whether FatRat should be the default, but imo the right expectation for an untyped language should be that very large or small numbers are represented with a floating point representation that (i) uses the FPU that's right there and (ii) sacrifices precision in the mantiss…

AFAIU, it's not only very large or small numbers that are affected, but any rational number with a denominator larger than 2*64. For most applications it's completely unpredictable when the switch to Num happens.

Re: Raku: A language for gremlins

#187

Post by lizmat »

nwellnhof wrote: post #186
librasteve wrote: post #159

Earlier quoted context omitted.

I disagree that graceful degradation from Rat to Num (ie double) when Real numbers over- or under-flow is a misfeature. We could (and have) debate whether FatRat should be the default, but imo the right expectation for an untyped language should be that very large or small numbers are represented with a floating point representation that (i) uses the FPU that's right there and (ii) sacrifices precision in the mantiss…

AFAIU, it's not only very large or small numbers that are affected, but any rational number with a denominator larger than 2*64. For most applications it's completely unpredictable when the switch to Num happens.

`INIT $RAT-OVERFLOW = CX::Warn` will produce a warning whenever a switch to Num happens.

`INIT $RAT-OVERFLOW = Exception` will throw an exception whenever a switch to Num would happen.

If you want to define your own behaviour, you can. For instance:

class ZeroOrInf { method UPGRADE-RAT(Int $nu, Int $de) { $nu > $de ?? Inf !! 0 } } INIT $*RAT-OVERFLOW = ZeroOrInf

would either convert the value to `Inf`if too large, or to `0` if too small.

Re: Raku: A language for gremlins

#188

Post by steelframe »

throwanem wrote: post #185
fuzztester wrote: post #89

Earlier quoted context omitted.

>Good grief, I don't miss working in Perl. Good and grief in the same sentence about the same language ... Perl. Delighted and horrified? ;-)

Delighted that the screwing around I did in high school from a copy of the Camel Book my mom got me for my birthday gave me a skill I could parlay into a job that turned into a great career. Horrified once I finally got out into the industry proper and discovered all I'd been missing. It's not that I regret ever having worked in Perl. It's just that I'm glad to have moved on to bigger and better things.

The Windows build still had plenty of Perl in it when I worked on Windows 8.

Re: Raku: A language for gremlins

#189

Post by Pet_Ant »

sigzero wrote: post #66
beeslol wrote: post #56

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

I would definitely use the ASCII versions.

Why? It's less readable. I like how JetBrains in recent releases renders ">=" as a single glyph. I mean maybe for typing, I see that as a benefit, but I'd hope my IDE would replace them with the proper Unicode character.

Re: Raku: A language for gremlins

#190

Post by Joker_vD »

trealira wrote: post #107
JonChesterfield wrote: post #102

Earlier quoted context omitted.

Linux kernel space on x64 uses "negative" pointer values so the high bits are set there. Which is probably the more interesting place to find this bug. Needs to be unsigned to get this failure mode, any signed loop gets compiled assuming no overflow for a different (though similar!) failure mode. I'm leaning towards "C is surprising". Didn't have to be but as presently implemented is very full of hazards.

> Needs to be unsigned to get this failure mode, any signed loop gets compiled assuming no overflow for a different (though similar!) failure mode. In C and C++, compilers will optimize assuming that signed integer overflow doesn't happen, but that doesn't stop it from actually happening. Unless you set it to trap on overflow, signed integers still wrap; it's just that compilers make (incorrect) optimizations assumin…

Do you mean unsigned branches? JB/JBE/JA/JAE instead of JL/JLE/JG/JGE? Are there actually code patterns where it's preferable to just JE/JNE? AFAIK, computing a pointer outside of the underlying array's boundaries (except for computing the one-past-the-last-element pointer) is UB so e.g.

    for (SomeStruct * curr = p, * end = &p[N]; curr
is an invalid optimization of

    for (SomeStruct * curr = p, * end = &p[N]; curr != end; ) {
        // processing the pair of curr[0] and curr[1], with care
        // in case when curr[1] doesn't exist

        if (++curr != end) { ++curr; }
    }
Post reply on HN