Engineering Chronon

All the technical and design details on Chronon - The DVR for Java

Light Table: Concept vs Reality

I recently came across this 'concept demo' of Light Table, which is being passed off as a ground breaking IDE, and has even managed to collect a fair chunk of change on KickStarter.

Being the geek that I am, it piqued my interest too and I took a good look at it. After analyzing the demo, even though the video looks cool, I dont see most of the functionality as groundbreaking and large parts of the demo seem highly contrived. Here are my thoughts and critique on what the Light Table concept demo.

Since I am a Java guy and the IDE concepts are defined as being language agnostic and that support for additional languages can be added later, I will compare the examples using Java code and Eclipse as the IDE.

Let's look at Light Table, feature by feature.

Docs everywhere

(download)

Here the author demos putting cursor on top of method calls and showing documentation on the side. He tries to pass this off as something revolutionary.

Maybe he should just open eclipse and its javadoc view, which does exactly the same thing.

Also unlike what is shown in the light table demo, where the documentation panel eats up half your screen, the javadoc view can be easily docked to any size and resized to preference.

Also the author says 'docs everywhere', but the demo shows that there is a special 'doc' tab you have to click on to be able to see the documentation (since it eats up half the screen). That means the 'doc' is in fact not everywhere and you have to switch to a special 'documentation mode' to see it.

Contrast that to eclipse's javadoc view, which can stay open continuously whenever you want and can be docked and resized wherever you want.

Finding functions

(download)

I am assuming java here, so i will refer to classes instead of functions for my examples. Even though java does allow functions inside classes i barely ever find myself searching for anything by its function name. Its almost always a class name, especially since multiple classes can contain a function with the same name. Also just looking at pure functions usually doesn't do it for me when examining code, since I also like to see the fields of a class.

Again what the author passes here for revolutionary is a trivial functionality in most IDE's. In eclipse, you can press Ctrl+Shift+T and type the name of a class, along with wildcards or package names if you want and voila you can get to it instantly. Only this has been possible for about 10 years now.....

No dealing with files

Throughout the demo, it is emphasized that the concept of files is hidden from the user. While good in concept, this is at best a leaky abstraction. At some point you will have to deal with files since that is what your version control system works with. However, almost all ides including visual studio, eclipse and intellij can show you views of your code that contains only the structural elements and not the files. Sure when you go to 'edit' the code, it shows you file name in the tab above, but is that really such a big deal....

(download)

The demo shows nice little functions calls which have their own small editing area. This seems very contrived. The functions shown are extremely small. How would the editing areas look like if the function in question was long. Wouldnt showing multiple functions on a single surface then lead to a 'resizing hell', where you are constantly trying to resize the individual editor windows to see the code you want to see? Sure one can make the argument that you should have small functions, but real world code doesn't exactly always play by those guidelines.

There is a reason why current ides only allow a split view of editors, and that is to avoid the 'resize hell' mentioned above since you only need to resize on one axis at most.

Instant feedback

(download)

In this part, which again feels extremely contrived, the author very conveniently shows small functions which operate only on primitive numeral types. 

However, real world code rarely works that way. You have objects calling other objects which in turn can call apis which in turn interact with external systems. 

How would the instant feedback work on a piece of code that deletes a bunch of files or sends a bunch of emails or is part of a distributed system and needs some input from a network or is complex multithreaded code? I dont want files on my system deleted as soon as I type an api call in the ide, same with sending emails, etc.

The second image here shows a portion of the Chronon Time Travelling Debugger code. How would 'instant feedback' work in this case? The code here relies not only on the state of the program in memory but also takes as input external files present on the filesystem. Will Light Table somehow magically generate the files in question and in the proper format that this function expects?

Even if LightTable were somehow to ignore api calls that say, modify your filesystem, how would the IDE 'know' about that api. Will someone have to manually go through all the apis in existence and make a list of which ones to emulate and which ones to not? That doesn't seem practical.

Also even if the code were indeed based on just basic numerical or string primitives, how would the 'instant feedback' work if the code were in a long, tight loop or did heavy cpu intensive stuff?

Conclusion

Even though the light table demo looks interesting at first glance, digging deep into it, some of the concepts presented as game changing like 'documentation everywhere' and 'find function' are already well implemented in other IDEs.

The other half of the demo looks extremely contrived and might look good in a 'concept' demo but the examples shown dont seem representative of real world coding and there is no solid explanation of how these problems would be tackled in the final implementation.

 

Filed under  //