7 ms·

Just because there are benefits, doesn't make it a deal-breaker.

dwaltrip 9y ago
I didn't say it was a deal breaker? Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.
- zzalpha 9y ago
  Yup, that's fair. 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).
  - goatlover 9y ago
    Lispers might be able to meet that challenge.
    - nickpsecurity 9y ago
      I could probably have countered it, too, in the same language during the challenge back when I used it. I found the incremental, per-function compilation feature reduced compilation time of most changes to a fraction of a second. Most of time in programming is spent thinking, tweaking, debugging, dealing with 3rd-party libs, etc. I don't think a difference in the source-to-execution part of under 1 second is going to make a big deal. It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.
  - mcorbin 9y ago
    Try Clojure.
    - zzalpha 9y ago
      I have. That'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.
    - fnord123 9y ago
      That's hardly fair. Clojure is unusable without having a REPL already loaded. $ time lein run Hello, World! real 0m5.683s user 0m5.981s sys 0m0.557s
    - wtetzner 9y ago
      At one point I wrote Clojure for my day job. I think having a REPL is actually more useful for untyped languages, especially Clojure, where most data "types" are maps/lists. By exploring in the REPL, you can get a good feel for what kinds of data a function works with. 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.
  - dang 9y ago
    You're demanding the impossible here and elsewhere in the thread. Asking for the impossible is maybe ok, demanding it not so much. 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.
    - zzalpha 9y ago
      No one can demonstrate productivity gains because productivity can't be measured. 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.
      - dang 9y ago
        The fact that no one has come up with any plausible way of doing this is so commonly observed as to be a cliché. See for example https://martinfowler.com/bliki/CannotMeasureProductivity.html https://martinfowler.com/bliki/CannotMeasureProductivity.htm.... > 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.
        burntsushi 9y ago
        Not sure I buy that. I think you need to go further up the thread chain to see the OP on this[1], which, to be fair to your interpretation, wasn't written by dwaltrip: > 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. [1] - https://news.ycombinator.com/item?id=14344891 https://news.ycombinator.com/item?id=14344891 [2] - https://news.ycombinator.com/item?id=14344957 https://news.ycombinator.com/item?id=14344957
  - dwaltrip 9y ago
    One example: REPLs can occasionally be a great way to implement helper methods or other well isolated functionality. I understand you might argue unit tests are better for this, but I would very strongly disagree they are better in every situation. 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.

I didn't say it was a deal breaker? Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.

zzalpha 9y ago
Yup, that's fair. 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).
- goatlover 9y ago
  Lispers might be able to meet that challenge.
  - nickpsecurity 9y ago
    I could probably have countered it, too, in the same language during the challenge back when I used it. I found the incremental, per-function compilation feature reduced compilation time of most changes to a fraction of a second. Most of time in programming is spent thinking, tweaking, debugging, dealing with 3rd-party libs, etc. I don't think a difference in the source-to-execution part of under 1 second is going to make a big deal. It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.
- mcorbin 9y ago
  Try Clojure.
  - zzalpha 9y ago
    I have. That'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.
  - fnord123 9y ago
    That's hardly fair. Clojure is unusable without having a REPL already loaded. $ time lein run Hello, World! real 0m5.683s user 0m5.981s sys 0m0.557s
  - wtetzner 9y ago
    At one point I wrote Clojure for my day job. I think having a REPL is actually more useful for untyped languages, especially Clojure, where most data "types" are maps/lists. By exploring in the REPL, you can get a good feel for what kinds of data a function works with. 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.
- dang 9y ago
  You're demanding the impossible here and elsewhere in the thread. Asking for the impossible is maybe ok, demanding it not so much. 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.
  - zzalpha 9y ago
    No one can demonstrate productivity gains because productivity can't be measured. 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.
    - dang 9y ago
      The fact that no one has come up with any plausible way of doing this is so commonly observed as to be a cliché. See for example https://martinfowler.com/bliki/CannotMeasureProductivity.html https://martinfowler.com/bliki/CannotMeasureProductivity.htm.... > 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.
      - burntsushi 9y ago
        Not sure I buy that. I think you need to go further up the thread chain to see the OP on this[1], which, to be fair to your interpretation, wasn't written by dwaltrip: > 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. [1] - https://news.ycombinator.com/item?id=14344891 https://news.ycombinator.com/item?id=14344891 [2] - https://news.ycombinator.com/item?id=14344957 https://news.ycombinator.com/item?id=14344957
- dwaltrip 9y ago
  One example: REPLs can occasionally be a great way to implement helper methods or other well isolated functionality. I understand you might argue unit tests are better for this, but I would very strongly disagree they are better in every situation. 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.