4 ms·
For me a big thing is avoiding error prone inconsistencies and other footguns. The less footguns a language has, the better. For example in objective-c, most
by mahyarm 11y ago
For me a big thing is avoiding error prone inconsistencies and other footguns. The less footguns a language has, the better.
For example in objective-c, most of the language deals with nil items without crashing or errors, except for a few APIs and collections. This abstraction mismatch in collections causes runtime crashes and is a language footgun.
Swift fixes this footgun with optional types, but objective-c could of made it's collections nil-safe and apple could of just declared in the company that your apis have to be able to handle nil arguments, no exceptions. The new nullable annotations are an ugly patch to just help transition to swift and still do not fix the footgun.
Java's NPE is another example of a footgun, and C++ & C have footguns everywhere that generate billions of dollars of security industry work.
What would you call the footguns of lisp & golang?
- Denzel 11y agoOff the top of my head, for Go, (1) the semantics around nil and closed channels resulting in deadlocks, and (2) failing to recover from an unexpected panic. I think error handling and documentation of the errors returned by methods could be improved in Go. I dislike having to comb through the Go standard library source to see what types of errors a method returns. I can't speak for lisp because I don't have enough experience with it.
- masklinn 11y agoGo also has the exact same NPE footgun Java has, IIRC.
- nickbauman 11y agoRight now, Denzel's points are spot on. I would add Go the compiler itself is something of a footgun. It routinely compiles things it shouldn't. Go vet is the bandaid on this. Common Lisp's biggest footgun is probably its lack of opinion about anything. It's truly multiparadigm and probably not in a good way. Alan Kay: "Lisp is not a language, it's a building material." A real world example: I had beers with the SIFT guys (a local AI consultancy here in Minneapolis) a couple of years ago. They explained to me that when they have a problem, they go and type text in an editor that explains the problem formally. Then they type words in that problem's "language" that allows them to express a solution. Then they go an implement that language they just came up with using Common Lisp. Clojure on the other hand is a Lisp with an opinion: parallelism can be done in the same idiom as non-concurrent logic if you use immutable constructs. So the language will push you in this direction. It turns out writing code without branches, variables, objects and yes even state can be done 99% of the time this way. And yes it is simpler in the truest sense of the word.