Question

When I code, I always write little pieces of unit, and compile it often. This helps me to make sure that everything run correctly, but it’s very time consumed. is there any programming language that can support us to do coding and running at the same time side by side ? i mean as soon as a key press leads to valid code, the effect of the edit is incorporated into the executing program.

Answer 1

What you are looking for, is sometimes called a lively system, incremental system or self-sustaining system (S³).

It’s not really a property of the programming language, it’s a poperty of the development environment. The only thing it does have to do with the programming language is that some programming language communities are violently opposed to the very idea of liveliness and thus those communities tend to not produce lively tools, while other communities cannot imagine life without a lively system, so they tend to produce them.

For example, almost all Smalltalk environments and many Lisp environments are lively, while I know of not a single lively C or C++ environment. There used to be a lively Java environment, called IBM Visual Age for Java (which was actually written in Smalltalk by IBM’s Smalltalk division and based on IBM Visual for Smalltalk, so there’s not really a surprise there), but when it was rewritten in Java as Visual Age for Java Micro Edition (which you probably know better under its current name, Eclipse), it lost its liveliness.

You ask about "coding and running at the same time side by side". Well, in a lively system, they aren’t even "side by side", they are actually one and the same: there is no distinction between coding and running, there is no distinction between IDE and application, there is no distinction between compile time and run time.

The way you often develop software in Smalltalk, is that you simply write down what you want and run it:

aCalculator ← Calculator new.
aCalculator compute: '1 + 1'.

(BTW: "Run it" simply means writing that little snippet of code into any text area anywhere on the screen, highlight it and click "Run".)

[Note: left arrow is assignment (think =), upwards arrow is return. Original Smalltalk systems had them on the keyboard, modern systems typically use := and ^ instead. Also, whitespace is message sending ("dot" in Java) and period terminates a sentence (;) in most languages. Arguments to methods are passed inline in the message itself after colons and not in parentheses.]

Of course, this doesn’t work, because the Calculator class doesn’t exist yet. So, the debugger pops up (did I mention there’s no distinction between running and debugging?) and one of the options it offers you is to create that class. You don’t restart the program, it just keeps on running. Now you get a new error, because the compute: method doesn’t exist. Again, the debugger offers to create the method for you and you can directly enter the code right there: (Did I mention there’s no distinction between the debugger and the editor?)

compute: aString
    ↑ 2.

The system has already filled the method name out for you and chosen a (somewhat) reasonable name for the method parameter. You only have to type the second line.

(BTW: if this workflow sounds familiar to you, it should. Kent Beck based the object model and execution model of his two testing frameworks (SUnit and JUnit), as well as the practices of Test-Driven Development and the Red-Green-Refactor cycle on exactly this workflow.)

Notice that at no time in the process did we stop or restart the running program. We were always editing the source code of the live system from within the system while the system was running. In fact, you actually cannot stop a Smalltalk program or Smalltalk system! Even if you shut down the Smalltalk system, what it actually does is serialize the entire state of the system (every class, every object, every variable, every thread, every window, even the position of the mouse pointer) to disk and when you start it up again, you are exactly where you left off. The system never stopped, it was just frozen. (If you are familiar with VMWare, Parallels, VirtualBox or something like that, it’s like taking a snapshot of the VM. Or think of hibernating or suspending your computer.)

In fact, if you download a version of Squeak today, there’s probably objects in there that have been literally running for 30 years. (This is another difference between Smalltalk and other systems. Smalltalkers believe that, just like fine wines, objects get better with age. This is in stark contrast to, for example, PHP or Ruby on Rails, where objects get thrown away pretty much after every web request.)

One of the most famous examples of this lively editing is from the pivotal "Apple Demo", when Steve Jobs, Jef Raskin and other members of the Lisa team visited Xerox PARC in 1979 to get a demo of the Smalltalk system:

One of the best parts of the demo was when Steve Jobs said he didn’t like the blt-style scrolling we were using and asked if we cold do it in a smooth continuous style. In less than a minute Dan [Ingalls] found the methods involved, made the (relatively major) changes and scrolling was now continuous! This shocked the visitors, espeicially the programmers among them, as they had never seen a really powerful incremental system before.—The Early History Of Smalltalk by Alan Kay, HOPL-II, ©1993 ACM

Oh, and yes, you did read that right: Dan Ingalls rewrote the video driver in a live system, from within a live system, without ever rebooting the system or even pausing the application. In less than 60 seconds. (Did I mention there’s no distinction between programming language and operating system?)

One of the best explanations of the liveliness properties can be found in the video Self; The Movie (Self is a derivative of Smalltalk). Also, take a look at the Lively Kernel by Dan Ingalls (one of the original designers of Smalltalk), which is basically a port of the Smalltalk ideas to JavaScript, running inside a web page.

As I wrote above, this is really a feature of the environment, not the language. Thus, even though I used Smalltalk here as an example, you could implement a lively system for any language. I already mentioned Lisp as a language for which many lively environments exist and I gave an example for JavaScript. APL and Forth systems tend to be lively as well. Factor is a nice example of a lively system. The most extreme example might be the VxWorks real-time operating system which contains a semi-lively system for C(!), which has been used to diagnose and fix a priority inversion problem leading to spurious system resets on the Sojourner rover on another friggin’ planet!