Create account

DEV Community

Meme Monday

Ben Halpern on March 10, 2025

Meme Monday!

Today's cover image comes from last week's thread.

DEV is an inclusive space! Humor in poor taste will be downvoted by mods.

fmerian • Mar 10

Anna Villarreal • Mar 13

Found on fb

webbureaucrat • Mar 18

Okay, I'll bite: There's a gamified code platform? What's it called?

Anna Villarreal • Mar 18

Ruby on Rails?

XD ~ not exactly gamified. but its a fun twist. You do sort of 'collect' gems and they sort of do give you 'powers' LOL

Reid Burton • Mar 20

Tynker, maybe Scratch?

Tylish Anup • Mar 18

Haha

Ivan Isaac • Mar 10

fmerian • May 2

they should have used trunk-based development

Sherry Day • Mar 10

Besworks • Mar 11 • Edited

Next suggestions...

public Button LefteyButton;
public Button LooseyButton;

Fred Functional • Mar 10

George Johnson • Mar 17

After 35 years you feel like a aged guitarist shredding riffs when you fire up vi and muscle memory kicks in! ha ha!

Ben Halpern • Mar 10

Let's kick things off with this week's awful AI-generated meme — this time featuring a pretend copyright notice in the bottom left — which is kind of rich considering the situation.

Besworks • Mar 11 • Edited

I actually had a good experience writing unit tests with copilot today. Seems I make that face more when I don't include tests.

Besworks • Mar 11

HB_the_Pencil • Mar 11

On gomfest and f fomfe :P

Julieana Andrade • Mar 12

lmao

Von Carter Griffen • Mar 10

Besworks • Mar 10

Charles Brown • Mar 10

Richard Mirks • Mar 10

Fyodor • Mar 11

Spot on, those youtube ninjas 🤣

Aaron Gibbs • Mar 10

1Link.Fun • Mar 11

true true true

Sawyer Wolfe • Mar 10

Shakhzhakhan Maxudbek • Mar 11

True story

Ansil Graves • Mar 10

Jessica Brown • Mar 10

Parker Waiters • Mar 10

Schemetastic (Rodrigo) • Mar 11

It's today! Thanks for the reminder, Hahahaha

BBM • Mar 10

Safin Ahmed • Mar 12

😆😆😆

Galloway Developer • Mar 10

Ethan Anderson • Mar 10

Ben Sinclair • Mar 10

Ok, that got a chuckle out of me.

Dream • Mar 10

BernerT • Mar 10

𒎏Wii 🏳️‍⚧️ • Mar 11

JavaScript is basically just Lua with random poor design decisions sprinkled in everywhere.

Besworks • Mar 11

It's not so much that (all) the decisions were poor at the time, but because of the nature of the web, we're stuck with them even when newer better methods are added to supersede the bad ones.

𒎏Wii 🏳️‍⚧️ • Mar 12

No, I think the decision that objects (including arrays!) can only have string keys was a fundamentally bad one, regardless of when it was made. Of course this could have been reversed if it weren't for backwards compatibility, but that's no excuse for making the language like that in the first place.

There's many such cases where JavaScript just does things in very sub-optimal ways.

Besworks • Mar 12 • Edited

What you want is Map. With it you can use any object or primitive as a key.

const scores = new Map();
const user = { name: 'Alice' };
scores.set(user, 10);
scores.has(user);
scores.get(user);
scores.delete(user);

𒎏Wii 🏳️‍⚧️ • Mar 12

Language flaws cannot be fixed with standard library extensions.

Besworks • Mar 12 • Edited

Are you writing JS for internet explorer 6 or something? These standard library extensions are WIDELY available. Map has existed for over 10 years. Languages evolve over time. When I started writing code we had to save it on cassette tape. You can still do that now if you choose but why would you? It's all about using the right tools for the job.

𒎏Wii 🏳️‍⚧️ • Mar 12

I am not talking about availability. Standard library extensions, regardless of ubiquity, will categorically never be a perfect fix for language design problems.

Maps will never replace objects, nor are they supposed to. They very likely won't get a dedicated syntax comparable to objects. They aren't even compatible with JSON, JS' de facto native format for data serialization.

The only way to fix the flaws with JS Objects would break compatibility and thus break the web.

Besworks • Mar 12 • Edited

But... how would you expect to serialize something that is passed by reference?

const a = { x : 'test' };
const b = { x : 'test' };
const c = { x : 'test' };
const m new Map();
map.set(a, true);
map.set(b, false);
map.has(c); // return false
map.has({ x : 'test' }); //  also false
// only the original reference works.
// and we can change the object
// while maintaining our ref in the table
a.x = 'changed';
map.has(a); // this is true!

In the example above, a,b and c all look equal but are not. You can't easily serialize into JSON without extra hackery to "preserve" the uniqueness of the original key but you would lose the references that make this association useful in the first place. I can't find any lang that directly allows serialization of objects as keys.

Python: dict serialization (pickle/json) doesn't handle object keys
Ruby: Hash serialization (Marshal/JSON) doesn't handle object keys
Java: HashMap serialization requires custom Serializable implementation
C#: Dictionary serialization doesn't handle object references as keys
Rust: HashMap serialization via serde requires explicit key types
Go: map serialization requires comparable key types

And NONE of these languages directly allow objects as keys on an object primitive. In Lua you can use any object directly as a key in a table but you lose the reference and the key becomes a clone of your original object (which, btw you have the option to do this in js as well). The problem here is not JS handling of object primitives, but rather how they are often abused to hold data that should be in a collection.

Lua's "everything is a table" design is actually less specialized/optimized than js's purpose-built data structures. JS arrays are true arrays (contiguous memory blocks), Lua arrays are just tables with integer keys. In js, Maps provide all the flexibility of Lua tables plus reference integrity and Arrays provide the speed of direct memory access.

𒎏Wii 🏳️‍⚧️ • Mar 14

Lua you can use any object directly as a key in a table but you lose the reference and the key becomes a clone of your original object

Only when you want to serialize your table though, which is a very reasonable limitation.

Lua, just like early JS, isn't an object-oriented language, so this is the reasonable choice. For an object-oriented example, see Ruby: it also separates objects from hashes, but its {key: value} syntax creates a new hash, rather than an object. Nobody uses objects with dynamic attributes as associative data structures in Ruby, because the syntax makes that more inconvenient. JavaScript, meanwhile, makes this the obvious way of writing code.

In terms of library, JS and Ruby are the same here: both have a Map class that is available by default and on its own behaves like any object. The fact that JS has a problem and Ruby doesn't shows that the design of the language is significant. Syntax matters.

I also want to point out that this is far from the only problem with JS as a language, it's just one example that nicely illustrates the differences.

Also, going back to serialisation, serialising maps in JS is trivial. Reject non-string keys and serialise maps as JSON objects. You won't get around the limitations of the language, but this is normal. Lua tables or Ruby hashes can't be serialised to JSON either. Neither can JS objects. This is simply a consequence of a simple serialisation format.

Lua's "everything is a table" design is actually less specialized/optimized than js's purpose-built data structures. JS arrays are true arrays (contiguous memory blocks), Lua arrays are just tables with integer keys. In js, Maps provide all the flexibility of Lua tables plus reference integrity and Arrays provide the speed of direct memory access.

None of what you said here is correct. Do you even actually know Lua or javascript?

Lua doesn't have arrays. It has sequences.
JavaScript "Arrays" are objects with string keys representing numbers
Lua tables are usually implemented with a hash part and an array part, meaning sequences are almost always stored in memory as arrays.
JavaScript VMs do the same, while having to maintain the illusion of string keys, meaning more overhead
Lua tables are more powerful than Maps: They can be meta-programmed, they have syntax sugar for method calls, they can have weak keys or weak values, can store sequences more effectively, etc.

Besworks • Mar 14

I actually do not know much about Lua, I may have misinterpreted some of the documentation I read. But I have been writing js since 1995, so yes, I know a thing or two about it. It wasn't my intention to bash Lua, just defend js.

Of course arrays are objects in js, as with pretty much everything. But this object just wraps an API around something very close to a raw array which does use contiguous blocks of memory. But you say...

Lua tables are usually implemented with a hash part and an array part, meaning sequences are almost always stored in memory as arrays.

...so it sounds to me like they behave pretty much the same. Personally, I don't worry about the marginal overhead that comes with js data structures though. I write optimized, efficient code that makes this issue trivial. I can't argue that js is without problems but it really depends on how you use it.

𒎏Wii 🏳️‍⚧️ • Mar 14

The point is that neither language has true arrays, and in either case it is up to the implementation to "optimise" lists into actual arrays in the memory. So the comparison just falls on its face immediately.

so it sounds to me like they behave pretty much the same

In the ways we've discussed, yes; but JavaScript arrays come with their own example of poor design, and that's that even if internally they are stored as arrays as a VM optimisation, to the programmer they still maintain the semantics of using string indices rather than actual numbers.

In practice this is rarely a big issue, but it sometimes still shows in cases like a for ... in loop, which loops over a series of strings. It's an easy source of confusion that just didn't have to be in the language if arrays were specified differently.