Hacker News Reader

Comment by radicalbyte | Hacker News Reader

Great. But please don't take too much notice of feedback at this stage, it's more likely to distract* you from your core goals.

Focus on expanding the concept, listen to a small group of critical people you can trust for feedback and you'll build the tool we're all supporting you to build :)

As an aside: to truly 'fix' files, you need to 'fix' version control. That's out of scope for Light Table, but it's something that could be addressed by a parallel project (if someone else fancies looking at it).

* i.e. complicating things so you can support Java/C# - few of those devs will ever use Light Table, and if the concept is a hit then you'll have Microsoft and Oracle waving big wads of cash at you to support their platforms.

View on HN

I agree. My first proof point is getting to where I'm moderately productive writing Light Table in itself. That should provide the bare necessities and ensure that I'm focusing on the right things instead of features that happen to seem cool :)

I don't know what you have in mind for "fixing" version control, but I'm actually working on something like that with a friend.

The basic idea is to diff and merge ASTs rather than long strings. We have some more specific ideas about specific features and advantages, but since we have almost no code yet I won't get into them. We should (since this is actually for school, we have to) have a working prototype several weeks from now, so I'll talk more about it then.

We're not really fixing "version control" per se; rather, we're building a tool that you could use in tandem with existing systems like Git. So we'll help with diffs, interactive merges (maybe even automatic conflict resolutions) and some other stuff but let the actual storage and versioning stay with Git (or any other VCS).

I can't make any promises, but if we get something interesting working I'll be sure to post it here. We actually tried to do something like this for a hackathon once, and it sort of worked, but was really a big hack throughout. Hopefully we'll get it right this time.

Sounds awesome. I've been complaining about the lack of AST-awareness in VCS for a few years now, though I haven't done anything about it. Please be sure to keep everyone up to date, even if it's only with the problems you discover about the approach.

That's pretty much what I had in mind: diff at language level not at text level.

Actually, ideally you would have content-aware DIFFs. So source code has one visualiser, images another, each binary format another.

That would make the experience much better.

Yes, this is a big deal and hasn't been attempted nearly enough yet. I believe Git will let you implement your own "hunk" handlers (I know Darcs would) so you should be able to do it there.

Once you have that it should be much easier to check in more granularity, produce a more accurate map of dependencies and roll out refactorings that didn't work out.

Could you fix files if you mounted the IDE atop a git repo; directly storing chunks as git objects?

While file-less source control would be a very interesting concept I don't see how the lack of it would affect the editor. Simply present code as file-less and behind the scenes put every entity (class, struct, whatever) into it's own file that can be version controlled

What ur problem with version controll? Its not really about files anymore, git does not care about files.

Reply on news.ycombinator.com