Live data from Hacker News

Software Development at 1 Hz

medium.com

61–70 of 121 posts

Re: Software Development at 1 Hz

#61

Earlier quoted context omitted.

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 quite strongly discourage teaching programming by starting with IDEs..." >>"...also happens if you give them a debugger..." 1). I assume you can cite no research supporting the idea that new programmers are better off with your recommendations? 2). Your idea doesn't seem to take into account that different people think in different ways. I believe this approach was good for you. But as far as we know you could b…

Are you genuinely attempting to argue that thinking ahead and fully understanding the problem isn't preferable to tweaking one's way to a solution?

Re: Software Development at 1 Hz

#62
post #30
post #9

I am a huge believer of In my new team I got it from 30s to 5s and the effects have been amazing. I have to thank VScode and Gulp to make this possible. With typescript vscode does fast parsing of your code on every keystroke and gives squigglys instantly. On every save, gulp does its magic and vscode runs the problem matcher and shows more squiggly on my editor. The browser knows when a file has changed and refreshe…

Web engineers are waiting for stuff to compile these days? I thought things were supposed to be moving forward, not backward.

There's always been a segment of web engineers who have had to wait for stuff to compile. That's not a bad thing, in and of itself. It's the really long compile times due to bad tooling that sucks. Those are avoidable, though.

Re: Software Development at 1 Hz

#63

This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical element of productivity, and without which one is relegated to spending time manual checking what automation does almost instantly. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think…

"fizzbuzz" was the wrong example, picked for familiarity but understating intended complexity. Point was that forms of "whiteboard coding" completely overlook the point of the article.

Re: Software Development at 1 Hz

#64

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the…

> High latency feedback forces you to be more methodical in your development and think about the changes you're making.

There is also an attitude in computer music that low latency audio and realtime systems are simply part of the march of historical progress and ultimately represent a step forward from the days when composers could wait a week to hear 15 seconds of music rendered.

I found that I like the think-write-render-listen-repeat loop that comes from a compiled music workflow. (I discovered this when writing a -- initially very slow -- nonrealtime python computer music system which in the early days would sometimes have me waiting a few hours to render a couple minutes of music.)

Realtime computer systems enabled all sorts of new forms of live improvisation, interactive algorithmic systems, etc but sometimes it's very nice to have to sit in a quiet room with a text editor or notebook and think your way through the next long render.

Re: Software Development at 1 Hz

#65

Earlier quoted context omitted.

> debugging first in your head is yet another skill that should really be taught to everybody but isn't Along with smelting iron. I don't know why people advocate skills one doesn't need, saying "but they make you better". Skills you don't need will atrophy, because you don't need them. Conversely, skills you need with strengthen. Why would I debug first in my inaccurate head when I have a perfectly accurate debugger…

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

Re: Software Development at 1 Hz

#66

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the…

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

One thing that helps is having short, self-contained, composable pieces of code that are easy to run in a repl or compile. This also helps testing and general understanding.

Re: Software Development at 1 Hz

#67
I'm reminded of this very amusing C++ compilation speedup trick: cat * > everything.cpp - http://stackoverflow.com/a/318495/3229684

---

Also, I tend to do all my work using a realtime-feedback model like this.

I discovered inotifywait a few years ago, and consider it to be the coolest thing I've discovered. Using a loop like:

    while true; do clear; ./program; inotifywait -qq -e delete_self program; done
I run my program, then sit waiting until I re-save it, at which point I run it again. This approach is very flexible; the example above works for shell scripts, or I can do "gcc -o file file.c && ./file", or I can do "node file.js", or whatever. Switching the sequence around I can have inotifywait pause before the first execution too, but I prefer the method above. I occasionally substitute "clear" for "tput reset" so I can wipe my scrollback and shift+pgup stops at the top of the current execution.

There are some caveats though.

The biggest is that this approach doesn't work too well for things that need to be killed to be restarted, like socket servers; that's fixable but nontrivial and likely project-specific too.

The second problem are the race conditions that will likely arise between your editor's slow file-save process and inotify's fast response time, producing irritating "File is in use" errors 50% of the time (since inotifywait exited, bash looped, and ./program is trying to be read by your compiler or interpreter while still locked by your editor).

The DELETE_SELF inotify event is specific to the Geany text editor; when Geany saves a file it does quite a few operations, and DELETE_SELF is amongst the last (but inotify doesn't see any of the following events since DELETE_SELF marks that the file - that inotify was watching - got deleted; this is thankfully coincidental with Geany being done with the file). You'll need to do something like "inotifywait -m program" and watch what events occur; inotifywait exits on the first event received; hopefully there's a lone unique event at the end of the sequence. Worst-case scenario you might have to add in "sleep 0.05"; I have not tested the success of prefixing the compilation step with something like "while [ ! -r program ]; do true; done".

Re: Software Development at 1 Hz

#68

Earlier quoted context omitted.

>>"I quite strongly discourage teaching programming by starting with IDEs..." >>"...also happens if you give them a debugger..." 1). I assume you can cite no research supporting the idea that new programmers are better off with your recommendations? 2). Your idea doesn't seem to take into account that different people think in different ways. I believe this approach was good for you. But as far as we know you could b…

Are you genuinely attempting to argue that thinking ahead and fully understanding the problem isn't preferable to tweaking one's way to a solution?

WhitneyLand is probably not arguing against the claim you make in the large, but against the unsubstantiated argument that using IDEs and debuggers is more likely to lead you to that style of thinking than high latency variants.

One could just as easily hypothesize that these tools let you avoid thinking in the small, and help you form a big picture overview that would otherwise be difficult to understand.

Re: Software Development at 1 Hz

#69
post #6

I once had - a super-fast assembler - a super-fast way to get the assembled code over to a target system ... and my turnaround time was on the order of five seconds: Edit, hit a button making the target ready to receive the code, assemble: Running. It almost didn't matter that I was writing 6502 assembly; things just fell together and it was magic . Years later I was in a place where it was common to have half-day bu…

I always laugh thinking that Turbo Pascal was so quick I didn't understand the difference between build and "build then run". And that was statically typed code on Pentium class computer.

I think Pascal was specifically designed in a way that allowed a compiler to go straight from the source code to machine code in just one pass (although the output wouldn't be particularly well optimised).

Re: Software Development at 1 Hz

#70
post #46

Earlier quoted context omitted.

Sure, but my point is that being forced to be more methodical isn't a good thing. Not needing to be methodical is better (because your tools will catch your mistakes for you).

Doesn't that also remove the need for discipline? So the last vestiges of 'engineering' that so many programmers aspire to vanish, they can blame their tools, and the only development challenges are found in the tools themselves (perhaps already true to some extent). This sounds depressing.

See it another way: you can spend the mental effort instead on solving harder and more interesting problems. That is, if you can find harder problems to solve...
Post reply on HN