A few of these are just a counterintuitive consequence of the floating-point standard (though JavaScript should always have natively supported more than floats). Most are a long-term price paid for the very temporary convenience of weak typing that was with JavaScript from the beginning. I definitely blame Perl 5 for the remainder of this crap not accounted for towards the beginning:
weak typing (not dynamic typing, weak typing in particular) is the fucking devil
Dynamic typing I can take or leave. I think maybe static with type inference is ideal (and apparently it can even work with operator overloading) but I still don't go to the extent of type hinting any of my Python code. But anyway yes weak typing is the devil barring a few principled exceptions. Ex: technically Python still uses strong typing for summing
bools which is useful for telling how many of an iterable meet some criterion or other but it has a weak typing "flavor".The funny thing is that stupid magic like this actually often makes things harder for beginners to understand. Just look at how many Docker users don't properly understand the distinction between containers and images because its convenience commands "helpfully" blur that distinction.
A lot of these aren't even a problem with implicit conversions per se, but rather a problem with allowing implicit conversions between unrelated types (
[]==0 should obviously be illegal in any sane language), greatly exacerbated by operator overloading (half the nonsense in the list would be eliminated if concatenation had its own distinct operator).= for numeric equality, == for string equality, === for object identity, + for numeric addition, ++ for union, || for string concatenation, ||| for list concatenation, etc.). I think they should have tightened it up a little more and allowed only conversions that can be performed in a single step, so that 5 + '321' would be an error instead of 128 (character set '321', canonically '123' -> string "123" -> integer 123), but on the whole it works well, even though I wish they allowed you to add optional type declarations instead of using comments.
I really like how lisp does comparisons, where you can relax/tighten them up as needed.
I see there is a book about using Unicon to write programming languages but it's published by Packt (which should be the name of a gay bar or gay bathhouse instead of a technical publisher). Is it any good? Do you know?
I would expand this to include languages that try to be "user friendly" with an "English-like syntax". SQL kind of gets away with it, but the innumerable army of other such languages are mostly in the dustbin of history, and for good reason. Trying to mirror people's hazy, imprecise ideas about things makes things more complicated for precise thinkers, and imprecise thinkers don't imprecisely think the same way, so they're going to get caught in the bullshit too.
COBOL is still quite alive and well
COBOL was actually the specific reason I said "mostly", but I thought it would burden the post too much to include. I probably could have changed "SQL gets away with it" to "COBOL and SQL get away with it" without dragging down the flow of the post too badly, but oh well.
What languages that are or were popular do you consider the biggest offenders here?
At some risk of revealing myself to be a fraud, I don't have an especially long list of well-known offenders (then again, this would be a list of languages that failed to get popular, so by definition I'm less likely to be aware of them.) I often notice "cute" DSLs and "scripting languages" that have this pattern, but I can't remember any offhand.
It's debatable, but to me this syntax feels "cute" in the wrong way. Operator overloading also gives people the opportunity to get "cute" with redefining operators in ways that are ergonomic to the author, and confusing to everyone else. Some "builder" patterns in the Java world also get "cute" like this. (What follows is not a real example; it's been a while since I've encountered this.)
List comprehension is a great feature, but the python version does feel pretty weird to use indeed.
I actually really like DSL's for many use cases. But yeah, trying to make it read like english usually goes wrong (Altough, if its instead encoding business rules into them it can be quite nice to work with. For example, with f# with computation expressions you can gain a lot of conciseness to express stuff like this
let processOrder () =
orderFlow {
TakeOrder
VerifyOrder
DispatchOrder
ErrorHandle errorfunc
}I'm thinking you would probably not like NetLogo or other forms of Logo:
There was a nigger, who came up with this idea:
cout << "Hello world" << endl;I tend to think the alternative to doing what Grace Hopper did with COBOL would look more like APL and I can't say I'd want that outcome
I forgot to put quotes, but I intended that second bullet point as a criticism of math people who impose their way of thinking onto the domain
They've been doing that since before people were writing code, CS has always been a type of applied mathematics
on the other hand "cute" in a nice way is overloading the
/ for filesystem::path in C++, i found that pretty amusing when i first saw it
Makes me think of some of the shenanigans the people contributing to the IOCCC get up to https://www.ioccc.org/index.html
// Are you there god??/
??=define _(please, help)
??=define _____(i,m, v,e,r,y) r%:%:m
??=define ____ _____(a,f,r,a,i,d)
main(__)<%____(!_(-~-??-((-~-??-!__<<-
??-!!__)<<-??-(!!__<<!!__))+-~-~-??--~-~
-~-~-~-~-??-(-~-~-~-~-??-!!__<<-~!!__),-
??-!__))<%??>%>_(__,___)??<____
(printf("please let me die??/r%d bottle%s"
" of bee%s""""??/n",(!(___
%-~-~!!___))?--__+!___++:__+!___++,!(__-!!___)
&&___%-~-~!!___??!??!!(___%-~-~!!___??!??!__
-(-~!!___))?"":"s",___%-~-??-!!___<-??-!!___?
"r on the wall":"eeeeeeer! Take one down,pass ??/
it around")&&__&&_(__,___),"mercy I'm in pain")??<??>??>
i would be very interested in knowing what the thought process of these language developers is because i would argue that it makes the code only harder to read with little to no benefit. even this argument of "but beginner programmers have it easier then" is flawed because beyond the first stage of having to learn what the various data types are, it only introduces more difficulties when you've to debug code that uses weak typing. maybe there's a good reason for that unbeknownst to me though.
Tbf, JS is kind of designed to never truly crash. It'd rather limp along with wrong data than crash.