The future is specific
chris-granger.com
chris-granger.com
Eclipse really makes Java programming very easy. And I can tell you minus Eclipse programming in Java would be a very frustrating experience, given the verbosity, configuration mess and XML's all over the place. Eclipse these days is advanced enough to really blur the difference between and novice and a expert Java programmers. So by any measure I would say eclipse already does what light table aims to do. The only problem with eclipse is its too heavy, chews a lot of memory and becomes very heavy as things go on.
What we expect from light table is really what things like Emacs and Vim already are, plus what they miss. Which is modern GUI candy, easy configuration, availability of packages, stuff like refactoring, bench marking, auto complete and Intellisense easily available out of the box. Along with evolution with modern needs and demands.
So that is why what we really needed was an Emacs + all that I mentioned.
I think it will be nice if at some point requirements are frozen for Light table. Because things like this really slip into Second systems effect easily.
According to me Light Table must be Emacs for the Modern Generation. Anything else, and it won't be impressive. A thin editor, extensible by lisp. All lisp and other Emacs editor goodies but with all the modern demands.
We already have enough of other kind of IDE's.
I think the parallel to emacs is a good one and while I certainly won't say at this point that we'll be the "modern emacs", it's our hope we can come close.
Well, Clojure too, on the server side of things.
We need to really keep Lisp as the extension language.
I think what we need is Light Table with something like this : http://www.kickstarter.com/projects/568774734/emacsy-an-embe...
You have to develop Light Table ON the Emacs OS!
The whole approach is guaranteed to not produce a perfectly compliant of any other language.
So long as it's close enough, you don't need perfect compliance.
truth-tables for (nested) if statements
petri-nets for a state machine
etc. etc. etc.However, what I see is people using dynamic languages because they are what frameworks are written in, not because they want to use a dynamic language. I hope that LightTable incorporates a packaging mechanism such that we can have a Ruby on Rails package, for example, and the 60% of RoR developers who never tweak anything can be more productive.
The problem is that you can give an excellent developer an unspecified tool and they will make it serve their purpose. We need the ability to pass those productivity improvements down the food chain, which is where Emacs fails utterly.
I'm not sure about that... Eclipse gets fatter and slower with each release. Of course, I still use it because Google really wants Android developers to do so. In my opinion, the most frustrating thing about using Eclipse for Android work is that it crashes every time I try to export a package, unless I close every open file and restart Eclipse before trying. (the problem is mitigated by disabling automatic builds)
I guess that's because Eclipse runs on Java and Java is wasteful. It would be really nice if we could have a "native" equivalent of Eclipse, with less bloat.
Edit: Typos.
(And then there's the UI bloat, which makes Eclipse look like this by default: < http://www.flickr.com/photos/geofharries/5145925147/sizes/o/... >. But that's a totally different issue. Thank goodness for Fast View.)
The issue is that it's more than just a Java language editor. Once you load it up with all the extras to accommodate development models, frameworks, runtimes, build processes, etc. it does become an unwieldy mess. But it's really hard not to considering how moving parts large-scale development has.
Emacs was born in a world of textfiles, Light Table shows us a post-textfile world, but before we can get to the future, it needs to be able to survive in the world we live in today, which is one where textfiles are king.
"If you couple [DSTs] with the generalized editing capabilities I showed last time, you have what we believe to be the future of tools: an environment that you are able to mold to the exact shape of your problem."
I agree, we have no intention of removing general editing - you need it as much as anything else at this point.
Why should I trust you to provide the most fundamental tool in my work?
That's not to say it won't happen, but the fear is there.
I'm fine paying for servers, for contractors, services, random productivity-ware like Pivotal Tracker etc. but I'm never going to be okay with subjecting my development environment, something I've honed for years and years, to fee extraction or proprietary control by a commercial entity.
You're right.
>I think it would be a mistake to do so.
Maybe.
>Visual Studio is very popular... When Light Table comes out
Does not follow. Visual Studio users will NOT be using Light Table even if they're aware of its existence (and they won't be, save for the few poor bastards working in Microsoft-land and reading HN).
Light Table, in terms of addressable market, is really only talking to grumpy hackers like me and startup people. Maybe particularly keen hobbyists who are good at following the state of the art.
> We're not the target audience.
Then why is his open source community (Clojure) and people he's reached mostly involve exactly our target audience?
>I'd rather that be the case and see a pretty end-product that serves its original goals well (and I may even try it for fun if it's free) than having a half-baked "vim-mode" stuck on at the end just to try and attract me.
That is...not what I was talking about. Did you even read what I said?
I was talking about freedom, not bolting it onto an existing editor. The point is that I don't want to Monsanto-ify my tools and be dependent on an unaccountable commercial entity for how I work.
Building a lighttable mode or even several small modes (libraries vs framework) for emacs would make more sense.
It is going to require a huge effort to duplicate a fraction of what it provides already.
But from a marketing point of view it is/was probably smarter to show eye candy to attract funding, but I am not sure it is the best route in the long run.
Though, is LightTable the best/easiest way to get that? I don't know, it may be easier to render emacs buffers into a webkit view, it may also not be.
That is what I meant with "connect to browser instances" (swank-js already allows that, among others). Basically when you need more advanced rendering, or browser environment when it is your target (browser based games and whatnot), this could be good enough and you can leverage a huge ecosystem for all the rest.
Can you come to a realization in the middle of an Eclipse debugging session, get a great idea for making yourself more productive, take time to script yourself a working and fully debugged extension of Eclipse and continue what you were doing 20 minutes later?
I've done precisely this in Smalltalk on many occasions. You can script something like a custom browser that shows you everything that uses function A and also function B and has a reference to class C (and with complete syntactic accuracy) in around that time.
I suspect that this kind of very small grained toolsmithing is common for really good programmers in dynamic environments. The only problem is that it's been harder than necessary to integrate that with the most commonly used coding tool. (TextMate's ability to export selections to scripts is very nice, but it can go farther than that. Emacs is very powerful for this, but not everyone wants to script in elisp.)
It's not that Light Table is going to do something unprecedented. It's more like what git did with quick access to diffs: a quantitative change can become a qualitative change. Change the cost-benefit of toolsmithing, and you can use it in new ways.
For a simple example, Acme has no paragraph justifier, but it doesn't need one, since fmt exists. To use it, highlight a paragraph of text with the left mouse button, highlight a typed-in |fmt command with the middle mouse button, and release the middle mouse button to run the paragraph through |fmt and replace it in place.
With this I can leverage anything I can call from the command line, in any language, to be part of my editor. No need to rewrite tools in the program's specific extension language, whether Elisp or Smalltalk or Clojure.
As another example, since it's so easy to just run a shell command from Acme (highlight the command text and middle-click it), I'm constantly customizing pre-written shell commands to e.g. grep for lines in code (to the point of creating indexes on the fly for files), and then right-clicking on grep -n output to jump to a specific line in a file.
The feature you're describing is awesome and useful, but I wouldn't be happy to have to use mouse for it. Is there a way to invoke it from keyboard in Acme?
You actually couldn't have everything update automatically and expect bad things never to happen. Functional programming has an advantage here.
To make Light Table work, you don't need 100% perfect semantics. You just need 99% good semantics, plus some way of turning off automatic refresh and refreshing manually.
For the "20 minutes later" version, I typically abuse JUnit tests, or use search+working sets.
What Eclipse misses more than anything else is performance and generalization. It's sufficient for my Java work: it is insufficient for my four-language code base.
“Making Java programming easy” is not one specific task!
I'm personally much more fond of the Unix 'tool approach', in which there are no task-specific modes or plugins, but tools can still be composed ad hoc, as in Plan 9's Acme.
The idea is that Light Table will be built from the ground up to support very dynamic environmental contexts in which you can place anything.
The comparison to emacs isn't meant as a slight to LightTable either, but please, let's not forgot the past when creating the future.
With that said, wouldn't his "It's hard for me to imagine being able to build anything I showed in say Eclipse in any reasonable amount of time" comment also apply to Emacs?
Light table looks to me (with all the respect due to the work of the authors) like a fad where people get all hyped up about a product. I mean there's nothing revolutionary and while looking at the video I was thinking "boy this is too confusing!". I also believe that when the project is going to have 500+ lines of code per file, the way it's done now, is going to be horrible to deal with it!
There are other stuff that bug me out: when I program I don't want rounded borders and everything. I don't want 40 different colors.
But if people are going to be it, great.
As for the rounded corners, I think it really is a matter of personal preference and they're definitely not going to affect my ability to program. Colors are just used to visual convey information seamlessly (think syntax highlighting). I think they can really be put to good use.
I do agree with you that huge "files" (the concept seems to be abstracted by the IDE) could get messy. However, I trust the Light Table guys to get it right :)
Isn't that the whole point? To me this looks pretty amazing.
That's just one example. The same conceptual problems pop up for stuff like on-the-fly code execution (what if your code depends on user input or many SQL queries or files that may or may not exist at that point), benchmark mode (benchmarking a complex app is obviously a lot more complicated than just running two code blocks side by side), etc.
I know this is just a demo and it's all very early in the process, and I'm not saying that this should be a solved problem yet, but I just can't picture in my head a way that this could ever be a solved problem as long as LightTable remains somewhat similar to its current state.
To your second point the normal caveats of a replish environment will apply to any code execution stuff :) And the benchmarking mode was a simple example for working against functions once you already know they're the bottleneck. In a real application you probably need help getting there.
I agree and I think a big part of the job ahead is to understand how we can ensure these sorts of experiences mesh and flow together when working on something larger. Fortunately, Light Table itself provides a great project to prove that on.
For those who can't use vimeo: http://www.youtube.com/watch?v=osLReQSB9F0
Extensible tool-building platforms for DSLs are hardly anything new. Reading things like this, i sometimes worry that the HN-circling web crowd is reinventing things that others invented just a few years ago. Like some sort of collective not-invented-here syndrome.
E.g. Check out MetaEdit+ - their website isn't Silicon Valley Sexy, but the tool is amazing. And has been, for the past 10+ years. http://www.metacase.com/mep/
Now, there's plenty new and well-rehashed ideas in Light Table. I'll be buying a license, probably. But the insight in this article isn't very new at all.
The difference in this case is that the HN web crowd are targeting their fellow programmers, and not the "Enterprise" crowd.
I've been following the DSL tooling scene, and it's horrible. Think closed source, expensive and targeted at the Enterprise (or specific engineering disciplines).
The community is full of MDA (model-driven-architecture) types: too often is the focus on increasing complexity (for ego boosting / job security) instead of simplicity and accessibility.
The HN crowd are pretty much the polar opposite: the focus is on simplicity and scale. Sharing knowledge, instead of locking it up for fun and "profit".
That's why I like it here :)
still, if you ignore the MDA and executable uml silliness, there's quite a few ideas that can be picked from that closed space, imo.
Thats what Light Table does, isn't it? If not it will at least allow you to implement these ideas in a simple way.
Is Light Table going to solve that problem? Unfortunately this blog post and the videos don't demonstrate how you create these modes. Do you have to become a clojure, clojurescript, html5, css expert?
On the gripping hand, there's zero chance that I'll be trying to replicate that functionality in emacs. Even with the wiki, and it's random ~/Desktop/elisp_notes.ver2.txt feel, isn't that helpful.
With some work it would probebly be possible to make the Server IPA more general.
How is that goal different from that of the Eclipse platform (http://www.eclipse.org/platform/overview.php) - a common base where people can develop individual add-ons to suit the domain they're working on? Eclipse platform and LT clearly have different interaction models and technologies, but from the leading quote of the article, the same goal.
Writing Java in Eclipse is, as many have said, a great experience (in the continuum of Java-development experience). But you know what else is pretty good? PyDev (http://pydev.org/) - a Python IDE that's written on the Eclipse platform. It uses the same interaction models and designs as Eclipse for Java, but it's also got a whole bunch of bits that are just targeted at Python development. There's also a tool (the name of which I don't recall) that our DBA uses for all his database management that's written on the Eclipse platform.
I'm all for specific - I use PyCharm every day, which does one thing (Python development) really well. But I think calling out Eclipse like the parent article does is wrong. It too can be a platform for "easily created domain specific experiences"; it's just a different one with a different paradigm.
It's not. It's really not. I've heard good things about PyCharm, but the best environment for Python that I have seen so far is Emacs. And Light Table definitely looks like an improvement on that. My only concern with this is the speed. I want this to have the same response time as Emacs or Vim. Then there would be no reason not to use it.
Once I started working in Python and spending 30-something hours/week in the environment, its flaws started to overcome its benefits (namely: it was free, and I knew how to use it), and it was time to move to PyCharm...which is also slow, unless you throw a few gigs of RAM at it and at which point it becomes amazing.
When I was learning to code, and still sometimes, what annoys me about typing is that I don't know what I don't know. With graphical programming, having predefined modules with discoverable inputs and outputs encourages me to try connecting things together on a what-if basis to a much greater degree than a textual environment. This is what I find very attractive about the way Light Table is going; a lot of the time I want to build things but not necessarily to write code.
As much as I like vim - it remains software from the stone age and it seems absurd that our main work interface (editor and shell) still consists of an emulated 1980s text-mode terminal.
LightTable looks like a major step in the right direction. I think the best indicator for success will be when the vim/emacs-diehards start porting their respective shortcuts and functionality over.
I could very well see this fundamental approach (modular/dynamically expanding interface) become the new paradigm for editors and (hopefully) terminals if the author manages to make the prototype versatile and hacker-friendly enough.
We've really been entrapped inside ancient TTY-emulations and inadequate GUI-widget sets for way too long.
I probably have a unique preferred layout of Vim splits and tabs that I use for each codebase I work with. Being able to take this further, telling the editor which parts of code are significant and in which ways they go together, I'd have so much less mental overhead.
I love the idea that I could navigate our current codebase by endpoint, jumping to the account management portion of our API, automatically having the relevant back-end code and unit tests on-screen, along with benchmark info and test results. Since we adhere to general conventions at least within a project, there's no reason this can't be done.
By contrast, emacs is basically an application platform that ships with an editor implementation, and eclipse is a platform for building editors.
It's not that vim isn't extensible, it is, just not as much as other alternatives, and nowhere near as easily as most of its competition.
IMO the real advantage of vim is that it is a highly efficient and productive tool that works great without any customization, and is available everywhere without installation. Which is pretty much the opposite of the above opinion.
The Irony! If you find this is what is supposed to replace Vim for you, then Emacs already replaces vim.
He is talking of Extensible Macros for <any tool>. And Emacs is Extensible Macros for Taco Editor.
I guess what you want is Emacs.
I can certainly think of a lot of ideas of what I might try to implement with such an approach. Really any existing code inspection/analysis approach.
I'm thinking some sort of view onto Powershell providers could be interesting.
Maybe exception lookups in the code as your browse through an error log.
Definitely a regex tester utility: does your string match the regex? Do parts of it match part of the regex? What's an example string that would match? Can we display all of this dynamically in real time?
...going to end up being Eclipse.
So either a massive wheel is being reinvented, or Light Table will be absent of all standard IDE features and consist of the flashy neato Code Bubbles stuff and not much more.
That said, I say develop the hell out of the Light Table concept for all the "new age" (circa 196X) dynamic coder people since their IDEs tend to suck, and let's hope it becomes a standard and we can implement it all in everything else. :)
Basically, I'm excited about Light Table because I think it will help me become a better programmer.
I like what Light table is trying to do, hoewver it is still working in pretty much the same 'domain' space as existing IDE's ('code'), and trying to improve on the 'easily created... experiences' part.
As the post is waxing lyrical, my piece to add to the broad-concept discussion is that I'd really like to see more programs which try to be applicable to a broad variety of non-coding domains, which actually occupy the majority of the work that people do on computers (working with images, working with spreadsheets, working with documents and pages, working with 3d spaces, animation, realtime information, etc.), allowing the easy creation of 'domain specific experiences' in these, which is generally impossible or very difficult in most of todays pre-compiled software for these tasks.
[I hope that all makes sense to someone :) Would also appreciate any discussion as something along these lines is a side-project of mine atm]
Best of luck to you by the way :)
Similarly, if you edit one of the "supporting" functions that appear and want to save those changes, will they be saved in-place (e.g. line 217-241) in whichever file that function is from?
"Bret Victor - Inventing on Principle" (http://www.youtube.com/watch?v=PUv66718DII)
Make tools to be extensions of our bodies via immediate feedback is a useful idea (it is not the main point of talk, but it stands out to me).
As a side note: It might be even be literally true for physical tools i.e., a brain can physically change to see the tool as an extension of the hand (from a study about ape, its brain, and a stick).
Do you have specific plans on how to incorporate version control when not primarily relying on files?
what do you think?
With your aditued there will not be that much progress, since everybody would have just said 'mmhh lets not develop a good compiler for C lets write assembler'. In my opinion as long as people develop better tools (languages, IDEs, compilers, debuggers) there is need for them. If one guy spends a couple of month on a Tool, how long will it take until the time saved is 'recoverd' by the users of that tool? Making tools yileds economic benefit, just like in the real word a maschine that does something better or faster will result in economic benefit.
That is not do say there is never mal-investment. Somebody might spend a long time developing something and nobody will use it, programming related or not. This however is not an argument for no innovation.
Here me out: the people who aren't in IDE's all day could benefit the most from this. They don't know where the functions are or even how to find them sometimes. I resort to google 9/10 when looking for how some functions.
This has huge applications for helping non-programmers become programmers.
Google didn't win by being the best general-purpose search, where people go to look for anything on the Internet. It won by being the best for searching only um, okay not the best example.
Facebook didn't just raise 14billion at a valuation of 100billion by being the best general-purpose social network, where just anyone would have a profile. It won by being the best network for, uh.. Okay, not the best example.
Well, take a revolutionary new product like the iPad. It doesn't have hundreds or thousands of apps to do uh, hold on. I'm sure that somewhere there's the ONE thing that it does. Uh, it's a screen?
Look, step back. There's only one thing you can do in Photoshop. I mean there's just one thing to use Ubuntu for. Sorry, I meant that when you say the word 'Harvard' everyone knows what the ONE thing that they teach is!
Okay, look, these might not be the BEST examples in the world. Take a pair of jeans. There is ONE time and ONE place to, uh.
Fuck. I'm done. If the future is anything like the present, nobody even knows what the fuck business Amazon is in anymore.
http://finance.yahoo.com/echarts?s=AMZN+Interactive#symbol=a...;
The future is the very opposite of the word "specific".
That's precisely what is being proposed here: a platform for creating a development environment that is more than the sum of its parts. Something that gives you composable pieces that can be fit together into something that maps directly onto your problem space.
Is this really so unclear? I can't picture the hypothetical product that you're arguing against.
You probably understand what you're saying better than I do, so please do explain. Because from where I'm standing, it seems the whole march of the Internet is in busting domain-specific-languages and approaches. Every time a cute hack with CSS hits the front page, it's proof that CSS derives its power precisely from not being a domain specific language. Off-hand, can you name a single domain-specific language or approach that has really 'won'?
You may know more about this than I do, so it is certainly a genuine question.
http://www.cssplay.co.uk/menu/amazing.html
or just google for hackernews posts like entirely in css, pure css, all in css, etc. Hell from a quick glance it seems that if you google for 'in css' half the posts on hackernews are like that...
http://y.ww.com/item?id=2636440
It's not hard to see where this is going...
I'll repeat that again: it's not the approach that's homogeneous, it's the quality.
You can see this with Apple, too. Their devices aren't limited to some set number of use-cases, it provides an API and ecosystem for creating new, domain-specific applications. You mention Objective-C in your response, which is kind of missing the point; we're talking about domain-specific applications, not domain-specific languages. LightTable will presumably be very consistent and general at the API level, and uses Clojure, which is a general-purpose language as well.
As for Amazon, their offerings span the entire spectrum from general to domain-specific. You can get an empty VM, but you can also get something like Elastic MapReduce. Amazon will happily develop domain-specific products on top of their platform as long as there's a large enough market.
Finally, look at Rails, which is a framework specifically for creating web apps. It doesn't help me write a new NoSQL server, it doesn't help me write a new AAA video game, it seems to be doing okay all the same. It's used because it's a really effective lever in certain, specific cases. If we can have a development environment which is a similarly large lever across a wide range of cases, how could that ever be a bad thing?
All those hundreds of thousands of iPad apps: mostly very specific, some wildly so.
Increasingly these days, every business Amazon gets into, it builds a different interface for. Certainly that's the case with their electronic and downloadable offerings.
Even Google web search is fairly specific when viewed in context of their putative mission to organize the world's information. It sure doesn't look like Groups (and thank god for that).
And Light Table itself: not very specific. A general platform.
The word "platform" is key, I think. The link discusses what we put on our platforms.