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...
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.
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].)
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...
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.
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 :)
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.
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]
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
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?
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?
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.
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.
- 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.
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.
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.
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...
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!
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.
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.
"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.
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.
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)
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.
314 comments
[ 3.3 ms ] story [ 405 ms ] threadA 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...
I can't help but think of a drafting pad and drafting notebook to allow us to work on our system everywhere...
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
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...
the operative phrase is "for consumers", I'm not going to be programming on an IPad ever.
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.
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.
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++
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 :)
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?
"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
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.
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.
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.
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
https://github.com/ibdknox/live-cljs/downloads
I haven't decided what to do about my prototype quite yet, got too excited about sharing the idea :)
Good work!
Could someone illuminate me?
[1] http://docs.python.org/library/parser.html
[2] http://docs.python.org/library/ast.html
[3] http://docs.python.org/library/symtable.html
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.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.
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.
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.
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.
What other sticking points are there?
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.
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.)
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!".
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.
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.
http://www.infoq.com/presentations/Simple-Made-Easy
http://t.co/cJgpnX5B
http://www.youtube.com/playlist?list=PL4BFC3F13B846707B
http://books.google.com/books/about/Mindstorms.html?id=HhIEA...
http://worrydream.com/
http://vpri.org/
Part 4 primarily of:
http://www.amazon.com/The-Design-Essays-Computer-Scientist/d...
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)
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.
http://www.maartensz.org/computing/squeak/Helps/Programming/...
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!