Light Table - a new IDE concept
chris-granger.com
chris-granger.com
- 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.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.
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!".
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.
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.
What other sticking points are there?
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 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.
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.
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.
http://www.maartensz.org/computing/squeak/Helps/Programming/...
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.
(More or less, I'm not saying it's black and white)
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.
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.
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
Exactly. But why do you actually need Kickstarter for that?
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.
Having said that, every time I've looked into graphical programming paradigms they almost always seem to fall apart or get in the way of translating ideas and thoughts into machine instructions.
In the end, at least for me, it's about having an environment and a language that gets out of the way and let's me program the way you'd play the piano: The music just flows and the technical bits that make it happen are invisible.
It's a graphical programming language with an emphasis on system design (for scientists and engineers) that uses a dataflow paradigm (amongst other things) and has a unique UI creation system.
(Disclaimer: I work for National Instruments and my comments here in no way reflect the views of National Instruments and yadda yadda.)
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.
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.
In any case, thank you for the feedback, it's always great to hear back from fellow programmers that have had experiences with LabVIEW.
What kind of programs are we missing out on by limiting ourselves to text? What kind of programmers?
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.- 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 :)
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)
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
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].)
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...
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.
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://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.
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++
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.
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;
}
}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.
http://people.csail.mit.edu/asolar/papers/asplos06-final.pdf
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?
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.
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!
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?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.
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.
Numbers.app has the nice feature (among others) to use column/row headers to name cells/colums/rows in formulas in a readable manner.
Data and formulas were kept completely separate so you could change them at will.
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.
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.
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.
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.
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.
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.
QuickCheck https://en.wikipedia.org/wiki/QuickCheck
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?
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.
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.
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.
Textmate 2 supports it if that's what you want.
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...
I can't help but think of a drafting pad and drafting notebook to allow us to work on our system everywhere...
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.
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.
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.
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"
Could someone illuminate me?
[1] http://docs.python.org/library/parser.html
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.
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.
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 would also love to have an editor of this kind for compiled languages ... What really sold me is seeing the flow of the data in the end of the video :)
Is Light Table also programmable in the language it's written in? I find extensibility and compose-ability far more important in an editor than any single feature alone.
Cool demo. I like the idea of alternate real-time visualizations of my code; especially in large and unfamiliar systems.
Just please don't let it become another Code Bubbles - a nice idea, breathtaking video, and no working tool available in the coming years.
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.
I for one would be most interested in Python, and even SQL (for the docs / drafting table).
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!
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.
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.
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
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.
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:
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.
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.
I'm interested because when I played with Clojure I didn't feel like you can make quick prototypes with it.
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).
I completely understand your sentiment on debugging and maintainability. I've done my fair share of quick-and-dirty apps that did one little thing wrong and a million highlighted executions and five years later, I've finally got a handle on what's wrong (mind you, I'm nowhere near a LabVIEW expert).
I love our documentation tool as well. We call it Context Help, and as you highlight over different parts of your code diagram, it's handy to see a quick, readable summary with links to full documentation for every single node and system available in LabVIEW.
If only all IDEs had the same functionality and it's the reason why I'm super psyched to see Light Table come out. Ready to be blown away.
Functionally striking, visually beautiful -- it makes me feel suddenly like things are coming together in a way that might stick this time around.
In form: Value placed on aesthetics -- beautiful & functional design -- is a concept that's taken root in the marketplace at large.
In code: Like gfodor commented, it feels like the doors are open wider than they've been in a long time to new ideas, and that we see some elegant language mechanisms being rediscovered and rising to the top.
In tools: The same pattern ... with lots of points of reference, a critical mass of seekers and open source contributors, and bootstrapped on powerful tools that allow rapid expression of new ideas, the good ones see the light of day and, if successful, can take an advantage of an unprecedented kinetics of this ecology to rise to viability and then prominence.
I hope you'll forgive me if I'm blowing this out of proportion to wax elegiac or whatever -- it just suddenly feels like a good day to be a programmer.
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....
The most important thing is to do away with the concept of a file as a main structural unit in a project.
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.
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.
* 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)
People could choose whether they wanted comments rendered inline with code like usual or displayed elsewhere.
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!
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.
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?
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?
Thanks for pulling the video together, there are a lot of really interesting ideas in there!
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 :)
There should be a name for this desire to create to contribute to society.
Am I missing the "what next" section? Is there a git repository or download somewhere?
Good work!
Why build an entire new IDE, while you can also integrate your brilliant bright new ideas into an already awesome editor like SublimeText?
And for some reason, this is screaming "Metro" at me.
I haven't decided what to do about my prototype quite yet, got too excited about sharing the idea :)
Those rectangulars - just visualized 'em few days ago, looking through some very long css files.
Cant wait to try this out :) Cheers !
It's no secret that I really like Clojure and as a lisp,
it was the easiest language for me to start the prototype
with, but there's no reason this couldn't be done for any
language with a dynamic runtime. The rest is mostly simple
analysis of an AST and some clever inference. So could
Light Table have used JS instead? Certainly - and
hopefully it will get there sooner rather than later.Nice job.
(Although better - this IDE is close enough to IntelliPad that I challenge your statment that it is a "new IDE concept.)
> Smallest unit of code is the function.
for what particular reason?
> Able to get instant feedback on code changes.
i've got 200 threads of execution in my fcgi module, how do you intend to eval that?
> Multiple editors with just one function in it. Show code in an "area of concern" not just in a file.
kinda interesting, but won't work really. usually you have quite a bunch of code, 100-200 lines in a function which is a regular business. put 10 of those on the screen and you've got enormous unmanageable pile of crap.
> The coding environment can show also results, app windows, graphics, other tools.
any specifics? but yeah, i must admit you can put fancy widgets on window panes lol
> Can save the configuration of the above. WOW!