Hacker News Reader

Comment by laureny | Hacker News Reader

I'd say the latter is much more likely to be misspelled since you abbreviated it arbitrarily. It's easy to write it prodDB or proddb, or was is productionDb?

Using actual English names actually minimizes the risks of mistakes.

And of course, using a statically typed language makes all these concerns moot since the compiler won't let you make these mistakes in the first place.

View on HN

using a statically typed language makes all these concerns moot

No, you can make exactly the same bug with a static type system. Structurally typed records are just that – structurally typed. If you add an extra field you never use, the type system doesn't care. You need further static analysis to catch that.

(Beside, Erlang ships with a decent static analyzer.)

Depends on your brand of static typing.

In fact, Erlang's records are something like this. They are tuples under the hood (with a first element being atom name of record "type"), and pre-processor translates matching properties by name to matching tuple elements in proper position. So, you can't made typo in this scenario - the code won't compile.

I.e., you declare:

    -record(foo, {bar = ?default_bar, baz = ?default_baz}).

And every time you write #foo{bar = 1} you get {foo, 1, ?default_baz} under the hood. Obviously, records are unusable as general-purpose dictionaries as they have fixed structure.

One big inconvenience with records is the fact that you have to type record's name every single time you have to do anything with it. And writing MyFoo#foo.bar is cumbersome, compared to MyFoo.bar in most other languages.

Another issue is that records exist only before pre-processing. Even compiler is unaware of member names, let alone the runtime. This makes introspection and live code operations (by connecting a shell to a running instance) quite inconvenient.

It'll still yell at you for typos, though. You can confuse positional with nominal, but you can't make invalid nominal statements.

Which is not at all to say that Erlang's tuple/record trick is anything but a clever trick. It is kind of neat to see how far you can go with just that, though.

The number of times I've had to type element(3, Record) (or whatever ordinal) for a filter/map, after manually -counting- the fields in the head of a list of records, because I didn't have the source with the record definition handy to rr() in my shell...

The abbrevation is not arbitrary and instead is very conventional among programmers. An arbitrary abbrevation would have been "ProDaBa" but no one abbrevates like that. The casing is also standardized: ProdDB in Python, prodDB in Java and (i believe) ProdDb in C#. Though that is beside the point because you still have to decide which letters to capitalize whether the name is long or short.

In Python, I would use `prod_db` as a dictionary key and not a name that looks like a class name. That said, I do agree that some very common abbreviations are okay in some contexts.

Static typing does nothing for hashes/maps. That would only help with attributes on objects.

Right, but the example code would probably, in a staticly typed language, be implemented with an object rather than a map.

It certainly does if your keys are not strings but objects.

Reply on news.ycombinator.com