8 ms·

With fast compiling languages a unit test is not for off from being a REPL. In Java I use JUnit as a REPL. Actually I prefer unit tests over a REPL the same re

With fast compiling languages a unit test is not for off from being a REPL. In Java I use JUnit as a REPL. Actually I prefer unit tests over a REPL the same reason I prefer bash scripts over one liners or SQL scripts instead of typing into the interpreter... I don't like the ephemeral nature of REPLs. Also with true REPLs unlike the debug unit test approach I mention with Java you really need the language to be dynamic. I'm not entirely sure why but static type languages are not very good at allowing code modification while running (I mean I have ideas but I don't know precisely if there is an actual theoretical limitation). I guess I prefer static analysis over the complete ability to modify the code base while running. Only add my 2 cents because the article doesn't mention any negatives to REPLs.

pjmlp 9y ago
REPLs are not ephemeral on Common Lisp environments. There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind. On Mesa/Cedar's paper they refer that they wanted to provide the same experience as their Smalltalk and Interlisp-D environments. On Oberon's case, it required just recompiling/reloading a specific module, which given Oberon's compile speed, was pretty quick. .NET has now a REPL, which coupled with Edit-and-Continue (when it works) is also quite good. I used to use Jython/Groovy as my Java REPL, now just have to wait for the Java 9 release.
- agentgt 9y ago
  > REPLs are not ephemeral on Common Lisp environments. You'll have to patiently elaborate more for me. Do you mean because the editors keep track of it and that you are working with immutable/idempotent stuff? Otherwise IMO it is ephemeral because you are mutating things and you can forget what you have loaded and what not. I'm probably wrong though. > There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind. Yes many do including my favorite of OCaml's utop but not many allow hot code replacement for a currently running program. I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out. > I used to use Jython/Groovy as my Java REPL, now just have to wait for the Java 9 release. I used Groovy as well but mainly because I didn't want to load a full IDE to test a couple of things. As I mentioned before I think with Eclipse/IntelliJ + JRebel + Debug attachment you can get damn close to a REPL. And depending on how you define REPL I think hot code replacement + debugger might actually be more powerful than a REPL but I have to explore that thought some more.
  - pjmlp 9y ago
    > You'll have to patiently elaborate more for me. They are image based, so you can just save your session and continue using it later in another day. > I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out. On those systems, the unit of loaded code is a module and the whole OS only has dynamic libraries as executables. So you can just reload a module and the next time you do module.proc on the repl, you will be referring to the newly loaded module. For me an ideal REPL should be like the experience I used to have in Smalltalk.
    - agentgt 9y ago
      Yes I agree on the Smalltalk point. I think Squeak was at one point the very future of REPL-like development and hence why I think the article doesn't really go into how REPLs could be better and how they aren't really that much better than other development tools (ie IDE + debugger,... I mention this in other comments). I had no idea that common lisp had image saving! I only used the Carnegie Mellon one in college.... its been a long time.
      - lispm 9y ago
        > I had no idea that common lisp had image saving! Lisp has image saving since around 1960...
        agentgt 9y ago
        I probably did at one point know this as I did use it in college but for some reason forgot it (we are talking 15 plus years) given that is apparently how you distribute executable lisp code... IIRC though I hated image saving when it came to Squeak aka Smalltalk so I'm not sure if I did like that.
        lispm 9y ago
        > given that is apparently how you distribute executable lisp code LispWorks can: * save images * create optimized images/applications for delivery, using a treeshaker for removing unused stuff * can generate Mac applications with the usual ceremony/ application bundles * can generate shared libraries which can be linked into programs written in C or similar Some other compilers can generate standalone C code doing whole-program compilation. For example mocl or some inhouse compilers used by companies.
Insanity 9y ago
Java is getting a REPL though. I believe it is part of Java 9 ;).
- agentgt 9y ago
  However to the author's point I believe some languages are inherently superior for REPLs particularly if they have powerful literal syntax. Java is not a fun language to type expressions in and IMO neither is Python albeit for completely different reason. I can elaborate more if you like but I think most will agree.. Java will be a pain to type in a REPL.
  - abhirag 9y ago
    You sir, seem to be hell-bent against REPLs :P I agree with your point that IDEs are getting better but REPLs are getting better too, why should they be relegated to be mere artifacts of the past. Your java REPL will mostly have autocomplete, give it a chance, it really might turnout to be fun :P And typing python in a REPL is fun for me, but fun is subjective, no point arguing about it :)
    - agentgt 9y ago
      I'm not against REPLs I just think they have been around since early Lisp and there are vast improvements that can be made. I use REPLs all the time... Bash is basically a REPL :) The reason I think Java REPL would be awful is not because I dislike REPLs but because Java is really painful for that kind of mutable command line like development. Like just making a damn struct like object is absolutely painful and Java does not have structural types (ignoring FunctionalInterfaces which isn't really structure types). Python REPL is painful because of required indentation and again because Python is similar to Java and prefers nominal types. I'm not against Python or Java but I don't think the language design of those languages really works well for REPL compared to say Lisp, OCaml, Haskell, or even Scala and Smalltalk.
      - stevedonovan 9y ago
tedmiston 9y ago
One nice thing about the Python REPL IPython is the ability to turn the ephemeral session into a file which contains every command in the session like a history file by just typing %logstart. Most of my projects start this way.
- lispm 9y ago
  Lisp has the function DRIBBLE for that. SLIME provides slime-repl-save-history ...
tikkabhuna 9y ago
I'm interested to see how useful Java's REPL is going to be. Like you I will use a JUnit test, or maybe a standalone class with a main method, to test a small bit of code. With Eclipse's debug support I don't feel the need for a REPL.
- _pmf_ 9y ago
  > With Eclipse's debug support I don't feel the need for a REPL. Clojure managed to make the tremendously powerful JVM debugging ecosystem completely useless (without providing any replacement with equal power).
  - joncampbelldev 9y ago
    As a person who has used the standard java debugger in intellij for clojure, could you expand on what features are missing? I find I don't get much use out of it anyway, due to immutable values and (mostly) pure functions I find I don't usually need the whole program to be running and frozen in time. However, I'd like to know what I'm missing.
valw 9y ago
Well, what are your thoughts on the 'Write fewer tests, faster' section of the article?
- agentgt 9y ago
  I assume you are the author? I think you make valid case/points but I have some kind counter points if you don't mind > 1. Having too many unit tests makes your codebase harder to evolve. You ideally want to have as few tests as possible capture as many properties of your domain as possible. Yes but I have found what often happened for me with with REPL environments is the actual code base would be littered with stuff to massage the REPL (commented out or left behind). At least with the unit tests that playing around stuff is away from the actual code. For both cases there is always the delete button :) . Also for some reason many developers I have worked with don't seem to have a problem deleting or putting an ignore on a test. After all the tests are source controlled. I do get your point but I don't think its that strong. > 2. Tests can only ever answer close-ended questions: "does this work?", but not "how does this work?", "what does this look like?" etc. I fail to understand this point. I mean you can obviously write tests that just run stuff and not throw an exception or error. Furthermore you can share how you set stuff up with other developers.... and again you can just delete it if its obnoxious. > 3. Tests typically won't run in real-world conditions: they'll use simple, artificial data and mocks of services such as databases or API clients. As a result, they don't typically help you understand a problem that only happens on real-life data, nor do they give you confidence that the real-life implementations of the services they emulate do work. This is exactly what I do not like about REPLs. You setup a custom environment and its hard to keep track of what you have done. I don't like the "not repeatable" nature of it. I do think you make excellent points about how immutability helps that problem as stuff basically becomes a log but for other languages this is not the case. However this is by far your strongest point. There are languages that allow you to play with a system while its running. Perhaps not through the command line but through a debugger. The Java debugger in Eclipse/IntelliJ can evaluate expressions and are not far off from being REPLs.... in some cases the debuggers are stronger than REPLs.
  - valw 9y ago
mjmein 9y ago
The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL. Instead, you develop code in a file, but constantly evaluate code as you go along. When I work on a clojure project, I very rarely open the actual REPL, but I am constantly evaluating code and experimenting with different implementations of functions. Then, when I'm happy with the results, I ask the editor to evaluate and insert the results back into the editor. This then becomes the unit test.
- agentgt 9y ago
  > The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL. > Instead, you develop code in a file, but constantly evaluate code as you go along. Yes but what you are describing is hot code replacement and evaluation. You do not need a REPL. For a concrete example Java + JRebel + Debugger (Eclipse calls it Display with a glasses icon) will do that for you. In my mind a REPL is very much about the input and of course the output otherwise its basically what I mentioned above. And I think the the article doesn't really go into any new innovation or attempts at making REPLs better (particularly because they mention Bret Victor)... ie better input and better output. Yes advanced REPLs have history saving capabilities and what not but then they are basically competing with the rest of the editor, IDE and source control. Really innovative REPLs I think are what Bret shows, as well Squeak, and Racket. Those environments offer really unique input and output.
- dagw 9y ago
  Instead, you develop code in a file, but constantly evaluate code as you go along. Half the time I find I go the other way. I develop in jupiter, and copy the function to a file once I get it working.
abhirag 9y ago
REPLs don't necessarily have to be ephemral, this is my REPL session(Jupyter Notebook) exported as HTML -- (http://abhirag.in/articles/train_of_thought_1.html http://abhirag.in/articles/train_of_thought_1.html), and also great REPLs can help in interactive static analysis, as a case in point consider the Idris REPL (http://docs.idris-lang.org/en/latest/reference/repl.html http://docs.idris-lang.org/en/latest/reference/repl.html).
- agentgt 9y ago
  Yes I think you make an excellent point but more so because the output of the REPL session is much better than a typical REPL session of just plain text. Sort of in a round about way but in my original comment my hope was to elicit the discussion that modern development tools of ide visualization + debugger + hot code swapping are not far off from traditional REPLs and in same cases better because the inputs and outputs are better. That is traditional REPLs (ie commandline with maybe some readline capabilities) I think aren't that much better the inputs/outputs aren't that good. To your point on the static analysis I agree but a truly interactive development system that allows google-esque querying I think is far more than a REPL or at least the REPLs I know/knew of but I guess REPL definition can be somewhat nebulous these days.
  - abhirag 9y ago
    The interactive development workflow in Idris is best described as type driven development and the focus seems to be on making the REPL an interface where an intelligent dialog can happen in between the programmer and the compiler, with the compiler trying to nudge you in the right direction. It is kinda fun, you should definitely check it out[1]. And regarding your point about the modern IDE workflow, I personally think that the sweet spot is somewhere in between, I personally prefer having a REPL process in the background I can interact with while still writing code in my source file and a REPL kept open as a scratch space where I can experiment freely without messing up my source code, I feel much better experimenting in a REPL, but to each his own I suppose :) Jupyter Notebook is a completely different beast though, modern REPL + literate programming, what's not to love. [1] -- (https://www.manning.com/books/type-driven-development-with-idris https://www.manning.com/books/type-driven-development-with-i...)
RyanHamilton 9y ago
I also used junit as a semi-REPL similar to how you describe. then I started playing with a REPL for a fully dynaimic language and when I came back to java, there were parts that I missed. So I actually created a java REPL: http://jpad.io http://jpad.io I would say the things it does that the typical junit run does not are: 1. Explorative queries, send sql statements see the results quickly. What particularly helps here is that any collection is converted to a table with each column representing a getXXX method. 2. Command line instant queries. Sometimes I just want an advanced calculator on the command line. I do "jpad -e 2+2" and it returns 4. No messing around with IDEs. 3. Automatic smart guessing of imports and ability to upload results straight to website to share with colleagues. That's what I liked, so I built it in. The lack of traffic may suggest others did not find it as useful :)

pjmlp 9y ago

REPLs are not ephemeral on Common Lisp environments. There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind. On Mesa/Cedar's paper they refer that they wanted to provide the same experience as their Smalltalk and Interlisp-D environments. On Oberon's case, it required just recompiling/reloading a specific module, which given Oberon's compile speed, was pretty quick. .NET has now a REPL, which coupled with Edit-and-Continue (when it works) is also quite good. I used to use Jython/Groovy as my Java REPL, now just have to wait for the Java 9 release.

agentgt 9y ago
> REPLs are not ephemeral on Common Lisp environments. You'll have to patiently elaborate more for me. Do you mean because the editors keep track of it and that you are working with immutable/idempotent stuff? Otherwise IMO it is ephemeral because you are mutating things and you can forget what you have loaded and what not. I'm probably wrong though. > There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind. Yes many do including my favorite of OCaml's utop but not many allow hot code replacement for a currently running program. I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out. > I used to use Jython/Groovy as my Java REPL, now just have to wait for the Java 9 release. I used Groovy as well but mainly because I didn't want to load a full IDE to test a couple of things. As I mentioned before I think with Eclipse/IntelliJ + JRebel + Debug attachment you can get damn close to a REPL. And depending on how you define REPL I think hot code replacement + debugger might actually be more powerful than a REPL but I have to explore that thought some more.
- pjmlp 9y ago
  > You'll have to patiently elaborate more for me. They are image based, so you can just save your session and continue using it later in another day. > I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out. On those systems, the unit of loaded code is a module and the whole OS only has dynamic libraries as executables. So you can just reload a module and the next time you do module.proc on the repl, you will be referring to the newly loaded module. For me an ideal REPL should be like the experience I used to have in Smalltalk.
  - agentgt 9y ago
    Yes I agree on the Smalltalk point. I think Squeak was at one point the very future of REPL-like development and hence why I think the article doesn't really go into how REPLs could be better and how they aren't really that much better than other development tools (ie IDE + debugger,... I mention this in other comments). I had no idea that common lisp had image saving! I only used the Carnegie Mellon one in college.... its been a long time.
    - lispm 9y ago
      > I had no idea that common lisp had image saving! Lisp has image saving since around 1960...
      - agentgt 9y ago
        I probably did at one point know this as I did use it in college but for some reason forgot it (we are talking 15 plus years) given that is apparently how you distribute executable lisp code... IIRC though I hated image saving when it came to Squeak aka Smalltalk so I'm not sure if I did like that.
        lispm 9y ago
        > given that is apparently how you distribute executable lisp code LispWorks can: * save images * create optimized images/applications for delivery, using a treeshaker for removing unused stuff * can generate Mac applications with the usual ceremony/ application bundles * can generate shared libraries which can be linked into programs written in C or similar Some other compilers can generate standalone C code doing whole-program compilation. For example mocl or some inhouse compilers used by companies.

Insanity 9y ago

Java is getting a REPL though. I believe it is part of Java 9 ;).

agentgt 9y ago
However to the author's point I believe some languages are inherently superior for REPLs particularly if they have powerful literal syntax. Java is not a fun language to type expressions in and IMO neither is Python albeit for completely different reason. I can elaborate more if you like but I think most will agree.. Java will be a pain to type in a REPL.
- abhirag 9y ago
  You sir, seem to be hell-bent against REPLs :P I agree with your point that IDEs are getting better but REPLs are getting better too, why should they be relegated to be mere artifacts of the past. Your java REPL will mostly have autocomplete, give it a chance, it really might turnout to be fun :P And typing python in a REPL is fun for me, but fun is subjective, no point arguing about it :)
  - agentgt 9y ago
    I'm not against REPLs I just think they have been around since early Lisp and there are vast improvements that can be made. I use REPLs all the time... Bash is basically a REPL :) The reason I think Java REPL would be awful is not because I dislike REPLs but because Java is really painful for that kind of mutable command line like development. Like just making a damn struct like object is absolutely painful and Java does not have structural types (ignoring FunctionalInterfaces which isn't really structure types). Python REPL is painful because of required indentation and again because Python is similar to Java and prefers nominal types. I'm not against Python or Java but I don't think the language design of those languages really works well for REPL compared to say Lisp, OCaml, Haskell, or even Scala and Smalltalk.
    - stevedonovan 9y ago

tedmiston 9y ago

One nice thing about the Python REPL IPython is the ability to turn the ephemeral session into a file which contains every command in the session like a history file by just typing %logstart. Most of my projects start this way.

lispm 9y ago
Lisp has the function DRIBBLE for that. SLIME provides slime-repl-save-history ...

tikkabhuna 9y ago

I'm interested to see how useful Java's REPL is going to be. Like you I will use a JUnit test, or maybe a standalone class with a main method, to test a small bit of code. With Eclipse's debug support I don't feel the need for a REPL.

_pmf_ 9y ago
> With Eclipse's debug support I don't feel the need for a REPL. Clojure managed to make the tremendously powerful JVM debugging ecosystem completely useless (without providing any replacement with equal power).
- joncampbelldev 9y ago
  As a person who has used the standard java debugger in intellij for clojure, could you expand on what features are missing? I find I don't get much use out of it anyway, due to immutable values and (mostly) pure functions I find I don't usually need the whole program to be running and frozen in time. However, I'd like to know what I'm missing.

valw 9y ago

Well, what are your thoughts on the 'Write fewer tests, faster' section of the article?

agentgt 9y ago
I assume you are the author? I think you make valid case/points but I have some kind counter points if you don't mind > 1. Having too many unit tests makes your codebase harder to evolve. You ideally want to have as few tests as possible capture as many properties of your domain as possible. Yes but I have found what often happened for me with with REPL environments is the actual code base would be littered with stuff to massage the REPL (commented out or left behind). At least with the unit tests that playing around stuff is away from the actual code. For both cases there is always the delete button :) . Also for some reason many developers I have worked with don't seem to have a problem deleting or putting an ignore on a test. After all the tests are source controlled. I do get your point but I don't think its that strong. > 2. Tests can only ever answer close-ended questions: "does this work?", but not "how does this work?", "what does this look like?" etc. I fail to understand this point. I mean you can obviously write tests that just run stuff and not throw an exception or error. Furthermore you can share how you set stuff up with other developers.... and again you can just delete it if its obnoxious. > 3. Tests typically won't run in real-world conditions: they'll use simple, artificial data and mocks of services such as databases or API clients. As a result, they don't typically help you understand a problem that only happens on real-life data, nor do they give you confidence that the real-life implementations of the services they emulate do work. This is exactly what I do not like about REPLs. You setup a custom environment and its hard to keep track of what you have done. I don't like the "not repeatable" nature of it. I do think you make excellent points about how immutability helps that problem as stuff basically becomes a log but for other languages this is not the case. However this is by far your strongest point. There are languages that allow you to play with a system while its running. Perhaps not through the command line but through a debugger. The Java debugger in Eclipse/IntelliJ can evaluate expressions and are not far off from being REPLs.... in some cases the debuggers are stronger than REPLs.
- valw 9y ago

mjmein 9y ago

The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL. Instead, you develop code in a file, but constantly evaluate code as you go along. When I work on a clojure project, I very rarely open the actual REPL, but I am constantly evaluating code and experimenting with different implementations of functions. Then, when I'm happy with the results, I ask the editor to evaluate and insert the results back into the editor. This then becomes the unit test.

agentgt 9y ago
> The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL. > Instead, you develop code in a file, but constantly evaluate code as you go along. Yes but what you are describing is hot code replacement and evaluation. You do not need a REPL. For a concrete example Java + JRebel + Debugger (Eclipse calls it Display with a glasses icon) will do that for you. In my mind a REPL is very much about the input and of course the output otherwise its basically what I mentioned above. And I think the the article doesn't really go into any new innovation or attempts at making REPLs better (particularly because they mention Bret Victor)... ie better input and better output. Yes advanced REPLs have history saving capabilities and what not but then they are basically competing with the rest of the editor, IDE and source control. Really innovative REPLs I think are what Bret shows, as well Squeak, and Racket. Those environments offer really unique input and output.
dagw 9y ago
Instead, you develop code in a file, but constantly evaluate code as you go along. Half the time I find I go the other way. I develop in jupiter, and copy the function to a file once I get it working.

abhirag 9y ago

REPLs don't necessarily have to be ephemral, this is my REPL session(Jupyter Notebook) exported as HTML -- (http://abhirag.in/articles/train_of_thought_1.html http://abhirag.in/articles/train_of_thought_1.html), and also great REPLs can help in interactive static analysis, as a case in point consider the Idris REPL (http://docs.idris-lang.org/en/latest/reference/repl.html http://docs.idris-lang.org/en/latest/reference/repl.html).

agentgt 9y ago
Yes I think you make an excellent point but more so because the output of the REPL session is much better than a typical REPL session of just plain text. Sort of in a round about way but in my original comment my hope was to elicit the discussion that modern development tools of ide visualization + debugger + hot code swapping are not far off from traditional REPLs and in same cases better because the inputs and outputs are better. That is traditional REPLs (ie commandline with maybe some readline capabilities) I think aren't that much better the inputs/outputs aren't that good. To your point on the static analysis I agree but a truly interactive development system that allows google-esque querying I think is far more than a REPL or at least the REPLs I know/knew of but I guess REPL definition can be somewhat nebulous these days.
- abhirag 9y ago
  The interactive development workflow in Idris is best described as type driven development and the focus seems to be on making the REPL an interface where an intelligent dialog can happen in between the programmer and the compiler, with the compiler trying to nudge you in the right direction. It is kinda fun, you should definitely check it out[1]. And regarding your point about the modern IDE workflow, I personally think that the sweet spot is somewhere in between, I personally prefer having a REPL process in the background I can interact with while still writing code in my source file and a REPL kept open as a scratch space where I can experiment freely without messing up my source code, I feel much better experimenting in a REPL, but to each his own I suppose :) Jupyter Notebook is a completely different beast though, modern REPL + literate programming, what's not to love. [1] -- (https://www.manning.com/books/type-driven-development-with-idris https://www.manning.com/books/type-driven-development-with-i...)

RyanHamilton 9y ago

I also used junit as a semi-REPL similar to how you describe. then I started playing with a REPL for a fully dynaimic language and when I came back to java, there were parts that I missed. So I actually created a java REPL: http://jpad.io http://jpad.io I would say the things it does that the typical junit run does not are: 1. Explorative queries, send sql statements see the results quickly. What particularly helps here is that any collection is converted to a table with each column representing a getXXX method. 2. Command line instant queries. Sometimes I just want an advanced calculator on the command line. I do "jpad -e 2+2" and it returns 4. No messing around with IDEs. 3. Automatic smart guessing of imports and ability to upload results straight to website to share with colleagues. That's what I liked, so I built it in. The lack of traffic may suggest others did not find it as useful :)