3 ms·

> There was no latency, or waiting for the language at all. I could live in a running Lisp image and iteratively define my programs from the inside out, or in w

> There was no latency, or waiting for the language at all. I could live in a running Lisp image and iteratively define my programs from the inside out, or in whatever way I wanted to, with immediate feedback after each change. I am becoming more and more convinced that developer latency is the most important metric for being able to deliver value to your customer (broadly defined). How fast does you code compile? How long for test to run? How long to deploy to an integration environment? To test environment with real users? To production? Lisp in some ways is still unmatched in this metric, for the kinds of reasons cited by the author.

Jtsummers 4y ago
> I am becoming more and more convinced that developer latency is the most important metric for being able to deliver value to your customer (broadly defined). This is generally true. Tighter feedback loops lead to greater responsiveness. You just have to make sure you don't get overwhelmed by them, too (feedback faster than you can respond to it).
- guenthert 4y ago
  A shorter change->effect delay eases learning (near instant gratification), but then again, Turbo Pascal on CP/M did already a good job at that.
aidenn0 4y ago
I have experienced this at work. We were working on a somewhat complex embedded system and seeing some unusual performance corner-cases. Everyone had a different theory for what was causing the problem. So I fired up SLIME and wrote a high-level simulator for the system, starting simple and adding in the complexities. Once we were seeing the same performance profile as the embedded system, I stopped, and we now had a malleable system. Then I spend the next 15 minutes implementing each of the recommended performance fixed individually, and we found one that worked in the simulation and then implemented that one in the real environment (it took almost 15 minutes just to update the program on the embedded target, and much longer to run a full test-case). Making it so you can check your guesses faster means you need not be as good at guessing. I should put in one additional warning though: don't fall into the trap of "make random changes until it looks like it works" and call it done. At this point we had only demonstrated that we knew where the issue was; the final fix was significantly different than the "quick and dirty" fix suggested by the simulation. The simulation I wrote definitely saved weeks (if not months) of time because 90% of the team was convinced that the issue was in a different part of the system than it ended up being in. We found the issue only because "It will take less than a minute, so what's the harm in trying?"
- wnoise 4y ago
  > Making it so you can check your guesses faster means you need not be as good at guessing Having more opportunities to check your guesses also increases your ability to guess...
  - cosmojg 4y ago
    And since practice makes perfect, you get better at making guesses as a result!
jcelerier 4y ago
> How fast does you code compile? How long for test to run? How long to deploy to an integration environment? To test environment with real users? To production? I'm working on ultra-fast iteration development methods for C++ with https://www.youtube.com/watch?v=fMQvsqTDm3k https://www.youtube.com/watch?v=fMQvsqTDm3k and yes, it makes productivity absolutely unmatched compared to everything I experienced before.
Jach 4y ago
Preferences seem to matter here, some people just seem to do better with longer cycles of feedback on more items than shorter cycles on fewer items. And some people really may need that "my code is compiling, it'll take a while and there's nothing I can do" break to mock-sword fight or whatever, almost like a pomodoro break between periods of intense focus. But there is some data on what could be, and you can of course measure your own latency on things. More narrowly defined, in the Java world JRebel is a product that can eliminate many kinds of forced redeploys after code changes -- or more simply, stopping and restarting your program and waiting for everything to come back up and reconfigure any necessary state to get back to what you were doing. I saved so much time thanks to it. Their own marketing materials suggest just this waiting on redeploys thing can quickly add to 20% of salaried time. (https://www.jrebel.com/sites/rebel/files/pdfs/rw-mythbusters-jrebel.pdf https://www.jrebel.com/sites/rebel/files/pdfs/rw-mythbusters...) Using it almost gets within javelin distance of what CL has always had, and gives you the flexibility to develop and debug in a more interactive style without having to go TDD or rewrite in ABCL. I haven't been keeping up (so would love to be informed things are otherwise) but I thought it was a shame that the JS front-end world seemed to finally be creeping up on where ClojureScript was in 2014 or so for interactive low-latency development, but then suddenly took several steps backwards with TypeScript -- with respect to interactivity at least, I don't doubt people's claims of steps forward on other metrics.
- jimbokun 4y ago
  > And some people really may need that "my code is compiling, it'll take a while and there's nothing I can do" break to mock-sword fight or whatever, almost like a pomodoro break between periods of intense focus. Yes, but working in a low latency feedback environment, you can still schedule breaks. But in a high latency feedback environment, it's impossible to avoid those breaks when you want to work quickly.
wglb 4y ago
I do mostly lisp these days, but your question brings me back to work I did with Smalltalk, one of the better integrated environments. It was so responsive and had effectively no compile cycle. At the end of an 8 hour day, i would be exhausted, as there was effectively no down time. (No time for sword play.)

Jtsummers 4y ago

> I am becoming more and more convinced that developer latency is the most important metric for being able to deliver value to your customer (broadly defined). This is generally true. Tighter feedback loops lead to greater responsiveness. You just have to make sure you don't get overwhelmed by them, too (feedback faster than you can respond to it).

guenthert 4y ago
A shorter change->effect delay eases learning (near instant gratification), but then again, Turbo Pascal on CP/M did already a good job at that.

aidenn0 4y ago

I have experienced this at work. We were working on a somewhat complex embedded system and seeing some unusual performance corner-cases. Everyone had a different theory for what was causing the problem. So I fired up SLIME and wrote a high-level simulator for the system, starting simple and adding in the complexities. Once we were seeing the same performance profile as the embedded system, I stopped, and we now had a malleable system. Then I spend the next 15 minutes implementing each of the recommended performance fixed individually, and we found one that worked in the simulation and then implemented that one in the real environment (it took almost 15 minutes just to update the program on the embedded target, and much longer to run a full test-case). Making it so you can check your guesses faster means you need not be as good at guessing. I should put in one additional warning though: don't fall into the trap of "make random changes until it looks like it works" and call it done. At this point we had only demonstrated that we knew where the issue was; the final fix was significantly different than the "quick and dirty" fix suggested by the simulation. The simulation I wrote definitely saved weeks (if not months) of time because 90% of the team was convinced that the issue was in a different part of the system than it ended up being in. We found the issue only because "It will take less than a minute, so what's the harm in trying?"

wnoise 4y ago
> Making it so you can check your guesses faster means you need not be as good at guessing Having more opportunities to check your guesses also increases your ability to guess...
- cosmojg 4y ago
  And since practice makes perfect, you get better at making guesses as a result!

jcelerier 4y ago

> How fast does you code compile? How long for test to run? How long to deploy to an integration environment? To test environment with real users? To production? I'm working on ultra-fast iteration development methods for C++ with https://www.youtube.com/watch?v=fMQvsqTDm3k https://www.youtube.com/watch?v=fMQvsqTDm3k and yes, it makes productivity absolutely unmatched compared to everything I experienced before.

Jach 4y ago

Preferences seem to matter here, some people just seem to do better with longer cycles of feedback on more items than shorter cycles on fewer items. And some people really may need that "my code is compiling, it'll take a while and there's nothing I can do" break to mock-sword fight or whatever, almost like a pomodoro break between periods of intense focus. But there is some data on what could be, and you can of course measure your own latency on things. More narrowly defined, in the Java world JRebel is a product that can eliminate many kinds of forced redeploys after code changes -- or more simply, stopping and restarting your program and waiting for everything to come back up and reconfigure any necessary state to get back to what you were doing. I saved so much time thanks to it. Their own marketing materials suggest just this waiting on redeploys thing can quickly add to 20% of salaried time. (https://www.jrebel.com/sites/rebel/files/pdfs/rw-mythbusters-jrebel.pdf https://www.jrebel.com/sites/rebel/files/pdfs/rw-mythbusters...) Using it almost gets within javelin distance of what CL has always had, and gives you the flexibility to develop and debug in a more interactive style without having to go TDD or rewrite in ABCL. I haven't been keeping up (so would love to be informed things are otherwise) but I thought it was a shame that the JS front-end world seemed to finally be creeping up on where ClojureScript was in 2014 or so for interactive low-latency development, but then suddenly took several steps backwards with TypeScript -- with respect to interactivity at least, I don't doubt people's claims of steps forward on other metrics.

jimbokun 4y ago
> And some people really may need that "my code is compiling, it'll take a while and there's nothing I can do" break to mock-sword fight or whatever, almost like a pomodoro break between periods of intense focus. Yes, but working in a low latency feedback environment, you can still schedule breaks. But in a high latency feedback environment, it's impossible to avoid those breaks when you want to work quickly.

wglb 4y ago

I do mostly lisp these days, but your question brings me back to work I did with Smalltalk, one of the better integrated environments. It was so responsive and had effectively no compile cycle. At the end of an 8 hour day, i would be exhausted, as there was effectively no down time. (No time for sword play.)