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.
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.
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.
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
A small piece of advice: Don't try to do everything at once. I think it would probably be better to start with something similar to a standard text editor with one or two bonus features and evolve that over time to your final product. Bringing in a bunch of radical new ideas all at once seems like it probably isn't going to work very well.
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.
> "Our communities are wildly different from language to language, so much so that idioms even contradict each other..."
> "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.
Dynamically multilingual is a good way of putting it. Editors can, for the most part, serve a single set of features to many different languages, but something like an environment has a much harder time doing that. Context matters. Really trying to nail what works in different contexts is arguably the greatest value that will come out of the project.
A simple browser extension like Readability or Instapaper can extract the article and display it in a readable manner. That way you don't have to miss out on potentially interesting articles if you don't like the design or are distracted by certain elements on a website. It works pretty well :)
Grey on grey is fine for me, but the typeface is definitely too light with too much space in the counters (how would a type-designer say this – does it make sense to call the face too "open"?) Looks pretty though.
Open is a good term. By chance, what OS/Browser are you on? I've been trying to gather some feedback about the "extended" fonts available now via @font-face and how people's OS also play a part in that.
Instant results etc are fun things to play with, but they will not matter for most use cases there are.
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.
Why was the (originally edited) title of this submission changed just recently? It was "Light Table - My goal" until it had 100 points, which made it completely obvious what it was about. Now it's been changed to the author's original title which explains absolutely nothing.
> 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.
Love the idea but I think a big way to get a ton more backers will be to set better levels for additional languages.
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.
Actually, I think you're vastly underestimating the amount of resources for each Lang to work out well. The key point is semantics. As currently presented, light table is exploiting languages whose semantics can live on a js substrate
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.) :-)
The backends can be written in any language that has support for TCP and JSON. :) Forcing people to write parsers/analyzers/etc in a language other than the host is bound for failure in the long run.
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.
Haters, no. Critics, yes. Anyone who asks an interesting question or poses an interesting problem shouldn't be ignored completely as long as it seems relevant to what the creator is trying to do. Judging by the timeliness of this post however it seems like he's doing a fine job of that.
Because when they make a persuasive argument, it forces you to work harder. To confront the issues that other people are bringing up. If you don't want that then you can make software just for yourself. Otherwise it's best to keep an open ear, even if the voices do nothing to change your direction.
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.
I'm not arguing that criticism isn't valuable, I'm just arguing that it isn't valuable when you are still in the early stages of building your idea. Build it based on what you think it should be, see if people use it, and then accept feedback.
The people criticizing you, especially this early, are obviously not your customer.
Great positive response from the OP -- I saw the critique on the idea at the start of today and already he has made a reply that gracefully deflects most of the criticisms raised about the idea.
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.
This post convinced me to contribute to the project.
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
I like the idea, I think it's a right step into the future of coding.
Beta Access @ $15 Pledge would be nice though, since ppl would certainly donate more money if they saw how cool the IDE is.
I assume "beta access" means you'll be providing some feedback as well, which can't apply to the lowest donation level. And I can't believe there wouldn't be screenshots and videos as the IDE develops.
Its too early in the day to get into these many details. The primary focus must now be
a. Set of goals.
b. Fastest way to get to the set of goals.
c. Building a community and getting them to contribute.
Anything else and we would be prematurely optimizing. And falling through a unproductive rabit hole.
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.
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.