5 ms·
I have some doubts about this one, despite my love and ongoing professional work with Clojure. For overall productivity, I find the issue of typos more signific
by hellofunk 9y ago
I have some doubts about this one, despite my love and ongoing professional work with Clojure. For overall productivity, I find the issue of typos more significant than this slide leads us to believe, especially in a language like Clojure where the compiler does not catch nearly 90% of my typos. It's very easy to have a nil running through your program in Clojure because you either mistyped a keyword or you just picked the wrong one when pulling something out of a map, for example. But that is just one example, I find that I spend a fair amount of my work day tracking down silly typos at run time, which frankly disappoints me tremendously. I really like Clojure but tackling this problem has been non-trivial.
- raiflip 9y agoI think the mistake he's making is in that while his hierarchy is correct in that one bug from a category further up is far worse than any bug in a category below it, if you have many more bugs from lower categories they can start to become problems on the scale of a few bugs higher up the chain. Constantly dealing with typos is a great example because one or two would not be a big deal, but they can add up to significant mental effort and time loss.
- kimi 9y agoI agree: one of the things I do appreciate in Java is that the compiler does catch those silly things and I don't really have to think about them any more. As a side effect, refactoring is very safe and you can depend on it. Clojure - that I like quite a bit - does not help me much along these lines; and this is an annoyance.
- abc_lisper 9y agoI agree with this sentiment, but I find that doing small checkins to git is helpful, with a good git ui.
- lispm 9y agoCommon Lisp OTOH uses defined arglists with keyword parameters, where the compiler can check mistyped/wrong keywords.
- raspasov 9y agoIntelliJ + Cursive makes keyword typos and most other typos a non-problem (or very easily spottable problem) for me.
- hellofunk 9y agoHow does Cursive know if you're pulling out a valid keyword in a map?
- positr0n 9y agoI doesn't know if :resource_id is in the map, but that's not a typo if that's the case. What OP meant is if you type :resuorce_id it won't autocomplete correctly so you're more likely to notice.
- hellofunk 9y agoAh, well I get that same behavior in Emacs. Doesn't always help though.
- raspasov 9y agoAlso if you type resuorce_id when referencing it will tell you that it cannot resolve the local. Of course if you BOTH destructure resuorce_id AND reference resuorce_id then you're out of luck :). That happens rarely though. One recent IntelliJ addition which is sometimes annoying but often very helpful in many cases like that is notifying you of grammatical typos: as long as you're not using obscure one off abbreviations, etc it will most likely catch "resuorce_id", "widht" and similar typos but might also complain about valid words or abbreviations in some niche domains.
- didibus 9y agoHum, the repl catches most of those for me almost as instantly as Eclipse would highlight it if it were in Java. And the onese that are left are annoying, but really not a massive amount of wasted time. Like possibly a lot less time then the time I would spend wrestling with complex types, or having to build generic structures so I can group disparate types together.
- rboyd 9y agoI'm with you here, they usually come out in the repl. There's always spec too, if it really turns into a problem. Seems like we could have some tooling that raises a flag if keywords with a short Levenshtein distance were detected.
- didibus 9y agoYa, I'm not trying to make excuses. I welcome better tooling, or even language features that help. The problem is there, but I agree with Rich Hickey in that its not the highest in my list.
- hota_mazi 9y agoUgh... And people complain about Java's NullPointerException, but this is way worse.