In certain environments/languages, real programs are developed in the REPL. Real programs, managing billion dollar portfolios, natural gas scheduling, and the payroll of Fortune 500 companies have essentially been "developed in the REPL."
Real World Haskell[1] is a great example of an introduction that provides small examples AND situates them in the context of programs that I could see myself actually using.
The article suggests that the repl is of use for finding the type of things. This is only half true. Consider the following:
type 'a my_extra_args = foo -> bar -> 'a
val some_fn : (int -> unit) my_extra_args
utop> some_fn;;
val - : (int -> unit) my_extra_args
Alternatively you could use compiled ocaml, write your programs in a sensible editor and then query the type using Merlin (a program to provide ide-like features to editors for ocaml)
On the other hand, I would expect a Common Lisp tutorial to talk about the repl as real world programs are written with the repl (but also in files)
In Common Lisp, Clojure, Scheme/Racket and Haskell, I constantly develop with the REPL. I also use it in other languages such as Ruby which are not necessarily REPL-centric.
I find that I write much better (less buggy) code, faster, in a language with great support for a REPL.
EDIT: http://pchristensen.com/blog/articles/are-you-this-agile-pau...
> This is a step beyond that. I'm not even doing releases; I've been pasting the changes into the running server's repl.
https://news.ycombinator.com/item?id=99586
Obviously it's a bit extreme to be hacking on the production site with no version control etc, but HN was a lot smaller back then.
Because at the end of the day, to build your program, you need to have code in a source file of disk Code in the REPL is not persistent
So unless the language come with some sort of repl server, which persist code on a server, and the program instantiate themselves from the server (something i have never seen and i doubt that this is what you meant)
I am guessing you actually mean, that development was REPL supported, and that you used the repl to test your code, and help you design your code
And I see no problem in that, but still you need a solid traditional cycle around that to actually build, deploy and distribute your code ... right
Because at the end of the day, to build your program, you need to have code in a source file of disk
Not necessarily in the way you'd imagine. In Smalltalk, there is what amounts to a transaction log of your code changes, which you can replay. There is also an operation analogous to a database "checkpoint" where you save the whole memory image.
In most production environments, there is a 3rd mechanism which also tracks and saves the configuration in a database, which also serves as part of a build/deployment mechanism.
Code in the REPL is not persistent
In Smalltalk, all code executed in one of the REPL-like things is recorded on the transaction log of your code changes.
I am guessing you actually mean, that development was REPL supported, and that you used the repl to test your code, and help you design your code
In many Smalltalk environments, there are REPL-like things everywhere, including the many of the fields/panes of the debugger, and seasoned Smalltalkers would pretty much write the system in the debugger.
A typical MIT Lisp Machine OS in the 80s recorded for all functions/etc. where they were defined and one edits a function by calling (ed 'foo) (or by pressing M-. in the editor on a function name) and then the source file with the function gets edited. So the Lisp IDE knows that foo is defined in the file hans:graphics;editor;foo.lisp.273 (where 273 is the version number or the file). If one saved an image, this information is stored and restored on starting the image. Common Lisp systems today still record the source location, but they lack the versioned file system and they also usually not record a particular location from a source code version system like SVN or GIT.
What Xerox Smalltalk did (and something similar did Xerox Interlisp-D) was to manage source code in a distribution file and a changes file. Thus where the MIT Lisp Machine IDE tracks a multitude of versioned files (and the user has to somewhat manage them by creating them, registering them, compiling, loading them), the Xerox Smalltalk abstracts the editing away from files and manages the source storage in a file mostly invisible for the user. Thus a Smalltalk class browser does not display files, but it displays individual definitions. Since the compiled code is some high-level byte-code, source code can also in a more limited way computed from the compiled code.
Similar: Xerox Interlisp-D (which was a Lisp IDE, which ran on the same hardware as the Smalltalk machines from Xerox), which also managed source code (using tools like the File Package and Masterscope), but the source code is actually Lisp data and the main code editor is a structure editor - not a text editor. Xerox called it a residential system - since the source is actually data in the image and the File Package manages to track the changes and keep external versions of the source.
I have actually no idea which ML also a) works with images and b) manages source code. Would be interesting to hear more about that.