5 ms·

When a certain thing is done in repl, it usually converts into a function or two in the source code. The ad-hoc testing code is converted into unit testing. Th

When a certain thing is done in repl, it usually converts into a function or two in the source code. The ad-hoc testing code is converted into unit testing. That should help with maintenance no? One big theoretical advantage I see in repl driven development is, I can be sure that _all_ the code has been executed at one time atleast. (In a normal edit-compile-link-test language cycle, I can not be sure of that)

xapata 6y ago
Yep, just copy-paste a bit of REPL history for a docstring, then use `doctest` to make sure it holds. Pretty soon you'll have ~100% test coverage. Minus the error paths you didn't test in REPL.
Scarbutt 6y ago
Sure, but the point is that it requires more discipline, since the REPL can encourage you to be more lazy/sloppy.
- Jtsummers 6y ago
  Only if you aren't delivering something. No one (sane) is delivering a lisp image as "The Product" without also having a way to regenerate that image. If you write something in the REPL and never convert it to a proper function/class/struct/package in source, you're hosed when your system reboots and that image is lost. This requires no more discipline than, say, actually committing files to a version control system to collaborate with others. Versus shouting from the hills, "It works on my machine!" and being confused when it turns out that you didn't commit "foo.c" and compiled it manually rather than updating your Makefile and committing both changes so others could use it.
  - webmaven 6y ago
    > No one (sane) is delivering a lisp image as "The Product" without also having a way to regenerate that image. Oh man, you are so wrong about that. It's worth noting that this style of development also hamstrung quite a few Python web app projects in the late 90s because the Zope application server encouraged the use of this style of development (except through a browser rather than the command line) and beginners eventually got to a point that they were stuck and needed to make the leap to a completely different workflow of development based on files on the filesystem and in version control instead for their code, while content (ie. application state) for each deployment of their app remained in the embedded object database. A frequent lament was "if you knew I would eventually have to switch to filesystem based development, why didn't you have me start out that way?"
    - pjmlp 6y ago
      This is how any major CMS works to this day, and anyone doing serious development does have the engineering workflows in place to replicate the database content.
      - webmaven 6y ago
        You're missing that Zope application-development-through-the-browser could (and did) allow you to do just about anything with a Turing-complete template language, and if that was too unwieldy, Python script objects (which executed in a sandbox to prevent direct access to the filesystem, etc.). Nothing forced you to a saner development model except for wanting to include 3rd-party libraries and being able to distribute and version your code. Remember, this was when servers were definitely pets and scaling a web app meant scaling up to a bigger server, not scaling out to more servers. It wasn't immediately obvious (especially to brand new developers) that having all the code for even a simple CRUD web app, which you only ever expected to have a single deployment to a single server, live as pickles inside an object database that had a transactional history of edits, was inherently a bad idea. A lot of interesting stuff was created that way, and integration with the facilities that were missing such as version control led directly to capabilities like versioning content in cvs and svn (since code was just another kind of content). Eventually, Zope's so-called "Z-shaped learning curve" hindered adoption and other Python-based web-app platforms surpassed it in popularity.
        pjmlp 6y ago
        Nope I am not missing that, because enterprise CMS still allow that kind of stuff.
        webmaven 6y ago
        Well, sure, but they aren't usually presented as the default path for development, but rather as an option for per-instance customization. But if you understood my point about developing new functionality this way, why the non sequitur regarding content? Y'know what? Nevermind. We're on the same page now.

xapata 6y ago

Yep, just copy-paste a bit of REPL history for a docstring, then use `doctest` to make sure it holds. Pretty soon you'll have ~100% test coverage. Minus the error paths you didn't test in REPL.

Scarbutt 6y ago

Sure, but the point is that it requires more discipline, since the REPL can encourage you to be more lazy/sloppy.

Jtsummers 6y ago
Only if you aren't delivering something. No one (sane) is delivering a lisp image as "The Product" without also having a way to regenerate that image. If you write something in the REPL and never convert it to a proper function/class/struct/package in source, you're hosed when your system reboots and that image is lost. This requires no more discipline than, say, actually committing files to a version control system to collaborate with others. Versus shouting from the hills, "It works on my machine!" and being confused when it turns out that you didn't commit "foo.c" and compiled it manually rather than updating your Makefile and committing both changes so others could use it.
- webmaven 6y ago
  > No one (sane) is delivering a lisp image as "The Product" without also having a way to regenerate that image. Oh man, you are so wrong about that. It's worth noting that this style of development also hamstrung quite a few Python web app projects in the late 90s because the Zope application server encouraged the use of this style of development (except through a browser rather than the command line) and beginners eventually got to a point that they were stuck and needed to make the leap to a completely different workflow of development based on files on the filesystem and in version control instead for their code, while content (ie. application state) for each deployment of their app remained in the embedded object database. A frequent lament was "if you knew I would eventually have to switch to filesystem based development, why didn't you have me start out that way?"
  - pjmlp 6y ago
    This is how any major CMS works to this day, and anyone doing serious development does have the engineering workflows in place to replicate the database content.
    - webmaven 6y ago
      You're missing that Zope application-development-through-the-browser could (and did) allow you to do just about anything with a Turing-complete template language, and if that was too unwieldy, Python script objects (which executed in a sandbox to prevent direct access to the filesystem, etc.). Nothing forced you to a saner development model except for wanting to include 3rd-party libraries and being able to distribute and version your code. Remember, this was when servers were definitely pets and scaling a web app meant scaling up to a bigger server, not scaling out to more servers. It wasn't immediately obvious (especially to brand new developers) that having all the code for even a simple CRUD web app, which you only ever expected to have a single deployment to a single server, live as pickles inside an object database that had a transactional history of edits, was inherently a bad idea. A lot of interesting stuff was created that way, and integration with the facilities that were missing such as version control led directly to capabilities like versioning content in cvs and svn (since code was just another kind of content). Eventually, Zope's so-called "Z-shaped learning curve" hindered adoption and other Python-based web-app platforms surpassed it in popularity.
      - pjmlp 6y ago
        Nope I am not missing that, because enterprise CMS still allow that kind of stuff.
        webmaven 6y ago
        Well, sure, but they aren't usually presented as the default path for development, but rather as an option for per-instance customization. But if you understood my point about developing new functionality this way, why the non sequitur regarding content? Y'know what? Nevermind. We're on the same page now.