One thing that I'm curious about, however: it (seems like it) will be a web-based platform. Can anyone comment on whether or not this is an advantage or disadvantage? I imagine a fully functioning offline mode will be available, and I can see chaching things like documentation locally, etc. But there must be a compelling reason that newer editors are not web-based (or maybe the better term would be browser-based).
it'll use a browser for the UI layer, but that's it. So browser-based is a better term I think. No internets needed. In the end, though, even that will probably be abstracted away into a webview or something. The overall distribution story is something I'm kind of curious about myself at this point. Lots of exploring to do there.
I'm pretty sure Rstudio uses this approach. The core app is all HTML/Javascript, but then they make a desktop version by putting a thin Qt wrapper around it and adding a few minor things like a relevant menu bar.
Well we can imagine choosing a version statically linked or a dynamically linked one when dowloading ? I agree it isn't a really slick solution, but it's a tool for developers it won't hit too hard the entry barrier.
Originally I started using it when I was building a platform to teach coding and it had the best Clojure support :) I remember getting annoyed by ACE's setup, whereas I just dropped CodeMirror in and it worked. The code definitely seemed easier to approach to me too.
We use Ace at work and this weekend I was looking for something else for a weekend project. I happened to pick CodeMirror and got the same results as you. It just worked. Plus, the docs were really well done. +1 for CodeMirror!
Super excited about this. Will definitely be looking into CodeMirror's vi key binding support and how I can help there.
Can't wait to see alphas and play with the bindings, as well. I would love to get a chance to see if it would be possible to run an out-of-band process to run some of the same stuff for a compiled language that does have a REPL and stuff that produces nice ASTs from code (e.g., Scala or even Java).
I also get the feeling there's going to be some space here to ease things with regards to testing… Not only because you'll be able to see your tests expanded instead of having to step through, but I think there's potential for just running some test code, seeing the output, checking it's right, and then hitting a key combo to codify that into an automated unit test.
Definitely feels like there's so much awesome lying around the corner. Mad props for putting this together and deciding to carry through with it. I'll be keeping an eye out for the Kickstarter.
In terms of out-of-band, it's being designed that way from the ground up so that we can support as many runtimes as you can imagine. Basically if you can create a service that talks over tcp and can handle JSON, you should be able to add support for it to Light Table. I think that might be the coolest part of the platform. :)
I definitely have thoughts on testing and there's a ton of interesting stuff we can do there.
Yeah, the biggest problem that a language like Scala will run into will be that the instantaneity will have to deal with a compiler hit, particularly if you have to hot swap code (where possible!) as you edit it. Still, wouldn't be fun if it wasn't a challenge ;)
I'm very interested in how the business side will work out. On the one hand, it's very fair to make some money when you make something great (and it funds ongoing creation).
On the other hand, dev tools are expected to be free and it feeds massive adoption (and if not free, devs have the ability reverse engineer e.g. linux and gcc). The common wisdom is that smalltalk got killed by high prices. There are exceptions: MS VS; some editors. Maybe the older, broader the appeal, and closer to the dev, the greater the pressure for free - so that new, specialized, and close-to-customer tools resist commoditization. Light table is new, but general and close to dev.
The Street_Performer_Protocolhttp://en.wikipedia.org/wiki/Threshold_pledge_system#Street_... fits perfectly with KS. But personally, I love the idea of making something great and getting rewarded in proportion to its greatness (as in product sales), not a fixed reward. An ideal solution seems to be to charge large customers (e.g. over 10 employees? Over 100?), but I've not seen this explicitly attempted... but I guess it's achieved by "enterprise" versions, with extra features, particularly those needed only by large customers... that may be what is being considered with "some plugins may remain closed source". Then one could create a marketplace for plugins, an app store etc.
Even Microsoft Visual Studio isn't that expensive. Microsoft created it's Express Editions partly as a response to the fact that institutions were choosing Linux for introduction to programming, because of the plethora of free tools available. And even before Visual Studio had free versions, Microsoft was rumored to be turning a blind eye towards piracy of Visual Studio, so that programmer who used a (pirated) copy of Visual Studio at home would ask for a (legitimate) copy of it at work.
My gut feeling is that Microsoft has turned a blind eye toward piracy by individuals for many years. Almost everyone I know who began doing system administration during the late 90's learned NT4 by pirating it.
In a way it's a smart way to differentiate customers. Since the pirates also add value to the platform you don't want to lose them, but you also want to extract the money you can from those willing to pay. By demonizing pirates while allowing the pirate channel to exist they are able to do both.
Microsoft have been giving free versions of their professional range to students for several years with the Dreamspark program :) https://www.dreamspark.com
Also MSDN Academic Alliance. Almost every MS product except Office is there for students, for free. That includes Visual Studio, all Windows version starting at 98 (including Server editions), XNA, and much more.
Edit: Now I see that it's probably the same thing. I'll leavy my comment here though, if anyone else was familiar with MSDNAA.
On the mailing list, it's planned as a local server + browser http://groups.google.com/group/light-table/browse_thread/thr...
I was thinking a webapp version would be easy to monetize (monthly), but it only makes sense when you have to store data - which I now realize could be the code itself. :) A front-end for developing hosted projects.
It could be sold to amazon AWS, heroku, google apps, IBM/Oracle etc; and perhaps to github, bitbucket, dropbox when they start hosting apps - or start a new dev cloud. (of course, still provide the local server version).
Maybe problems with network latency + javascript performance... but might work for some divisions of labour, on some platforms (e.g. iPad). Network latency is worth it, if the result is faster than a local server could do... and if roundtrip + server was 100-200ms, that feels pretty much instant. If your app is remotely hosted, the main benefit is orthogonal, being convenient access (100% portable dev environment) - so, as JS and networks improve, it becomes more compelling. Test and integration servers can also be remotely hosted - no need to edit the live app. (This approach, like vim-editing remote files, has appealed to me for a long time).
As excited as I am about this concept, I was worried that a Kickstarter-backed project would result in a closed-source deliverable; thankfully it sounds like he's interested in releasing the source at launch. I'll definitely be contributing to this.
Good luck, and stay strong. I think the demo you created was incredibly impressive, and I suspect a lot of people will therefore expect a lot from this product. This is going to sound overly pessimistic, so please forgive me - but I suspect that, as time goes on - and it will, because to me the goals of this project seem huge, and the problems you're attempting to solve seem hard - you'll probably cop a bit of backlash over the time taken, not living up to expectations, etc.
I hope that if that happens, you're able to ignore it and keep working on it anyway. Regardless of whether you accomplish your goals or not, I'll happily be throwing some money into the kickstarter and crossing my fingers for you guys, because the actual idea behind this is awesome.
Thanks I appreciate the support and it's a good reminder :)
I completely agree with you. There's always good and bad to presenting something like this. On the good side it gets people dreaming - it leaves enough to the imagination for it to seem amazing, for the possibilities to be endless. But unfortunately those things cannot map perfectly to reality, at least not all of them. Having worked on VS, I definitely know I can't build an IDE over night, not by myself, not even with 100's of people. And for some that will take the magic out of it initially. The way to combat that, though, is through transparency I think. I will be very open as the project goes on. I want people to know what we're thinking, what we're working on, and why we're doing it. My hope is that we can sustain a dialog as time goes on about how we as a community of creators go about creating things.
Despite the realities though, I will do my absolute best to deliver some of that magic. :)
With that said, most of these ideas have been in one demo or another for quite a while. As soon as you leave toy problems behind and try to visualize loops, objects, and deep recursion it's next to impossible to visualize flow and your back to inspecting breakpoints. But, if you want something you could probably implement and get people to use I would suggest something like XSL-FO. It's a pure functional language so you don't need to worry about loops, objects, or changing state just deep recursion. Unlike Lisp, C#, or even Java there is no great IDE's out there and your rarely dealing with multi megabyte's of code. You can even start with XPath, XSL-FO, and then try and get a more complex functional language working.
Transparency is a great idea. May I suggest starting off by releasing your intended feature list for the product? That way, with each release, you can cross things off the feature list, and people can see that you're making progress.
Going to disagree that this is a good idea. One of the worst things you can do is release a product "road map." It makes expectations way too specific, and will put you in the position where if you need to alter or change that roadmap you are going to get pre-emptive backlash for work you have not even done yet.
I could not switch away from vim for some kind of meager and broken vim-ish interface. Apparently "vim bindings" just means jklhiI$^0/ support, as if that's in any way able to approach an iota of what makes vim great.
Don't even bother with vim key bindings. I have yet to see even half-hearted support for a decent vim like interface on these new web based editors. The fact of it is that being as powerful as vim requires a decade or two of work more than anyone is willing or able to offer. If these people looking for a new editors all the time are not already using vim I doubt they would have the patience it would take to get it up to vim's speed.
I wholeheartedly agree that there is more to Vim than jkhiI$&0... but berating such a fantastic product is very counter productive.
Instead, think of ways (or contribute ways) to improve the VIM plugins to Code Mirror. Even suggesting which other parts of VIM you find so useful would be of more use than berating them for using VIM plugins instead of VIM itself.
Ignoring OP's harshing, it does seem hopeless. There's little incentive. Probably the easiest way is to compile vim direct to javascript (or java), and ignore/hack the OS integration. Unfortunately, improving the plugin seems to have fundamental limits (see the js for the actual bindings http://codemirror.net/keymap/vim.js - there's a few more than I'd expected):
> Because CodeMirror's internal API is quite different from Vim, they are only a loose approximation of actual vim bindings, though.http://codemirror.net/demo/vim.html
From a theoretical point of view - all text editors offer nearly the same feature set, so all features should be available through a different set of keybindings.
In reality, of course, this can be difficult if the editor doesn't offer reasonable support for accessing all of the keybindings through the API.
Still, CodeMirror does seem to offer better support than most.
Could you switch away from vim for the other features that Light Table might have? Your comment makes me think you didn't read or watch the demo posted earlier. The point of vim bindings would be to make you a bit more at home, nothing more. Same with Emacs bindings.
There are of course serious tradeoffs involved with making Light Table an in-browser or webview based editor, but it's definitely not clear cut. I'm sure you could build Light Table as an Emacs mode, a Vim plugin, or an Eclipse plugin, but then it would be tied up with that platform, and people would have to re-implement it (badly) elsewhere. See the poor Java support outside of the big and bloated IDEs like Eclipse.
Furthermore, before you denigrate web based editors like CodeMirror, consider what a crazy idea they are in the first place, and what it takes to build something as good as CodeMirror: http://codemirror.net/doc/internals.html
depending on how we do on the funding route, python and ruby would be my next choices. JS is the next easiest one to build this for I think (though it's far more difficult than Clojure).
Either way, even if we don't end up building it, I certainly believe it will materialize :)
Do you plan on launching with Clojure support, and then later on add JS support? Since JS is far more difficult, do you worry that the project will morph into a quagmire as you try to fit all of the features in? Do you have a plan to mitigate that risk?
I'm sorry, this is off-topic, but why did no one tell me how impressive Code Mirror is. Every limitation I can think of in a browser-based text editor is accommodated in the usage examples. Honestly, I couldn't believe he was going browser-based with this. Will be cool to see.
Please please please support parenscript for customization (this means you write a parenscript API that looks a lot like elisp).
Plenty of editors think "emacs bindings" means C-n, C-p, and C-v, and hardcode C-space to something intellisense-ish. And forget about the kill ring or infinite undo.
These are the heart of emacs. If you don't have them, emacs users will never be able to switch.
That story did seem to spend an inordinate amount of time on the front page, but I've been noticing that in general there has been slower turnover on the front page. I wonder if there has been an algorithm tweak or if it is due to some change in community behavior.
I notice that to, figured the community was just piling on more to the current top stories. Diversity is a little down, I assume new submissions are still rising, just less being seen.
This is what I envisioned for the Scala IDE when I started that project 6 or so years ago. But I got frustrated when it started turning in a Java-Frankenstein monster that was trying to embody all of what I thought was wrong with Java ecosystem. Eclipse just wasn't the right platform, and the Eclipse IDE metaphors are just clunky and outdated. My ScalaLive proposal was perhaps 6 years too early, while I never really figured out to package up my live programming work as well as Bret and Chris have.
I'm glad that this project exists and is being pursued. Its about time!
Not to sure if anyone has mentioned this yet. If you run light table as client(browser)/server model, then effectively your sever could run in a cloud and your session would be reachable from any browser no matter where and what computer or smart phone/tablet you are on.
With things like ClojureScript and Meteor, this is very achievable today and a definite game changer. Exiting times we live in.
It's not taboo - just observe the success of Visual Studio.
I think charging for tools does limit the potential user base of those tools. After all, why pay for an editor when vim is free? The same applies for a lot of development tools.
Another potential reason is that charging for something creates an expectation of quality and support. This attracts certain classes of user, but not everyone wants to provide this expectation. Giving the tool away for free helps absolve the developer of responsibility at a later date.
There's another caveat. Just look at what happened to textmate, it was closed source many of us paid for it. The author decided to rebuild everything and we didn't get any real update for like three or four years. And yet we couldn't do anything about it. And yet it didn't met the community expectations.
Seriously, building a code editor is a massive amount of work, having it open means you'll find someone to help if you don't have a massive company like microsoft behind you.
Frankly TextMate met my expectations just fine and I don't regret paying for it.
> we didn't get any real update for like three or four years
Call me old-fashioned but I can't keep up with updating all my tools every few month. Maybe three four years is a bit too long but it's nice to have some period of stability. Despite not having major updates TextMate remained very popular. It must have gotten many things right from the very first release. I wish there were more products like that.
Well, there are things you can expect from a code editor, like not crashing or getting sluggish because you opened your logs. At least this issue was present when I left Textmate.
Besides that kind of details, Textmate is indeed a very well made product, that go t a lot of things right from the beginning as you said. But it's just sad to see it just "froze" as it is.
Anyway it's not really about an update frenzy, it's basically as it's not an open product but one we paid for, I expect them to polish it over time.
Id like to see a pricing model similar to SublimeText - full functionality with very occasional prompts, in Sublimes case when you save.
Since the prompts are user invoked they're discrete enough to allow an unlicensed SublimeText to function as a main editor without making the user feel nagged, it's inexpensive and with its indie developer engaged in the community & active in improving the editor licensing has a feel good factor attached.
82 comments
[ 2.2 ms ] story [ 152 ms ] threadOne thing that I'm curious about, however: it (seems like it) will be a web-based platform. Can anyone comment on whether or not this is an advantage or disadvantage? I imagine a fully functioning offline mode will be available, and I can see chaching things like documentation locally, etc. But there must be a compelling reason that newer editors are not web-based (or maybe the better term would be browser-based).
Essentially you write your application in standard html/css/js and are then able to distribute OS-specific applications for all major platforms.
Similar to PhoneGap, but I think the results are a bit better with desktop apps :) (especially something as "simple" as a text editor.
Could you briefly explain your decision of using CodeMirror instead of Ace editor?
[1] http://github.com/coreh/nide
Can't wait to see alphas and play with the bindings, as well. I would love to get a chance to see if it would be possible to run an out-of-band process to run some of the same stuff for a compiled language that does have a REPL and stuff that produces nice ASTs from code (e.g., Scala or even Java).
I also get the feeling there's going to be some space here to ease things with regards to testing… Not only because you'll be able to see your tests expanded instead of having to step through, but I think there's potential for just running some test code, seeing the output, checking it's right, and then hitting a key combo to codify that into an automated unit test.
Definitely feels like there's so much awesome lying around the corner. Mad props for putting this together and deciding to carry through with it. I'll be keeping an eye out for the Kickstarter.
I definitely have thoughts on testing and there's a ton of interesting stuff we can do there.
Me too. One thing that might be helpful is looking at Cloud9 editor, which just recently added a "VIM Mode".
On the other hand, dev tools are expected to be free and it feeds massive adoption (and if not free, devs have the ability reverse engineer e.g. linux and gcc). The common wisdom is that smalltalk got killed by high prices. There are exceptions: MS VS; some editors. Maybe the older, broader the appeal, and closer to the dev, the greater the pressure for free - so that new, specialized, and close-to-customer tools resist commoditization. Light table is new, but general and close to dev.
The Street_Performer_Protocol http://en.wikipedia.org/wiki/Threshold_pledge_system#Street_... fits perfectly with KS. But personally, I love the idea of making something great and getting rewarded in proportion to its greatness (as in product sales), not a fixed reward. An ideal solution seems to be to charge large customers (e.g. over 10 employees? Over 100?), but I've not seen this explicitly attempted... but I guess it's achieved by "enterprise" versions, with extra features, particularly those needed only by large customers... that may be what is being considered with "some plugins may remain closed source". Then one could create a marketplace for plugins, an app store etc.
Edit: Now I see that it's probably the same thing. I'll leavy my comment here though, if anyone else was familiar with MSDNAA.
It could be sold to amazon AWS, heroku, google apps, IBM/Oracle etc; and perhaps to github, bitbucket, dropbox when they start hosting apps - or start a new dev cloud. (of course, still provide the local server version).
Maybe problems with network latency + javascript performance... but might work for some divisions of labour, on some platforms (e.g. iPad). Network latency is worth it, if the result is faster than a local server could do... and if roundtrip + server was 100-200ms, that feels pretty much instant. If your app is remotely hosted, the main benefit is orthogonal, being convenient access (100% portable dev environment) - so, as JS and networks improve, it becomes more compelling. Test and integration servers can also be remotely hosted - no need to edit the live app. (This approach, like vim-editing remote files, has appealed to me for a long time).
I hope that if that happens, you're able to ignore it and keep working on it anyway. Regardless of whether you accomplish your goals or not, I'll happily be throwing some money into the kickstarter and crossing my fingers for you guys, because the actual idea behind this is awesome.
I completely agree with you. There's always good and bad to presenting something like this. On the good side it gets people dreaming - it leaves enough to the imagination for it to seem amazing, for the possibilities to be endless. But unfortunately those things cannot map perfectly to reality, at least not all of them. Having worked on VS, I definitely know I can't build an IDE over night, not by myself, not even with 100's of people. And for some that will take the magic out of it initially. The way to combat that, though, is through transparency I think. I will be very open as the project goes on. I want people to know what we're thinking, what we're working on, and why we're doing it. My hope is that we can sustain a dialog as time goes on about how we as a community of creators go about creating things.
Despite the realities though, I will do my absolute best to deliver some of that magic. :)
With that said, most of these ideas have been in one demo or another for quite a while. As soon as you leave toy problems behind and try to visualize loops, objects, and deep recursion it's next to impossible to visualize flow and your back to inspecting breakpoints. But, if you want something you could probably implement and get people to use I would suggest something like XSL-FO. It's a pure functional language so you don't need to worry about loops, objects, or changing state just deep recursion. Unlike Lisp, C#, or even Java there is no great IDE's out there and your rarely dealing with multi megabyte's of code. You can even start with XPath, XSL-FO, and then try and get a more complex functional language working.
Don't even bother with vim key bindings. I have yet to see even half-hearted support for a decent vim like interface on these new web based editors. The fact of it is that being as powerful as vim requires a decade or two of work more than anyone is willing or able to offer. If these people looking for a new editors all the time are not already using vim I doubt they would have the patience it would take to get it up to vim's speed.
Instead, think of ways (or contribute ways) to improve the VIM plugins to Code Mirror. Even suggesting which other parts of VIM you find so useful would be of more use than berating them for using VIM plugins instead of VIM itself.
> Because CodeMirror's internal API is quite different from Vim, they are only a loose approximation of actual vim bindings, though. http://codemirror.net/demo/vim.html
In reality, of course, this can be difficult if the editor doesn't offer reasonable support for accessing all of the keybindings through the API.
Still, CodeMirror does seem to offer better support than most.
There are of course serious tradeoffs involved with making Light Table an in-browser or webview based editor, but it's definitely not clear cut. I'm sure you could build Light Table as an Emacs mode, a Vim plugin, or an Eclipse plugin, but then it would be tied up with that platform, and people would have to re-implement it (badly) elsewhere. See the poor Java support outside of the big and bloated IDEs like Eclipse.
Furthermore, before you denigrate web based editors like CodeMirror, consider what a crazy idea they are in the first place, and what it takes to build something as good as CodeMirror: http://codemirror.net/doc/internals.html
20,000 years from now, if we've survived this far, you'll find Pham Nuwen hacking away at some backdoor program in vim.
If you're not familiar with him or his work, here's a good start: http://vimeo.com/36579366 http://worrydream.com/#!/KillMath
http://news.ycombinator.com/item?id=3746692
(...but imagine it's probably just a matter of time.)
Either way, even if we don't end up building it, I certainly believe it will materialize :)
Plenty of editors think "emacs bindings" means C-n, C-p, and C-v, and hardcode C-space to something intellisense-ish. And forget about the kill ring or infinite undo.
These are the heart of emacs. If you don't have them, emacs users will never be able to switch.
If it doesn't have proper support, perhaps you could help add it?
I get that codemirror is the thing to contribute to, I don't have the time right now but hopefully someone will.
I'm glad that this project exists and is being pursued. Its about time!
With things like ClojureScript and Meteor, this is very achievable today and a definite game changer. Exiting times we live in.
[edit] Oh and good luck Chris and the team.
Almost fits better... as in we're leaving the past, or era of emacs/vim.
Still, I remain curious if this was deliberate or typo?
I think charging for tools does limit the potential user base of those tools. After all, why pay for an editor when vim is free? The same applies for a lot of development tools.
Another potential reason is that charging for something creates an expectation of quality and support. This attracts certain classes of user, but not everyone wants to provide this expectation. Giving the tool away for free helps absolve the developer of responsibility at a later date.
> After all, why pay for an editor when vim is free?
Why develop a new editor if it's not gonna be better than vim?
Seriously, building a code editor is a massive amount of work, having it open means you'll find someone to help if you don't have a massive company like microsoft behind you.
> we didn't get any real update for like three or four years
Call me old-fashioned but I can't keep up with updating all my tools every few month. Maybe three four years is a bit too long but it's nice to have some period of stability. Despite not having major updates TextMate remained very popular. It must have gotten many things right from the very first release. I wish there were more products like that.
Besides that kind of details, Textmate is indeed a very well made product, that go t a lot of things right from the beginning as you said. But it's just sad to see it just "froze" as it is.
Anyway it's not really about an update frenzy, it's basically as it's not an open product but one we paid for, I expect them to polish it over time.
Since the prompts are user invoked they're discrete enough to allow an unlicensed SublimeText to function as a main editor without making the user feel nagged, it's inexpensive and with its indie developer engaged in the community & active in improving the editor licensing has a feel good factor attached.