Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LightTable detailed critique: Concept vs Reality

eblog.chrononsystems.com

Post reply on HN
Print view View original

111–120 of 136 posts

Re: LightTable detailed critique: Concept vs Reality

#111

Post by dibbeke »

stcredzero wrote: post #104
dibbeke wrote: post #80

Earlier quoted context omitted.

Ah, finally, here we have the gist of the argument: "Many of his points aren't very useful for other languages." The rest is all noise and no signal. Well, although that point has been answered on other parts of the forum, it seems the auto-eval function is reserved for immutables only and non-recursive languages. So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one…

So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one of his points applies to all other languages. Do you want to hear argumentation for the other points? It seems we've touched a nerve, which is a bit embarrassing. Clearly, the kinds of things the Light-Table gentleman is talking about are applicable to more than zero languages. I know because I've spent 1.5 decade…

How would you render trees or (big) matrices? Recursive functions? Infinite lists?

I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts"); by claiming a conflict of interest while this is not applicable (the OP does not claim authority!); or by appeals to authority ("because I've spent 1.5 decades coding in one").

By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.

Re: LightTable detailed critique: Concept vs Reality

#112

Post by dirtyaura »

SoftwareMaven wrote: post #79
edanm wrote: post #41

Everyone is jumping in to disagree with the OP. I have to be honest: I thought the OP's points were very well made, and as much as I loved the LightTable demo, I think I immediately dismissed it, in my mind, as "looks cool, but can't be made". I think there is a big disconnect between this author, a "working programmer" who actually writes code, and at least some of the commenters in this thread. Let me give my take…

For one thing, the op mentioned that, while functions should be small, they usually aren't. Functions shouldn't be small just to be small. Functions should be exactly the size needed to encapsulate their function. I had to wade through a few thousand lines of JavaScript in which every function was made as small as possible (since functions are supposed to be small ). Stuff like (and I am not exaggerating): var xor_it…

I agree that code with too small functions can be hard to understand, especially if the naming of functions is not top notch. And naming things is one of the hardest parts of programming. Ability to give good names requires thorough understanding of concepts involved, which often isn't true the first time (or even second time) you write the code.

There's also interesting discussion about "optimal" function length in Steve McConnell's Code Complete. If I recall correctly, there was no evidence that functions of even 100 LoCs for complex algorithms were significantly more error prone than similar code with shorter functions, and that very short functions actually lead to more bugs than code with functions with reasonable length. I think it is because of naming: it's hard to name hundreds of small things well.

Re: LightTable detailed critique: Concept vs Reality

#113

Post by seancorfield »

edanm wrote: post #58
weavejester wrote: post #52

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…

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.

Re: LightTable detailed critique: Concept vs Reality

#114

Post by Zak »

Someone wrote: post #94
Zak wrote: post #74

Earlier quoted context omitted.

I also would like to see a system that forbid me to write code that is not covered by a unit test yet. I suspect that would lead to the people who are currently not writing unit tests writing useless tests just to circumvent the requirement. It would also make exploratory programming, where you haven't completely figured out what you want it to do much more difficult.

See, THAT is why you think before you leap. Iteration #1: make it 'forbid to commit code' instead of 'forbid to write code'. And I agree that that might only work fine in safety-critical code. And writing useless tests won't help if this would be as strict as I envision. Imagine a project where you cannot commit if flag: doA else: doB unless you have a test that hits the doA part and a test that hits the doB part. Co…

Are you reinventing design by contract using tests?

Re: LightTable detailed critique: Concept vs Reality

#115

Post by tel »

brazzy wrote: post #108
tel wrote: 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…

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 environment also allows horrible codebases to survive longer.

Re: LightTable detailed critique: Concept vs Reality

#116

Post by alttab »

tikhonj wrote: post #84
edanm wrote: post #55

Earlier quoted context omitted.

Efficiency is actually not the only, or even most important, concern. At least, not necessarily. For example, one important consideration is how easy to use it is, especially for new programmers. For better or worse, Eclipse makes programming in Java easier for many programmers. This is a pretty important consideration for most organizations.

I think valuing how easy it is to learn over efficiency is not the best option: learning even a difficult text editor takes a constant and reasonably small amount of time. Being more efficient is a benefit proportional to how much you use the editor. So anybody planning to program for a long time is probably going to be well served by learning a more efficient but "harder" editor. Now, in the real world there are oth…

This whole talk of efficiency surprises me. if that is what we are looking for, then in my mind you are either writing too much code or aren't thinking the problem through. In my experience, coding takes up less time because you get better at it.

Re: LightTable detailed critique: Concept vs Reality

#118

Post by dustingetz »

dibbeke wrote: post #29
kenneth wrote: post #18

You're comparing Java to Clojure. Conceptually, they're insanely different--Apple and Oranges, really. Clojure, Lisp, and similar languages are homoiconic. That means they're beautifully suited to an interactive environment such as that provided by LightTable. Conceptually, unlike typical IDEs, LightTable is not a series of scripts that will attempt to help you deal with common development tasks such as looking up do…

Java's annotations could be seen as 'part of the environment' (whatever that may mean). I often use annotations which indicate how a method should be used, and those annotations are used by static analysis to validate correctness. When using Java, I often change my program while it is running. recompiling classes on the fly. It works in most cases, and when it doesn't work, I believe other languages would fail as wel…

> he problem with Java is the sheer amount of 'bad' code written in it

java was designed to influence code towards solving all problems with classes. the "bad code" you speak of is idiomatic java code.

Jane Street wrote about how they migrated core systems to java, abandoned it because "But somehow when coding in Java we built up a nest of classes that left people scratching their heads when they wanted to understand just what piece of code was actually being invoked when a given method was called"[1]. then, the same team moved to a functional language to great success.

Writing "good code" in java takes discipline and expertise to overcome Java's gravity towards classes. Without discipline and expertise, teams end up at the natural equlibrium you read about on thedailywtf.com. java did an awesome job of replacing C++ for the last 15 years, but there's something inherent about the design of java that doesn't scale well with the bigger, higher complexity problems we face today.

[1] http://queue.acm.org/detail.cfm?id=2038036 ~10 paragraphs in

Re: LightTable detailed critique: Concept vs Reality

#119

Post by stcredzero »

dibbeke wrote: post #111
stcredzero wrote: post #104

Earlier quoted context omitted.

So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one of his points applies to all other languages. Do you want to hear argumentation for the other points? It seems we've touched a nerve, which is a bit embarrassing. Clearly, the kinds of things the Light-Table gentleman is talking about are applicable to more than zero languages. I know because I've spent 1.5 decade…

How would you render trees or (big) matrices? Recursive functions? Infinite lists? I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts"); by claiming a conflict of interest while this is not applicable (the OP does not claim authority!); or by appeals to authority ("because I've…

How would you render trees or (big) matrices? Recursive functions? Infinite lists?

You don't. I think the Light Table author is naive here. Instead, you let the programmer rewind the stack at will.

I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts")

The facts in question have to do with things I've seen implemented. Your argument is an indication you aren't aware of the same. That's not tainting your credulity. I'm questioning if you have all the facts.

By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.

You are the one who is upset. You are also incorrect about what you purport to be upset about. (My intentions in pointing out certain facts and their implications.) Please process this data.

Re: LightTable detailed critique: Concept vs Reality

#120

Post by mcguire »

edanm wrote: post #41

Everyone is jumping in to disagree with the OP. I have to be honest: I thought the OP's points were very well made, and as much as I loved the LightTable demo, I think I immediately dismissed it, in my mind, as "looks cool, but can't be made". I think there is a big disconnect between this author, a "working programmer" who actually writes code, and at least some of the commenters in this thread. Let me give my take…

"looks cool, but can't be made"

Or, rather, "Looks cool, but wouldn't be really all that earth-shaking."

Post reply on HN