138 points

On the other hand, I don’t think you should add those ever

permalink
report
reply
52 points

Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.

permalink
report
parent
reply
14 points

Agreed! Unfortunately these maddening behaviors were kind of set in stone several decades ago, and it has been (correctly) decided “Don’t break the web”, these weird quirks are kept in modern interpreters/compilers.

It’s actually quite interesting to read through the logic to follow when implementing an interpreter:

https://262.ecma-international.org/13.0/#sec-object.prototype.tostring

permalink
report
parent
reply
4 points
*

a sane language

JavaScript

Pick one.

permalink
report
parent
reply
1 point
*

I thought it was clear I was saying JavaScript is not a sane language for this very reason

permalink
report
parent
reply
1 point

What’s a sane, dynamically typed language?

permalink
report
parent
reply
3 points

I was trying to make a point without starting a flamewar that was beside the point. Personally I’d never choose a dynamically typed language for a production system. That being said, Python and Ruby complain if you try to add an array, dict/hashmap, string, or number to another (of a different type) so they’re certainly more sane than JavaScript.

permalink
report
parent
reply
1 point

Lisp?

permalink
report
parent
reply
46 points

Onfuscators probably use it though, so no spec ever will be able to get rid of this crap.

permalink
report
parent
reply
16 points

Can I vote for obsfuscators not holding a language hostage?

permalink
report
parent
reply
7 points

Best I can do is tie your pension to it.

permalink
report
parent
reply
2 points

Only if I can vote for sandwiches not falling apart when I eat them

permalink
report
parent
reply
118 points
*

Use TypeScript, and nonsensical things like adding arrays to objects will be compile-time errors.

permalink
report
reply
58 points
*

Yup. The libraries underneath will still allow nonsense at runtime, though, and it will now be harder to see, so it’s a partial solution as done in standard practice.

An all-TypeScript stack, if you could pull it off, would be the way to go.

permalink
report
parent
reply
22 points

Most libraries have TypeScript types these days, either bundled directly with the library (common with newer libraries), or as part of the DefinitelyTyped project.

permalink
report
parent
reply
11 points

DefinitelyTyped is the exact kind of thing I’m talking about. You put TypeScript definitions over things, but under the hood it’s still JavaScript and can fail in JavaScript ways.

permalink
report
parent
reply
20 points

So a strictly typed language… I think those already exist.

permalink
report
parent
reply
7 points

If there was an easy way to use rust or something on webassemly and use that instead of JS. I’d be so happy, but I can’t find how to do it without npm.

permalink
report
parent
reply
3 points

Yeah, ideally TypeScript would be natively supported. Or maybe just Python, which is sort-of strictly typed, and definitely won’t do “wat”. Alas, it’s not the world we live in, and browsers take JavaScript.

permalink
report
parent
reply
1 point

The libraries underneath will still allow nonsense at runtime

Only if you use a badly written library. Most libraries have types provided by DefinitelyTyped. Those who don’t are (in my experience) so tiny that you probably aren’t using them; or, if you really wanted, can check yourself.

In the end, if you encounter a bug, it’ still 99% of the time not a library’s fault, even if it’s written in plain JS.

permalink
report
parent
reply
1 point
*

Like I said to the other person, those are just types over top of JavaScript that can still fail if/when coercion happens under the hood.

I don’t even know how to search it now, but a specific example came up on here of a time when JavaScript libraries will cause problems, and problems you can’t even see very well if you’re expecting it to act strictly-typed.

permalink
report
parent
reply
9 points

By that logic what we really need is a modernization of Ada, where there are no compiler warnings and anything that would generate one in another language is instead a compiler error, everything is strongly typed, etc, etc.

If you aren’t familiar with Ada, just imagine Pascal went to military school.

permalink
report
parent
reply
5 points

Pascal went to military school.

I’m not in love with the idea, but a language that cuts out the BS has a sudden appeal when on a group/team project.

permalink
report
parent
reply
10 points

That analogy was chosen for a reason. Ada was originally developed by DOD committee and a French programming team to be a programming language for Defense projects between 1977 and 1983 that they were still using at least into the early 2000s. It’s based on Pascal.

It was intended for applications where reliability was the highest priority (above things like performance or ease of use) and one of the consequences of that is that there are no warnings - only compiler errors, and a lot of common bad practices that will be allowed to fly or maybe at worst generate a warning in other languages will themselves generate compiler errors. Do it right or don’t bother trying. No implicit typecasting, even something like 1 + 0.5 where it’s obvious what is intended is a compiler error because you are trying to add an integer to a real without explicitly converting either - you’re in extremely strongly-typed country here.

Libraries are split across two files, one is essentially the interfaces for the library and the other is it’s implementation (not that weird, and not that different than C/C++ header files though the code looks closer to Pascal interface and implementation sections put in separate files). The intent at the time being that different teams or different subcontractors might be building each module and by establishing a fixed interface up front and spelling out in great detail in documentation what each piece of that interface is supposed to do the actual implementation could be done separately and hypothetically have a predictable result.

permalink
report
parent
reply
97 points
permalink
report
reply
29 points

I come back to watch this every few years. It’s so good!

permalink
report
parent
reply
23 points

How do I know so little about programming yet this is still so funny?

Maybe the neuroscientists have some insight:

permalink
report
parent
reply
7 points

You can tell that they find the answers absurd and the WAT memes are universally funny.

permalink
report
parent
reply
-1 points

I’ve seen this guy referenced twice today. If only he knew how to write instead of giving talks…

permalink
report
parent
reply
40 points

Just wait until OP learns about cross product of matrices.

permalink
report
reply
10 points

mfw non-commutativeness

permalink
report
parent
reply
39 points
*

In node, I get the same result in both cases. "[object Object]"

It’s calling the toString() method on both of them, which in the array case is the same as calling .join(",") on the array. For an empty array, that results in an empty string added to "[object Object]" at either end in the respective case in the picture.

Not sure how we’d get 0 though. Anybody know an implementation that does that? Browsers do that maybe? Which way is spec compliant? Number([]) is 0, and I think maybe it’s in the spec that the algorithm for type coercion includes an initial attempt to convert to Number before falling back to toString()? I dunno, this is all off the top of my head.

permalink
report
reply
44 points
*

The inspector REPL evaluates as a statement-with-value (like eval), so the {} at the beginning is considered an empty block, not an object. This leaves +[], which is 0. I don’t know what would make Node differ, however.

Edit: Tested it myself. It seems Node prefers evaluating this as an expression when it can, but explicitly using eval gives the inspector behavior:

permalink
report
parent
reply
21 points

So there’s yet another level of quirkery to this bullshit then, it seems. 😆 Nice digging! 🤝

I also noticed that if you surround the curlies with parentheses, you get the same again:

> eval('{} + []')
0
> eval('({}) + []')
'[object Object]'
permalink
report
parent
reply
10 points

Yep, parentheses force {} to be interpreted as an expression rather than a block — same reason why IIFEs have !function instead of just function.

permalink
report
parent
reply

Programmer Humor

!programmer_humor@programming.dev

Create post

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

  • Keep content in english
  • No advertisements
  • Posts must be related to programming or programmer topics

Community stats

  • 9.1K

    Monthly active users

  • 842

    Posts

  • 32K

    Comments