4 ms·

Do not make it REPL-centric. Real life programs are not developed in the REPL. Include examples of complete programs. In certain environments/languages, real p

Do not make it REPL-centric. Real life programs are not developed in the REPL. Include examples of complete programs. 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."

dan-robertson 8y ago
Ocaml is not one of those environments. The repl is of limited value in ocaml as the language is not dynamic enough to use it. Much of the language is built on its module system and the repl requires one to write an entire module and (it’s signature) at once. This makes the repl very much inferior to compiled ocaml. 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 Now suppose you want to know the type of the function so you ask at the repl: utop> some_fn;; val - : (int -> unit) my_extra_args And now if you want to know how to call this function you need to try to guess arguments until a type error expands the type. 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)
jorge-fundido 8y ago
I interpreted that as not making his "intro to ocaml" REPL-centric, so that things like the build tooling gets covered.
Scarbutt 8y ago
I read that as do not make your program depend on REPL features.
SomeHacker44 8y ago
I sort of lost interest in what else the author had to say at this early point, despite having been interested in OCaml for many years. (Referring, for context, to the "Do not make it REPL-centric" comment in the article.) 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.
- lucidone 8y ago
  100% agree. Rails console and irb is a major reason why I keep coming back to Rails, I haven't found anything as mature and pleasant to use in a web dev framework for verifying the code and tinkering with my models.
- dmbaturin 8y ago
  I'm not against the REPL (perhaps I should even describe its usage in more detail). In fact, I use it all the time. I'm against books like Learn You A Haskell that leave the reader wondering how to make and distribute executable programs. Or, worse, create an impression that it is not even possible, if the reader is not motivated enough to read another book or blog posts.
tlrobinson 8y ago
And... Hacker News. I can't find it now, but I'm pretty sure pg talked about how Hacker News was, at least initially, REPL-centric (not in those words) EDIT: http://pchristensen.com/blog/articles/are-you-this-agile-paul-graham-changes-hacker-news-while-you-wait/ 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 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.
shafte 8y ago
A REPL is an incredibly useful tool for all sorts of development, "real" or not. But I share the author's frustration with intros to functional programming that take advantage of a REPL to provide small, context-less examples. It makes it hard to see how I could use the language in for a complex project with significant side effects (e.g. file/network IO). 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. [1] http://book.realworldhaskell.org/read/ http://book.realworldhaskell.org/read/
devmunchies 8y ago
but this article is about learning, not the day-to-day development in OCaml. I agree it is good to learn how to structure, compile, and run code without a REPL. ie. learning how to import files and all that.
systems 8y ago
How does that really work? 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
- stcredzero 8y ago
  How does that really work? 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.
- brudgers 8y ago
  The image abstraction often found in the ML family of languages (and Smalltalk). An image is a serialization of an interperter's state. An image includes the entire interperter/REPL/console code within the application. The effect is somewhat similar to REPL's attached to applications found in Common Lisp or Clojure.
  - lispm 8y ago
    Not sure who invented dumping and loading images, but the first Lisp did that already around 1960. From there it spread to Smalltalk in the 70s. 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.

dan-robertson 8y ago

Ocaml is not one of those environments. The repl is of limited value in ocaml as the language is not dynamic enough to use it. Much of the language is built on its module system and the repl requires one to write an entire module and (it’s signature) at once. This makes the repl very much inferior to compiled ocaml. 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 Now suppose you want to know the type of the function so you ask at the repl: utop> some_fn;; val - : (int -> unit) my_extra_args And now if you want to know how to call this function you need to try to guess arguments until a type error expands the type. 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)

jorge-fundido 8y ago

I interpreted that as not making his "intro to ocaml" REPL-centric, so that things like the build tooling gets covered.

Scarbutt 8y ago

I read that as do not make your program depend on REPL features.

SomeHacker44 8y ago

I sort of lost interest in what else the author had to say at this early point, despite having been interested in OCaml for many years. (Referring, for context, to the "Do not make it REPL-centric" comment in the article.) 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.

lucidone 8y ago
100% agree. Rails console and irb is a major reason why I keep coming back to Rails, I haven't found anything as mature and pleasant to use in a web dev framework for verifying the code and tinkering with my models.
dmbaturin 8y ago
I'm not against the REPL (perhaps I should even describe its usage in more detail). In fact, I use it all the time. I'm against books like Learn You A Haskell that leave the reader wondering how to make and distribute executable programs. Or, worse, create an impression that it is not even possible, if the reader is not motivated enough to read another book or blog posts.

tlrobinson 8y ago

And... Hacker News. I can't find it now, but I'm pretty sure pg talked about how Hacker News was, at least initially, REPL-centric (not in those words) EDIT: http://pchristensen.com/blog/articles/are-you-this-agile-paul-graham-changes-hacker-news-while-you-wait/ 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 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.

shafte 8y ago

A REPL is an incredibly useful tool for all sorts of development, "real" or not. But I share the author's frustration with intros to functional programming that take advantage of a REPL to provide small, context-less examples. It makes it hard to see how I could use the language in for a complex project with significant side effects (e.g. file/network IO). 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. [1] http://book.realworldhaskell.org/read/ http://book.realworldhaskell.org/read/

devmunchies 8y ago

but this article is about learning, not the day-to-day development in OCaml. I agree it is good to learn how to structure, compile, and run code without a REPL. ie. learning how to import files and all that.

systems 8y ago

How does that really work? 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

stcredzero 8y ago
How does that really work? 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.
brudgers 8y ago
The image abstraction often found in the ML family of languages (and Smalltalk). An image is a serialization of an interperter's state. An image includes the entire interperter/REPL/console code within the application. The effect is somewhat similar to REPL's attached to applications found in Common Lisp or Clojure.
- lispm 8y ago
  Not sure who invented dumping and loading images, but the first Lisp did that already around 1960. From there it spread to Smalltalk in the 70s. 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.