Live data from Hacker News

Software Development at 1 Hz

medium.com

111–120 of 121 posts

Re: Software Development at 1 Hz

#111
post #38

I would really like to see someone write enough code to do anything (or even compile), compile it, and interpret the results in a useful manner in less than a second. Continually, over a significant period of time. The tooling is certainly available, but the biological part of that process would seem to be superhuman.

The point is that you want to use the high frequency to get the simpler tools you will need out of the way, preserving your energy and attention for the complicated parts.

If you used up your energy by the time you made it through the simple stuff you are looking at a bad time later.

Re: Software Development at 1 Hz

#112
post #4

A 20s turnover is not even that slow. Debugging undecidable timing issues in an FPGA may have turnover counted in hours given how slow HW synthesizers are. If the need of better tooling is clear, the OP does not mention one important point: faster machines have created some sort of fast food approach to programming, where programs are built on the go with the help of the appropriate tools (some sort of computer-aided…

This is one reason why I'm so happy about the Raspberry Pi. It is not that the Pi as such added anything to the world that wasn't there before. But it is small enough to do the little things I always wanted while still running a normal OS, and it is attractive and widespread enough that SBCL was ported to it. I can now have the whole stack of SBCL with SLIME and all the other Lisp toys on the Pi.

Re: Software Development at 1 Hz

#113
post #86

The aversion towards upfront thinking and tendency to glorify the TDD slot machine is a bit unsettling.

That's somewhat unfair don't you think? It's perfectly possible to incrementally evolve code using TDD towards a particular destination determined by upfront thinking.

Re: Software Development at 1 Hz

#115

Earlier quoted context omitted.

Being methodical is good when your problem is intricate and well defined. Fast feedback won't be helpful in implementing a complex algorithm like a compiler or a numerical simulation (although I would argue it will help you debug it). When what you're doing is simple but error prone, or not well defined fast feedback can make you much more efficient. If you're using an underdocumented API/dataset, the best way to und…

> When what you're doing is simple but error prone That just means the problem is deeper than your understanding of it.

Or deeper than you >can< understand it without probing, because documentation is simplistic, wrong or non-existent.

Re: Software Development at 1 Hz

#116
post #103
post #95

Earlier quoted context omitted.

I think when you have to resort to using debugger, probably it is better to discard the code entirely and rethink the solution.

If you have to break out the multimeter, it's probably just better to throw out that radio and make a new one.

I don't think this is a right analogy, because the code can't "go bad" on its own one day (as if some capacitor would go dry), unless you modify it to do so. Maybe when you don't have access to the source code and you want to see what is going on, use of debugger could make sense.

Re: Software Development at 1 Hz

#117

Earlier quoted context omitted.

> When what you're doing is simple but error prone That just means the problem is deeper than your understanding of it.

Or deeper than you >can< understand it without probing, because documentation is simplistic, wrong or non-existent.

In that case you have a much bigger problem :P

Re: Software Development at 1 Hz

#118

Earlier quoted context omitted.

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. This! People rely on their fancy REPLs and super fast feedback loops and 1000 unit tests too much these days. What do you actually do when you can't run the code? What if you have to debug it just by reading it? There's a lot to be said about being efficient with trivial changes vs being methodical…

This is exactly the reason why I actually quite strongly discourage teaching programming by starting with IDEs. Far too often I see beginners fall into what I call "programming tunnel vision" where they repeatedly make very tiny and often random changes to a piece of code in an attempt to get it to compile or produce the right result, seeming to completely abandon any thoughts about the overall goal. A lower latency…

I think the "compleat" programmer can move freely between the two extremes. I have one piece of code -- in Common Lisp! -- that I've been working on for a couple of months of weekends and still haven't tried to run (except for an occasional one-line experiment to check that I have the correct syntax for a macro).

But I can also adopt a much more interactive, experimental approach in situations where experiments are cheap and easy.

It all depends on the nature of the task.

Re: Software Development at 1 Hz

#119
post #98
post #74

Earlier quoted context omitted.

This is as silly as asking why people advocate exercise. I mean, you clearly don't need to be able to lift heavy things. Even if it is sometimes helpful. Similarly, thinking about things before you do them will almost always be something you could just skip out on. But... It can be very helpful. And exercise is a great way to get better at work. "Practise makes perfect" and all.

No, people advocate exercise because it's necessary for long-term health.

Some exercise certainly helps long-term health. Calling it necessary greatly over states the importance, though.

And, I should be clear, I was saying "exercise" to refer to gym style exercise.

Re: Software Development at 1 Hz

#120

Earlier quoted context omitted.

Being unable to run through code in your head and fully conceptualise a codebase is a great way to introduce subtle integration-level bugs that escape unit testing.

That's why we have things called "integration tests". https://en.wikipedia.org/wiki/Integration_testing

And of course, there are never any bugs in software, ever, because we have integration testing!
Post reply on HN