palordrolap

You don’t know how to do something in raw JavaScript. You’re not even sure you should. You find a library / module / package / whatever-the-name-is-this-week on the Internet. You paste it into your code. Your code now works. Your code is now 1MB larger. This web app is heavy, man.

Wait until you learn that postfix conditionals are syntactic sugar and the compiler* turns that line into the equivalent of $debug and print(debug message), putting the conditional in first place, a lot like the ternary operator.

* Perl compiles to bytecode before running.

The ternary operator itself isn’t implemented in terms of and (and or) but it could be.

I think there’s a personality anti-correlation that keeps this mostly exclusive.

Serial killers tend to be more outgoing and active (to a troubling degree), whereas coders who create their own languages tend to be indoors types who don’t mind sitting in one place for long periods.

I mean there are plenty of psychologies that could make for someone who does both, but it would seem to reduce the odds a lot.

Ah. The usually implicit topical “this” didn’t even occur to me because I thought, er, this, was about objects. $_ isn’t used for those in Perl.

I suppose there might be some parallels with the implicit nature of $_ in non-OO contexts in Perl versus this in OO contexts in Javascript, but, at least to me, that feels pretty tenuous.

As at least one nautically themed childrens’ book surely has it: C is for crab.

Coming at programming sideways feels more like a Haskell or Prolog thing, though.

At the time JS was created, Perl didn’t have a this. A lot of the docs and books suggested using $self but a reference to the object would be passed as the first parameter to all class methods and you assign that to any name you wanted.

It’s only very recently (as in the last year or so) with a new class system that Perl has hard-coded $self for that purpose.

Not strictly true.

Perl’s default bitwise operators do differentiate between numbers and strings that look like numbers in a way that addition doesn’t*, and the readline/glob operator <> does different things depending on what (if anything) is between the signs.

There’s also the whole overload pragma for objects, which doesn’t affect default data types, but if you’re sufficiently perverse, you can define a String class that uses ‘+’ like JavaScript.

* in 2015, they added new operators so that those and the original operators don’t overload and have only one specific purpose if the bitwise pragma Edit: feature is turned on. You might know all this already though.

You’re right. I’ve got too much Perl on the brain and forgot my roots. There is a language that does what you’re talking about with the ‘+’ operator: BASIC

Good luck getting the same thing retrofitted into JavaScript though. I can imagine a large number of websites would break or develop mysterious problems if this (mis)behaviour was fixed.

Given it’s JavaScript, which was expressly designed to carry on regardless, I could see an argument for it returning NaN, (or silently doing what Perl does, like I mention in a different comment) but then there’d have to be an entirely different way of concatenating strings.

Perl is an old but notable exception. + is purely for addition in the base language.

If you try to add two strings with it, they’ll be converted to numbers based on any number-like characters they have at their left hand ends, and, if warnings are enabled (and you should definitely do that), you’ll get runtime warnings about it if there’s even anything vaguely non-numeric about them.

e.g. “1”+“11” will get you 12 with no complaint, warnings or otherwise. Not even the string “12” either, although it’s hard to determine one from the other in Perl. It’s a need-to-know kind of thing. And you generally don’t.

“a”+“bb” gives 0 as the result because they’re not numbers and “1a”+“11bb” will give 12, but these latter two will give warnings. Two each, in fact, one for each dodgy parameter.

String concatenation is done with the dot operator instead. “1”.“11” gives “111”. This comes with it’s own minor problems, but at least + is safe.

it commutes

Maybe the behaviour with regard to type conversion, but not for the operation itself.

“13”+12 and 12+“13” don’t yield the same result.

Reminds me of the company where one of the top brass tried to unmount an important fileshare with rm. That was the day they found out that they didn’t have recent backups of a, shall we say disquieting, amount of important information and people’s work.

Staff started taking their own private backups of important things after that.

My motherboard has two NVMe slots. I imagine that if I’d had the funds and desire to populate both of them, this same issue could rear its ugly head.

A lot of the original C coders are still alive or only very recently gone (retired, or the ultimate retirement, so to speak), and they carried their cramped coding style with them from those ancient and very cramped systems. Old habits die hard. And then there’s a whole generation who were self-taught or learned from the original coders and there’s a lot of bad habits, twisted thinking and carry-over there too.

(You should see some of my code. On second thought, it’s probably best you don’t.)

For writing loops, many early BASICs had FOR/NEXT, GOTO [line] and GOSUB [line] and literally nothing else due to space constraints. This begat much spaghetti. Better BASICs had (and have) better things like WHILE and WEND, named subroutines (what a concept!) and egads, no line numbers, which did away with much of that. Unless you were trying to convert a program written for one of the hamstrung dialects anyway, then all bets are off.

Assembly style often reflects the other languages people have learned first, or else it’s written to fit space constraints and then spaghettification can actually help with that. (Imagine how the creators of those BASICs crammed their dialect into an 8 or 16K ROM. And thus, like begetteth like.)

C code style follows similarly. It is barely concealed assembly anyway.

COBOL requires a certain kind of masochist to read and write. That’s not spaghetti, it’s Cthulhu’s tentacles. Run.

You jest, but on some older computers, all ones was the official truth value. Other values may also have been true in certain contexts, but that was the guaranteed one.

Depends if you go with the original idea, or the battery idea designed by Hollywood execs who didn’t think the audiences would understand.

… thus proving that Hollywood execs and the people they make their changes for are only good for batteries*, but I digress.

* For legal reasons, this is a joke. I have to say this because some Hollywood execs have more lawyers than braincells**.

** For all the same reasons, this is also a joke.

Oh, I guarantee that pi is 100% normal. Just not necessarily in the base you want it to be normal in.

Turkish has (and maybe related languages have) genderless pronouns, but I don’t know whether that context shifts elsewhere in the sentence structure or not, and how necessary it might be in legal contracts.

It’s a “joke” because it comes from an era when memory was at a premium and, for better or worse, the English-speaking world was at the forefront of technology.

The fact that English has an alphabet of length just shy of a power of two probably helped spur on technological advancement that would have otherwise quickly been bogged down in trying to represent all the necessary glyphs and squeeze them into available RAM.

… Or ROM for that matter. In the ROM, you’d need bit patterns or vector lists that describe each and every character and that’s necessarily an order of magnitude bigger than what’s needed to store a value per glyph. ROM is an order of magnitude cheaper, but those two orders of magnitude basically cancel out and you have a ROM that costs as much to make as the RAM.

And when you look at ASCII’s contemporary EBCDIC, you’ll realise what a marvel ASCII is by comparison. Things could have been much, much worse.