On concepts and realities
chris-granger.com
chris-granger.com
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.
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.
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.
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.
I put in $50. I think this project could be really cool if it turns into more than just vaporware. Best of luck to you.
> "The way Clojure developers work is very different than the way C developers do..."
This couldn't be more true, and makes the $200,000 investment goal a heck of lot more reasonable. Imagine the difference between developing and testing HTML5 games with Javascript and creating business CRUD apps with Rails. It's very ambitious when you think about it, which is why I'm just as eager to see how this project evolves in the next couple of months.
Light Table has a huge potential to be dynamically multilingual. Each of these languages and platforms have vibrantly unique communities, and being able to speak to all of them will be the "thing" that makes it worth using.
I could install custom style sheets. But now I choose to ignore unreadable pages.
Perhaps other people are also ignoring what you have to say, but not letting you know?
For me it's these two lines you mentioned:
1) You should never have to look for documentation
2) Files are not the best representation of code, just a convenient serialization.
First one is easily doable and there are a lot of plugins that help you with that.
The second is what makes this project interesting and almost made me write my own editor the moment I first saw Light Table.
Files are indeed good way to serialize stuff, but handling each separate section of code as independent (and at the same time, dependent on other sections of code) could actually be a better way. At least it's something I'd like to try.
That's also something that's doable for most languages there are.
Only thing needed are the rules that tell what parts are separate, and additional logic that links those parts to the parts that are called from that one to connect the whole thing as one big entity.
> You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it.
What I'm saying is you're right, some editor obviously didn't read the guideline properly. Even if "Light Table - My goal" were somehow gratuitously editorial, the title of the blog post is a horrible choice to replace it.
If you think about it $100,000 for python is fairly steep. Not unreasonable, but take me for example. I develop primarily in ruby. If you add a ruby tier, I will back the project. But I think you should make add language tiers and make them a bit easier to reach.
If you do the foundation properly, the difference between adding Python and Ruby should be small. Perhaps if you set Python at $250k/275k and then make ruby and other languages an extra ~$25k you will gain the support of a HUGE ruby audience and open up other big audiences.
Here's a +1 to ruby, and to doing it at much less than $100k.
If anything, I think they're optimistically underestimating the engineering work for addin js backends for other languages (assuming that's how they plan to have es languages integrated in.) :-)
That, however, is a subject for a later post.
Having just gone through 9 months of rapid iteration on a product, I've learned so much, both about building good products and about accepting (or not) feedback.
Can't wait to see what Light Table brings to the...um...table.
It's easy to be a critic, much more difficult to put your money where your mouth is.
Criticism is no science, and sure they might not be making the same thing as you but that doesn't mean they don't have anything valuable to say about it. You could be a brilliant programmer but absolutely no imagination when it comes to UX, in which case a little user criticism would go a long way and may even bleed a little into the program architecture.
The people criticizing you, especially this early, are obviously not your customer.
I wonder how close Cling[1] is to this ideal.
Most of us are probably aware by now that some of the features that the OP is offering has already been done. It was pointed out that Eclipse supported docs everywhere, for example. I agree that these are _principles_ that have a much higher purpose than promising some neat features: they will guide and define the development of this product.
I, almost many others, find what the OP is doing very intriguing and I am eagerly watching how Light Table will develop into a product that perhaps we can use one day.
I thought it was a great idea at first, but didn't contribute because of the odd kickstarter levels and my own faulty perception that the project was to create a fleshed out version of the initial demo.
Clearly stating that the priority is on your ideals was a great idea:
- You should never have to look for documentation
- Files are not the best representation of code, just a convenient serialization.
- Editors can be anywhere and show you anything - not just text.
- Trying is encouraged - changes produce instantaneous results
- We can shine some light on related bits of code a. Set of goals.
b. Fastest way to get to the set of goals.
c. Building a community and getting them to contribute.
The primary focus at this time must be to worry about a basic usable product with a extensible mechanism and growing a community. The faster you get something out, the more awesome it will be. After this kind of a built up, not having a quick release or a bad release will disappoint a lot of people.
Will be nice to see something in the next 6 months.