Hacker News Reader

Comment by fournm | Hacker News Reader

We do, in fact, use tabs at work. But I wanted to attempt to avoid starting this war yet again.

Radical idea: lets move code away from the anachronism of flat files. There have been incredible evolution in some areas of development, and other areas time has completely frozen. We should have modern tools from the top-down.

dons flame retardant suit

Explanation? You could put code elsewhere than in flat files? Elsewhere that is neither VBA nor PLSQL ;)? I'm interested.

Otoh, if you're going to suggest binary structures, I wont be able to approve you if they're not easy to manage in Git.

Roughly it would be some sort of structured text, markup that represents the structure of the code rather than having a flat text file which then requires parsing to reconstruct structure. There are a couple of motivations here: structured representation allows editors to much more freely handle custom visual representations. Debates about tabs, spaces, braces, semicolons, parenthesis, etc etc are painfully outdated. These simply become properties of your chosen visual representation. It also allows more meaningful transforms without requiring a compilation pass, as a meaningful intermediate language is already present. This would have a few benefits: semantic text highlighting, straightforward semantic changeset merging, enhanced error highlighting and more semantic error detection (if I insert a line of code somewhere, the error is readily marked as the inserted line as the surrounding code is still semantically valid), sharing the semantic representation between IDE plugins. I'm sure this is just scratching the surface.

I'm reminded of the project I recall reading about from steve yeggie regarding a language agnostic IDE framework (whatever happened to that anyways?). A language agnostic, semantically rich file format would allow entire classes of transforms to apply across all languages that could be marked up by the language agnostic file format.

There are so many possibilities here, and yet a non-trivial amount of programmers are still anchored by the supposed benefits of editing code from the console! Programmers should be the first to be looking forward rather than being tied down to the past.

I thought you were going to suggest something crazy and imaginative issued from Big Data, like introduce some concept of Big Code, where you'd map-reduce your execution path, have non-consistent executions spread over thousands of servers, with the explicit target of singularity ;)

The option you suggest could have been done since long and it hasn't: I'm inclined to wonder why. Probably text-file editing has reached the good-enough level where we've got enough tooling to cope with the drawbacks, and the basics of open source is, it has to be the most urgent solution for the one who takes the initiative.

I used IBM's VisualAge for Java for a while back in the day, which was essentially applying a Smalltalk model of code organization to Java, but I never liked the image system. There's just something wonderful to me about being able to use a bunch of command line tools to perform ad hoc code analysis on files.

It's a radical idea that's been tried several times before and never stuck. See: Interlisp, Smalltalk, VisualAge for Java.

I suspect part of the problem is that there is a huge ecosystem of tools that work on plain text, and it's also easy to write more tools that work on plain text. You lose all of that when the database or parse tree is the primary representation, which means that when someone goes to make an adoption decision and their favorite tool doesn't work, they go back to the old way.

Reply on news.ycombinator.com