Hacker News Reader

Comment by dunefox | Hacker News Reader

> The idea of immutable variables always struck me as oxymoronic

It is, they're called constants.

That's a bad choice of name from one or more old languages that misused established mathematical terminology (e.g. C misuses void, constant and variable). An immutable variable (or in maths, just "variable') has a value that is unknown at build time but is constant at runtime. A constant has a known value at build time.

What nearly every language calls a variable today, is probably better described as a "reference" or "assignable", but sadly that ship has sailed and we'll forever be inconsistent with the math terminology for that one. Immutable variable is therefore a useful synonym for "proper variable".

It's variable in the mathematical sense, not the memory machine sense.

f(x) <= x is a variable, but once you picked a value for x you have no means to 'modify' it. Mathematicians seem to frown upon that for consistency reasons and instead will define a new variable name for a derived information from x current value.

ps: I'm not sure how true it is, but there was a picture of Ada Lovelace writings saying that Babbage computing machine caused troubles because you couldn't keep track of the value of a gear/variable which made design on paper very error prone

I like "(name) binding"

Bad choice or no, the language is appropriate... Constants should remain constant at runtime. Variables should be allowed to vary. I don't see why people think immutable strings is a good idea, for example. How do you ever build a text editor, if the strings can't be edited?

The language and notation is inconsistent with hundreds of years of use in maths and confusing for kids learning both maths and programming (at least it confused me).

Regarding your skeptism of immutable data structures, it's best to think of immutable data and data structures as copy-on-write instead of update-in-place. This is a technique that is currently very underused, for example most programming languages do not come with "persistent" copy-on-write collections.

Here is an example text editor built using immutable data structures in C++: https://github.com/arximboldi/ewig

Advantages are excellent support for concurrency (background save works while you edit) and trivial support for undo/redo.

I tried diving into the source code, and immediately ran into something new :: everywhere and starting googling....

Namespaces?!? - Looks like a solution in search of a problem. The whole point of object oriented programming was to prevent reaching inside of objects from the outside, thus making then implementation independent from use... Namespaces seem to break that. Like leaving the cover off a machine so that you can push on one of the relay contacts by hand.

C, C#, C++ feel to me like Greek all sorts of keywords that make no sense, and random !@#$%^&*():"<>?[] everywhere

Somewhere at the top of all that code, there has to at least be one actual pointer variable where you keep track of the last revision, isn't there?

There is a difference between "real constants", like the value of pi, and "runtime constants or almost-constants", such as "liftoff time" in software that runs onboard a rocket going to space. While preparing for launch, the latter value may be changed, but once the vehicle is on its way, it becomes a constant until the end of mission.

It would be nice to protect such variable from modification, "lock its value" somehow.

Well, OO folks would say : Enapsulate it in a class which contains a check for lift off and a value change method.

I would say "yes it's nice, but it's also complex and you are just as likely to inject a bug by doing this as you are to prevent a failure". (although for this example I think it isn't a bad idea really)

I have no idea what the heck is going on with objects in C++, it makes no sense to me. The model in Delphi/Lazarus/Free Pascal has always seemed quite natural to me since I first encountered it.

Reply on news.ycombinator.com