4 ms·

Something I’ve experienced programming is that if you establish a feedback loop you progress faster, worse scenario is when you have legacy code in a broken loc

Something I’ve experienced programming is that if you establish a feedback loop you progress faster, worse scenario is when you have legacy code in a broken local environment and changes take very long to be deployed somewhere. Mastering the art of zooming-in to the enough scope you can handle and make significant verificable progress it’s not a trivial task. Sometimes makes want to migrate to whatever language that has the best tools for debugging and more stable local dev environments so I can get to enjoy fast loops of feedback and be motivated by feeling like the progress in a game experience like article points out. Edit: Shameless plug: that’s actually what inspired me to create flowcus.bar to have constant feedback on the screen like in games. https://github.com/indiedevai/flowcus.bar https://github.com/indiedevai/flowcus.bar

omnibrain 3y ago
I often rant about everything related to the Delphi project I inherited, especially the stupid single pass compiler. But on the other hand having a blazing fast compiler that compiles even very large programs within seconds makes makes developing, debugging and testing so much easier. Even better is developing a new project with vue.js and Vite, where changes in the code just show up in the browser. Often even without visible reload. Fells like magic.
- ReactiveJelly 3y ago
  Yeah, slow compile loops are the worst part of Rust for me. (The 2nd-worst part is fighting the borrow checker) I know it'll get faster as hardware marches on, but I often wish I could draw a boundary and say, "Look compiler, this program is months from being done. Let's say everything outside this boundary can be optimized and it won't change. But everything inside the boundary is quick-changing business logic that I'm actively debugging. Don't link or optimize across that boundary. Use wasm to enforce that if you need it." In C++ I did that with Lua for a while, but the DevEx cost of FFI boundaries is pretty awful even when the performance cost is affordable. I dunno.
  - feoren 3y ago
    > I know it'll get faster as hardware marches on What makes you think this? Nothing else has gotten faster as hardware marches on. Almost all software is significantly slower than the equivalent (if it existed, of course) 20 years ago.
  - senkora 3y ago
    Can you not achieve this in the build system using incremental builds plus disabling LTO plus specifying that some translation units shouldn’t be optimized?
- Our_Benefactors 3y ago
  > where changes in the code just show up in the browser I still reflexively refresh the page after making changes after being burned by hot reloading systems one time too many. Hot reloading systems are great when you have only static content, but usually fall apart once front end state is introduced. It would be incredible for the JS ecosystem to get a hot reloading strategy that “just worked”.
  - KTibow 3y ago
    The one Vite has is pretty damn good
otikik 3y ago
That's a very neat idea, installed. Consider adding some links on the Readme itself about how to install, the releases tab is easy to miss. It would also be great if it was available as a homebrew cask.
- alfonsodev 3y ago
  that makes sense, I've updated the README and created an issue to remind me to make available trough brew. Thanks!
melvinroest 3y ago
The fast feedback loop is why I programmed in Pharo for a while

omnibrain 3y ago

I often rant about everything related to the Delphi project I inherited, especially the stupid single pass compiler. But on the other hand having a blazing fast compiler that compiles even very large programs within seconds makes makes developing, debugging and testing so much easier. Even better is developing a new project with vue.js and Vite, where changes in the code just show up in the browser. Often even without visible reload. Fells like magic.

ReactiveJelly 3y ago
Yeah, slow compile loops are the worst part of Rust for me. (The 2nd-worst part is fighting the borrow checker) I know it'll get faster as hardware marches on, but I often wish I could draw a boundary and say, "Look compiler, this program is months from being done. Let's say everything outside this boundary can be optimized and it won't change. But everything inside the boundary is quick-changing business logic that I'm actively debugging. Don't link or optimize across that boundary. Use wasm to enforce that if you need it." In C++ I did that with Lua for a while, but the DevEx cost of FFI boundaries is pretty awful even when the performance cost is affordable. I dunno.
- feoren 3y ago
  > I know it'll get faster as hardware marches on What makes you think this? Nothing else has gotten faster as hardware marches on. Almost all software is significantly slower than the equivalent (if it existed, of course) 20 years ago.
- senkora 3y ago
  Can you not achieve this in the build system using incremental builds plus disabling LTO plus specifying that some translation units shouldn’t be optimized?
Our_Benefactors 3y ago
> where changes in the code just show up in the browser I still reflexively refresh the page after making changes after being burned by hot reloading systems one time too many. Hot reloading systems are great when you have only static content, but usually fall apart once front end state is introduced. It would be incredible for the JS ecosystem to get a hot reloading strategy that “just worked”.
- KTibow 3y ago
  The one Vite has is pretty damn good

otikik 3y ago

That's a very neat idea, installed. Consider adding some links on the Readme itself about how to install, the releases tab is easy to miss. It would also be great if it was available as a homebrew cask.

alfonsodev 3y ago
that makes sense, I've updated the README and created an issue to remind me to make available trough brew. Thanks!

melvinroest 3y ago

The fast feedback loop is why I programmed in Pharo for a while