Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.
BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to).
I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an existing codebase, but I can't envision a workflow where a REPL provides significant productivity gains for an experienced, professional software developer that aren't realized in other ways (e.g. writing unit tests).
No one can demonstrate productivity gains because productivity can't be measured. Lines of code can, and those are often a bad thing. Some of our most productive efforts make programs smaller.
So then the OP shouldn't have made the claim. It ain't my job to prove it. :)
That said, I fundamentally disagree with the idea that one can't measure developer productivity. I agree that there are many potential measures, all of which have the potential to be flawed or distorted. But the idea that the productivity of a developer can't be measured at all is something I've never heard anyone seriously claim.
> So then the OP shouldn't have made the claim
Come now, it was you who moved those goalposts and you moved them half a field or more. OP claimed REPLs "have benefits". Your response was (paraphrased) "demonstrable measurement of productivity improvement or GTFO". That sort of ante-upping just isn't that nice for good conversation, and certainly not when you're demanding a standard none of us can meet about anything.
> If your language doesn't have a REPL, your language is less productive. Deal with it.
That seems exactly like the kind of claim that everyone should view with a healthy dose of skepticism, and I think zzalpha's initial response[2] hit that right on the nose.
I repeat: there are no perfect measures of productivity. But there are imperfect measures that have some utility. The idea that we cannot measure at all because we cannot measure perfectly is simply untrue.
In this case we could, for example, take 1000 individuals with similar years of programming experience and given them two languages and a non-trivial problem to solve and see how long they take to come to a working and correct solution.
Is that perfect? No. But it's still something that's measurable. Do that with a reasonably large sample and you can probably start making inferences.
Our industry suffers from a horrible lack of concrete, scientific studies to back common wisdom. We would all benefit from ignoring Fowler, here, and getting down to the nuts and bolts of finding solutions to that problem. Until we do, while we'll have lots of fun having pointless debates on HN that cannot be resolved because we have no real data, the industry simply won't move forward.
Unit tests provide some additional benefits, but are a heavier approach with a slower, clunkier feedback loop. There are times when those additional benefits are not worth the added cost. Unit tests are also additional code that must be maintained.
It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.
In a statically typed language, a REPL can still be useful, but the gains from it are less than you'd get with an untyped language. It's easy to see what kinds of data a function works with by just looking at the types. There are exceptions of course, like when the type is very complicated, it can be helpful to see some examples of actual values of the type. And I suppose that's why languages like Haskell and OCaml have REPLs.
$ time lein run
Hello, World!
real 0m5.683s
user 0m5.981s
sys 0m0.557sThat's not even the beginnings of a useful reply. :)
Give me a highlight of your normal day-to-day with the language. What, exactly, does the REPL offer you that provides significant productivity gains that can't be had any other way?
Because clearly I've missed it.
And it should be pretty easy for you to describe if it's that common and/or obvious.