- Smallest unit of code is the function.
- Able to get instant feedback on code changes.
- Multiple editors with just one function in it. Show code
in an "area of concern" not just in a file.
- The coding environment can show also results, app
windows, graphics, other tools.
- Can save the configuration of the above.
Smalltalkers have been doing this in commercial projects since the 80's. If only we could have communicated about this as well as Mr. Granger.
EDIT - Also:
- 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 instaneous results
- We can shine some light on related bits of code
Things like this were happening in Smalltalk environments since the 80's. The first and the last points above were satisfied by lightning fast "senders" and "implementers" searches.
Of course this comment was inevitable. If Smalltalkers really believe their environment is the right way to code, their attitude should not be one of "we did this first, meh" but instead be "here's what we did right, here's what we did wrong. heed the lessons of history and good luck, you are on a mission from God."
I think with the proper care and nurturing, we could be at the beginning of a renaissance where many of the great ideas of the 60s and 70s that have been isolated to a small group of people (who are aging rapidly) are being rediscovered and reimagined by this generation. This is happening in no small part due to Rich Hickey and the Clojure community's unbelievable foresight in developing Clojure and ClojureScript in just the right way that it balances these pure, beautiful ideas with pragmatism in a way that makes them irresistible.
Those who lived through the heyday of Xerox PARC, the AI lab, the lisp machines and Smalltalk should see this as an opportunity to help make sure things don't go off the rails this time. Otherwise, we may end up back here again in 25 years with the C++ and MySQL of the future installed in our cybernetic implants.
I can already point to projects that are invisibly pushing us towards another deep, sticky, next-generation tarpit, and people are diving in because it's not yet recognizable as such. (I won't name names!) Lets try to make it so this time around we truly realize the dreams of computation by encouraging people who are building elegant, beautiful things for the modern era, no matter how much the ideas therein have been tried before.
If Smalltalkers really believe their environment is the right way to code, their attitude should not be one of "we did this first, meh"
That was totally not the spirit in which I meant my post. It's more like, "I told you so!" (My mind works differently, I guess. I present facts that challenge people's model of the world, hoping the curious absorb the information and run with it. Many people seem to take these as some kind of attack.)
I didn't quite "live through" those, being too young (mid-30's now) but did buy a lispm and hack on Smalltalk. I do support things like making Smalltalk Git-compatible, declarative, etc. I haven't jumped on the Clojure bandwagon because I lack interest in the JVM, but ClojureScript is great.
FYI: One thing Light Table could pick up / learn is the ability to scale as function set grows, to gain a kind of fractal navigability.
EDIT: I should clarify that I like Clojure quite a bit. It just doesn't speak to the kind of programming I do "in anger" right now. So I learn about it and watch ClojureScript more intently because it speaks to the environment I've chosen for my products/projects.
It seems that Dan Ingalls, the father of Smalltalk, has picked up the baton again, this time using Javascript. Check out Lively Kernel (http://lively-kernel.org/). I saw a live demo at JSConf, it was pretty jaw-dropping stuff, completely in line with the Smalltalk legacy.
Yes, but our code was entirely in these utterly unusable changeset files that couldn't work nicely with the version control that everyone else in the entire world was using; his version still uses files under the hood. There's a team that's trying to back Monticello with Git, I believe by saving each method into its own file in part of a Git source tree; that looks promising as a compromise.
We also had Virtual Machines with snapshots and rollbacks doing the things VMWare is now pushing so very hard.
I have missed those tools for the past 13 years, since I left the language. The idea that I might get those tools back, in a language that also supports all the emacs-or-gtfo coders, is like promising me a perpetual motion machine. I will believe it when I see it, and until then it will taunt me in my dreams.
As always, the multi-media programming environments are miles ahead and nobody knows about them. Field is amazing. Max/MSP, Pd, et al. are a different paradigm altogether, but have had live editing, documentation a click away, etc. and have been in heavy use for 20+ years.
what smalltalk didn't quite do is the instantaneous view of the results of your code changes. Seeing the result of your changes in Light Table is like updating a cell in a spreadsheet. Smalltalk (I'm guessing), would involve switching to the executing window or hitting a play/continue button. A subtle difference, but it takes the immediacy to the next level.
Isn't it ironic that this is posted on a site that does startup funding and the comments are "please put this on kickstarter" not "please apply for Y Combinator"?
Is it possible that Kickstarter will disrupt Y combinator style startup funding?
If we (the consumers) can bypass the investors and pay for what we want, why do we need the startup gatekeepers?
Obviously this wouldn't work for all startups but a large portion of founders might be better off on kickstarter? Unless of course the advice/mentoring/network effect that Y combinator, et al provide is vital to a startups success.
Although you can argue that a "product does not make a business," many businesses start off with a single product.
Kickstarter is great way to determine if there is commercial viability for an product, but only within the early adopter customer segment -- and that's about it.
YC primarily looks for teams they like. The description of the product idea in the application is indicative of the team's ability to communicate (which is critical), and the actual idea may give a glimpse into the judgement of the team, but a good number of teams (including mine) pivoted pretty dramatically during our time in YC.
Steve Blank, who spoke to our batch, says that a startup is a temporary organization formed to search for a repeatable and scalable business model. Understanding this, and understanding when to pivot, was one of the most critical teachings made by YC.
> Isn't it ironic that this is posted on a site that does startup funding and the comments are "please put this on kickstarter" not "please apply for Y Combinator"?
Why, one can do both :). (eg. Pebble is funded by Kickstarter, but the creators are an YC company)
Anyway, the most important thing is: make it happen, make it happen fast, and don't let it become another CodeBubbles - an IDE idea with a video that captured imagination of programers few years ago, but implementation of which is yet to be seen.
I can't imagine the monetary investment from YC is more significant than the advice and mentoring that you get. Raising $20k isn't impossibly hard. Finding the right mentors is.
Off topic, but an old aphorism is, "If you want advice, ask for money. If you want money, ask for advice." In some ways, asking YC for money is a way of asking for advice and constraining YC to prove that they're sincere.
Kickstarter let's you basically preorder a product that lacks investors.
Being a startup investor has become the game rich people love to play. There are people who'll fund anything in return for a small percentage of the company in the hopes it might be the next Google/Facebook/Paypal ...
Billionaires don't want to be in the smallprinted section of the forbes-list, they want to be "legends" like Peter Thiel or Andy Bechtolsheim and want their name in the history books
Probably the people who mentioned kickstarter tend to think kickstarter for ideas without large profit potential, and unless you also sell a software-deployment platform (like Microsoft and Apple do) tools for programmers does not IMHO have large profit potential.
I'm not sure I agree. Textmate made a crap ton of money, companies like JetBrains and DevExpress have made very successful businesses building dev tools.
And while you mention MSFT as building a platform, if VS alone can make a billion, even without a platform I suspect you could do quite well.
For years I've been bothered by the fact that we still use ASCII text-based documents to program. Having spent a good deal of time programing in APL, a language that uses symbols extensively, I'd like to think that I saw just how different things could be.
Having said that, every time I've looked into graphical programming paradigms they almost always seem to fall apart or get in the way of translating ideas and thoughts into machine instructions.
In the end, at least for me, it's about having an environment and a language that gets out of the way and let's me program the way you'd play the piano: The music just flows and the technical bits that make it happen are invisible.
It's a graphical programming language with an emphasis on system design (for scientists and engineers) that uses a dataflow paradigm (amongst other things) and has a unique UI creation system.
(Disclaimer: I work for National Instruments and my comments here in no way reflect the views of National Instruments and yadda yadda.)
My experience with LabVIEW, for the brief amount of time I worked with it for our high school robotics team, was slightly frustrating. I liked the dataflow paradigm, and to some degree the dashboard system, but connecting and managing the "wires" was a pain. Especially since I'm more comfortable/faster with a keyboard than I am with a mouse.
It also seemed to be harder to read and understand the flow of the code, which made debugging a pain sometimes. I remember struggling to figure out why my code wasn't working, only to find out I had used 1 instead 1.0 as a constant. The only indicator of the data type was a thin colored border around the box.
LabVIEW seems to do a great job as a kind of Visual Basic for scientists and engineers, but I'd probably find it frustrating to spend any substantial amount of time programming with it.
Comics and movies are pretty good ways to tell stories too. Some stories are better suited to text. Some are not. I'm in the middle of making a comic that makes deep use of color and the relative position of panels on the page to tell its story, for instance.
What kind of programs are we missing out on by limiting ourselves to text? What kind of programmers?
I'm not sure if you can say that text is the best way. It's certainly one way to tell a story, and even a fundamental way to tell a story, but there have been many interesting advancements in storytelling in the last few millennia. I also enjoy pictures and, especially, talking pictures.
This is great, however it glosses over the elephant in the room: what if a function is called multiple times, or what happens when code within a function is run multiple times? Which data do you display in the data flow view? What is really needed is an intuitive way to select a context or multiple contexts.
SubText's approach to this is to let you dig deeper in the call tree by clicking on function calls, but for a language like Clojure you also need a way to select a context for a piece of code nested within a function. For example suppose you have
(map (fn [x]
...
...)
xs)
You need an intuitive way to display or select a context for the fn.
And recursion. Light table's display is like a stacktrace, but each line expanded to the whole function. These scaling problems can be solved: exclude some functions, esp libraries (e.g. "native" functions like map aren't expanded). And standard scaling tricks e.g. one line, click to expand (like his doc navigator).
By "context", you mean you nominate a deeper function to display, but then how do you know which call to it is displayed? I think the answer is to display the rest of it, but collapsed/summarized. hmmm, the call trace is a tree in general, so that's getting a little hairier to manage. (NOTE: a tree, assuming you display a fresh instance of a function for each invocation, which you need to do to show the correct variable values)
SubText handles recursion well. It shows the toplevel invocation, and when you click on a recursive call in that invocation, then that recursive call opens next to it. Like this you can expand the call graph as you with.
I can't get my hands on this soon enough. It makes so much sense: we're moving away from the files and folders metaphor everywhere, so why not in the IDE too?
We might not want the hassle of dealing with files and folders all the time, but I sometimes worry that a new generation of "programmers" will emerge who have no understanding of how the underlying filesystem works.
Why is that a bad thing (aside from the "I had to walk uphill both ways through the snow" aspect)?
A significant portion of this generation doesn't understand CPUs and buses. They wouldn't have been able to write anything remotely complex 20 years ago). That doesn't seem to be hindering things much, though. There are still system programmers out there who dive into it, but our abstractions have gotten good enough that all programmers don't need to understand the details to be successful.
(FWIW, I am conflicted on this topic. I wrote a little more here[1].)
I sometimes worry that a new generation of "programmers" will emerge who have no understanding of how the underlying anything works.
For as useful as sites like stackoverflow are for sharing knowledge, it is potentially encouraging a generation of copy/paste coders who's job it is to find and glue snippets together until they get the desired outcome.
Maybe I'm getting old, but I'm starting think some knowledge needs to be earned. [get off my lawn].
If you aren't comfortable slinging files and directories around, you probably aren't a very productive software developer.
As far as ide's go, this concept is definitely intriguing. But I believe putting too much faith in abstractions like what is implied by being function focused(there is no "file") rather than file focused(these are your "files") has the potential of blowing up in your face. I think you need both.
Anyone who had to code on a team using VB6 remembers the pain of *.frx files and how they needed to be version controlled, but you didn't need to worry about them because it was an implementation detail required by the ide. UNTIL, 2 people made visual edits to the same screen and then the project wouldn't open. GOOD TIMES.
Maybe that is a good thing? If programmers have no assumptions or presumptions about files and filesystems, then they are open for innovating new stuff without the burden of legacy.
I'm sad to see the current generation of programmers who don't understand that a hierarchical filesystem is one possible choice for organizing data on an underlying storage medium.
I think there are (at least) two different viewpoints of what is required for people to be able to program (and do it well).
First, an explosion in the power of the hardware being programmed on has made people think less of the efficiency that coding once required and more about getting something done. This feels sloppy, but can be a good starting point for iteration (+1 buzzword).
Similarly, the number of tools out there to get someone (like me) started on programming has EXPLODED in recent years. This results in a lot more people at least starting to code in whatever limited way.
I think it's naïve to think that people who start to code "the simple way" will always code that way. If they're actually pursuing as a career, they will always be digging more and trying to find out why something works a particular way.
Not seeing the filesystem/structure at first glance also isn't necessarily the same as NEVER looking at it or being interested in how the pieces all fit together. it simply means you don't have to worry about it RIGHT NOW.
How 'bout this: have a file system which can contain aggregating symbolic links, with configurable ordering schemes. We can edit functions in their own files and tell the compiler to compile the aggregation. This would be usable for C & C++ as well.
Less likely than our generation having no idea how CPU branching mechanisms work. Files are still how the vast majority of people, coders and non-coders, interact with their documents and data artifacts and organize backups. Anything deeper than that should be abstracted away, since it's subject to change.
Whenever I get the chance to use a spreadsheet, I really enjoy it. I find it really satisfying to set up cascading functions and see them update in real-time. I'd like to see that experience translated to general programming. I'd like to update code and see the unit tests update automatically, and an understandable representation of the objects being manipulated.
/**
* Auto-generated, do not edit!
*/
function add(x, y) {
/* test 1 */
if (x == 2 && y == 2) {
return 4;
}
/* test 2 */
if (x == 1 && y == -1) {
return 0;
}
}
Am I the only one who wants to see multiple, proportional fonts in editors?
Sure, I want to keep the methods themselves in monospaced font, but can't I have the method declaration in a larger size, and comments in a proportional serif?
There is a wealth of design experience out there in communicating things better and more quickly with typography, so why do we not take advantage of that in our IDEs?
Because when people try it, it doesn't look or work very well.
I think it's important to understand that this doesn't mean that such things will never work, but it is also important to understand that almost every idea that you've ever heard of has actually been tried lots of times (lots of lots of times in many cases), and there are often good reasons that they haven't actually been adopted.
As others are already pointing out, the linked proposal bears a striking resemblance to what Smalltalk does, so it's more helpful to ask "Why haven't the many attempts at this approach been successful?" than to ask "Why hasn't anyone tried this?" The first may lead you to a successful variant, the second will lead you down the same garden paths that everyone else went down.
I don't think anything prevents you from setting comments to be a different size and proportional in current editors. I know that it would be trivial in Emacs; some themes actually do that already.
You can try this by doing M-x modify-face, entering font-lock-comment-face then "DejaVu Sans" (or any other proportional typeface) and pressing enter a bunch of times.
In most cases there's little reason to have the code in monospaced font either. People really just need their blocks (and their continuation lines) to be properly left-aligned, and that works fine, because even in proportional fonts, a tab at the beginning of the line is always the same width.
Just don't mix spaces and tabs.
Sometimes you want columns of figures to be aligned throughout, but fortunately most fonts respect the rule that all digits should be the same width (for exactly this reason).
My emacs is set for Dejavu Sans semicondensed bold at 6pt ... I find that for code, bold or demibold works a lot better than regular weight.
Disclaimer: although I really do code in proportional fonts, using emacs is only a 90% solution. It's harder to navigate code when hitting the up/down keys causes your cursor to jump left and right because emacs' proportional-font implementation is just a thin skin over a fixed-width world. I'm still looking for a next-generation IDE which will free me from this kind of issue.
No you're not the only one. I've been working on pretty printers for SQL and Clojure, to render their textual representation using html elements other than <pre> so that they keep their indentation, regardless of font style or size (example: http://pastehtml.com/view/bun1zr4o7.html).
No you're not the only one. I've been working on pretty printers for SQL and Clojure, to render their textual representation using html elements other than <pre> so that they keep their indentation, regardless of font style or size (example: http://pastehtml.com/view/bun1zr4o7.html).
I wasn't really sure of all of the benifits, then I saw the picture of the video game making example and it dawned on me... make it happen! I'm throwing money at my screen but nothing is happening.
I did indeed. I used to be the Program Manager for C# and VB in the IDE. :)
A number of the ideas presented here started brewing during my time there, but it took me a bit to figure out what the overall abstraction should be. I really love the drafting table parallel - it's especially interesting when you start thinking about what we can do with touch...
This is great, I would love to try something like it. Making each code artifact living outside of the file paradigm should enable new way to develop, but in the past what I saw trying failed (at least for me). The drafting table look like the abstraction that can make this work. The interactivity would be key too.
I can't help but think of a drafting pad and drafting notebook to allow us to work on our system everywhere...
Light Table looks brilliant and clearly deserves much success... but I can't help but wonder if it will ever catch on as much as I'd hope, because the alternative -- using plain-text files -- is (IMO) a canonical example of the simple-to-implement, New-Jersey-style, worse-is-better approach.
As comments elsewhere in this thread (e.g., see stcredzero's and gfodor's comments) detail, the ideas behind Light Table have been around for decades, yet somehow failed to catch on in prior incarnations. Why?
Some here say it's because earlier proponents of these ideas were just too early, meaning that hardware and infrastructure weren't sufficiently powerful at the time. Others here say that early proponents and their implementations were too ideological and not pragmatic enough. Maybe.
My gut tells me earlier incarnations lost out in the marketplace because MIT/Stanford-style approaches tend to lose out to simple-to-implement, New Jersey-style, 'worse-is-better' approaches in the long run. What prevents Light Table from suffering a similar fate?
Light Table has problems for non-trivial code anyway. What happens when functions have side effects like deleting files? Most of my code involves networking, especially Android devices talking to http servers providing functionality that has state. Things don't run in isolation, there are databases involved and code can't be called willy nilly.
And a lot of code is about error handling. In addition to the normal path I really need to see the flow through the problems - permissions issues, timeouts, resource limits, service failures etc.
If this showed up as a Kickstarter project, I'd put $100 behind it right now.
The bickering over KS/YC or product/business is zero-sum. I just want to use this, and I'm prepared to put my money where my mouth is to see Chris Granger working on it full-time.
@ibdknox: you definitely need to get this project on kickstarter (to fund the work on an open source implementation ideally) it could really change the way people approach software development and Clojure in particular. The ideas you're presenting aren't necessarily new, but if they didn't caught on was more due to being done at the wrong time or the wrong way. I could definitely see you being able to pull it off!
Anyone's who's Googled around for the "proper" way to setup Emacs for Clojure development (and found innumerable blog posts dating back 5 years each with completely different instructions) is intimately aware of what an easy-to-use IDE for clojure, one with a simple install procedure on multiple platforms, would do for language adoption.
My two wishes:
1) vim style editing as an option
2) support static languages with every feature but the real time debugging, if need be.
My second wish may seem like it is missing one of the main, most beneficial features. But the other features are enough, such as " Multiple editors with just one function in it." or "Show code in an area of concern"
Awesome stuff. I think ClojureScript and Bret's visionary talk are brewing a perfect storm: the era of projectional, structural, domain specific editing in the browser is finally coming. This looks awesome and as the author mentions it is just the beginning.
This is awesome. I love the idea and the implementation looks great. ibdknox claims that it would work with any dynamic language. I'm not sure there is anything capable of finding dependent functions in Python without actually executing the code.
"...but there's no reason this couldn't be done for any language with a dynamic runtime."
With your (ibdknox) background, could this work for c#/f#? I like Visual Studio, but I feel more and more it gets in my way when I'm debugging/navigating code. There is too much "chrome"/widgets/toolbars and hundreds of specialized windows, each with their own chrome that eat up precious space on my 27" monitor.
When I use it on my 15" laptop I really have to strip everyting away and use a simple editor window.
I'd love an editor with the power of Visual Studio without all the noise.
It could indeed, they'd need to focus on building out the evaluation context (basically a REPL), but as I recall there was a prototype of one somewhere.
Past that, the new Roselyn language models would fill in a bunch of the gaps that would make this particularly hard currently.
The real problem for making it happen in VS is political though :( I actually pitched similar ideas while I was there.
> I like Visual Studio, but I feel more and more it gets in my way when I'm debugging/navigating code. There is too much "chrome"/widgets/toolbars and hundreds of specialized windows, each with their own chrome that eat up precious space on my 27" monitor.
Chrome eat up space on a 27" monitor? Not sure if you're actually being serious here since a 27" monitor probably has 2560x1440 resolution which is gigantic compared to the chrome. Furthermore, you can customize the UI to disable every toolbar manually. Or in VS2010, there is a full screen mode where it hides all the toolbars from every side, and shows a basic text editor. That's probably what you want.
I agree, working a lot with VS (and previously with Eclipse, which has the same kind of problem), on a big screen it's fine, but as soon as I have to only use my laptop screen, I cry ...
I would also love to have an editor of this kind for compiled languages ... What really sold me is seeing the flow of the data in the end of the video :)
Is Light Table also programmable in the language it's written in? I find extensibility and compose-ability far more important in an editor than any single feature alone.
Cool demo. I like the idea of alternate real-time visualizations of my code; especially in large and unfamiliar systems.
You might also find eldoc-mode[1] and it's various mode-specific children (c-, perl-, ...) to a useful minor-mode. It displays a short string describing the function-at-point, and the order and name of it's arguments. Sort of zero-click docs. Whatever way it does it could probably be hacked up to display more complete docs in a split window or frame. Something I'll think about when I finally get an SSD :)
Great to see another clojure tool heading away from the old traditional and largely text based environments to something new and better. Anyhow, looks a lot like Code-Bubbles to me (http://www.andrewbragdon.com/codebubbles_site.asp).
As he was talking about how other engineers work, on big tables where they place and organize all their current notes, items, documents - in the future, I'd like to have a large epaper covered, touch and object sensitive desk and couple of light epaper devices to take down and organize notes and code. Software will become more complicated in the future, so I think at some day we will need to adapt and use more powerful tools than the ones we currently have.
This really looks great. The doc and play views alone would be fabulous as I'm trying to learn clojure. Seems like an incredible sandbox environment for learning the language and exploring open source to understand how things are working. What are your plans for releasing/availability?
As concepts go, not a bad start. One of my immediate thoughts was that this would be better served on a multi-monitor system. Every single one of our development machines has three 24 inch 1920 x 1200 screens. It's fantastic. You can keep everything you need up and available. It makes working on complex ideas an absolute pleasure.
On the hardware design front we use a program use a EDA tool called Altium Designer for schematics and board design. This, by far, is the most well thought-out application I have seen when it comes to multi-monitor smarts. It makes for a nicely flowing and efficient design process.
He talks in very generic terms, so I think you can gauge this to be the overall intent. But, I would have some reservations about the challenges of live-evaluation in other languages. It's not insurmountable by any means, but using a lisp really gives you a massive head start.
Functionally striking, visually beautiful -- it makes me feel suddenly like things are coming together in a way that might stick this time around.
In form: Value placed on aesthetics -- beautiful & functional design -- is a concept that's taken root in the marketplace at large.
In code: Like gfodor commented, it feels like the doors are open wider than they've been in a long time to new ideas, and that we see some elegant language mechanisms being rediscovered and rising to the top.
In tools: The same pattern ... with lots of points of reference, a critical mass of seekers and open source contributors, and bootstrapped on powerful tools that allow rapid expression of new ideas, the good ones see the light of day and, if successful, can take an advantage of an unprecedented kinetics of this ecology to rise to viability and then prominence.
I hope you'll forgive me if I'm blowing this out of proportion to wax elegiac or whatever -- it just suddenly feels like a good day to be a programmer.
Lovely demo, well explained. I'm using the same principles for my visual design web application, and I see the same simplicity and elegance here as well. Can't wait to try it out.
One thing I notice while playing video games is that having an SSD doesn't help that much once the game is loaded. This is because game devs think about file access and make sure that it is optimized. It would be nice to just get something like eclipse that takes 5 minutes to become usable and slows down all the time because it is hitting the file system without any regard for performance.
Due to a jar locking problem I'm having to restart eclipse several times a day and it is so painful watching it "build" and validate all this code when my real build happens on the command line.
I wish video game developers would start writing IDEs for other reasons like graphics as well. They seem to be the only ones who understand flow and how disrupting it is for a program to just become unresponsive for even a few seconds.
Hardly a "new" concept. MS Research did something akin to his different functions on one light table. Displaying HTML in the REPL is (I believe) a Factor thing, amongst others. Documentation everywhere is supported by any decent IDE these days.(Except it's usually a hover tip, not a separate window). Code is not a file is the subject of entire Internet rants.
Don't get me wrong, this is cool when you tie it together. But it's hardly new. I'm inclined to say it would benefit from research into what others have done, but maybe I'm wrong. Maybe you really need to be unencumbered by old ideas to push this again, and maybe succeed this time.
"Files are not the best representation of code, just a convenient serialization."
I agree. Files (and version control systems) leak a tremendous amount of valuable information. They are a very '20th century' technology.
I'm working on a tool that behaves like a distributed version control system (branching and merging) but stores more fine-grained information about the programming process. This information can be played back and developers can tell a story about why the code is the way it is:
This looks amazing, it would be a perfect tool for learning programming in the first place, but can easily work great for experts as well. Incredible. When can we get a download link to try this out?
Emacs is most of the way already. It doesn't have an interactive code display thing like this (as far as I know), but most everything else either already works or works similarly.
For example, getting documentation is just as easy. (Actually, I don't know if you can search by docstring, but otherwise it's the same.) You can also get the same experience as having functions rather than files open by having a lot of little "windows" (in the Emacs sense) with a function in each. Since you can have multiple "windows" open on a single buffer, it can work for functions in different parts of the same file as well.
In short: Emacs has all the building blocks you need (as always) and some of the features are already easy to replicate. Building something like this on top of Emacs just makes sense.
I was thinking the same thing. Many of those ideas would be great emacs modes. In fact during the first minute of the video I was going to ask how he skinned emacs to be so pretty :)
Amazing----I've dreamed of having something like this ever since I started programming. Can't wait to try it out.
Mind if I share a couple ideas that might not be hard to implement with what you've got?
1) It would be nice to see \aggregate information about what has happened in function calls. The simplest would be: while the code is running, put and update a bar graph next to each function to show, proportionally to others, how many times it has been called so far.
2) More generally: record and associate with a function \all the inputs and outputs it has had. (Other commenters talked about having "context"). Then the programmer can scroll through these lists, calculate statistics for them if they are numbers, or choose one of them to plug into the function. (Often when you are refactoring code, some function lower in the code path gets 'orphaned'----it took some kind of complex input you don't want to bother putting in by hand, and so now if you want to modify it you're deterred. If you had prior inputs, you could just 'wire it up' with one of those.)
3) Commenters talked about having different fonts. I think the \one area where this would be helpful in Lisp is with the parentheses. I've shared prior versions of this idea before, but what I think would be helpful is to vary both \color and \size of parentheses. You pick three or four colors, say red, blue, and black (more than that is hard to tell apart in context, especially with syntax coloring), and once you've varied that, you bump the size up. So if you had seven parentheses in sequence, there would be three sizes, with the outermost three the largest, the next three medium, etc.
5-6 days, most of which had to do with me having to hack around in the compiler a little. That was new for me and the Java there is particularly weird, so that took longer than I would've liked.
I've unfortunately had to spend a great deal of time working with Labview (a graphical engineering software development environment that works based on data flow. Functions are represented by blocks with terminals for input and output data. You wire functions together to pass data between them). Some aspects are horrible (primarily the maintainability of anything more than a trivial application), but they also do some interesting things that I thought were quite parallel to this demonstration.
Documentation is quite well embedded into the software, and comes up with a similar box detailing the docs for every function you come across. The system also shows you the flow of data through a programme, allowing you to debug and see the data types moving between functions. You can dive into sub-functions and see what data's moving through them. Debugging can be fantastically quick if you constructed your programme carefully. If you didn't though, it's hell (see the point about maintainability).
If you wouldn't mind me (your friendly, neighborhood National Instruments programmer browsing HN) asking, could you expound a little more on other things you've found horrible with LabVIEW?
I completely understand your sentiment on debugging and maintainability. I've done my fair share of quick-and-dirty apps that did one little thing wrong and a million highlighted executions and five years later, I've finally got a handle on what's wrong (mind you, I'm nowhere near a LabVIEW expert).
I love our documentation tool as well. We call it Context Help, and as you highlight over different parts of your code diagram, it's handy to see a quick, readable summary with links to full documentation for every single node and system available in LabVIEW.
If only all IDEs had the same functionality and it's the reason why I'm super psyched to see Light Table come out. Ready to be blown away.
Functionally striking, visually beautiful -- it makes me feel suddenly like things are coming together in a way that might stick this time around.
In form: Value placed on aesthetics -- beautiful & functional design -- is a concept that's taken root in the marketplace at large.
In code: Like gfodor commented, it feels like the doors are open wider than they've been in a long time to new ideas, and that we see some elegant language mechanisms being rediscovered and rising to the top.
In tools: The same pattern ... with lots of points of reference, a critical mass of seekers and open source contributors, and bootstrapped on powerful tools that allow rapid expression of new ideas, the good ones see the light of day and, if successful, can take an advantage of an unprecedented kinetics of this ecology to rise to viability and then prominence.
I hope you'll forgive me if I'm blowing this out of proportion to wax elegiac or whatever -- it just suddenly feels like a good day to be a programmer.
Great work, and I'm impressed at how quickly Chris Granger created Light Table. I wonder how hard it would be to build an IDE for Meteor (EDIT: I mean get JS support in Light Table, since Meteor is just JS) - how amazing would that be. Or port Meteor to Clojure and wow ... these combined would be amazing.
I've believed for a long time that files were archaic and agree completely - and we should extend that idea to version control. If we version functions (and classes, stored procs, etc...) then you can create a type of failover to a last known good version down to that logical function.
As for the rest of the ideas - the table, organize and layout related code, the documentation and the interface are all terrific ideas and I can't wait to see where it goes. Imagine laying out all that code on a nice huge touch tablet with multi-touch support ... drool....
This is great. I'm so happy someone finally started moving in a new direction. I've been thinking along these lines for a long time, but never found the time or energy to actually start implementing anything.
The most important thing is to do away with the concept of a file as a main structural unit in a project.
Interesting... @Taligent we built a completely object-oriented dev. environment for C++ (borrowing a lot from various SmallTalk environments). There was no file system - everything was an object - comments were stored in the object system along with implementations. This allowed for some really cool self-documented versioning on classes. However the real magic was in the debugger where we were building runtime support for "edit/run" and "what if" so you can edit faulty code and rerun w/out the recompile (essentially patching the class as it was running). Seems easy now (w/dynamic languages) but at the time this was close to "rocket science..."
A man after my own heart. Here's another concept to dramatically improve efficiency: Code Contexts. Enable the user to select (or add) a specific set of contexts. When coding under a specific set of contexts, differentiation of code applies only under the given context set. Or, after making a code change the user could add/remove contexts to which it applies. This would resolve a lot of the complexities of OO programming. Behind the scenes, context sets can be organized into a class hierarchy. But the programmer wouldn't have to search through the damn hierarchy to find out what version of a particular method is currently in play..
Hi, I develop in Python and js. Idle is ok, but I'm sick and tired of Eclipse and I almost freaked out when I saw your article. The video seems pretty awesome and after taking a peep at the code, I'm thinking of learning Clojure just to be able to participate in the project. Visual Studio has finally proven itself useful (developing in it make you imagine better ways to develop software apparently) XD
My request is if you have some link for a let's say "decent" coder who wants to understand and maybe try to compile the code on his own computer (debian). Perhaps even recommend an IDE for Clojure until this one is ready.
At least some of the features you've brought up in the article can be done with BugAid (for C#). For example, the ability to "visualize" the data in a function by replacing the variables with the actual values can be done, albeit in a different way (http://www.bugaidsoftware.com/). The other feature, like a documentation that shows whatever you're looking at, can be achieved partially with Visual Studio by itself and Resharper (http://www.jetbrains.com/resharper/).
This looks fantastic! It also has the side effect of making me want to get back in to learning Clojure. The idea of the file not being the fundamental unit of code is especially intriguing, but hard to wrap my brain around - that's such a low-level, base assumption that it's difficult to picture truly challenging that.
What are some examples of other paradigm-shifting (argh, buzzword) ideas in the world of software development? Deviations from the norm often become the new norm, and I'm too young and inexperienced (I've only been out of college for 10 months) to remember the "old way" of things.
Perhaps you could make comments part of the ast decoration. Hover over a function call and the IDE can popup a display showing comments for that function. The popup could be easily switched back and forth between comments, the parameter list, or possibly other info about the function. The comments could be plain-text, rendered HTML, or even crazier stuff like audio/video recordings for particularly important comments.
People could choose whether they wanted comments rendered inline with code like usual or displayed elsewhere.
Perhaps you could make comments part of the ast decoration. Hover over a function call and the IDE can popup a display showing comments for that function. The popup could be easily switched back and forth between comments, the parameter list, or possibly other info about the function. The comments could be plain-text, rendered HTML, or even crazier stuff like audio/video recordings for particularly important comments.
People could choose whether they wanted comments rendered inline with code like usual or displayed elsewhere.
Perhaps you could make comments part of the ast decoration. Hover over a function call and the IDE can popup a display showing comments for that function. The popup could be easily switched back and forth between comments, the parameter list, or possibly other info about the function. The comments could be plain-text, rendered HTML, or even crazier stuff like audio/video recordings for particularly important comments.
People could choose whether they wanted comments rendered inline with code like usual or displayed elsewhere.
I love the visualization aspect of this. I can think of multiple situations where popping this open to look at a couple of interactions would be helpful, especially when getting acquainted with a code base I didn't help build. I'd happily add it to my toolbox! Great thinking, great design.
Would I use it for everything? Nope. Most of the time I just want to type with the occasional jump into the command line. For that I use command-line vim, and I don't see jumping ship any time soon.
There's one thing I don't understand. When you execute code automatically, what do you do about side effects? If I have code that write, read or delete a file for example.
Glad to see someone finally understands the limitations of files and folders in IDEs. Let me suggest that your next step might be cooperative development as opposed to solo development. Hiveware for SoftwareDevelopment (not yet developed) would let Light Table users develop a single project's functions cooperatively and simultaneously without merge. Check out www.grammarapps.com to get an idea of the technology.
The last example, where the code called within a block is shown to its right, is something that I've often tried to do statically, manually when first trying to learn a large code base. I would want this for that alone. The fact that what's shown is live-ish is a big, diabetic coma-inducing glob of icing on the cake.
Very interesting concept and really pushes the idea of writing code beyond simply text editing. I'm in Visual Studio all day and I really wish I could do more with less panels and wizards. Or get a getter bird's eye view of my codebase without all those tree views. Sometimes I wish my class view was my code view.
This looks great. I was talking about this with some friends who mainly use vim and they would be for using this if it incorporated vim key-bindings. Whenever they have to use other IDEs (usually Eclipse) they have a hard time not using vim commands.
Love it. However the thing that often keeps me away from rich IDEs is that they so often only support 1 or 2 languages: so I get used to the nice features, then I'm stuck as soon as I have to switch language.
If this took off, it would be amazing.
I love it, when can I use it, and for what languages? I would recommend Kickstarter over YC because I expect Kickstarter would result in something I can use sooner :)
Thanks for pulling the video together, there are a lot of really interesting ideas in there!
Looks really interesting, would be great to have something like this for the web. I wonder how interested the author of Sublime Text would be in this as he seems to be very responsive with development, perhaps worth reaching out to him.
As a Ruby/Objective-C developer, I've always wanted something like this for my ruby projects. Xcode is awesome, but this level of integration for our distributed projects would make things go so much faster. I cannot wait to use it :)
I agree that sometimes files are not the best representation for code but languages gives them semantics. For instance, namespacing/packaging is based on files (which make dependencies based on files too).
I always wonder how can live preview work with I/O statements, like selecting/inserting from/to database.
Can you forbid REPL to execute such statements? And then somehow mock that data for live preview?
This... is fantastic. I want it. A lot. What are your plans for further development? How are you going to distribute it. I guess I'm really just looking for, can I have it, when, and for how much?
I really like the idea of seeing multiple functions (which might be in different files) on the same page at the same time. In Textmate it would be great to see the whole MVC of one function at once.
This is a great idea. I can almost see my development time going down by a big factor and writing much more robust programs.
I wonder, how hard it would be to do this in existing editors ?
this is quite cool, I'm not much of an IDE person, I like to stick with good old vim, but this sparks my interest. If it's open source then I might seriously consider it, even contribute some vi keybindings. I just hope it goes more in the way of building upon vi/emacs and modernizing it rather than stripping down an IDE and modernizing it.
like was said in the article, a js in-browser implementation, if possible, would be great. Imagine being able to get back to your work from any computer of any kind, anywhere, without having to download any ides or set up remote debuggers or anything. a great idea that would be even better (and I think manageable) in the cloud
He's using ClojureScript. He states at the bottom of the page:
It's no secret that I really like Clojure and as a lisp,
it was the easiest language for me to start the prototype
with, but there's no reason this couldn't be done for any
language with a dynamic runtime. The rest is mostly simple
analysis of an AST and some clever inference. So could
Light Table have used JS instead? Certainly - and
hopefully it will get there sooner rather than later.
Reminds me of the design and dynamic visualizations from IntelliPad (written for Microsoft's retired project 'Oslo') with several features from visual studio all incorporated into an elegant interface.
Nice job.
(Although better - this IDE is close enough to IntelliPad that I challenge your statment that it is a "new IDE concept.)
okay. i have a comparatively small pet project i work on in my free time, it's close to 60k lines of c++ code. now, please, tell me, how your "ide" is going to help me organize things better?
> Smallest unit of code is the function.
for what particular reason?
> Able to get instant feedback on code changes.
i've got 200 threads of execution in my fcgi module, how do you intend to eval that?
> Multiple editors with just one function in it. Show code in an "area of concern" not just in a file.
kinda interesting, but won't work really. usually you have quite a bunch of code, 100-200 lines in a function which is a regular business. put 10 of those on the screen and you've got enormous unmanageable pile of crap.
> The coding environment can show also results, app windows, graphics, other tools.
any specifics? but yeah, i must admit you can put fancy widgets on window panes lol
There was a UX video a while back, quite a long video, and there were IDE features shown off that were slightly similar to this. You could trace code and modify it while it's running and visualize the results. I feel that it would have inspired or complement this concept very well.
I always wonder how can live preview work with I/O statements, like selecting/inserting from/to database.
Can you forbid REPL to execute such statements? And then somehow mock that data for live preview?
okay. i have a comparatively small pet project i work on in my free time, it's close to 60k lines of c++ code. now, please, tell me, how your "ide" is going to help me organize things better?
> Smallest unit of code is the function.
for what particular reason?
> Able to get instant feedback on code changes.
i've got 200 threads of execution in my fcgi module, how do you intend to eval that?
> Multiple editors with just one function in it. Show code in an "area of concern" not just in a file.
kinda interesting, but won't work really. usually you have quite a bunch of code, 100-200 lines in a function which is a regular business. put 10 of those on the screen and you've got enormous unmanageable pile of crap.
> The coding environment can show also results, app windows, graphics, other tools.
any specifics? but yeah, i must admit you can put fancy widgets on window panes lol
Smalltalkers have been doing this in commercial projects since the 80's. If only we could have communicated about this as well as Mr. Granger.
EDIT - Also:
Things like this were happening in Smalltalk environments since the 80's. The first and the last points above were satisfied by lightning fast "senders" and "implementers" searches.
Of course this comment was inevitable. If Smalltalkers really believe their environment is the right way to code, their attitude should not be one of "we did this first, meh" but instead be "here's what we did right, here's what we did wrong. heed the lessons of history and good luck, you are on a mission from God."
I think with the proper care and nurturing, we could be at the beginning of a renaissance where many of the great ideas of the 60s and 70s that have been isolated to a small group of people (who are aging rapidly) are being rediscovered and reimagined by this generation. This is happening in no small part due to Rich Hickey and the Clojure community's unbelievable foresight in developing Clojure and ClojureScript in just the right way that it balances these pure, beautiful ideas with pragmatism in a way that makes them irresistible.
Those who lived through the heyday of Xerox PARC, the AI lab, the lisp machines and Smalltalk should see this as an opportunity to help make sure things don't go off the rails this time. Otherwise, we may end up back here again in 25 years with the C++ and MySQL of the future installed in our cybernetic implants.
I can already point to projects that are invisibly pushing us towards another deep, sticky, next-generation tarpit, and people are diving in because it's not yet recognizable as such. (I won't name names!) Lets try to make it so this time around we truly realize the dreams of computation by encouraging people who are building elegant, beautiful things for the modern era, no matter how much the ideas therein have been tried before.
If Smalltalkers really believe their environment is the right way to code, their attitude should not be one of "we did this first, meh"
That was totally not the spirit in which I meant my post. It's more like, "I told you so!" (My mind works differently, I guess. I present facts that challenge people's model of the world, hoping the curious absorb the information and run with it. Many people seem to take these as some kind of attack.)
3 replies →
I didn't quite "live through" those, being too young (mid-30's now) but did buy a lispm and hack on Smalltalk. I do support things like making Smalltalk Git-compatible, declarative, etc. I haven't jumped on the Clojure bandwagon because I lack interest in the JVM, but ClojureScript is great.
FYI: One thing Light Table could pick up / learn is the ability to scale as function set grows, to gain a kind of fractal navigability.
EDIT: I should clarify that I like Clojure quite a bit. It just doesn't speak to the kind of programming I do "in anger" right now. So I learn about it and watch ClojureScript more intently because it speaks to the environment I've chosen for my products/projects.
It seems that Dan Ingalls, the father of Smalltalk, has picked up the baton again, this time using Javascript. Check out Lively Kernel (http://lively-kernel.org/). I saw a live demo at JSConf, it was pretty jaw-dropping stuff, completely in line with the Smalltalk legacy.
Interesting stuff, I'm quite new to programming, could you please recommend some reading materials to get acquainted with these ideas?
As a newbie, I'd like to educate myself so I can contribute to the "right" projects for this time and learn to avoid the tarpits.
3 replies →
why not name names? seems like it could be informative.
5 replies →
Yes, but our code was entirely in these utterly unusable changeset files that couldn't work nicely with the version control that everyone else in the entire world was using; his version still uses files under the hood. There's a team that's trying to back Monticello with Git, I believe by saving each method into its own file in part of a Git source tree; that looks promising as a compromise.
https://github.com/CampSmalltalk/Cypress
Hopefully this project will take off :)
Smalltalk vendors will probably add a layer of Envy/Store/Monticello on top of it but that would be a giant step forward.
We also had Virtual Machines with snapshots and rollbacks doing the things VMWare is now pushing so very hard.
I have missed those tools for the past 13 years, since I left the language. The idea that I might get those tools back, in a language that also supports all the emacs-or-gtfo coders, is like promising me a perpetual motion machine. I will believe it when I see it, and until then it will taunt me in my dreams.
There is a Gemstone group at VMware. Send your resume.
Field (http://openendedgroup.com/field) is a modern programming environment that embraces most (if not all) of these principles.
As always, the multi-media programming environments are miles ahead and nobody knows about them. Field is amazing. Max/MSP, Pd, et al. are a different paradigm altogether, but have had live editing, documentation a click away, etc. and have been in heavy use for 20+ years.
4 replies →
I immediately thought of Visual Age for Smalltalk when I saw this, but having been done is no reason to not try again.
VisualAge for Java was my thought. Unfortunately, as with many of IBM's good ideas - before its time, poorly marketed/placed, etc.
2 replies →
True, Smalltalkers were there first. The thing I like.. the further enhancement here.. is the UI. No more tiles and windows.
In the Table view it might be nice to color the cards based on their namespace like Whisker browser:
http://www.maartensz.org/computing/squeak/Helps/Programming/...
what smalltalk didn't quite do is the instantaneous view of the results of your code changes. Seeing the result of your changes in Light Table is like updating a cell in a spreadsheet. Smalltalk (I'm guessing), would involve switching to the executing window or hitting a play/continue button. A subtle difference, but it takes the immediacy to the next level.
No, it was, is or at least can be, instantaneous where that makes sense.
Autotest, which is now built-in to Pharo, will automatically run unit tests relevant to the method you're editing when you save the method, so you can get pretty close. http://magaloma.blogspot.com/2010/06/autotest-for-pharo.html
Isn't it ironic that this is posted on a site that does startup funding and the comments are "please put this on kickstarter" not "please apply for Y Combinator"?
Is it possible that Kickstarter will disrupt Y combinator style startup funding?
If we (the consumers) can bypass the investors and pay for what we want, why do we need the startup gatekeepers?
Obviously this wouldn't work for all startups but a large portion of founders might be better off on kickstarter? Unless of course the advice/mentoring/network effect that Y combinator, et al provide is vital to a startups success.
Food for thought.
Kickstarter is for products, YC is for businesses.
(More or less, I'm not saying it's black and white)
Kickstarter is product-focused, YC is founder-focused.
Ah, but business should be product-based...
7 replies →
Although you can argue that a "product does not make a business," many businesses start off with a single product.
Kickstarter is great way to determine if there is commercial viability for an product, but only within the early adopter customer segment -- and that's about it.
YC primarily looks for teams they like. The description of the product idea in the application is indicative of the team's ability to communicate (which is critical), and the actual idea may give a glimpse into the judgement of the team, but a good number of teams (including mine) pivoted pretty dramatically during our time in YC.
Steve Blank, who spoke to our batch, says that a startup is a temporary organization formed to search for a repeatable and scalable business model. Understanding this, and understanding when to pivot, was one of the most critical teachings made by YC.
> Isn't it ironic that this is posted on a site that does startup funding and the comments are "please put this on kickstarter" not "please apply for Y Combinator"?
Why, one can do both :). (eg. Pebble is funded by Kickstarter, but the creators are an YC company)
Anyway, the most important thing is: make it happen, make it happen fast, and don't let it become another CodeBubbles - an IDE idea with a video that captured imagination of programers few years ago, but implementation of which is yet to be seen.
AFAIK Code Bubbles is now Debugger Canvas http://msdn.microsoft.com/en-us/devlabs/debuggercanvas
1 reply →
I can't imagine the monetary investment from YC is more significant than the advice and mentoring that you get. Raising $20k isn't impossibly hard. Finding the right mentors is.
Off topic, but an old aphorism is, "If you want advice, ask for money. If you want money, ask for advice." In some ways, asking YC for money is a way of asking for advice and constraining YC to prove that they're sincere.
Kickstarter let's you basically preorder a product that lacks investors.
Being a startup investor has become the game rich people love to play. There are people who'll fund anything in return for a small percentage of the company in the hopes it might be the next Google/Facebook/Paypal ...
Billionaires don't want to be in the smallprinted section of the forbes-list, they want to be "legends" like Peter Thiel or Andy Bechtolsheim and want their name in the history books
"Kickstarter let's you basically preorder a product that lacks investors."
Exactly. But why do you actually need Kickstarter for that?
Probably the people who mentioned kickstarter tend to think kickstarter for ideas without large profit potential, and unless you also sell a software-deployment platform (like Microsoft and Apple do) tools for programmers does not IMHO have large profit potential.
I'm not sure I agree. Textmate made a crap ton of money, companies like JetBrains and DevExpress have made very successful businesses building dev tools.
And while you mention MSFT as building a platform, if VS alone can make a billion, even without a platform I suspect you could do quite well.
3 replies →
Iyc
For years I've been bothered by the fact that we still use ASCII text-based documents to program. Having spent a good deal of time programing in APL, a language that uses symbols extensively, I'd like to think that I saw just how different things could be.
Having said that, every time I've looked into graphical programming paradigms they almost always seem to fall apart or get in the way of translating ideas and thoughts into machine instructions.
In the end, at least for me, it's about having an environment and a language that gets out of the way and let's me program the way you'd play the piano: The music just flows and the technical bits that make it happen are invisible.
Oh wow. I've never used APL but this demo of it always blows me away http://www.youtube.com/watch?v=a9xAKttWgP4&feature=youtu...
If APL looks good to you, it may be worth checking out its descendent J: http://www.jsoftware.com/
I'd be interested to hear your thoughts on LabVIEW, if you've ever used it: http://www.ni.com/labview/.
It's a graphical programming language with an emphasis on system design (for scientists and engineers) that uses a dataflow paradigm (amongst other things) and has a unique UI creation system.
(Disclaimer: I work for National Instruments and my comments here in no way reflect the views of National Instruments and yadda yadda.)
My experience with LabVIEW, for the brief amount of time I worked with it for our high school robotics team, was slightly frustrating. I liked the dataflow paradigm, and to some degree the dashboard system, but connecting and managing the "wires" was a pain. Especially since I'm more comfortable/faster with a keyboard than I am with a mouse.
It also seemed to be harder to read and understand the flow of the code, which made debugging a pain sometimes. I remember struggling to figure out why my code wasn't working, only to find out I had used 1 instead 1.0 as a constant. The only indicator of the data type was a thin colored border around the box.
LabVIEW seems to do a great job as a kind of Visual Basic for scientists and engineers, but I'd probably find it frustrating to spend any substantial amount of time programming with it.
1 reply →
The whole time I was using LabVIEW (for a class) I kept dreaming of the days when I'd be done with it and back to a typed language.
1 reply →
Text is still the best way too tell a story and programs are just that: stories. I would say that any language requiring a fancy IDE is doomed.
Comics and movies are pretty good ways to tell stories too. Some stories are better suited to text. Some are not. I'm in the middle of making a comic that makes deep use of color and the relative position of panels on the page to tell its story, for instance.
What kind of programs are we missing out on by limiting ourselves to text? What kind of programmers?
1 reply →
I'm not sure if you can say that text is the best way. It's certainly one way to tell a story, and even a fundamental way to tell a story, but there have been many interesting advancements in storytelling in the last few millennia. I also enjoy pictures and, especially, talking pictures.
This is great, however it glosses over the elephant in the room: what if a function is called multiple times, or what happens when code within a function is run multiple times? Which data do you display in the data flow view? What is really needed is an intuitive way to select a context or multiple contexts.
SubText's approach to this is to let you dig deeper in the call tree by clicking on function calls, but for a language like Clojure you also need a way to select a context for a piece of code nested within a function. For example suppose you have
You need an intuitive way to display or select a context for the fn.
There are several options here:
- show multiple iterations in place - show a single iteration with a forward and back - show multiple blocks for some reasonable n iterations - ...
I definitely don't think that's going to be an issue longer term and I think there are lots of potential avenues to play around with :)
You could just sample and show an example - that's good enough for many uses.
1 reply →
And recursion. Light table's display is like a stacktrace, but each line expanded to the whole function. These scaling problems can be solved: exclude some functions, esp libraries (e.g. "native" functions like map aren't expanded). And standard scaling tricks e.g. one line, click to expand (like his doc navigator).
By "context", you mean you nominate a deeper function to display, but then how do you know which call to it is displayed? I think the answer is to display the rest of it, but collapsed/summarized. hmmm, the call trace is a tree in general, so that's getting a little hairier to manage. (NOTE: a tree, assuming you display a fresh instance of a function for each invocation, which you need to do to show the correct variable values)
SubText handles recursion well. It shows the toplevel invocation, and when you click on a recursive call in that invocation, then that recursive call opens next to it. Like this you can expand the call graph as you with.
A demo shows it better than words: http://subtextual.org/demo1.html
And a newer demo, although it does not show the call graph expansion: http://subtextual.org/subtext2.html
I can't get my hands on this soon enough. It makes so much sense: we're moving away from the files and folders metaphor everywhere, so why not in the IDE too?
We might not want the hassle of dealing with files and folders all the time, but I sometimes worry that a new generation of "programmers" will emerge who have no understanding of how the underlying filesystem works.
Why is that a bad thing (aside from the "I had to walk uphill both ways through the snow" aspect)?
A significant portion of this generation doesn't understand CPUs and buses. They wouldn't have been able to write anything remotely complex 20 years ago). That doesn't seem to be hindering things much, though. There are still system programmers out there who dive into it, but our abstractions have gotten good enough that all programmers don't need to understand the details to be successful.
(FWIW, I am conflicted on this topic. I wrote a little more here[1].)
1. http://news.ycombinator.com/item?id=3826551
5 replies →
I sometimes worry that a new generation of "programmers" will emerge who have no understanding of how the underlying anything works.
For as useful as sites like stackoverflow are for sharing knowledge, it is potentially encouraging a generation of copy/paste coders who's job it is to find and glue snippets together until they get the desired outcome.
Maybe I'm getting old, but I'm starting think some knowledge needs to be earned. [get off my lawn].
If you aren't comfortable slinging files and directories around, you probably aren't a very productive software developer.
As far as ide's go, this concept is definitely intriguing. But I believe putting too much faith in abstractions like what is implied by being function focused(there is no "file") rather than file focused(these are your "files") has the potential of blowing up in your face. I think you need both.
Anyone who had to code on a team using VB6 remembers the pain of *.frx files and how they needed to be version controlled, but you didn't need to worry about them because it was an implementation detail required by the ide. UNTIL, 2 people made visual edits to the same screen and then the project wouldn't open. GOOD TIMES.
10 replies →
Maybe that is a good thing? If programmers have no assumptions or presumptions about files and filesystems, then they are open for innovating new stuff without the burden of legacy.
I'm sad to see the current generation of programmers who don't understand that a hierarchical filesystem is one possible choice for organizing data on an underlying storage medium.
I think there are (at least) two different viewpoints of what is required for people to be able to program (and do it well).
First, an explosion in the power of the hardware being programmed on has made people think less of the efficiency that coding once required and more about getting something done. This feels sloppy, but can be a good starting point for iteration (+1 buzzword).
Similarly, the number of tools out there to get someone (like me) started on programming has EXPLODED in recent years. This results in a lot more people at least starting to code in whatever limited way.
I think it's naïve to think that people who start to code "the simple way" will always code that way. If they're actually pursuing as a career, they will always be digging more and trying to find out why something works a particular way.
Not seeing the filesystem/structure at first glance also isn't necessarily the same as NEVER looking at it or being interested in how the pieces all fit together. it simply means you don't have to worry about it RIGHT NOW.
How 'bout this: have a file system which can contain aggregating symbolic links, with configurable ordering schemes. We can edit functions in their own files and tell the compiler to compile the aggregation. This would be usable for C & C++ as well.
Less likely than our generation having no idea how CPU branching mechanisms work. Files are still how the vast majority of people, coders and non-coders, interact with their documents and data artifacts and organize backups. Anything deeper than that should be abstracted away, since it's subject to change.
Whenever I get the chance to use a spreadsheet, I really enjoy it. I find it really satisfying to set up cascading functions and see them update in real-time. I'd like to see that experience translated to general programming. I'd like to update code and see the unit tests update automatically, and an understandable representation of the objects being manipulated.
"I'd like to update code and see the unit tests update automatically"
I think you have that a bit backwards there. I want to write the tests and have my code automatically update to make them pass.
2 replies →
"Combinatorial Sketching" is a surprising technique that does something close to this:
http://people.csail.mit.edu/asolar/papers/asplos06-final.pdf
http://blip.tv/clojure/dan-friedman-and-william-byrd-minikan...
19:20
Editing complex functions in a spreadsheet is an absolute nightmare though. AS long as he doesn't recreate that part we are good :)
Editing complex functions in a spreadsheet is an absolute nightmare
Can you expand on why? Also, if you can imagine a spreadsheet that actually did a good job of this, what would it look like?
25 replies →
The Haskell folks have developed some combinators for automatic test case generation that might fit well with this project.
QuickCheck https://en.wikipedia.org/wiki/QuickCheck
Am I the only one who wants to see multiple, proportional fonts in editors?
Sure, I want to keep the methods themselves in monospaced font, but can't I have the method declaration in a larger size, and comments in a proportional serif?
There is a wealth of design experience out there in communicating things better and more quickly with typography, so why do we not take advantage of that in our IDEs?
Because when people try it, it doesn't look or work very well.
I think it's important to understand that this doesn't mean that such things will never work, but it is also important to understand that almost every idea that you've ever heard of has actually been tried lots of times (lots of lots of times in many cases), and there are often good reasons that they haven't actually been adopted.
As others are already pointing out, the linked proposal bears a striking resemblance to what Smalltalk does, so it's more helpful to ask "Why haven't the many attempts at this approach been successful?" than to ask "Why hasn't anyone tried this?" The first may lead you to a successful variant, the second will lead you down the same garden paths that everyone else went down.
I don't think anything prevents you from setting comments to be a different size and proportional in current editors. I know that it would be trivial in Emacs; some themes actually do that already.
You can try this by doing M-x modify-face, entering font-lock-comment-face then "DejaVu Sans" (or any other proportional typeface) and pressing enter a bunch of times.
In most cases there's little reason to have the code in monospaced font either. People really just need their blocks (and their continuation lines) to be properly left-aligned, and that works fine, because even in proportional fonts, a tab at the beginning of the line is always the same width.
Just don't mix spaces and tabs.
Sometimes you want columns of figures to be aligned throughout, but fortunately most fonts respect the rule that all digits should be the same width (for exactly this reason).
My emacs is set for Dejavu Sans semicondensed bold at 6pt ... I find that for code, bold or demibold works a lot better than regular weight.
Disclaimer: although I really do code in proportional fonts, using emacs is only a 90% solution. It's harder to navigate code when hitting the up/down keys causes your cursor to jump left and right because emacs' proportional-font implementation is just a thin skin over a fixed-width world. I'm still looking for a next-generation IDE which will free me from this kind of issue.
I saw this proposal lately that would allow proportional fonts everywhere: http://nickgravgaard.com/elastictabstops/
No you're not the only one. I've been working on pretty printers for SQL and Clojure, to render their textual representation using html elements other than <pre> so that they keep their indentation, regardless of font style or size (example: http://pastehtml.com/view/bun1zr4o7.html).
Suns Fortress language was kinda interesting experiment in that direction: http://software.intel.com/en-us/articles/first-impressions-o...
You can already do this with barely any effort at all in emacs. M-x customize-faces and then set the method face to be larger or a different family.
Source insight does just that: http://www.sourceinsight.com/features.html
Like this? http://i.imgur.com/8XYfb.png
Textmate 2 supports it if that's what you want.
No you're not the only one. I've been working on pretty printers for SQL and Clojure, to render their textual representation using html elements other than <pre> so that they keep their indentation, regardless of font style or size (example: http://pastehtml.com/view/bun1zr4o7.html).
I wasn't really sure of all of the benifits, then I saw the picture of the video game making example and it dawned on me... make it happen! I'm throwing money at my screen but nothing is happening.
This is pretty exciting stuff. IIRC ibdknox used to work on Visual Studio when he was at Microsoft.
I did indeed. I used to be the Program Manager for C# and VB in the IDE. :)
A number of the ideas presented here started brewing during my time there, but it took me a bit to figure out what the overall abstraction should be. I really love the drafting table parallel - it's especially interesting when you start thinking about what we can do with touch...
This is great, I would love to try something like it. Making each code artifact living outside of the file paradigm should enable new way to develop, but in the past what I saw trying failed (at least for me). The drafting table look like the abstraction that can make this work. The interactivity would be key too.
I can't help but think of a drafting pad and drafting notebook to allow us to work on our system everywhere...
Even if it proves unweildy once a project grows too large, as a learning and prototyping tool this looks fantastic. Thank you!
Some friendly advice - never state in writing that some ideas started brewing when you were with your previous employer.
Light Table looks brilliant and clearly deserves much success... but I can't help but wonder if it will ever catch on as much as I'd hope, because the alternative -- using plain-text files -- is (IMO) a canonical example of the simple-to-implement, New-Jersey-style, worse-is-better approach.
As comments elsewhere in this thread (e.g., see stcredzero's and gfodor's comments) detail, the ideas behind Light Table have been around for decades, yet somehow failed to catch on in prior incarnations. Why?
Some here say it's because earlier proponents of these ideas were just too early, meaning that hardware and infrastructure weren't sufficiently powerful at the time. Others here say that early proponents and their implementations were too ideological and not pragmatic enough. Maybe.
My gut tells me earlier incarnations lost out in the marketplace because MIT/Stanford-style approaches tend to lose out to simple-to-implement, New Jersey-style, 'worse-is-better' approaches in the long run. What prevents Light Table from suffering a similar fate?
I hope I'm wrong.
Light Table has problems for non-trivial code anyway. What happens when functions have side effects like deleting files? Most of my code involves networking, especially Android devices talking to http servers providing functionality that has state. Things don't run in isolation, there are databases involved and code can't be called willy nilly.
And a lot of code is about error handling. In addition to the normal path I really need to see the flow through the problems - permissions issues, timeouts, resource limits, service failures etc.
If this showed up as a Kickstarter project, I'd put $100 behind it right now.
The bickering over KS/YC or product/business is zero-sum. I just want to use this, and I'm prepared to put my money where my mouth is to see Chris Granger working on it full-time.
@ibdknox: you definitely need to get this project on kickstarter (to fund the work on an open source implementation ideally) it could really change the way people approach software development and Clojure in particular. The ideas you're presenting aren't necessarily new, but if they didn't caught on was more due to being done at the wrong time or the wrong way. I could definitely see you being able to pull it off!
Anyone's who's Googled around for the "proper" way to setup Emacs for Clojure development (and found innumerable blog posts dating back 5 years each with completely different instructions) is intimately aware of what an easy-to-use IDE for clojure, one with a simple install procedure on multiple platforms, would do for language adoption.
My two wishes: 1) vim style editing as an option 2) support static languages with every feature but the real time debugging, if need be.
My second wish may seem like it is missing one of the main, most beneficial features. But the other features are enough, such as " Multiple editors with just one function in it." or "Show code in an area of concern"
Awesome stuff. I think ClojureScript and Bret's visionary talk are brewing a perfect storm: the era of projectional, structural, domain specific editing in the browser is finally coming. This looks awesome and as the author mentions it is just the beginning.
This is awesome. I love the idea and the implementation looks great. ibdknox claims that it would work with any dynamic language. I'm not sure there is anything capable of finding dependent functions in Python without actually executing the code.
Could someone illuminate me?
Take a look at these:
[1] http://docs.python.org/library/parser.html
[2] http://docs.python.org/library/ast.html
[3] http://docs.python.org/library/symtable.html
"...but there's no reason this couldn't be done for any language with a dynamic runtime."
With your (ibdknox) background, could this work for c#/f#? I like Visual Studio, but I feel more and more it gets in my way when I'm debugging/navigating code. There is too much "chrome"/widgets/toolbars and hundreds of specialized windows, each with their own chrome that eat up precious space on my 27" monitor.
When I use it on my 15" laptop I really have to strip everyting away and use a simple editor window.
I'd love an editor with the power of Visual Studio without all the noise.
It could indeed, they'd need to focus on building out the evaluation context (basically a REPL), but as I recall there was a prototype of one somewhere.
Past that, the new Roselyn language models would fill in a bunch of the gaps that would make this particularly hard currently.
The real problem for making it happen in VS is political though :( I actually pitched similar ideas while I was there.
> I like Visual Studio, but I feel more and more it gets in my way when I'm debugging/navigating code. There is too much "chrome"/widgets/toolbars and hundreds of specialized windows, each with their own chrome that eat up precious space on my 27" monitor.
Chrome eat up space on a 27" monitor? Not sure if you're actually being serious here since a 27" monitor probably has 2560x1440 resolution which is gigantic compared to the chrome. Furthermore, you can customize the UI to disable every toolbar manually. Or in VS2010, there is a full screen mode where it hides all the toolbars from every side, and shows a basic text editor. That's probably what you want.
http://blogs.msdn.com/b/zainnab/archive/2010/07/17/full-scre...
I agree, working a lot with VS (and previously with Eclipse, which has the same kind of problem), on a big screen it's fine, but as soon as I have to only use my laptop screen, I cry ...
I would also love to have an editor of this kind for compiled languages ... What really sold me is seeing the flow of the data in the end of the video :)
It looks a lot like what I already do with Emacs.
Is Light Table also programmable in the language it's written in? I find extensibility and compose-ability far more important in an editor than any single feature alone.
Cool demo. I like the idea of alternate real-time visualizations of my code; especially in large and unfamiliar systems.
Could you name the modes, which help you accomplish live-debug and 1-click documentation effects?
You might also find eldoc-mode[1] and it's various mode-specific children (c-, perl-, ...) to a useful minor-mode. It displays a short string describing the function-at-point, and the order and name of it's arguments. Sort of zero-click docs. Whatever way it does it could probably be hacked up to display more complete docs in a split window or frame. Something I'll think about when I finally get an SSD :)
[1] http://emacswiki.org/emacs/ElDoc
Slime and Geiser give you this for Lisp dialects, including Clojure.
Great to see another clojure tool heading away from the old traditional and largely text based environments to something new and better. Anyhow, looks a lot like Code-Bubbles to me (http://www.andrewbragdon.com/codebubbles_site.asp). As he was talking about how other engineers work, on big tables where they place and organize all their current notes, items, documents - in the future, I'd like to have a large epaper covered, touch and object sensitive desk and couple of light epaper devices to take down and organize notes and code. Software will become more complicated in the future, so I think at some day we will need to adapt and use more powerful tools than the ones we currently have.
This really looks great. The doc and play views alone would be fabulous as I'm trying to learn clojure. Seems like an incredible sandbox environment for learning the language and exploring open source to understand how things are working. What are your plans for releasing/availability?
Where is the download link?
Just please don't let it become another Code Bubbles - a nice idea, breathtaking video, and no working tool available in the coming years.
Indeed, love the idea but not the transparency. Disappointing to see closed-source, demo-only videos on the top of HN.
As concepts go, not a bad start. One of my immediate thoughts was that this would be better served on a multi-monitor system. Every single one of our development machines has three 24 inch 1920 x 1200 screens. It's fantastic. You can keep everything you need up and available. It makes working on complex ideas an absolute pleasure.
On the hardware design front we use a program use a EDA tool called Altium Designer for schematics and board design. This, by far, is the most well thought-out application I have seen when it comes to multi-monitor smarts. It makes for a nicely flowing and efficient design process.
Very interesting, especially if multiple language support becomes part of it. Is making this a "generic" IDE a project goal?
I for one would be most interested in Python, and even SQL (for the docs / drafting table).
He talks in very generic terms, so I think you can gauge this to be the overall intent. But, I would have some reservations about the challenges of live-evaluation in other languages. It's not insurmountable by any means, but using a lisp really gives you a massive head start.
This is very cool indeed.
Cedric Vivier has made a LiveScratchpad that does live JavaScript evaluation in Firefox.
http://neonux.github.com/LiveScratchpad/
It would be cool to add the multiple function source to that!
This fills me with hope.
Functionally striking, visually beautiful -- it makes me feel suddenly like things are coming together in a way that might stick this time around.
In form: Value placed on aesthetics -- beautiful & functional design -- is a concept that's taken root in the marketplace at large.
In code: Like gfodor commented, it feels like the doors are open wider than they've been in a long time to new ideas, and that we see some elegant language mechanisms being rediscovered and rising to the top.
In tools: The same pattern ... with lots of points of reference, a critical mass of seekers and open source contributors, and bootstrapped on powerful tools that allow rapid expression of new ideas, the good ones see the light of day and, if successful, can take an advantage of an unprecedented kinetics of this ecology to rise to viability and then prominence.
I hope you'll forgive me if I'm blowing this out of proportion to wax elegiac or whatever -- it just suddenly feels like a good day to be a programmer.
Lovely demo, well explained. I'm using the same principles for my visual design web application, and I see the same simplicity and elegance here as well. Can't wait to try it out.
One thing I notice while playing video games is that having an SSD doesn't help that much once the game is loaded. This is because game devs think about file access and make sure that it is optimized. It would be nice to just get something like eclipse that takes 5 minutes to become usable and slows down all the time because it is hitting the file system without any regard for performance.
Due to a jar locking problem I'm having to restart eclipse several times a day and it is so painful watching it "build" and validate all this code when my real build happens on the command line.
I wish video game developers would start writing IDEs for other reasons like graphics as well. They seem to be the only ones who understand flow and how disrupting it is for a program to just become unresponsive for even a few seconds.
Looks gorgeous!
Interestingly, the whole idea of "the environment (and the IDE) is dynamic" is present in almost any Smalltalk dialect.
The file is just a convenient way to serialize the code but is not necessary for the act of programming.
Damn, I was expecting this from Ruby, I thought Clojurers were happy to use emacs :p
Now, all you need is a kickstarter.
Hardly a "new" concept. MS Research did something akin to his different functions on one light table. Displaying HTML in the REPL is (I believe) a Factor thing, amongst others. Documentation everywhere is supported by any decent IDE these days.(Except it's usually a hover tip, not a separate window). Code is not a file is the subject of entire Internet rants.
Don't get me wrong, this is cool when you tie it together. But it's hardly new. I'm inclined to say it would benefit from research into what others have done, but maybe I'm wrong. Maybe you really need to be unencumbered by old ideas to push this again, and maybe succeed this time.
"Files are not the best representation of code, just a convenient serialization."
I agree. Files (and version control systems) leak a tremendous amount of valuable information. They are a very '20th century' technology.
I'm working on a tool that behaves like a distributed version control system (branching and merging) but stores more fine-grained information about the programming process. This information can be played back and developers can tell a story about why the code is the way it is:
http://www.storytellersoftware.com
This looks amazing, it would be a perfect tool for learning programming in the first place, but can easily work great for experts as well. Incredible. When can we get a download link to try this out?
Have you released the prototype or do you plan to? I cannot seem to find it on your GitHub account.
I don't see the code out there, but here is his github: https://github.com/ibdknox
I like it. I'd not be surprised if someone comes up with vim and emacs version any time near soon.
Emacs is most of the way already. It doesn't have an interactive code display thing like this (as far as I know), but most everything else either already works or works similarly.
For example, getting documentation is just as easy. (Actually, I don't know if you can search by docstring, but otherwise it's the same.) You can also get the same experience as having functions rather than files open by having a lot of little "windows" (in the Emacs sense) with a function in each. Since you can have multiple "windows" open on a single buffer, it can work for functions in different parts of the same file as well.
In short: Emacs has all the building blocks you need (as always) and some of the features are already easy to replicate. Building something like this on top of Emacs just makes sense.
I was thinking the same thing. Many of those ideas would be great emacs modes. In fact during the first minute of the video I was going to ask how he skinned emacs to be so pretty :)
Amazing----I've dreamed of having something like this ever since I started programming. Can't wait to try it out.
Mind if I share a couple ideas that might not be hard to implement with what you've got?
1) It would be nice to see \aggregate information about what has happened in function calls. The simplest would be: while the code is running, put and update a bar graph next to each function to show, proportionally to others, how many times it has been called so far.
2) More generally: record and associate with a function \all the inputs and outputs it has had. (Other commenters talked about having "context"). Then the programmer can scroll through these lists, calculate statistics for them if they are numbers, or choose one of them to plug into the function. (Often when you are refactoring code, some function lower in the code path gets 'orphaned'----it took some kind of complex input you don't want to bother putting in by hand, and so now if you want to modify it you're deterred. If you had prior inputs, you could just 'wire it up' with one of those.)
3) Commenters talked about having different fonts. I think the \one area where this would be helpful in Lisp is with the parentheses. I've shared prior versions of this idea before, but what I think would be helpful is to vary both \color and \size of parentheses. You pick three or four colors, say red, blue, and black (more than that is hard to tell apart in context, especially with syntax coloring), and once you've varied that, you bump the size up. So if you had seven parentheses in sequence, there would be three sizes, with the outermost three the largest, the next three medium, etc.
How long did it take you to build this prototype?
I'm interested because when I played with Clojure I didn't feel like you can make quick prototypes with it.
5-6 days, most of which had to do with me having to hack around in the compiler a little. That was new for me and the Java there is particularly weird, so that took longer than I would've liked.
I've unfortunately had to spend a great deal of time working with Labview (a graphical engineering software development environment that works based on data flow. Functions are represented by blocks with terminals for input and output data. You wire functions together to pass data between them). Some aspects are horrible (primarily the maintainability of anything more than a trivial application), but they also do some interesting things that I thought were quite parallel to this demonstration.
Documentation is quite well embedded into the software, and comes up with a similar box detailing the docs for every function you come across. The system also shows you the flow of data through a programme, allowing you to debug and see the data types moving between functions. You can dive into sub-functions and see what data's moving through them. Debugging can be fantastically quick if you constructed your programme carefully. If you didn't though, it's hell (see the point about maintainability).
If you wouldn't mind me (your friendly, neighborhood National Instruments programmer browsing HN) asking, could you expound a little more on other things you've found horrible with LabVIEW?
I completely understand your sentiment on debugging and maintainability. I've done my fair share of quick-and-dirty apps that did one little thing wrong and a million highlighted executions and five years later, I've finally got a handle on what's wrong (mind you, I'm nowhere near a LabVIEW expert).
I love our documentation tool as well. We call it Context Help, and as you highlight over different parts of your code diagram, it's handy to see a quick, readable summary with links to full documentation for every single node and system available in LabVIEW.
If only all IDEs had the same functionality and it's the reason why I'm super psyched to see Light Table come out. Ready to be blown away.
This fills me with hope.
Functionally striking, visually beautiful -- it makes me feel suddenly like things are coming together in a way that might stick this time around.
In form: Value placed on aesthetics -- beautiful & functional design -- is a concept that's taken root in the marketplace at large.
In code: Like gfodor commented, it feels like the doors are open wider than they've been in a long time to new ideas, and that we see some elegant language mechanisms being rediscovered and rising to the top.
In tools: The same pattern ... with lots of points of reference, a critical mass of seekers and open source contributors, and bootstrapped on powerful tools that allow rapid expression of new ideas, the good ones see the light of day and, if successful, can take an advantage of an unprecedented kinetics of this ecology to rise to viability and then prominence.
I hope you'll forgive me if I'm blowing this out of proportion to wax elegiac or whatever -- it just suddenly feels like a good day to be a programmer.
Great work, and I'm impressed at how quickly Chris Granger created Light Table. I wonder how hard it would be to build an IDE for Meteor (EDIT: I mean get JS support in Light Table, since Meteor is just JS) - how amazing would that be. Or port Meteor to Clojure and wow ... these combined would be amazing.
I've believed for a long time that files were archaic and agree completely - and we should extend that idea to version control. If we version functions (and classes, stored procs, etc...) then you can create a type of failover to a last known good version down to that logical function.
As for the rest of the ideas - the table, organize and layout related code, the documentation and the interface are all terrific ideas and I can't wait to see where it goes. Imagine laying out all that code on a nice huge touch tablet with multi-touch support ... drool....
This is great. I'm so happy someone finally started moving in a new direction. I've been thinking along these lines for a long time, but never found the time or energy to actually start implementing anything.
The most important thing is to do away with the concept of a file as a main structural unit in a project.
Interesting... @Taligent we built a completely object-oriented dev. environment for C++ (borrowing a lot from various SmallTalk environments). There was no file system - everything was an object - comments were stored in the object system along with implementations. This allowed for some really cool self-documented versioning on classes. However the real magic was in the debugger where we were building runtime support for "edit/run" and "what if" so you can edit faulty code and rerun w/out the recompile (essentially patching the class as it was running). Seems easy now (w/dynamic languages) but at the time this was close to "rocket science..."
A man after my own heart. Here's another concept to dramatically improve efficiency: Code Contexts. Enable the user to select (or add) a specific set of contexts. When coding under a specific set of contexts, differentiation of code applies only under the given context set. Or, after making a code change the user could add/remove contexts to which it applies. This would resolve a lot of the complexities of OO programming. Behind the scenes, context sets can be organized into a class hierarchy. But the programmer wouldn't have to search through the damn hierarchy to find out what version of a particular method is currently in play..
Hi, I develop in Python and js. Idle is ok, but I'm sick and tired of Eclipse and I almost freaked out when I saw your article. The video seems pretty awesome and after taking a peep at the code, I'm thinking of learning Clojure just to be able to participate in the project. Visual Studio has finally proven itself useful (developing in it make you imagine better ways to develop software apparently) XD
My request is if you have some link for a let's say "decent" coder who wants to understand and maybe try to compile the code on his own computer (debian). Perhaps even recommend an IDE for Clojure until this one is ready.
At least some of the features you've brought up in the article can be done with BugAid (for C#). For example, the ability to "visualize" the data in a function by replacing the variables with the actual values can be done, albeit in a different way (http://www.bugaidsoftware.com/). The other feature, like a documentation that shows whatever you're looking at, can be achieved partially with Visual Studio by itself and Resharper (http://www.jetbrains.com/resharper/).
This looks fantastic! It also has the side effect of making me want to get back in to learning Clojure. The idea of the file not being the fundamental unit of code is especially intriguing, but hard to wrap my brain around - that's such a low-level, base assumption that it's difficult to picture truly challenging that.
What are some examples of other paradigm-shifting (argh, buzzword) ideas in the world of software development? Deviations from the norm often become the new norm, and I'm too young and inexperienced (I've only been out of college for 10 months) to remember the "old way" of things.
Great concept. This is kind of similar to an editor we've been talking about for Overtone. How about,
* allow for render plugin functions so values can be rendered with images, rendered canvases, control elements, etc.
* treat the AST as the primary data for each function or form, and then make the source code one of multiple renderings of the data.
- makes paredit type manipulations just operations on the ast
- allow for decorating the ast with additional data, which can be rendered with plugins (for example, heat-up regions of code as a profiler runs)
Perhaps you could make comments part of the ast decoration. Hover over a function call and the IDE can popup a display showing comments for that function. The popup could be easily switched back and forth between comments, the parameter list, or possibly other info about the function. The comments could be plain-text, rendered HTML, or even crazier stuff like audio/video recordings for particularly important comments.
People could choose whether they wanted comments rendered inline with code like usual or displayed elsewhere.
Perhaps you could make comments part of the ast decoration. Hover over a function call and the IDE can popup a display showing comments for that function. The popup could be easily switched back and forth between comments, the parameter list, or possibly other info about the function. The comments could be plain-text, rendered HTML, or even crazier stuff like audio/video recordings for particularly important comments.
People could choose whether they wanted comments rendered inline with code like usual or displayed elsewhere.
Perhaps you could make comments part of the ast decoration. Hover over a function call and the IDE can popup a display showing comments for that function. The popup could be easily switched back and forth between comments, the parameter list, or possibly other info about the function. The comments could be plain-text, rendered HTML, or even crazier stuff like audio/video recordings for particularly important comments.
People could choose whether they wanted comments rendered inline with code like usual or displayed elsewhere.
I love the visualization aspect of this. I can think of multiple situations where popping this open to look at a couple of interactions would be helpful, especially when getting acquainted with a code base I didn't help build. I'd happily add it to my toolbox! Great thinking, great design.
Would I use it for everything? Nope. Most of the time I just want to type with the occasional jump into the command line. For that I use command-line vim, and I don't see jumping ship any time soon.
Thanks for the work!
There's one thing I don't understand. When you execute code automatically, what do you do about side effects? If I have code that write, read or delete a file for example.
Glad to see someone finally understands the limitations of files and folders in IDEs. Let me suggest that your next step might be cooperative development as opposed to solo development. Hiveware for SoftwareDevelopment (not yet developed) would let Light Table users develop a single project's functions cooperatively and simultaneously without merge. Check out www.grammarapps.com to get an idea of the technology.
And here I was hoping for a 36 x 48" tablet type experience :-)
See also Jef Raskin's THE (now called Archy apparently [1]) as another take on how things could be different than they are today.
I find it interesting that different styles of thinking so profoundly affect peoples opinions on the quality of the tools they have available.
[1] http://en.wikipedia.org/wiki/Archy
Very cool!
There is the part where he calls (x 3) and the number 3 percolates through the definition of x. What would have happened if x was recursive?
I hate to be that guy, but where did you get the basis for the colorscheme. It (along with the rest of the editor) is beautiful!
Looks kind of like http://ethanschoonover.com/solarized
See I'm not sure if it draws much from Ethan's colors, the purple maybe, but that green is way different.
The last example, where the code called within a block is shown to its right, is something that I've often tried to do statically, manually when first trying to learn a large code base. I would want this for that alone. The fact that what's shown is live-ish is a big, diabetic coma-inducing glob of icing on the cake.
Very interesting concept and really pushes the idea of writing code beyond simply text editing. I'm in Visual Studio all day and I really wish I could do more with less panels and wizards. Or get a getter bird's eye view of my codebase without all those tree views. Sometimes I wish my class view was my code view.
You would make Bret Victor proud! For a slight chance you have not seen this; check it out for additional inspiration http://vimeo.com/36579366 http://worrydream.com/
Oh this is so awesome. Would it be possible to create a VIM plugin that uses some of these concepts?
Kudos on a job well done. I have been thinking about these things, and in case you haven't seen lisping(iPad app), check that out too.
One question though: Where do you store all your functions? Do you use a db or something like that? Or just one flat file or file/func?
This looks great. I was talking about this with some friends who mainly use vim and they would be for using this if it incorporated vim key-bindings. Whenever they have to use other IDEs (usually Eclipse) they have a hard time not using vim commands.
I'm the same way myself - I <3 vim.
Love it. However the thing that often keeps me away from rich IDEs is that they so often only support 1 or 2 languages: so I get used to the nice features, then I'm stuck as soon as I have to switch language. If this took off, it would be amazing.
I love it, when can I use it, and for what languages? I would recommend Kickstarter over YC because I expect Kickstarter would result in something I can use sooner :)
Thanks for pulling the video together, there are a lot of really interesting ideas in there!
Looks really interesting, would be great to have something like this for the web. I wonder how interested the author of Sublime Text would be in this as he seems to be very responsive with development, perhaps worth reaching out to him.
WANT.
IE: Very, very neat.
As a Ruby/Objective-C developer, I've always wanted something like this for my ruby projects. Xcode is awesome, but this level of integration for our distributed projects would make things go so much faster. I cannot wait to use it :)
I agree that sometimes files are not the best representation for code but languages gives them semantics. For instance, namespacing/packaging is based on files (which make dependencies based on files too).
I always wonder how can live preview work with I/O statements, like selecting/inserting from/to database. Can you forbid REPL to execute such statements? And then somehow mock that data for live preview?
This reminds me of Bret Victor's presentation http://vimeo.com/36579366. He presents a few demos with similar concepts and a great talk nonetheless.
This... is fantastic. I want it. A lot. What are your plans for further development? How are you going to distribute it. I guess I'm really just looking for, can I have it, when, and for how much?
I really like the idea of seeing multiple functions (which might be in different files) on the same page at the same time. In Textmate it would be great to see the whole MVC of one function at once.
Wow, Code Bubbles (http://www.cs.brown.edu/people/acb/codebubbles_site.htm) for Clojure, and done right!
This is a great idea. I can almost see my development time going down by a big factor and writing much more robust programs. I wonder, how hard it would be to do this in existing editors ?
As I said elsewhere, most of this would be very easy in Emacs. I think only the code-tracing stuff would be particularly difficult.
"There's an incredible opportunity to change the way we build, and as a result introduce tremendous value into the world."
There should be a name for this desire to create to contribute to society.
What a great presentation. The concepts are very well detailed and seem intuitive and highly useful.
Am I missing the "what next" section? Is there a git repository or download somewhere?
I would like to see the value-flowing features with recursion. Can't really imagine how this IDE will behave when the same function is called twice.
This is exciting! We wouldn't be coding the same way in 50 years - I hope what we do now will be compared to punch cards of early computing by then.
Looks really nice! I'm wondering how you provide instant feedback on loops, where each iteration would replace the variables with different values?
Clear and concise video. You really did a great job here Chris. My only critique is that I am now aware of what I am missing for my Java projects.
As a JS game developer, I can safely say this would revolutionize the way I work. Please make this an actual product, I would gladly pay for it!
That's awesome - I usually have a few different windows, either in emacs or just other terminals open to look at different functions at once.
Good work!
In my book, ibdknox is in the early lead for clojure hacker of the year. He has been putting out some very useful software. Thanks!
This looks really exciting. I also like the way that it is presented as enormously simplifying a somewhat complex space. Great stuff!
Hi Chris,
Why build an entire new IDE, while you can also integrate your brilliant bright new ideas into an already awesome editor like SublimeText?
this is quite cool, I'm not much of an IDE person, I like to stick with good old vim, but this sparks my interest. If it's open source then I might seriously consider it, even contribute some vi keybindings. I just hope it goes more in the way of building upon vi/emacs and modernizing it rather than stripping down an IDE and modernizing it.
I love the drafting table concept. In fact, I love the entire concept of this type of IDE.
And for some reason, this is screaming "Metro" at me.
like was said in the article, a js in-browser implementation, if possible, would be great. Imagine being able to get back to your work from any computer of any kind, anywhere, without having to download any ides or set up remote debuggers or anything. a great idea that would be even better (and I think manageable) in the cloud
Found a download!
https://github.com/ibdknox/live-cljs/downloads
That's actually my live game editor - not the same thing, but also fun!
I haven't decided what to do about my prototype quite yet, got too excited about sharing the idea :)
This is so cool, that I think you'd get plenty of funding to further develop this via a Kickstarter project.
1 reply →
'Smallest unit of code is the function.'
Those rectangulars - just visualized 'em few days ago, looking through some very long css files.
This is really amazing ! Wonderfully explained . And i LOVE the documentation everywhere concept !
Cant wait to try this out :) Cheers !
Many people have said this already, but as soon as you create any way to donate to this project, I'm definitely in.
This could be simpler if the there was a service that parsed all languages like Steve Yegge proposes in that video.
Would be nice to make a github with your sources, so we could try and/or work on a JS version (or other).
Let's say I wanted to do a native, or JVM-hosted, version of this. Which toolkits could I turn to?
that makes me want to learn Clojure.
+1 for the most interesting thing I've seen all week. Bravo for thinking outside of the box.
Very nice concept, haven't experienced any similar, so I got quite excited about it.
Looks great. I´d love to have that REPL as a buffer in vim. "Search, search".
Have the light table folks used a modern IDE? This looks so much like Emacs.
Very promising. Curious if that is a particular color scheme for the fonts?
This is my dream. I would love if someone, or a group, could develop this.
This is really cool, I hope you are able to launch this in the future!
Shutup and take my money.
I'd love trying it, but couldn't find the code. Is it aviable?
I really hope it's open source, I can't wait to give it a try.
This is something that I might actually trade in Vim for.
This looks great. What about code that has side-effects?
all of this (except the wonderful idea for debugging) is available in intellij you should also take a look at their scala repl, which just rocks
Yep - have the Lighttable folks ever used IntelliJ IDEA?
I would pay to be able to use this on Rails projects.
ibdknox: So this is sweet looking -- of course I want to know: when we can get our hands on a version?
It looks like the Emacs revolution!
Love the demo! Where to download?
How do we get it? \O/
This looks great =)
i will gladly support this endeavor with donations.
Is something like this out? If it is, take my money now.
Really cool concept, can't wait to try it !
Impressive!
when can we have it for C++?
I want a "buy now button", seriously.
Freakin awesome.
Ew
What language is it? Is the language just specific to that ide or can other language be changed to work with this ide?
He's using ClojureScript. He states at the bottom of the page:
Reminds me of the design and dynamic visualizations from IntelliPad (written for Microsoft's retired project 'Oslo') with several features from visual studio all incorporated into an elegant interface.
Nice job.
(Although better - this IDE is close enough to IntelliPad that I challenge your statment that it is a "new IDE concept.)
okay. i have a comparatively small pet project i work on in my free time, it's close to 60k lines of c++ code. now, please, tell me, how your "ide" is going to help me organize things better?
> Smallest unit of code is the function.
for what particular reason?
> Able to get instant feedback on code changes.
i've got 200 threads of execution in my fcgi module, how do you intend to eval that?
> Multiple editors with just one function in it. Show code in an "area of concern" not just in a file.
kinda interesting, but won't work really. usually you have quite a bunch of code, 100-200 lines in a function which is a regular business. put 10 of those on the screen and you've got enormous unmanageable pile of crap.
> The coding environment can show also results, app windows, graphics, other tools.
any specifics? but yeah, i must admit you can put fancy widgets on window panes lol
> Can save the configuration of the above. WOW!
There was a UX video a while back, quite a long video, and there were IDE features shown off that were slightly similar to this. You could trace code and modify it while it's running and visualize the results. I feel that it would have inspired or complement this concept very well.
I always wonder how can live preview work with I/O statements, like selecting/inserting from/to database. Can you forbid REPL to execute such statements? And then somehow mock that data for live preview?
I hate to be that guy, but where did you get the basis for the colorscheme. It (along with the rest of the editor) is beautiful!
This is probably one of the most innovative ideas I've seen in a while.
Can't we all just get along?
Amazing.
yes yes yes yes yes!
okay. i have a comparatively small pet project i work on in my free time, it's close to 60k lines of c++ code. now, please, tell me, how your "ide" is going to help me organize things better?
> Smallest unit of code is the function.
for what particular reason?
> Able to get instant feedback on code changes.
i've got 200 threads of execution in my fcgi module, how do you intend to eval that?
> Multiple editors with just one function in it. Show code in an "area of concern" not just in a file.
kinda interesting, but won't work really. usually you have quite a bunch of code, 100-200 lines in a function which is a regular business. put 10 of those on the screen and you've got enormous unmanageable pile of crap.
> The coding environment can show also results, app windows, graphics, other tools.
any specifics? but yeah, i must admit you can put fancy widgets on window panes lol
> Can save the configuration of the above. WOW!
SHUT UP AND TAKE MY MONEY!