Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I spent much of a week debugging an issue in a Clojure multiplayer game where the same action was being handled differently on different machines. Somehow, the "true" branch of an if-statement was being taken even though the condition was "false."

The reason? When the action was sent over the network, the boolean was converted to a Boolean.

On the same project, I would also frequently suffer from name-typoes -- in structure keys (deftype and defrecord didn't exist yet).

A dynamically-typed language is still dynamically typed. A lot of basic analyses are still undecidable. Lexical scoping doesn't fix that.



Yes, it's definitely by degrees. Some dynamic languages provide a great deal more help than others for common issues listed in the original article. And using the print-str and read-string (with read-eval off) is a fantastic way to serialize data between Clojure processes.


When the action was sent over the network, the boolean was converted to a Boolean.

That sounds more like an impedance mismatch between Clojure and its underlying platform.


And yet strong typing would have identified the issue immediately.


How do you know that? Programs in statically typed languages can still have bugs reconstituting objects serialized over a network.


In a statically-typed language, I couldn't have used a Boolean as the condition of an if-statement.


I like the point. And not being able to use if(0) (as in C) has caught tons of bugs (like writing "if(x=0)" instead of "if(x==0)"). There are ton of things that sounded convenient in the early history of programming languages that are really anti-patterns.

For example:

  Confusing ints with booleans.
  Confusing ints with pointers (no longer done, thank goodness).
  allowing assignments to have a non-void type ("x=1.0" should be of type void, not type double).
  Poor choice of assignment and test equals (would be nice not to use "=" but to force ":=" and "==").
  Pverly aggressive type coercion and autoboxing.
  Integer division using the same symbol as floating point (many end-users want 5/2 to be 2.5 as the answer, mostly you want it to be 3 if you are doing loop-foo).
  Making "else if" and if-braces mere convention.
  Allowing null way too many places.
  Automatic variable decleration.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: