I do a good combination of data science and development.

REPLs are nice, don't get me wrong, but they are by nature single entrance, single exit. You are basically riding shotgun on a single unit test. You get a great view along the way, but the problem solving doesn't scale, nor can it handle situations where you need to consider multiple paths through the code. Writing a good test suite, and knowing just where and how to place debug trace statements are two of my best problem solving skills.

F# hits a really nice sweet spot for this: scripts with an integrated interactive scripting environment, and complete access to a plethora of unit testing frameworks.

That lets you work line-for-line through your code, inspect and analyze each step as needed, edit parameters as wanted, restart and do clean runs through calculations using custom and third party libraries, and also interactively execute any tests/specs you have defined. It's a very tight feedback loop that doesn't compromise any of the long term artifacts you might want in a serious app.

In conjunction with .Nets extension mechanisms and some F# language features the setup lets you fire up a basic script, replace/extend anything from your object graph with new code, write accordant tests, and execute any or all parts of the test as desired in an interactive REPL-like session for problem solving and debugging: all in the same file :)

This flows really nicely with the single pass compiler, keeping things nice and clean so they integrate into the main app once exploratory development is done. Semi-serious typing, functional composition, and dynamic exploration -- it ain't bad.

Once you achieve the right result from the function you are writing, you just add that REPL invocation to your test suite. Then you just re-run your tests from time to time as you change the code further.

A REPL makes writing both code and tests easier.

This is exactly my flow. Get the small snippet/function working in the REPL, copy it into the source....move on.

>You are basically riding on a single unit test. You get a great view along the way, but the problem solving doesn't scale, nor can it handle situations where you need to consider multiple paths through the code.

Where a REPL starts to fail, I find integration tests start to shine and vice versa.

I see it along the lines of REPLs being helpful for prototyping code. TDD, strong static type systems and proper separation of concerns let you build larger maintainable systems.

A good REPL keeps a history. It happens frequently enough that dumping that history will give you a reasonable basis for a unit test. :)

Indeed, that's partly what my own testing framework (that I wrote and use on my own private projects) takes advantage of, except in interactive use.

The Common Lisp REPL automatically binds the last expression evaluated to the variable "+". It also automatically binds the value returned from the evaluation of the last expression to the variable "*".

I write code and develop interactively at the REPL with the package under development loaded/running. When the value I expect gets returned from the function or form I'm developing at the REPL, i just evaluate the "test" function (or a variant thereof if extra specificity or features are wanted such as names, doc-strings or tags, etc.), and the forms and expected values are packaged into a test and added to the projects' test repository.

Pretty much all the benefits of TDD, without writing tests up-front or wanting to do red/green (i did allow for the option, but i practically never do in practice), because they're an almost costless artifact of just developing now...

Yes, IPython supports something like that with the %save magic command, IIRC.

REPL are obviously a poor substitute for unit tests; but a unit test is a poor substitute for a REPL.

I happily use both. REPLs are for exploratory development. Unit tests are for ensuring code works (and continues to work in the future).

I disagree.

I have my IDE setup with some scripts to copy a database from production. Set some breakpoints and press the play button and I am debugging.

With A REPL first I need to do a load of import statements. Then populate my objects. Then get started with the actual debugging. I personally don't find it anywhere near as efficient as an IDE that has been setup. Plus with the IDE I can stop at a certain point in the code, have numerous variables populated then run "evaluate" in PyCharm, which gives most of the benefits of a REPL as far as I can tell.

Admittedly the IDE does take a fair bit more effort to get to a state where it is set up to be useful, but dealing with the whole system as opposed to a small part of it is incredibly beneficial for development. Though I guess a lot depends on the type of problem you are solving.

>With A REPL first I need to do a load of import statements. Then populate my objects. Then get started with the actual debugging.

No, you absolutely do not. You just need to click around until your code hits the point in the code (or, ideally, run an integration test that gets you to that point) where you want the ability to run methods, inspect objects, etc.

Just make sure you've shoved an import IPython ; IPython.embed() in there and you're good to go. No additional imports necessary.

I agree that having your environment set up with production data (or as close an approximation as you can get) is a good idea, but I'd rather script that with a test framework where it can be used for regression testing rather than bodge it together using an IDE.

"You just need to click around until your code hits the point in the code (or, ideally, run an integration test that gets you to that point) where you want the ability to run methods, inspect objects, etc."

This is generally a lot less effort than populating objects in the REPL to reproduce the same set of conditions.

That's basically an admission that you're not writing enough realistic tests or your dev environment is set up wrong.

For me, it's way way easier the other way around.

Ahh the classic "you're doing it wrong" reply with no advice on why it is wrong.

Do you need advice on why creating a code base not surrounded by realistic & reliable tests is a suboptimal approach?

Or did you think that once they're there it would still be a lot of effort to use them to populate objects?

Doesn't mean that its going to catch the bugs that are present. An IDE when properly setup is closer to a production system than a load of unit tests and as such will be able to fix far more bugs in my opinion.

But you are welcome to do what works for you. Maybe you work on something more suited to your approach. My approach works better for what I do.

I write integration tests, as I mentioned in the first post and realistic ones as mentioned in the second. I try not to write unit tests because, as you mentioned, they are unrealistic (among other reasons), and unrealistic tests tend not to catch bugs.

That said, a high level 'unit test' (e.g. one that manufactures a request and checks its response) is often realistic enough and works pretty well with IPython.embed().

> I have my IDE setup with some scripts to copy a database from production.

Can't you just run those scripts as the first thing in your REPL session?

That just copies the data, its doesn't do imports or initial fetching of data - which running the application in and IDE does for me.

Having an IDE setup is pretty essential to my job, so I am going to need that for debugging certain errors anyway. Once that is setup, I rarely see the need to start scripting things for a REPL as a debugger feels far more useful to me.

The "Open Debug Prompt" in Pycharm is the best of both. Breakpoint at the point of interest, enter the REPL, and continue writing at the prompt. Also good in Matlab. I hope I can see this feature in Rust someday, although it seems like a tall order for a non-interpreted language.

I have used python javascript and clojure and let me tell you that repl driven development is not exactly what you get with python and javascript. The most frustraiting thing after having used a lisp is the fact that you can not connect to your program while it's executing. In node for example i wish i could just connect to the running server and test some functions with the current program state, like database conections etc. In clojure you can do that from your editor and that is awesome it's really powerfull. You can just point to a function and execute it inside the running whole.

Node has a built in debugger that allows you to attach to a running process. You can even use chrome dev tools for debugging it.

In Python the built-in debugger can't attach to a running process, but it's just a matter of installing one.

Why Jupyter? Do you mean iPython? Jupyter isn't a REPL. I find doing actual development in Jupyter to be impossible. It's OK to write the top-level orchestration script, but for writing functions (which is what using a REPL is all about) it's just horrible.

I think you're confusing the old and new naming scheme. The old iPython project split back in 2015 into Jupyter and iPython. Jupyter is the name of the language agnostic part of project that develops the notebook, web apps, repl and messaging protocol parts. iPython is the kernel that provides python support for Jupyter. However since python is by far the most popular language used by Jupyter, people generally just say Jupyter when just say Jupyter/iPython.

No, the REPL is still part of iPython. Jupyter is the language-agnostic notebook.

I was pretty sure all the 'GUI' components ended up under the Jupyter umbrella, not just the web notebook. I'll admit I could be wrong.

That being said, why do you find iPython so much better than Jupyter? I write probably 80% of my python code in Jupyter and cannot imagine coding without it.

One reason is that I can use iPython with a decent text editor like emacs. I've tried to make Jupyter work, but it seems like you're supposed to use the web based editor, which is horrible.

But it's also just not a nice workflow. Projects are not linear. I tend to work on a function and get it working in the REPL. Then build up the program by combining together higher level functions. How am I suppose to test functions in Jupyter? Write the test then keep evaluating it and then delete it later?

Jupyter is not linear. You can edit and evaluate any cell at any time. If you don't want test interspersed with the code, you can keep tests at the bottom by adding cells in the middle.

Jupyter is mostly useful for diplay of preexisting work.

I use it to make very pretty PDFs for bosses who want executive summaries, and I've started investigating using it to give lab talks so we can hack on the data together if i have to.

I don't think it's a particularly useful development tool.

Yeah this is my feeling too. I like it for presenting work that's already been done. But I won't actually do that work in Jupyter.

In an IDE, the REPL is often called the "Immediate" panel or similar. It's available whenever you're stopped at a breakpoint.

I can't think of any good ide (dating back to vb6 20 years ago) that doesn't have one.

Those things are specifically not called a REPL because they aren't a REPL. However, there is now a thing called the C# REPL [1] that shipped with VS 2015 Update 1, but I've never used it so I'm not sure if it's true to the name.

[1] https://msdn.microsoft.com/en-us/magazine/mt614271.aspx

Your link has a section titled "The Visual Studio C# Interactive Window" explaining that that's where to find all this REPL functionality in VS.NET.

But, as I said above, it's not explicitly labeled as such.

I got "Interactive" confused with the "Immediate" window. Things like the Immediate Window have been around for decades in most version of VS, but both "Interactive" and "C# REPL" are new to VS 2015.