News for hackers. Stuff that matters.
Re:Two years of Rust by dwaltrip on Monday May 15, 2017 @05:19PM (#14345212)
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.

Re:Two years of Rust by zzalpha on Monday May 15, 2017 @05:21PM (#14345234)
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).

Re:Two years of Rust by dang on Monday May 15, 2017 @10:41PM (#14347001)
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.

Re:Two years of Rust by zzalpha on Monday May 15, 2017 @11:30PM (#14347170)
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.

Re:Two years of Rust by dang on Tuesday May 16, 2017 @01:02AM (#14347476)
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.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.

Re:Two years of Rust by burntsushi on Tuesday May 16, 2017 @08:36AM (#14349050)
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

[2] - https://news.ycombinator.com/item?id=14344957

Re:Two years of Rust by zzalpha on Tuesday May 16, 2017 @09:53AM (#14349567)
Eh, here Fowler just falls into to the trap of the Perfect Solution fallacy.

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.

Re:Two years of Rust by dwaltrip on Monday May 15, 2017 @11:48PM (#14347242)
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.

Re:Two years of Rust by goatlover on Monday May 15, 2017 @05:56PM (#14345495)
Lispers might be able to meet that challenge.
Re:Two years of Rust by nickpsecurity on Monday May 15, 2017 @07:27PM (#14346116)
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.

Re:Two years of Rust by mcorbin on Monday May 15, 2017 @06:08PM (#14345580)
Try Clojure.
Re:Two years of Rust by wtetzner on Monday May 15, 2017 @07:31PM (#14346137)
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.

Re:Two years of Rust by fnord123 on Monday May 15, 2017 @07:23PM (#14346093)
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
Re:Two years of Rust by zzalpha on Monday May 15, 2017 @06:13PM (#14345623)
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.