Hacker News new | comments | show | ask | jobs | submit login
Light Table - a new IDE concept (chris-granger.com)
1592 points by ibdknox 2067 days ago | hide | past | web | favorite | 291 comments



    - 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.)


Ah, understood. Tone threw me off and it's all too common to see the attitude I outlined above when old ideas are given fresh paint. Apologies for misrepresenting your view.


> Apologies for misrepresenting your view.

Oh please. He even misrepresented his own view.

"I wasn't attacking anyone, I was only letting everybody know they've been told"

The constructive bit of information was "hey cool this uses a lot of the concepts SmallTalk used in the 80s, great to see it getting some traction" instead of "I told you so!".


After a decade of waiting, I think I'm entitled to express a bit of frustration.

Your position is quite contradictory. Do you really think I'd extoll these capabilities for years while mainstream programmers pooh-poohed me, then suddenly change my position to "meh?" "I told you so," seems to be the most sensible response to me.


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.




check out udacity, coursera and khanacadamy.


why not name names? seems like it could be informative.


Not in this thread. This is Light Table's moment to shine, don't want to clog it up with such a derail.


Then do it somewhere else and point here, please? Another comment mentioned version control, which is a very important thing to get right, and I don't know how I'd diff two Self workspaces, for example...

What other sticking points are there?


Squeak smalltalk (among others I'm sure) has had version control for quite a while in the form of http://wiresong.ca/monticello/


Not old enough to have lived through what you said, but old enough to have noticed the ripples of "what could have been". Plan9. Lisp Machines. etc. So I'm also looking forward to your much-needed show-and-tell post!


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.


I've been using Max/MSP lately and while I find the language itself lacking (one example of something I wish I could do is nested lists), the editor is amazing. The live programming is ahead of any normal REPL I've used and the debugger is pretty cool too.

If it had a few extra features it would make it pretty close to my ideal programming environment: a way of (temporarily) disabling selected code; a unit testing mechanism and a way of extracting selected code to a unit test; a visual code diff tool; git integration (especially branches)


Where can I find a list of these amazing multi-media programming environments that I've never heard of before, but which look so awesome?


Max/MSP, Pure Data, vvvv, QuartzComposer, SuperCollider, ChucK, Processing, openFrameworks, Cinder, and Field are the big names.

But there are many more smaller projects such as Lubyk, Overtone, LuaAV, Faust, Plask, Impromptu and Fluxus.

I also want to plug NoFlo, which is a 'flow-based programming' library for node.js, which integrates with a visual editor.


I was unable to find anything close to a definitive list, but http://en.wikipedia.org/wiki/Visual_programming_language is a start.


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.


Visual Age for Java Micro Edition (re-written in Java) became Eclipse framework.


I did not know this. History even in software is interesting (http://en.wikipedia.org/wiki/IBM_VisualAge , http://en.wikipedia.org/wiki/Eclipse_(computing))

I wonder why the built in code repo did not become a feature - unless this another part of the project history I am unaware of.


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...


That's certainly true, but the two aren't mutually exclusive. Kickstarter will get you the funds to go out and build a cool product, but it won't tell you how to generate a model that's sustainable, teach you how to go to market, or even tell you if there's an available market at all.


Exactly. I can imagine a need for "Kickstarter mentors".


Kickstarter tells you there's no market by not funding your project: it's a MVP. But KS seems hard unless you're already well known.


Eh, product-focused, maybe. Being completely based on a single, unproven product is not really a great way to run a business, at least from Y Combinator's viewpoint.


Isn't that exactly what Y Combinator companies do? They create single, focused, unproven products and try to "prove" them.


YC companies very often end up with completely different products than they start out with. This almost never happens with Kickstarters, because those are actually project-based.


For founders looking at relatively quick exits, they are the product.


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


Kind of. Code Bubbles inspired a few of us (mostly steven schermerhorn + chris) to write a prototype of it for VS called Codeporium, which was at least part of what made it into debugger canvas. Of course, we didn't do any of the hard work (like getting the debugger working), so I'm not sure how much credit we should get :) Chris probably remembers more about it than I do.


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.


when you say that VS can make a billion, I assume you refer to sales revenues. I always thought MSFT spent more money developing their programming tools than they got in revenue (which makes sense for them because more developers for Windows lead to more licensed users of Windows)


Would you mind me asking how long it took you to develop that demo?


On Twitter he said it took six days: https://twitter.com/#!/ibdknox/status/190857331238645760


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.


I understand the frustration. I've run into from a few of my students on the FTC teams that I mentor in my neighborhood. I think that this can be attributed to a lack of really great educational material (there is good stuff out there, but it can be hard to find when the build season really picks up), but on the flip side, I've seen kids in elementary school pick up the basics of dataflow programming, especially when working with the NXT-G software that comes with the Mindstorms NXT.

It's definitely a tool and one should always use the best tool for the job. Sometimes the best tool is not necessarily the one with the most suited features, but the one that you're most adept at using. Either way, thanks for the input, really. It helps a lot to understand what people walk away with when they use a product you've been a part of, and I love that HN users are honest and gracious in their feedback. Cheers.


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.


That's the sentiment that's been conveyed to me when visiting a few university classes that make use of LabVIEW. I think that a great number of programmers that come from textual programming languages (I'm one of them) find the environment jarring as we try to force LabVIEW to fit norms we've built through out experiences in other languages. I think this is a combination of poor educational material catered towards dispelling projected similarities between graphical and textual programming languages and less than great communication beyond the scientific engineering user base of what LabVIEW is really great at.

In any case, thank you for the feedback, it's always great to hear back from fellow programmers that have had experiences with LabVIEW.


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?


Upvoted but I don't know the answers to your questions. Maybe getting more programmers is a good thing. For me, right now the issue is to get better ones, and I doubt having box drawing languages should bring better programmers on the boat.


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.


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.


I like the previous/next idea -- for me, it's often much easier to understand what a chunk of code does when you can see its behavior on multiple inputs.


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


CPUs and buses have been abstracted away pretty successfully by now, especially if you use a high-level language. But I can't imagine that the same will happen to file systems, at least not in the next 10 years. Too many of our critical tools, like all version control systems, depend on knowing where in the file system hierarchy your stuff is stored. Even if your IDE hides that from you, you'll need to know where to look as soon as something goes wrong. And things go wrong at the file system level a lot more often than they do at the CPU level.


Really? iOS has very effectively abstracted away the filesystem at a consumer level. I don't see it as much of a jump to see that occurring at the programming level, at least for application-level coding.

Obviously, there will always be a need for a class of programmers who are intimately familiar with the lowest levels, but that set of programmers will always be vastly smaller than the numbers of those who code line-of-business applications, etc...


"Really? iOS has very effectively abstracted away the filesystem at a consumer level."

the operative phrase is "for consumers", I'm not going to be programming on an IPad ever.


Did you even read my comment?


yep :)


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.


I think it would depend on the language to a certain extent. For example, good luck writing anything complicated in Python without touching files and directories, because every file is a module and every directory is a namespace.

A programmer obviously can't be expected to know how everything works, which is why we have abstractions. But I think abstractions need to be leak-proof to a certain extent before you can justify not knowing what lies below. The current state of file system abstractions is nowhere near that. They leak all over the place.


Speaking of file conflicts:

I'm picturing an alternate universe in which 'the database' stands in for 'the filesystem'. Data is laid out in a manner logical for its origins. Most programs use the library-provided implementation, of course, but there is a little more variability than in our world.

People have spent the past fifty odd years writing utility programs for manipulating databases instead of files, so concerns like 'moving' data between programs are still basically trivial.

In that universe functions really are the basic building block of code, and the database engine's consistency guarantees handle editing conflicts implicitly (with logging for version control, of course). Too bad, perhaps, that we're here rather than there.

Thoughts, criticisms, elaborations?


Reminded me of something Jaron Lanier wrote... found it:

"For instance, there is the idea of the computer file, which was debated up until the early 80s. There was an active contingent that thought that the idea of the file wasn't a good thing and we should instead have a massive distributed data base with a micro-structure of some sort. The first (unreleased) version of the Macintosh did not have files. But Unix jumped the fence from the academic to the business world and it had files, and Macintosh ultimately came out with files, and the Microsoft world had files, and basically everything has files. At this point, when we teach undergraduates computer science, we do not talk about the file as an invention, but speak of it as if it were a photon, because it in effect is more likely to still be around in 50 years than the photon."[1]

http://www.edge.org/documents/day/day_lanier.html


wasn't micorsoft supposed to roll something out with Vista that was sql server standing in for the filesystem?

http://en.wikipedia.org/wiki/WinFS#Development

I don't use windows anymore, but I hang with some .NET developers, and they aren't raving about WINFS, or Power Shell, or Sharepoint. Generally they seem pretty miserable.


Your mention of .frx files just gave me a potent flashback, complete with psychosomatic hives.


yeah sorry about that. I wish I could forget about *.frx and regsvr32 and VSS.


Registering versioned DLLs in Microsoft Transaction Server so that IIS could proxy requests from IE5.5's RDS ActiveX control to allow async callbacks on your 1999 intranet? Priceless.

Those DLLs calling functions in highly specific versions of the library that talks MS Exchange Server's data store protocol? Even more priceless.

Rebuilding an NT box from scratch because a junior developer accidentally installed a new version of Outlook Express which overwrote the working Exchange DLL with a slightly different version that exposes entirely different interfaces (but none that allow VB to access Exchange, curiously enough)? Priceless++


I've got plenty of stories just like that from the mid-90's

And this is precisely why I don't think it's a good idea to try and abstract crap away like the damn filesystem for software development/IDE. I bet it would be cheaper, less complex and for the overall good to instead teach developers how to wrangle files(if that really is a problem worth solving)

I wonder if it's time for a "I used to have to work with Microsoft Tech in the 90's" Meetup/Support Group :)


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.


    /**
     * 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;
      }
    }


Simple. Do some monte carlo comparisons between a large number of generated functions, based on various heuristics like number of instructions. So quickly get rid of explicit mapping of tests, especially if used larger. Add some genetic algorithms and a little more AI stuff ;)

One interesting thing though with auto-generated code based on specific test code is that when the test fails at some point the process just has to be repeated, potentially being done automatically.


Why not jump to prolog if you want to want to declare what the properties of the code are and have the compiler figure out how to actually do it?


"Combinatorial Sketching" is a surprising technique that does something close to this:

http://people.csail.mit.edu/asolar/papers/asplos06-final.pdf



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?


I can think of a few reasons, though they may not be the ones he has in mind.

There's the fact that you're dealing with cell references rather than variable names, so all of your expressions look like ($K4 - $S$1) rather than (principal - payment).

There's the fact that the IDE you're working in is trash -- rather than a text file with carefully indented parenthetical statements, it's a single line text field. Sort of like trying to code in a URL bar.

There's the fact that pieces of a program are often littered all over the spreadsheet, and it's hard to look at the whole thing at once.

There's the fact that it's extremely stateful -- the whole thing exists and depends on a table of values -- and when and where and how and in what order they're updated. From a programming perspective, everything is a global variable, and anything can update anything, and setting the state of those global variables is the only way for functions to return data or talk to each other.

I would say all of these are problems that Real Programming Languages have under control, so I can't say I worry too much about such an IDE descending into spreadsheet madness. I do wonder how you would show meaningful realtime results, though, without running a program from the top.


> There's the fact that you're dealing with cell references rather than variable names, so all of your expressions look like ($K4 - $S$1) rather than (principal - payment).

In Excel, use the "Name Manager" dialog and the "Name Box" on the formula bar. They re somewhat hidden, but discovery of them forever changed my spreadsheets!


Even better, stick the name at the end of the row or column, select the entire range and press alt-i n c. Good luck discovering that since they introduced the ribbon bar, though.


Oh come on, spreadsheets aren't that bad. Excel has had named ranges forever, and they can be scoped to the worksheet so they aren't completely global.

http://office.microsoft.com/en-us/excel-help/define-and-use-...

And functions can be VBA so the state of those global variables isn't the only way for functions to talk to each other. e.g.

    Dim x As Integer

    Function setx(n)
        x = n
        setx = 1
    End Function

    Function getx()
        getx = x
    End Function
and then you can put =setx(200) in one cell and =getx() in another. It is hard to look at the whole thing at once, but when do you need to do that?


Excel + VBA solves a lot of that. The spreadsheet part just becomes a view.

Somebody should really build a web app version of that, there are millions of custom Excel+VBA spreadsheets spread throughout businesses across the world.

The only way they will migrate online is either through custom web apps (I used to do a lot of those) or with a generic solution which doesn't exist yet.


To migrate them online, do you think what's needed is a single-click "just upload your Excel spreadsheet and it will all work, including the VBA"? That is, how important is 100% compatibility, including VBA? (The technical bar for that is pretty high.)


I don't think it has to be compatible, just something that is as capable. I have been thinking about it for a while, I would use Lua or Javascript as the scripting language.

I don't know why Google hasn't done this yet.


"There's the fact that you're dealing with cell references rather than variable names"

Excel has named ranges - allows you to give a meaningful name to single cell or a range of cells - a pretty widely used feature.

"it's a single line text field"

Excel's formula editor can be as large as you want.


> all of your expressions look like ($K4 - $S$1) rather than (principal - payment).

Numbers.app has the nice feature (among others) to use column/row headers to name cells/colums/rows in formulas in a readable manner.


Back in the NeXT days there were a bunch of variable based spreadsheets. The stars were Quantrix and Lotus Improv.

Data and formulas were kept completely separate so you could change them at will.


Those reasons are spot on. Also errors are difficult to track down and spreadsheets have horrible code re-use.


Oh yeah. I knew there was one I forgot.

You get compiler errors about as helpful as trying to debug C++ macros -- namely, something is wrong with this big glob of code, but it ain't gonna tell you what or where.


Spreadsheets would be nicer if they had a coherent dataflow model. Some spreadsheet programs do this automatically, but it could be a great place for a visual programming language too.

One ugly pattern that I'm often doing is to set a column with values by the function "A3=A2" and dragging that down. This gives a column of constant values which are tweakable by tweaking just the first element. That's what a scalar variable looks like in a spreadsheet. I'd like a separate calculation area where I could refer to these. Also when I select a column I might right-click and choose "Reduce → Mean", and the mean of that column could appear in the scalar area too. With some visual tinkering you might even have a sort of "iframe" containing the columns and the scalars at the bottom of the page, and have the mean appear underneath the column to remind me what it's the mean of -- but it should float; I shouldn't have to move it when I want to drag-down the calculation to enter in a few more rows.

With spreadsheet logic you have a couple of atomic operations like, "this is a fixed column specified by me," or "this is a column containing every half-int from 12.5 through 28.5" and so on. You have reductions of those list types, like Mean and Sum and Length. You have transformations of the data too, like NormalDist(x, mean, stdev). And some of them are cached-recursive, e.g. the running-sum function you might use to find a balance given a transaction history:

    balance[-1] = 0
    balance[i] = change[i] + balance[i - 1]
Finally you've got a wide variety of visualizations of that data, which might also be linked from the "scalar area" -- in fact it might be nice to develop ultrasmall "thumbnail versions" that update dynamically as the data updates.

I think those elements are sort of the "core" of a spreadsheet and are handled woefully inadequately by Excel, which was not originally designed for the popular usage case it has become.


Spreadsheets would be nicer if they had a coherent dataflow model.

What do you mean by "coherent dataflow model"? (I'm working on these problems - hence all the questions.)

This gives a column of constant values which are tweakable by tweaking just the first element. That's what a scalar variable looks like in a spreadsheet.

Why not just put the value in a cell and reference that cell absolutely?

With some visual tinkering you might even have a sort of "iframe" [...] but it should float

It seems that the general solution here would be (a) make it much easier to decompose a problem across multiple sheets (in your example, scalars and reductions could go in a different sheet), and (b) allowing sheets to "float" if you want them to, rather than always being in a different tab that you're forced to switch to. Does that make sense?

balance[i] = change[i] + balance[i - 1]

It's interesting that you single out this kind of recurrent calculation, where a later value of a column depends on an earlier value. It doesn't get mentioned very often. But it's fundamental to what spreadsheets do computationally and is the reason why parallelizing them is a lot harder than at first appears.


(1) You're right, I should have explained that more. I wanted to contrast this with something like "spreadsheets today have a datum-flow model" but a nice phrasing didn't come to me and I posted without remembering to insert the missing sentence.

What I mean is that spreadsheets are (right now) fundamentally based on the idea of a grid of cells which are individually meaningless and can contain anything, any individual datum, and datums may refer to each other by arbitrary operations. This grid view might be a good way to present datums to users but it requires a style convention when you want to write it to be readable; it encourages styles which obscure your ability to actually see what this sheet does.

It's not just that you can't see how the data flows, although that's part of it -- it's that the data is allowed to flow in ways that you could never easily visualize in the first place. Imagine that we simply draw the "depends on" relation by drawing a little curvy arrow from A to B if B depends on A. The Excel equivalent of "spaghetti code" could then literally look like spaghetti on the spreadsheet -- it would have neither head nor tail.

This could be solved with a nice model for how data, not individual datums, are allowed to flow through the application. Calculating a velocity might be as simple as writing "(x - last(x))/(t - last(t))", if x and t accepted vector subtractions and last(q)[i] == q[i - 1].

(2) I'm not entirely sure what you think the referring code is doing, if not putting the values in cells and referencing those cells. The reason why I can't be "absolute" about it is because in Calc (and Excel the last time I used it), to extend a computation over a vector, you highlight the computation and then click in a resizing corner to resize it into an area parallel to the input vectors -- or else you use some right-click "Fill" tool.

I used to think that these tools were broken but I think I can now appreciate that, because their model is so easily grasped, it's not really a break if it's hard to say, "no! I wanted this parameter fixed.

(3) That sounds suspicious. mean(v) should be associated with the column v in a clear way.


Interesting. It seems our views are similar on some aspects of this and divergent in others. I agree with you that the cell-based referencing system that treats every individual datum independently is too low-level and can lead to arbitrary spaghetti. (Boy do I know that spaghetti. I have been doing battle with that spaghetti. Or more precisely, with the computational model that you correctly describe as allowing for spaghetti.) There is clearly a need to express operations at a higher level: on vectors of data, let's say, rather than arbitrarily cell-by-cell. On the other hand, the grid layout and cell referencing system are the essence of the spreadsheet. If you mess with it very much, you forfeit the familiarity of spreadsheet users and run the risk of forfeiting what makes spreadsheets so accessible and popular in the first place. So I see the challenge less as "how to come up with a more structured UI that maps to a more coherent dataflow model" (where by "coherent" we mean literally, "let related data cohere together") and more as "how to generalize existing spreadsheet language into something that allows for coherence and exploits it where possible". Although spreadsheet language allows spaghetti, most spreadsheets do lay out their data and calcs in a coherent fashion. It's just that the system fails to recognize it.

Once one achieves "coherent dataflow", there might be a case for adding some features into spreadsheets at the application level that allow for declaring and visualizing more structure. But I think it's a mistake to start with that - or at least risky, because spreadsheet users like spreadsheets and there is no guarantee they will like anything else. (There's a reason why it's always programmers who come up with ideas for "fixing" the spreadsheet UI. You gave yourself away with the Haskell reference :)) The approach I'm advocating is risky too, though, since it's not obvious that there is any coherent generalization to be had out of the spreadsheet data model.

The reason why I can't be "absolute" about it is because in Calc (and Excel the last time I used it), to extend a computation over a vector, you highlight the computation and then [...] resize it into an area parallel to the input vectors

Yes, but in your example the computation that you extended this way had an identical number in every cell. (That is, by extending it, you were copying a formula guaranteed to evaluate to the same number in every cell of the column.) If that's correct, why copy that number at all? Why not just keep it in one cell and have everyone reference it from there? Is it that you wanted it to be visually nearby in every row? I'm probably just missing something about your example.

That sounds suspicious. mean(v) should be associated with the column v in a clear way.

But the solution is to make it very easy for you to lay out your data and calculations in the way you find clear. It is certainly not to force every user to lay out their data and calculations that way.


Just to answer your question with regards to (2):

Suppose I open up LibreOffice Calc, and my first row gets the values "c", "x", "y" in that order, as labels for three columns. The second row gets the values 2, -2, 0. The third row gets the odd formulas:

    =A2, =B2 + 0.02, =B3 * B3 + A3 * B3 - 1
Now I highlight C3 and drag it up to C2 (the y=0 term which shouldn't be y=0 is now correct). I also highlight A3 through C3 and drag it down, until my x's range from -2 to +2; this happens at row 202.

The key thing is, this "dragging autofill" has quickly managed to make all of the y computations dependent on the same c, whose authoritative value is stored at cell A2. (I can also change what x's I look at by tweaking the cell B2.)

So I highlight the x and y columns, click the Chart button, to do a scatterplot, lines only -- no point markers. Then I need to kill the autoadjustment of the y axis because it will confuse me, so I set it to go from y = -5 to +10.

Now I can just start modifying this parameter c in cell A2, and see how the graph changes. I might notice for example that the vertex of the parabola hits a maximum when c = 0. That's an interesting feature; it suggests that the vertex of the parabola describes its own parabola as you vary c. Et cetera.

The only reason for doing it this way is because that is the easiest way I know of to get the computation right for 200 data cells. You're right, I could hand-write 200 different computations to all point to A2. It would take a long time and I would hate my life. I could also write in the value "2" and whenever I want to change it, drag across 200 rows. But then I would never get to see how this thing changes. (If you've never seen it, see Bret Victor's "Inventing on Principle" talk for a discussion of the power of having a direct connection with your artistic creations.)


Maybe by "coherent dataflow model" he means some separation between what's an input to any given operation, so you can see what data is going where and how instead of it being scattered all over the place. That's what I'd like, anyway.

What it looks like to me is more like a program than a table, but with really good list/table entry and flow arrangement tools. That may just be because I'm a programmer.

Can you share anything more about what you're working on? These are interesting problems to me, too.


There's an aspect of that, too. I'm especially influenced by the circuit diagrams in G, the language which you program in when using LabVIEW. Basically most of the system, except for loops, looks like one big circuit. (Since loops are ugly because they're nonfunctional, I have wasted some time trying to think of what the Haskell version of G would look like, how you would embed monads in the circuit elements, and so forth.)


Can you point to an example of a nontrivial program in G that does something people would normally do in a spreadsheet?


The best reference I can show for the general programming model was a blog post which is not in G, but was called "Why Concatenative Programming Matters":

http://evincarofautumn.blogspot.com/2012/02/why-concatenativ...

which shows you how graphical diagrams can make sense out of concatenative programs.

If you really want an example, then I will give you this with some caution:

http://team358.org/files/programming/ControlSystem2009-/LabV...

The caution is that LabVIEW views a data source as a sort of continuous input stream, so that it is manipulating individual values at any given time. I would rather view vectors as more fundamental in a spreadsheet language.


I'd be happy to discuss it offline if you want to email me (address in profile).


I think it'd look a lot like Resolver One:

http://www.resolversystems.com/products/resolver-one/

It's not necessarily clear but the spreadsheet UI generates an IronPython program and you can hack the Python if you so desire. I've only used it lightly a couple years ago but I still think it's neat.


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.


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!


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?



"...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.


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.


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


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.


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!



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



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.


I'm far from a developer, but this got me excited. Actively watching code changes would make learning that much easier. I'd donate.


'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 !

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: