81–90 of 257 posts
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.
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…
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-compliant, but something possible nonetheless. Hence, Maguire said that this code:
void *memchr(void *pv, unsigned char ch, size_t size)
{
unsigned char *pch = (unsigned char *)pv;
unsigned char *pchEnd = pch + size;
while (pch "What range of memory would memchr search when pv points to the last 72 bytes of memory and size is also 72? If you said 'all of memory, over and over,' you're right. Those versions of memchr go into an infinite loop because they use a risky language idiom—and Risk wins."
So, he said that that code should be replaced with this code:
void *memchr(void *pv, unsigned char ch, size_t size)
{
unsigned char *pch = (unsigned char *)pv;
while (size-- > 0)
{
if (*pch == ch)
return (pch);
pch++;
}
return (NULL);
}
Earlier quoted context omitted.
Unable to deduce arithmetic or geometric sequence from: 1,2,5 Did you really mean '..'?
> arithmetic or geometric See, that doesn't delight me. OEIS is what's needed here.
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…
I'm very interested in bottom right langs.
I’m in a desparate need of a message from Captain Obvious right now. I know nothing about perl
Earlier quoted context omitted.
> arithmetic or geometric See, that doesn't delight me. OEIS is what's needed here.
Do you want it to take the first match? Inputting a unique prefix doesn't sound practical.
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.
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. :)
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.
Earlier quoted context omitted.
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.
Then a 3d chart with "likelihood of" being a point or region in the space. The axises would then be "Surprise", "Delight", and "Horrify".
The problem with Perl (or, I assume, Raku) in production is that the responsible way to read it is like reading every single footnote in an annotated edition of Shakespeare. It sucks the joy out of it, and joy is the point. Production Perl is joyless and therefore pointless, unless you're some kind of prodigy who understands every obscure political reference and every 16th century pun without any help.
Earlier quoted context omitted.
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.
Apparently by replacing them with new horrifying surprises, if this article is any indication. Good grief, I don't miss working in Perl.
Good and grief in the same sentence about the same language ... Perl.
Delighted and horrified?
;-)
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…
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.