3 ms·
> I just can't imagine anyone disagreeing that most code looks like this in the real world. I disagree, at least when it comes to Clojure. The size of the fun
by weavejester 15y ago
> I just can't imagine anyone disagreeing that most code looks like this in the real world.
I disagree, at least when it comes to Clojure.
The size of the functions in the demonstration is about average for Clojure. The author of the critique suggests that the examples are "contrived", but speaking as a Clojure programmer, I didn't get that impression at all.
Hidden state change might cause problems for tracing the values of variables, and I wonder how well Light Table would work for Javascript. However, since Clojure is a functional language, there's very little hidden state to worry about.
Most of the critique seems to be either "This isn't new" or "This wouldn't work in Java". But just because something isn't new doesn't mean it isn't beneficial to do it, or that existing UIs could not be improved. The Light Table demonstration of inline docs seems more responsive and more immediate than the equivalent functionality I've seen in Eclipse.
Secondly, even though Light Table is supposed to be language agnostic, it doesn't really seem designed for languages like Java. The dynamic code traces demonstrated would work very well for Clojure, but I can certainly imagine production Java code being too complected for it to be useful. But that's fine; just because it isn't suited for Java doesn't mean I can't take advantage of it in Clojure.
- edanm 15y ago> I disagree, at least when it comes to Clojure. This hits on another difference: Java is much, much, much more likely to be used in the real world over Clojure. The set of people who use Clojure are very likely to be in the set of people who write small functions, both because they're more "cutting edge" in terms of TDD, because they're only writing "toy" or "hobby" projects, or because they're just better programmers (e.g. Paul Graham's article on Python programmers tending to be better). Having said that, please don't be offended - I'm speaking in generalities here. If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more. Btw, I completely agree that making an amazing IDE for only one language is still a great goal, even though I would personally find it hard to work with a different IDE for Clojure and for my other code.
- stcredzero 15y agoReal world Smalltalk projects have mostly short methods, with some exceptionally long ones.
- weavejester 15y agoI can say that all of the Clojure code I've personally seen for "real world" systems in Clojure tend to have a very small average method size, but I can't speculate on proprietary code I haven't seen. Certainly most open source Clojure code is very well written. And if Light Table is only an IDE for "better programmers" then I don't think that's necessarily a bad goal to have. That said, since Light Table is supporting Javascript as well, it's not exactly only catering for minority languages.
- GlennS 15y agoI don't think it's even a matter of 'well written' as such, just how the language works. When every code path must end in a return value, writing large functions becomes difficult.
- Tuna-Fish 15y ago> If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more. Go look at any Clojure project on github. Seriously. Stuart Halloway, one of the more prominent Clojure committers and evangelists once (semi-)famously said: "No function should ever be longer than 5 lines. And if you think you have one that needs to be longer, show it to me, and I'll prove you wrong." That is some of the ethos behind the language.
- nickik 15y agoHe later said that this is not true after some people provided some examples. Its more a 99% rule. Most of them are Java Interop related but sometimes a algorithem is clearer in one function.
- 15y ago