Hacker News Reader

Comment by andrewmcwatters | Hacker News Reader

My favorite feature of Lua is that it tells you who all of the complexity-loving people in the room are and those who enjoy syntax monocultures.

Almost every single time, without failure.

I consider its simplicity and the fact that people merely complain about its syntax as highlights of an extremely thoughtful piece of software.

I have complaints about its use for threaded work as well as performance, but it’s relatively hard to run into issues with the language in regular practice.

I don’t buy the lack of types argument in any programming language to be a compelling argument. Maybe consider that you or other authors you’re working with are bad at writing software. It’s a more boring conclusion and more often more accurate.

View on HN

>I don’t buy the lack of types argument in any programming language to be a compelling argument. Maybe consider that you or other authors you’re working with are bad at writing software.

I don't buy the lack of seatbelts argument in any car to be a compelling argument. Maybe consider that you or other drivers you're driving nearby are bad at driving.

Types are more like that annoying chime that beeps when you have the door open.

I think this is only true for a language like Python, or TypeScript, where types are second class citizens…

For me, using types in Swift is sort of like “NOS” in that it’s helped me go faster (and further”!

I still find typing in Python and TypeScript hugely beneficial, even just for how it makes my editor work better. Being able to click to a definition does wonders for reading unfamiliar code

definition

In python, go and C maybe, but in typescript? People tend to kungfu-type their APIs way too much where healthy repetition would suffice.

I believe ts typing power will eventually become “considered harmful”. I also think that ts should have a way to intertwine types as it does now, but leave that to technical part of dts and give a way to declare that by <that gibberish> you meant <this clear interface>.

Typescript types are really powerful imo. I didn't do much js but I was always amazed at how library authors can just "make everything click" with them.

Remind me a bit of Rust's type system.

> I don't buy the lack of seatbelts argument in any car to be a compelling argument. Maybe consider that you or other drivers you're driving nearby are bad at driving.

Types are a good idea of many languages, but not a universally good idea.

I love your seatbelt analogy. Since seabelts are a good feature of cars, this does not mean at all that they would be a good feature for sailboats. Or for bicycles. In fact, they would be a terrible and very dangerous feature!

I like your take, though I think the analogy is more accurately applied as -- if you need lifejackets you are a bad sailor, or if you need a bicycle helmet you are a bad rider

Of course!

And if you happen to want lifejackets and seatbelts on your bicycle, then everybody will be safe to assume that you are an exceptionally bad rider.

Same thing for wanting types on languages where they are not needed.

The whole derive arguments is a ease of access gimick, with a heavy payment later in the game.

This is why lua is in beginner sandboxes like robblox, which then will later turn into jaded developers, yearning for types.

Seatbelts don't impede my ability to drive (having to constantly manage the car keeps me in the seat). Types _do_ impede my ability to write code: I have to write more of it.

Types can certainly help prevent something from going wrong, but they're not a zero programmer time cost safety feature.

OP worded it aggressively, but if someone can't see how others benefit from lower overhead, they should look closer.

> Maybe consider that you or other authors you’re working with are bad at writing software.

OK, I've considered it. Now what?

(I don't use typed programming languages, I just want to call out this kind of rhetoric.)

Yes! Totally agree.

Completely happy to accept that I'm a horrible developer. But that doesn't really solve any of my issues.

(I have absolutely no issues with Lua btw)

Like many Lua developers, I have an extended table library containing the following functions: `clone1`, which is a fast, jittable implementation of a shallow clone from the openResty fork, `clone(tab, depth)` which defaults to one and performs a shallow clone to `depth` which will unroll cycles, `cloneinstance` which recursively clones everything with cycle detection, but gives copies the same metatable as their original, and `deepclone`, which will also clone metatables. `clonearray` could exist but I haven't found a frequent need for it.

Hence the reason cloning is a library function rather than core: when you have only one data structure, there are a lot of ways to copy it, and that's before getting into the various ways that metamethods can override the default behaviors of a table. Do you want to clone every pair in the table, or do you want to clone only the ones returned by `pairs`, which has a metamethod which can override the default behavior?

There are a dozen decisions like this to make.

Congratulations! "syntax monocultures" is now a Googlewhack! https://www.google.com/search?q=%22syntax+monocultures%22

Hah! Thanks for that.

>Maybe consider that you or other authors you’re working with are bad at writing software.

You are making the classic mistake of thinking you aren't also just as bad as everyone else. Chances are you are just as bad or worse.

Taking advantage of tools that make mistakes less likely and accepting that you suck just as much as everyone else are requirements for being good at writing software I think (this applies to anything really).

Learning it recently for a small game design, I was surprised that you couldnt easily copy a table, and even more suprised you needed "metatables" to do it...the extra steps seem far from simple.

Maybe I'm just missing something. If I recall, I was simply trying to create a new 'object' (game character) from a template but it required metatable boiler plate that just made no sense to me.

Many languages, this is simply a = b, or at most allocating some space first.

You might find it handy to add lua-enumerable.lua to your standard set of Lua-project modules:

https://github.com/mikelovesrobots/lua-enumerable/blob/maste...

See: table.dup()

NOTE: Doesn't copy metamethods, doesn't copy subtables either.

In many scripting languages this is not the case, and you are ever only passing around references. Python comes to mind.

Lots of people obviously have a problem with this as it deeply different from the algebra derived assignment syntax.

local a = b creates a local copy, but even then, its not a deepcopy, containing references to other tables.

python has both .copy() methods and a copy module. That's not to highlight Python's strengths, but an indication that it's a complex topic in Python - it has footguns here. The copy module might even do the wrong thing for a given object.

The algebra-derived assignment syntax kind of falls apart with mutation anyway.

>I was surprised that you couldn't easily copy a table

Lua's designers have a sort of maxim "if it can't be done perfectly, let the user roll their own". This can be frustrating, but for table-copying it's not surprising. Do you copy subtables by reference or value? What about recursive tables? Mutually recursive subtables? Closures in tables? And then userdata can contain references that are opaque to the language runtime. It's not easy to define the behavior of deep copy in the fully general case.

Types are bicycles for the mouse.

Reply on news.ycombinator.com