Live data from Hacker News

LightTable detailed critique: Concept vs Reality

eblog.chrononsystems.com

121–130 of 136 posts

Re: LightTable detailed critique: Concept vs Reality

#121
post #58

Earlier quoted context omitted.

> 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 v…

> 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 programme…

>>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.

The number of people even wanting to learn clojure are generally going to be in the bracket of people who are going to learn not just for a living but to perfect their craft. So you are likely to find good programmers in Clojure than in Java. In fact it might be difficult to find bad clojure programmers.

On the hand other chances of finding good programmers among java programmers is going to be difficult. And your average Java programmer can't even write a fully functional program let alone a full app without eclipse doing 90% of the auto completion, and vast part of code automation happening automatically for him. So the IDE use case for a java programmer is totally different. What a java programmer needs is a tools that can program in itself with little inputs from him.

Light table is not for code automation and auto completion in itself. Its for programmers who like think instead of IDE doing that for them.

Re: LightTable detailed critique: Concept vs Reality

#122
post #87

Earlier quoted context omitted.

> 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, sh…

He 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.

>>sometimes a algorithem is clearer in one function.

Once many such reusable algorithms come up. The function sizes keep shrinking.

Re: LightTable detailed critique: Concept vs Reality

#123

Earlier quoted context omitted.

I think you are arguing a cultural phenomena. I am an Eclipse power user myself but alas Eclipse is not an effective option if I need to drop into a remote server and cut some code. (Yes, I use VIM for these occasions.) And let's be perfectly frank: developers who get their start on IDEs are typically (not all, don't be offended) relatively clueless on the command line. IntelliSense gives these what unix commands hav…

To wit, IDEs encourage complexity and bloat and fat function/methods I write all my Clojure code in IntelliJ, using a (customised) version of La Clojure. Could you explain to me how this encourages complexity and bloat in my code?

He is talking of programmers who start programming with IDE's and nothing else. If you belong to this category it will difficult to explain you the very concept of bloat, because that is what you have started with and feel it to be perfectly normal.

Most people who program in Editors I know read the documentation, manual and tutorial better. They think and code. On the other hand IDE only programmers I know can't write even simple functional programs without IDE, autocompletion and intellisense.

Take a big Java project and try to work on it without IDE/eclipse/IntelliJ, that would give a true picture of how much work IDE had automated for you.

Re: LightTable detailed critique: Concept vs Reality

#124
post #108
post #99

Earlier quoted context omitted.

I can't help but feel that every person I've seen who loves their IDE codes Java. I, for years, did not understand this finding vim and emacs perfectly sufficient. I liked SLIME, but found it only marginally better than any non-"superpowered" editor/repl pairing. Then I tried programming Java. I concede totally. It's not just easier to program Java with an IDE, Java is essentially designed to be impossible to code wi…

On could also see it exactly the other way round: Java's strong typing makes it possible for an IDE to do amazing things, which help you cope with horrible codebases, which in turn makes code viable that would be completely unmanageable in other languages. As for "Java is essentially designed to be impossible to code without an IDE.", I'd say that's a pretty ridiculous statement given the state of art of IDEs at the…

No Sorry, And please.

Almost all Java programmers I've seen so far can barely write any code without IDE, autocompletion and intellisense. Even people who claim to have years of experience in Java.

Its just the community is very heavily on IDE side. The libraries, frameworks are all heavy bloats designed with the perspective that IDE is going to take care of that anyway.

In other words, Java world without IDE doesn't exist and I presume that is going to be the case for a long time to come.

And that is one of the reasons why I never went deep into Java because one tour of eclipse and the best and worst Java programmers both become the same.

Re: LightTable detailed critique: Concept vs Reality

#125
post #124
post #108

Earlier quoted context omitted.

On could also see it exactly the other way round: Java's strong typing makes it possible for an IDE to do amazing things, which help you cope with horrible codebases, which in turn makes code viable that would be completely unmanageable in other languages. As for "Java is essentially designed to be impossible to code without an IDE.", I'd say that's a pretty ridiculous statement given the state of art of IDEs at the…

No Sorry, And please. Almost all Java programmers I've seen so far can barely write any code without IDE, autocompletion and intellisense. Even people who claim to have years of experience in Java. Its just the community is very heavily on IDE side. The libraries, frameworks are all heavy bloats designed with the perspective that IDE is going to take care of that anyway. In other words, Java world without IDE doesn't…

Yeah, do keep repeating your bias and prejudices while ignoring conflicting facts pointed out by others, and tell yourself that makes you smart.

Re: LightTable detailed critique: Concept vs Reality

#126
post #115
post #108

Earlier quoted context omitted.

On could also see it exactly the other way round: Java's strong typing makes it possible for an IDE to do amazing things, which help you cope with horrible codebases, which in turn makes code viable that would be completely unmanageable in other languages. As for "Java is essentially designed to be impossible to code without an IDE.", I'd say that's a pretty ridiculous statement given the state of art of IDEs at the…

Perhaps it just has to do with modern practices and libraries encouraged by modern IDEs. I approached it recently, so I can't speak for times before the IDEs were there. Strong typing is certainly very helpful for making smart compilers and tools---I can't deny that, I'm a Haskell junky. I don't think it's always a best practice though. Being able to handle horrible codebases means that the language/editor environmen…

That always seemed a really, really unproductive notion to me, that great tools must be bad because they help you deal with problems that would otherwise make you fail sooner.

Re: LightTable detailed critique: Concept vs Reality

#127
post #125
post #124

Earlier quoted context omitted.

No Sorry, And please. Almost all Java programmers I've seen so far can barely write any code without IDE, autocompletion and intellisense. Even people who claim to have years of experience in Java. Its just the community is very heavily on IDE side. The libraries, frameworks are all heavy bloats designed with the perspective that IDE is going to take care of that anyway. In other words, Java world without IDE doesn't…

Yeah, do keep repeating your bias and prejudices while ignoring conflicting facts pointed out by others, and tell yourself that makes you smart.

Its neither a bias nor a prejudice. Because I write in Java and Other languages like Python and Perl in my day job. Although I'm trying to run away from Java as quickly as I can.

Vast majority of Java programmers can't program without IDE's is a fact. Java being verbose is a fact. Java frameworks being bloated is a fact. Medium to large Java application not being easily handled thorough ordinary tools like text editors is a fact.

Its almost like what Dijkstra said couple of decades back about basic. It can destroy your thinking abilities. I don't want to risk mine with too much exposure to autocompletion and intellisense. And without them it makes zero sense to write in Java, as you can no longer be even remotely productive.

Well I don't know about others, but I, myself would not like to be bunched in that kind of commodity market of programmers whose only known expertise is 'Knows how to use an IDE'.

Re: LightTable detailed critique: Concept vs Reality

#128
post #58

Earlier quoted context omitted.

> 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 programme…

This made me go check our Clojure code base at work: including comments, docstrings and whitespace, our functions average about 11.5 lines each (and I know we could clean up some of our earlier code to reduce that average). So, yeah, I'll consider that evidence that real world Clojure is pretty tidy.

Out of curiosity, do you know the average without the docstrings and whitespace?

Re: LightTable detailed critique: Concept vs Reality

#129
post #127
post #125

Earlier quoted context omitted.

Yeah, do keep repeating your bias and prejudices while ignoring conflicting facts pointed out by others, and tell yourself that makes you smart.

Its neither a bias nor a prejudice. Because I write in Java and Other languages like Python and Perl in my day job. Although I'm trying to run away from Java as quickly as I can. Vast majority of Java programmers can't program without IDE's is a fact. Java being verbose is a fact. Java frameworks being bloated is a fact. Medium to large Java application not being easily handled thorough ordinary tools like text edito…

http://en.wikipedia.org/wiki/Proof_by_assertion

Re: LightTable detailed critique: Concept vs Reality

#130

Earlier quoted context omitted.

I think you are arguing a cultural phenomena. I am an Eclipse power user myself but alas Eclipse is not an effective option if I need to drop into a remote server and cut some code. (Yes, I use VIM for these occasions.) And let's be perfectly frank: developers who get their start on IDEs are typically (not all, don't be offended) relatively clueless on the command line. IntelliSense gives these what unix commands hav…

To wit, IDEs encourage complexity and bloat and fat function/methods I write all my Clojure code in IntelliJ, using a (customised) version of La Clojure. Could you explain to me how this encourages complexity and bloat in my code?

Encouragement is suggestive[,] not coercive.
Post reply on HN