Hacker News Reader

Comment by alfonsodev | Hacker News Reader

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

View on HN

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.

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.

> 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.

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?

> 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”.

The one Vite has is pretty damn good

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.

that makes sense, I've updated the README and created an issue to remind me to make available trough brew.

Thanks!

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

Reply on news.ycombinator.com