LightTable detailed critique: Concept vs Reality • Hacker News Board

Re: LightTable detailed critique: Concept vs Reality

#131

Post by tel » Mon, Apr 23, 2012, 2:41 PM UTC

brazzy wrote: post #126

tel wrote: post #115

Earlier quoted context omitted.

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.

I didn't say IDEs weren't powerful or bad. I indicated the opposite. Sports cars are fantastic. They are really fun to drive. I would start walking if everyone in America had one. Too dangerous.

Re: LightTable detailed critique: Concept vs Reality

#132

Post by tel » Mon, Apr 23, 2012, 2:41 PM UTC

brazzy wrote: post #126

tel wrote: post #115

Earlier quoted context omitted.

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.

I didn't say IDEs weren't powerful or good in and of themselves. I indicated the opposite. Sports cars are fantastic. They are really fun to drive. I would start walking if everyone in America had one. Too dangerous.

Re: LightTable detailed critique: Concept vs Reality

#133

Post by tikhonj » Mon, Apr 23, 2012, 3:14 PM UTC

alttab wrote: post #116

tikhonj wrote: post #84

Earlier quoted context omitted.

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.

Efficiency isn't really about entering text, it's about quickly navigating around large amounts of text, editing parts, performing larger operations, integrating the rest of your workflow (maybe a REPL or a browser preview or tests...), testing code, exploratory programming, combining different languages, working with markup languages (HTML, XML, Markdown, LaTeX), writing documentation, reading documentation...etc. The beauty of Emacs is that it does all this (and more :)) well for a whole range of languages.

The goal is not just to be able to do anything you need quickly, but to do it in a way that doesn't break your concentration and doesn't take much thought. Moreover, this has to apply to pretty much every sort of thing you do with your source files, which is actually quite a lot. Today, almost any work you do on your software project as a developer involves text, not just programming, so efficiency really matters.

Additionally, it should be really easy to create complicated workflows for your specific project. For example, I am working on some code that operates on two trees and produces a third. It literally took me half and hour to create an Emacs command that took some (configurable) input, ran my function on it, rendered the result with LaTeX (using a tree-drawing package) and displayed it. This way, when I make an edit to the algorithm, I just run a single command and see the output immediately with a nice visualization. This makes playing around with modifications to the algorithm very simple.

Re: LightTable detailed critique: Concept vs Reality

#134

Post by Someone » Mon, Apr 23, 2012, 10:13 PM UTC

Zak wrote: post #114

Someone wrote: post #94

Earlier quoted context omitted.

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?

Now you mention it: yes, probably.

Re: LightTable detailed critique: Concept vs Reality

#135

Post by Rage » Tue, Apr 24, 2012, 8:44 AM UTC

dibbeke wrote: post #81

Rage wrote: post #46

Earlier quoted context omitted.

Well, Eclipse is slow, crashes, has a lot of features but doesn't really do anything nicely (javadoc integration is damn awful tu use). More features doesn't mean better. What i like about LighTables is that it seems to have few features, but do them well. It has a nice clean UI (even if it's just mockup, i don't think it needs anything else) and the UX seems nice too from what i understood. Maybe what you didn't und…

Eclipse needs a good amount of memory and recently, unfortunately, has a tendency to crash. Most of the features can be disabled; the UI can be reconfigured to your liking. Btw, I generally disable the javadoc view and just F3 to the location to see the code and docs together (docs are often wrong anyways). The problem with mockups is that they haven't touched reality yet: there is always so much detail you don't see…

yup, but eclipse is too big for me i think, i'm not really a fan. I prefer to user sublime text with completion help that run instantly.

Re: LightTable detailed critique: Concept vs Reality

#136

Post by alttab » Thu, May 03, 2012, 2:22 PM UTC

tikhonj wrote: post #133

alttab wrote: post #116

Earlier quoted context omitted.

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.

Efficiency isn't really about entering text, it's about quickly navigating around large amounts of text, editing parts, performing larger operations, integrating the rest of your workflow (maybe a REPL or a browser preview or tests...), testing code, exploratory programming, combining different languages, working with markup languages (HTML, XML, Markdown, LaTeX), writing documentation, reading documentation...etc. T…

I use VI with default key bindings and few macros. In my mind workflow is based more on how you approach the problem and less about what tools you end up using. You wrote an emacs command that I would imagine could be done with bash just as well. Have to tab to a different terminal to run the command? Not that big of a deal in the grander scheme of things.

If you need to build new software to shave a couple of seconds off of finding a piece of code, or switching to documentation, or running a command without pressing ALT-TAB, I would venture to say you have other problems not related to workflow or tools. Say, your ability to stay concentrated and focused without interruptions, understanding that your development workflow does not a product team make, or focusing on the problem your product is trying to solve in the real world market versus getting into self-masturbatory work-flow science.

I don't disagree that component-based workflows are important, but I also can't count how many times I've seen developers more concerned with how they work than what they produce.