Live data from Hacker News

Raku: A language for gremlins

buttondown.email

191–200 of 257 posts

Re: Raku: A language for gremlins

#191

Earlier quoted context omitted.

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.

Given all I've heard of the Windows build process, I think this is much more an argument in support than in opposition.

Re: Raku: A language for gremlins

#192

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

Pedantry incoming- one of my greatest pet peeves is when some words in a list, or diagram, are in their adjectival form and some are in their verbal form. "Surprising" + "horrify" It really unnerves me. The worst is that nearly every company has this in some form in their promotional or educational materials. E.g. here at Genericorp, we prioritize the following valurs : integrity, kindness, honest, Etc You get my poi…

The grammatical term for this is - perhaps surprisingly, for this crowd - "parallelism".

Re: Raku: A language for gremlins

#193

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…

Rational numbers do not overflow or underflow. The only reason for having a type with this degenerate behaviour is to screw over the unsuspecting user who expects the language to protect them because they saw it using rational number representations in some contexts.

Re: Raku: A language for gremlins

#194

Earlier quoted context omitted.

> 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 != en…

> Do you mean unsigned branches? JB/JBE/JA/JAE instead of JL/JLE/JG/JGE?

Yeah, that's what I meant. Thanks for speaking more clearly.

> Are there actually code patterns where it's preferable to just JE/JNE?

That's a good point, and sidesteps the issue of pointer signedness.

I think sometimes JE / JNE isn't enough. For example, if you want to process a buffer in reverse order using pointer arithmetic:

  /* p starts off one past the end of the buffer */
  char *p = buffer + bufsize;
  while (--p >= buffer) {
      /* ... */
  }
I'm not sure if this would technically be undefined behavior, though, as the C standard only explicitly permits computing a pointer one past the end of the array, and other out-of-bounds computations are undefined, IIRC. In practice, I don't think any compiler would miscompile this.

Re: Raku: A language for gremlins

#195

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.

Nearly, the docs say "To prevent the numerator and denominator from becoming pathologically large, the denominator is limited to 64 bit storage." (https://docs.raku.org/type/Rat)

Please bear in mind that in raku (like perl and other untyped scripting languages) it is normal to say:

my $x = 1; say 1 + $x; #2 say 'a' ~ $x; #'a1'

My point is that when the type is automatically inferred/coerced like this, is is very natural that small/whole Numerics are Int, that medium/fractional/decimal Numerics are Rat and that large/exponential Numerics are Num (ie double). And that you can freely perform maths operations mixing the various Numeric types at will.

my $y = 1; say 1 + $y; #2 Int say 1.1 + $y; #2.1 Rat say 1e27 + $y; #1e27 Num

And, in raku, if you want to control the type, then just use the type system like this.

my FatRat $r;

I also think from a 2nd order point of view that a denominator of 2*64 means you are dealing with quite a small number 5e-20 ish), although admittedly that is a matter of taste and machine performance. It makes most sense in my view to go with Rat (which is stored as an Int (uint64) for the numerator and an Int for the numerator.

That way (i) you get to use all those transistors that you bought for your FPU and (ii) you do not get a surprise as Rat operations perform slowly without warning.

--- And yes - @lizmat has pointed out the various pragmas to let you control the behaviour you want if you disagree.

Re: Raku: A language for gremlins

#196
post #61

Earlier quoted context omitted.

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.

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.

and yet, raku is the first serious attempt to unify Int-Rat-Num-Complex types into a cooperative Numeric space --- which I think is a good design given its untyped default approach

Re: Raku: A language for gremlins

#197
post #79

Earlier quoted context omitted.

>Let's face it, the Perl 5/PCRE regex syntax is atrocious. Agreed, but god-damn is it useful.

Raku’s new grammar syntax is much less awful and just as amazingly useful.

That's cool that's cool, but the problem is getting people to use Raku.

Re: Raku: A language for gremlins

#198

Earlier quoted context omitted.

I'm very interested in bottom right langs.

Languages where there has been significant modernization and progress, but where codebases and online resources lag behind: CMake, PHP, CSS

Nothing can redeem CMake and CSS in my eyes. To me they fit perfectly in the bottom right, unsurprising horror.

PHP is often just bland drudge, true horror in PHP land is unexpected when I encounter it.

Re: Raku: A language for gremlins

#199
post #59

Earlier quoted context omitted.

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!

Yes, awful. It takes a crack in the wall and drives a bus through it, at a significant penalty to readability. The compatibility advantage doesn't matter when you're evaluating syntax in a vacuum.

Not everything has to be super easy-to-use.

Re: Raku: A language for gremlins

#200

Earlier quoted context omitted.

Yes, awful. It takes a crack in the wall and drives a bus through it, at a significant penalty to readability. The compatibility advantage doesn't matter when you're evaluating syntax in a vacuum.

Not everything has to be super easy-to-use.

Nobody is suggesting super easy to use.

But sometimes interfaces could be easier with no loss of ability, because they grew over time and nobody ever fixed them.

Post reply on HN