101–110 of 257 posts
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.
Earlier quoted context omitted.
Gone through a whole range of emotions looking at this. Tried to put together an argument about the high bits of (common) address spaces being zero and therefore it's safe but I don't think that works. It's the while (i++ < UINT32_MAX) bug in different clothing. Would make for a cruel take on the interview question of "tell me what bugs you see in this function".
>Tried to put together an argument about the high bits of (common) address spaces being zero and therefore it's safe but I don't think that works. Yep; on AMD64, bits 48 through 63 must be identical to bit 47, which can be 1 or 0, akin to sign extension. In practice, I don't think any sane OS would let you reserve the very last n bytes of memory, especially not with an address space as large as that of AMD64, but you…
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.
Earlier quoted context omitted.
You can definitely get there with C but the language isn’t actively pushing you into horror.
It doesn't actively push you there, which is why it's on the bottom half. There is a fairly coherent mental model for C and once you have it, the language rarely surprises you. But when it does surprise you, it's almost never anything good. Stuff like Duff's device, `3[someArray] = value`, etc. The surprises are always the language's raw machinery showing through in unpleasant ways, and never a delightful bonus featu…
Not always. It's rare, but eg `o[objects].up[objects].t[textures]` was definitely a delightful bonus feature (where `objects` and `textures` are global arrays).
Earlier quoted context omitted.
As long as the negative sides of both axes are included too. e | | | -r ------------- r | | | -e
Filling in language names is left as a fun exercise for the reader .
(Don't kill me fanatics)
> Raku has no qualms about using Unicode operators.
You have the option. I have used this option because I want my code to be compact and expressive on screen. A good fit for careful, considered, creative unicode usage.
Or the ever popular (Jeez that's new):
> I hate the sigil thing
For me I have been using Raku/ Perl 6 because I loved the expressiveness of Perl's swiss army chainsaw. Raku is Perl to the power of Perl. It's cleaned up. It's expressive. Some massive piles of features have been built up from the good old Perl. It's great. The documentation is good - and does need some continuing work. (The comparison with Perl is tough. Perl documentation was/is just amazing.)
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 c…
I actually feel the same about bash
Earlier quoted context omitted.
>Tried to put together an argument about the high bits of (common) address spaces being zero and therefore it's safe but I don't think that works. Yep; on AMD64, bits 48 through 63 must be identical to bit 47, which can be 1 or 0, akin to sign extension. In practice, I don't think any sane OS would let you reserve the very last n bytes of memory, especially not with an address space as large as that of AMD64, but you…
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.
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 assuming that it doesn't happen.
You know, this makes me wonder whether it's better pointers to be compared with signed or unsigned comparisons. Currently, my compiler emits unsigned comparison instructions for them.
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…
Should this be a fundamental lesson for language designers? Should languages come with a converter to switch back and forth between the "calm, proper english version" and the "compact, expert mode" visual?
(Without mentioning the translated programming languages like BASIC in french and such things which were discussed on HN not long ago.)