13 ms·

Software Development at 1 Hz

180 points by akkartik 10y ago

mpweiher 10y ago
I've been working on/with an environment that gives me feedback on every keystroke. The effect has been amazing, and it's always painful to go back to regular environments. Even traditional Smalltalks or REPLs where I have to do something to execute the current command are jarring. Regular compile/link/debug is painful. Xcode is excruciating.
- wreft 10y ago
  What are you using now?
  - mpweiher 10y ago
    My own Objective-Smalltalk. Here with a more traditionally interactive environment (so updates are applied when you save the method): https://www.youtube.com/watch?v=ArcClqt2vTc https://www.youtube.com/watch?v=ArcClqt2vTc Here in a really live environment I call CodeDraw, with updates computed on every keystroke (the "Run" button is just left-over UI, it doesn't do anything): https://www.youtube.com/watch?v=sypkOhE-ufs https://www.youtube.com/watch?v=sypkOhE-ufs Most interpreted or incrementally compiled systems should be able to do this.
  - deleted 10y ago
    [deleted]
- lokedhs 10y ago
  I agree. That's the experience I have doing web development in Lisp. Most other languages have at least a deployment step, even if it's a scripting language that doesn't require compilation. I'm getting this with a language that has a very high performance native compiler. And it's sad not more people use this.
- na85 10y ago
  Why wouldn't you include the name of said environment?
jimmytidey 10y ago
This is an enormous deal to me, although I'm only messing about with Node and Meteor. Productivity plumets if a change takes long enough to be visible for me to justify looking at Twitter.
eeks 10y ago
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 programming). Back in the 60s, when programs where being shipped by snail mail to some data center somewhere in the country to be entered by a random assistant and scheduled in a long pool of jobs, turnover was counted in days. Yet, we walked on the moon. So beyond better tooling, maybe a key to maintaining that attention span is check is to simply spend more time on the design board.
- DigitalJack 10y ago
  I wouldn't say FPGA synthesizers are slow. They take a long time, but that's not the same thing.
- digi_owl 10y ago
  Possibly. All this talk about getting antsy if things take time to build seems to fit a worry i have about our current web focused world. Observe Google and their management of Android. Again and again they have pushed out some half-baked X.0 version with the unstated intent that it will be sorted in a near future update. A clear example of that was the introduction of the Storage Access Framework. This is the web mentality seeping into the development of firmware and physical products, and it is leading to a massive culture clash and crap products. Basically you can't just code, push, run, repeat on devices in peoples pockets and bags like you can a web site.
  - alphapapa 10y ago
    Seriously, the reason I can't rely on my phone is mostly Google Play Services. I never know when it will update behind my back, and suddenly I'll feel a warm spot on my leg, and less than halfway into my day my phone's battery is at 5% because of Google Play Services running infinite loops. Or how at least every two days, the phone's wifi and LTE connections just stop working, for no apparent reason. But if I Force Stop on Google Play Services, they suddenly work again. This has been going on for several months now. Of course, these issues didn't used to happen with older versions of Play Services. And if I downgrade the Play Services app to the version installed with my ROM, I never have these problems--but then I can't use any current Google apps, like Gmail, Maps, etc. The AOSP software is mostly fine. But the Play Services side of Google simply cannot be trusted. Their CADT/web-style of development is almost enough to push me back to iOS. I want a phone that just runs Debian. :(
kabdib 10y ago
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 builds (30 minutes if you arranged things well). In fact, my last three weeks on that job I never got a working build at all, despite our group having an entire source control team whose job it was to make builds work. Current big project, it's about 30 seconds of tool churning, then another 30 of startup time. Could be better.
- kyled 10y ago
  Can you go into more details? Why did something take 30 minutes or longer to build? Was the environment being cleaned every time? Was an artifact server not being used?
  - kabdib 10y ago
    I've had long turnarounds (other than the artificial punchcard hell that is really just economics surfaced by IT budgets) in many projects. The ones that come to mind: - Burning EPROMs for the hardware bring-up of a consumer 68000 machine. Download and burn time for six EPROMs was well over 45 minutes. Things got better when we wrote a downloader, but initial bring-up was kind of painful for a couple of months. - An unbelievably crappy and development-hostile environment for set-top boxes. Getting 900K of code to a device could take 20-30 minutes, and the transfers often just abjectly failed. "Working as designed" said the people running the head-end. If you wonder why set-top-box software sucks so hard, this is one of the reasons. The whole TV industry is a fractal of shitty practices. Not that I'm bitter. [I did a work-around that let us do dynamic code loading over a different pipe that we theoretically weren't supposed to use "for network stability purposes" and got a biiig bonus after our team's productivity went way up] - Game development using a cross-assembler on a minicomputer,. The mini was also used as the department's email and office memo system. 45 minutes during the day turned into less than 5 minutes at night, so you can imagine the hours I kept. - Working on some Windows internals, the less said about this, the better. The common thread: When bad decisions and designs were institutionalized, things never got better. When it was possible for individuals to improve things, they did.
maaaats 10y ago
When I write code, I have this mental model of how the world (application) works. I write some lines of code based on it, and then test the code. More often than not, something happened that I hadn't thought about, and my mental model is updated. This summer I worked on an application where it took 8 minutes to see the effect of changed code. Between each iteration, I had forgot most of the assumptions I had made. So when things didn't work, I had a hard time figuring out why my model of the world didn't work. I basically started from scratch each iteration. Possibly very obvious, but it was interesting to learn how I attack a problem. And scary to see that I didn't just lose the 8 minutes between each run of the program, but much, much more.
- hobo_mark 10y ago
  If 8 minutes sounds like a lot... turnaround times when you work with FPGA code can be hours (and months if you're taping out an ASIC). After having to cope with that for a while, I've found that even with software I think a lot more before writing any code, and now I find myself stepping into the debugger much less often. (My point is: debugging first in your head is yet another skill that should really be taught to everybody but isn't).
  - StavrosK 10y ago
    > 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 right here, and I can run my test suite in ten seconds? Debugging first in your head is a good skill if actual debugging will take hours. If feedback is instant, you're probably faster writing the first thing that comes to you and iterating on it.
    - plaguuuuuu 10y ago
      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.
nojvek 10y ago
I am a huge believer of <10s Dev loop. I quit my previous team because compile times were greater than 2mins and I wasn't in a position to influence making it shorter. 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 refreshes immediately. Vscode has a chrome-debug plugin so my breakpoints hit immediately in the IDE. It's been an amazing experience so far. We've also revved up our CI systems to run 1000's of tests in parallel. You actually enjoy work when you don't spend forever waiting for things to compile.
- DougBTX 10y ago
  This is a problem I'm having at the moment, 20s webpack builds with ts-loader, plus other build steps running in VS 2015. Seems I need to drop ts-loader, and build more directly. Are your build files available to look at somewhere?
  - donw 10y ago
    That sounds... high. No guarantees that I can help with your current stack, but my email is in my profile if you'd like to run your setup by me.
  - methyl 10y ago
    Do you run webpack on Windows? It's much slower there than on *nix platforms
- christophilus 10y ago
  Interesting. I may have to give that setup another shot. I found TypeScript compilation to be really slow. Was recently amazed by Bucklescript's lightning-fast compile times and killer repl, but its integration with the JavaScript ecosystem was nowhere near as smooth.
- pags 10y ago
barrkel 10y ago
You can get this experience in most interpreted languages fairly easily (if an interactive debugger like pry or a JS console isn't good enough), and compiled languages with sufficiently good tooling for dynamic code replacement under a debugger. For dynamic languages, use the `watch` command combined with a host script that loads the code you're developing dynamically and executes it with some interesting parameters, and dumps the output. As you edit the source, you can see the effects immediately, character by character. You can get the same effect in something like Java in an IDE if you can structure the interesting code like a game loop (ideally it is a game loop): it's being continuously evaluated, so every change has an immediate effect. You can see Notch use this technique in this video here: https://youtu.be/rhN35bGvM8c?t=5757 https://youtu.be/rhN35bGvM8c?t=5757 As he edits code in the IDE, the application responds dynamically.
Waterluvian 10y ago
Writing django and JavaScript apps with a hot reloader has spoiled me. The dev loop for other cases now feels almost painful.
dkarapetyan 10y ago
For Ruby pry comes close but he's right about the inability to have the same kind of turnaround cycle when you're developing a C extension. I don't think anyone is gonna beat SBCL in that regard any time soon. There is no way to take Ruby and then generate machine code that ends up being callable from the current address space. Although I guess there is some way to do it with cffi and a compiler constantly running in the background.
keithnz 10y ago
It's really interesting how little time it is before things become disjointed. Recently working with some legacy code I noticed this. Usually I have a continuous unit testing process which normally is < 4 seconds to give feedback. I had to wrap some tests around some legacy code, which required some expensive setup which added an extra 10 seconds. I really feel pained working with that code and the extra 10 seconds. It is just enough time for the brain to drift off somewhere else. Ironic when in the past I have worked with C++ code bases that would take 20 minutes to compile, though incremental builds and parallel builds brought that number down. Also in embedded systems, I've got 3 minute cycles to try something out. However most of the coding is done on a PC with a fast unit testing cycle which dramatically improves feedback loops.
k__ 10y ago
My dev-loop currently takes ~10sec. But I worked with worse... Yes I prefer faster loops, but nerver had a job where I could influence the build pipeline...
- MaulingMonkey 10y ago
  I just try and fix the build pipeline when it annoys me. I was running into some 1-minute link times per project on Android, with several projects. Investigated and found out there was an alternative linker named "gold" - a few minutes to figure out how to reconfigure our builds and our link times were down to ~10 seconds / project or something. Nobody complained when I checked that in ;) Dealing with C++ build pipelines for large projects, there's only so low I can get build times for the whole project - better to try and make the data hot reloadable in a lot of cases. Similar goal: Fast iteration loops. Even if you can't fix them for the entire project, you may be able to fix them for whatever you're working on right now.
ctdonath 10y ago
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 thru a myriad of special cases. Relegated to "whiteboard coding" interview questions, I'm left looking a whole lot worse than I am - not because I don't know it, but because I know enough that thoroughness is painfully slow (without leveraging tools multiplying my skills & speed).
- darthdeus 10y ago
  > 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. Do you really need to compile/run something like fizzbuzz? What if you're writing code that can't be run, such as when modifying a larger piece of code that won't run until all modifications are made? Isn't there some value in being able to verify correctness of code just by looking at it for a few seconds? Surely you can overlook some things, but with practice probably a lot less than people think.
- userbinator 10y ago
  I would argue that if you can't write a correct FizzBuzz without needing to compile and run it, or even worse, an IDE to hold your hand, you don't actually understand what's happening and are just leaning on a crutch. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases. The peril of that sort of workflow is that you often won't realise the importance of those special cases until it's too late to change things easily. "It looks like it works, it compiles and runs" --- I've heard this sentiment from such IDE users many times, and yet when I inspect their code, they inevitably missed something important. Someone once gave me a phrase I like to keep in mind when programming: "How can you tell the machine what to do if you're not even sure how to do it yourself?"
ams6110 10y ago
This isn't relevant only for development. Applications that take 10+ seconds to process an action are annoying and tiring as well. At work a lot of stuff is like this. Enterprisey applications that take 10, 15, 20 seconds to process each entry. Time enough to get distracted. Time enough to tab over to email or some other application and lose focus. Just overall mentally fatiguing. Developers who are annoyed by 10 second delays in their development process should remember that their users will be just as annoyed by slow response time in applications. Cut the weight. Make it faster. I'm more and more convinced that nothing else will go as far in making users happy.
kuon 10y ago
I know work with phoenix + live-reload and the nearly instant dev cycle is the best thing that happened to me since I started web dev. I know rails has something similar but I haven't worked with rails for nearly 2 years now so I can't tell. As a side note, having a short dev loop is really good for education.
corecoder 10y ago
From this perspective, the worst things I meet are setting up or tuning complex CI pipelines and developing infrastructure automation: a cycle can easily last more than half an hour and there doesn't seem to be an easy way to speed up things, really.
- Retr0spectrum 10y ago
  With a modular TDD approach, you could in theory test individual components very rapidly. I haven't looked into it too much, but I assume such systems exist.
  - jerf 10y ago
    I have also often complained about this pain of CI systems. One of the problems is that the things you need to have a proper CI system conflict with fast build times. Proper CI requires a clean checkout, and a total compile fromscratch. If you're doing something in Docker, you ought to start your Docker process from scratch. If you're in a VM, you really ought to revert to a snapshot to make sure you're not accidentally accumulating un-CI'ed state. And so on. While in normal development you may have a very fast turnaround, a properly configured CI system needs to assume the worst, start from scratch, and build everything, in every combination you support. (You may also want a less accurate CI build that trades speed for accuracy and just does an incremental build of some particular aspect of the system. But that should be supported by the full CI I describe here.) Consequently, something that fails only 97% into that build process, and only fails on the CI server, can be very annoying to fix. But you don't really have a choice, because any hacky alternative is too risky. A CI system that has human intervention isn't a CI system.
  - justifier 10y ago
    similarly, when in development i'll hack around slow CI times by storing the output of the most cycle heavy steps in the CI and on subsequent runs determine if i can just use the old stored values stead running through everything that said, i agree that there should be effort, or at least roadmap, to get CI compile times down to near native to play devels[sic] advocate we've had lengthy compile times on systems and native apps since time immemorial, it just seems that browser work has caught up in complexity and ubiquity.. even if some of that complexity can be blamed on negligent or lazy development
sebastianconcpt 10y ago
Today I was thinking in the idea that LISP and Smalltalk are probably at the top on instant feedback for development. And Smalltalk dev tools might rank even higher because you can dig any instance to any dept and evaluate code "talking to it" and getting instant answers right there.
castratikron 10y ago
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 same time. When one run finished, I would verify its behavior, look at the binary's hash, and then know that my code change was safe. It was a very slow process, but effective. After doing this kind of development for a while I'm weary of claims like this that imply that feedback with a latency <10s is actually a good thing. High latency feedback forces you to be more methodical in your development and think about the changes you're making.
- darthdeus 10y ago
  > 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 and able to solve much complicated problems when they arise.
  - userbinator 10y ago
    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 feedback only encourages this behaviour more. The same phenomenon also happens if you give them a debugger --- they spend plenty of time just stepping through the code without any good sense of the bigger picture. Maybe it feels productive, but it's not. Their attention is too preoccupied with the feedback that they do not think deeply enough about their solution, and as a result, overall code quality often also suffers. Instead, I believe in thinking carefully about the problem. Close your eyes and visualise the program and its data and control flow in your mind, then write the code. Use a whiteboard or even pencil and paper to collect your thoughts and get a good mental model of what you're trying to accomplish. Block out all other distractions and focus on the problem. Many others I've talked to are in disbelief when I tell them I can spend an hour writing several hundred lines of code that compiles and works flawlessly the first time, but this is what careful thought will allow. Even with a very fast feedback loop you may spend several times longer fiddling with the code until you get something that seems to work, but actually doesn't in all cases precisely because you did not ever think about those cases while you were fiddling with it and had your attention focused on getting that next dose of feedback.
djur 10y ago
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.
- cracauer 10y ago
  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.
watermoose 10y ago
> At the same time I cannot use toy languages that have no compile time type checking This guy seems like and sounds like a serious developer, so I'm totally confused by this statement. Dynamic languages that don't do compile time type checking are not toys. I used to only write in Java or C++, but I think it's a stage of maturity as a developer to realize that you can develop code that can take arguments with the assumption that the objects sent in are of types that will have the behavior you need to work with them. If you argue that the code is faster when it is compiled- that's fine, and I agree, and that's good, if it matters. If you argue that you need types because otherwise you can't be safe, I'm sorry, but that's like being a helicopter-parent. Sometimes maybe you can't trust what is calling your code even when you give it trust, and that's valid; just like as a parent, sometimes the child really needs that level of micromanagement. But, for a lot of if not most of practical web development, you can use dynamic typing, and most children do not need that level of micromanagement. There's nothing wrong with languages that provide type checking, but it isn't necessarily a deficiency when it's not there.
- MaulingMonkey 10y ago
  > But, for a lot of if not most of practical web development, you can use dynamic typing, and most children do not need that level of micromanagement. I use TypeScript because that level of "micromanagement" saves me more time in avoiding bugs than I spend adding static annotation. Hell, the improved intellisense alone means I no longer need to read docs in a lot of cases, meaning writing code is faster for me too - even ignoring bug rates. (Of course, it's sometimes prudent to check the docs for things like edge cases regardless.) In C++-land, I've started using e.g. clang's threading annotations to good effect in catching some of the most heinous bugs to debug - incorrect multithreaded code that forgets to do simple things like lock mutexes meant to protect data structures. I've dabbled in a toy project in Rust-land. The ability to catch and prevent data races is fascinating, and the ability to stem the tide of null dereferences at runtime seems pretty handy. Have you never had a hell-to-reproduce null deref that only occurs in your release builds? It's pretty bad when it ships to a large number of customers. I see SQL injection vulnerabilities, and wish APIs properly segregated SQL Data from SQL Commands - two entirely different types of things entirely. And yet for awhile I was a lot more forgiving of dynamically typed languages. Until I was able to compare JavaScript vs TypeScript - which I'd argue started as basically JavaScript with static typing tacked on as, effectively, an afterthought. > If you argue that you need types because otherwise you can't be safe, I'm sorry, but that's like being a helicopter-parent. If helicopter parents were as beneficial as static typing, I'd have a lot less against them.
PakG1 10y ago
Relevant XKCD: http://xkcd.com/303/ http://xkcd.com/303/
i336_ 10y ago
I'm reminded of this very amusing C++ compilation speedup trick: cat * > everything.cpp - http://stackoverflow.com/a/318495/3229684 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".
_pmf_ 10y ago
The aversion towards upfront thinking and tendency to glorify the TDD slot machine is a bit unsettling.
- GrumpyYoungMan 10y ago
  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.
- GoToRO 10y ago
  There's enough "upfront thinking" to be done on the problem you actually try to solve...

180 points by akkartik 10y ago

I've been working on/with an environment that gives me feedback on every keystroke. The effect has been amazing, and it's always painful to go back to regular environments. Even traditional Smalltalks or REPLs where I have to do something to execute the current command are jarring. Regular compile/link/debug is painful. Xcode is excruciating.

wreft 10y ago
What are you using now?
- mpweiher 10y ago
  My own Objective-Smalltalk. Here with a more traditionally interactive environment (so updates are applied when you save the method): https://www.youtube.com/watch?v=ArcClqt2vTc https://www.youtube.com/watch?v=ArcClqt2vTc Here in a really live environment I call CodeDraw, with updates computed on every keystroke (the "Run" button is just left-over UI, it doesn't do anything): https://www.youtube.com/watch?v=sypkOhE-ufs https://www.youtube.com/watch?v=sypkOhE-ufs Most interpreted or incrementally compiled systems should be able to do this.
- deleted 10y ago
  [deleted]
lokedhs 10y ago
I agree. That's the experience I have doing web development in Lisp. Most other languages have at least a deployment step, even if it's a scripting language that doesn't require compilation. I'm getting this with a language that has a very high performance native compiler. And it's sad not more people use this.
na85 10y ago
Why wouldn't you include the name of said environment?

jimmytidey 10y ago

This is an enormous deal to me, although I'm only messing about with Node and Meteor. Productivity plumets if a change takes long enough to be visible for me to justify looking at Twitter.

eeks 10y ago

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 programming). Back in the 60s, when programs where being shipped by snail mail to some data center somewhere in the country to be entered by a random assistant and scheduled in a long pool of jobs, turnover was counted in days. Yet, we walked on the moon. So beyond better tooling, maybe a key to maintaining that attention span is check is to simply spend more time on the design board.

DigitalJack 10y ago
I wouldn't say FPGA synthesizers are slow. They take a long time, but that's not the same thing.
digi_owl 10y ago
Possibly. All this talk about getting antsy if things take time to build seems to fit a worry i have about our current web focused world. Observe Google and their management of Android. Again and again they have pushed out some half-baked X.0 version with the unstated intent that it will be sorted in a near future update. A clear example of that was the introduction of the Storage Access Framework. This is the web mentality seeping into the development of firmware and physical products, and it is leading to a massive culture clash and crap products. Basically you can't just code, push, run, repeat on devices in peoples pockets and bags like you can a web site.
- alphapapa 10y ago
  Seriously, the reason I can't rely on my phone is mostly Google Play Services. I never know when it will update behind my back, and suddenly I'll feel a warm spot on my leg, and less than halfway into my day my phone's battery is at 5% because of Google Play Services running infinite loops. Or how at least every two days, the phone's wifi and LTE connections just stop working, for no apparent reason. But if I Force Stop on Google Play Services, they suddenly work again. This has been going on for several months now. Of course, these issues didn't used to happen with older versions of Play Services. And if I downgrade the Play Services app to the version installed with my ROM, I never have these problems--but then I can't use any current Google apps, like Gmail, Maps, etc. The AOSP software is mostly fine. But the Play Services side of Google simply cannot be trusted. Their CADT/web-style of development is almost enough to push me back to iOS. I want a phone that just runs Debian. :(

kabdib 10y ago

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 builds (30 minutes if you arranged things well). In fact, my last three weeks on that job I never got a working build at all, despite our group having an entire source control team whose job it was to make builds work. Current big project, it's about 30 seconds of tool churning, then another 30 of startup time. Could be better.

kyled 10y ago
Can you go into more details? Why did something take 30 minutes or longer to build? Was the environment being cleaned every time? Was an artifact server not being used?
- kabdib 10y ago
  I've had long turnarounds (other than the artificial punchcard hell that is really just economics surfaced by IT budgets) in many projects. The ones that come to mind: - Burning EPROMs for the hardware bring-up of a consumer 68000 machine. Download and burn time for six EPROMs was well over 45 minutes. Things got better when we wrote a downloader, but initial bring-up was kind of painful for a couple of months. - An unbelievably crappy and development-hostile environment for set-top boxes. Getting 900K of code to a device could take 20-30 minutes, and the transfers often just abjectly failed. "Working as designed" said the people running the head-end. If you wonder why set-top-box software sucks so hard, this is one of the reasons. The whole TV industry is a fractal of shitty practices. Not that I'm bitter. [I did a work-around that let us do dynamic code loading over a different pipe that we theoretically weren't supposed to use "for network stability purposes" and got a biiig bonus after our team's productivity went way up] - Game development using a cross-assembler on a minicomputer,. The mini was also used as the department's email and office memo system. 45 minutes during the day turned into less than 5 minutes at night, so you can imagine the hours I kept. - Working on some Windows internals, the less said about this, the better. The common thread: When bad decisions and designs were institutionalized, things never got better. When it was possible for individuals to improve things, they did.

maaaats 10y ago

When I write code, I have this mental model of how the world (application) works. I write some lines of code based on it, and then test the code. More often than not, something happened that I hadn't thought about, and my mental model is updated. This summer I worked on an application where it took 8 minutes to see the effect of changed code. Between each iteration, I had forgot most of the assumptions I had made. So when things didn't work, I had a hard time figuring out why my model of the world didn't work. I basically started from scratch each iteration. Possibly very obvious, but it was interesting to learn how I attack a problem. And scary to see that I didn't just lose the 8 minutes between each run of the program, but much, much more.

hobo_mark 10y ago
If 8 minutes sounds like a lot... turnaround times when you work with FPGA code can be hours (and months if you're taping out an ASIC). After having to cope with that for a while, I've found that even with software I think a lot more before writing any code, and now I find myself stepping into the debugger much less often. (My point is: debugging first in your head is yet another skill that should really be taught to everybody but isn't).
- StavrosK 10y ago
  > 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 right here, and I can run my test suite in ten seconds? Debugging first in your head is a good skill if actual debugging will take hours. If feedback is instant, you're probably faster writing the first thing that comes to you and iterating on it.
  - plaguuuuuu 10y ago
    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.

nojvek 10y ago

I am a huge believer of <10s Dev loop. I quit my previous team because compile times were greater than 2mins and I wasn't in a position to influence making it shorter. 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 refreshes immediately. Vscode has a chrome-debug plugin so my breakpoints hit immediately in the IDE. It's been an amazing experience so far. We've also revved up our CI systems to run 1000's of tests in parallel. You actually enjoy work when you don't spend forever waiting for things to compile.

DougBTX 10y ago
This is a problem I'm having at the moment, 20s webpack builds with ts-loader, plus other build steps running in VS 2015. Seems I need to drop ts-loader, and build more directly. Are your build files available to look at somewhere?
- donw 10y ago
  That sounds... high. No guarantees that I can help with your current stack, but my email is in my profile if you'd like to run your setup by me.
- methyl 10y ago
  Do you run webpack on Windows? It's much slower there than on *nix platforms
christophilus 10y ago
Interesting. I may have to give that setup another shot. I found TypeScript compilation to be really slow. Was recently amazed by Bucklescript's lightning-fast compile times and killer repl, but its integration with the JavaScript ecosystem was nowhere near as smooth.
pags 10y ago

barrkel 10y ago

You can get this experience in most interpreted languages fairly easily (if an interactive debugger like pry or a JS console isn't good enough), and compiled languages with sufficiently good tooling for dynamic code replacement under a debugger. For dynamic languages, use the `watch` command combined with a host script that loads the code you're developing dynamically and executes it with some interesting parameters, and dumps the output. As you edit the source, you can see the effects immediately, character by character. You can get the same effect in something like Java in an IDE if you can structure the interesting code like a game loop (ideally it is a game loop): it's being continuously evaluated, so every change has an immediate effect. You can see Notch use this technique in this video here: https://youtu.be/rhN35bGvM8c?t=5757 https://youtu.be/rhN35bGvM8c?t=5757 As he edits code in the IDE, the application responds dynamically.

Waterluvian 10y ago

Writing django and JavaScript apps with a hot reloader has spoiled me. The dev loop for other cases now feels almost painful.

dkarapetyan 10y ago

For Ruby pry comes close but he's right about the inability to have the same kind of turnaround cycle when you're developing a C extension. I don't think anyone is gonna beat SBCL in that regard any time soon. There is no way to take Ruby and then generate machine code that ends up being callable from the current address space. Although I guess there is some way to do it with cffi and a compiler constantly running in the background.

keithnz 10y ago

It's really interesting how little time it is before things become disjointed. Recently working with some legacy code I noticed this. Usually I have a continuous unit testing process which normally is < 4 seconds to give feedback. I had to wrap some tests around some legacy code, which required some expensive setup which added an extra 10 seconds. I really feel pained working with that code and the extra 10 seconds. It is just enough time for the brain to drift off somewhere else. Ironic when in the past I have worked with C++ code bases that would take 20 minutes to compile, though incremental builds and parallel builds brought that number down. Also in embedded systems, I've got 3 minute cycles to try something out. However most of the coding is done on a PC with a fast unit testing cycle which dramatically improves feedback loops.

k__ 10y ago

My dev-loop currently takes ~10sec. But I worked with worse... Yes I prefer faster loops, but nerver had a job where I could influence the build pipeline...

MaulingMonkey 10y ago
I just try and fix the build pipeline when it annoys me. I was running into some 1-minute link times per project on Android, with several projects. Investigated and found out there was an alternative linker named "gold" - a few minutes to figure out how to reconfigure our builds and our link times were down to ~10 seconds / project or something. Nobody complained when I checked that in ;) Dealing with C++ build pipelines for large projects, there's only so low I can get build times for the whole project - better to try and make the data hot reloadable in a lot of cases. Similar goal: Fast iteration loops. Even if you can't fix them for the entire project, you may be able to fix them for whatever you're working on right now.

ctdonath 10y ago

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 thru a myriad of special cases. Relegated to "whiteboard coding" interview questions, I'm left looking a whole lot worse than I am - not because I don't know it, but because I know enough that thoroughness is painfully slow (without leveraging tools multiplying my skills & speed).

darthdeus 10y ago
> 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. Do you really need to compile/run something like fizzbuzz? What if you're writing code that can't be run, such as when modifying a larger piece of code that won't run until all modifications are made? Isn't there some value in being able to verify correctness of code just by looking at it for a few seconds? Surely you can overlook some things, but with practice probably a lot less than people think.
userbinator 10y ago
I would argue that if you can't write a correct FizzBuzz without needing to compile and run it, or even worse, an IDE to hold your hand, you don't actually understand what's happening and are just leaning on a crutch. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases. The peril of that sort of workflow is that you often won't realise the importance of those special cases until it's too late to change things easily. "It looks like it works, it compiles and runs" --- I've heard this sentiment from such IDE users many times, and yet when I inspect their code, they inevitably missed something important. Someone once gave me a phrase I like to keep in mind when programming: "How can you tell the machine what to do if you're not even sure how to do it yourself?"

ams6110 10y ago

This isn't relevant only for development. Applications that take 10+ seconds to process an action are annoying and tiring as well. At work a lot of stuff is like this. Enterprisey applications that take 10, 15, 20 seconds to process each entry. Time enough to get distracted. Time enough to tab over to email or some other application and lose focus. Just overall mentally fatiguing. Developers who are annoyed by 10 second delays in their development process should remember that their users will be just as annoyed by slow response time in applications. Cut the weight. Make it faster. I'm more and more convinced that nothing else will go as far in making users happy.

kuon 10y ago

I know work with phoenix + live-reload and the nearly instant dev cycle is the best thing that happened to me since I started web dev. I know rails has something similar but I haven't worked with rails for nearly 2 years now so I can't tell. As a side note, having a short dev loop is really good for education.

corecoder 10y ago

From this perspective, the worst things I meet are setting up or tuning complex CI pipelines and developing infrastructure automation: a cycle can easily last more than half an hour and there doesn't seem to be an easy way to speed up things, really.

Retr0spectrum 10y ago
With a modular TDD approach, you could in theory test individual components very rapidly. I haven't looked into it too much, but I assume such systems exist.
- jerf 10y ago
  I have also often complained about this pain of CI systems. One of the problems is that the things you need to have a proper CI system conflict with fast build times. Proper CI requires a clean checkout, and a total compile fromscratch. If you're doing something in Docker, you ought to start your Docker process from scratch. If you're in a VM, you really ought to revert to a snapshot to make sure you're not accidentally accumulating un-CI'ed state. And so on. While in normal development you may have a very fast turnaround, a properly configured CI system needs to assume the worst, start from scratch, and build everything, in every combination you support. (You may also want a less accurate CI build that trades speed for accuracy and just does an incremental build of some particular aspect of the system. But that should be supported by the full CI I describe here.) Consequently, something that fails only 97% into that build process, and only fails on the CI server, can be very annoying to fix. But you don't really have a choice, because any hacky alternative is too risky. A CI system that has human intervention isn't a CI system.
- justifier 10y ago
  similarly, when in development i'll hack around slow CI times by storing the output of the most cycle heavy steps in the CI and on subsequent runs determine if i can just use the old stored values stead running through everything that said, i agree that there should be effort, or at least roadmap, to get CI compile times down to near native to play devels[sic] advocate we've had lengthy compile times on systems and native apps since time immemorial, it just seems that browser work has caught up in complexity and ubiquity.. even if some of that complexity can be blamed on negligent or lazy development

sebastianconcpt 10y ago

Today I was thinking in the idea that LISP and Smalltalk are probably at the top on instant feedback for development. And Smalltalk dev tools might rank even higher because you can dig any instance to any dept and evaluate code "talking to it" and getting instant answers right there.

castratikron 10y ago

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 same time. When one run finished, I would verify its behavior, look at the binary's hash, and then know that my code change was safe. It was a very slow process, but effective. After doing this kind of development for a while I'm weary of claims like this that imply that feedback with a latency <10s is actually a good thing. High latency feedback forces you to be more methodical in your development and think about the changes you're making.

darthdeus 10y ago
> 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 and able to solve much complicated problems when they arise.
- userbinator 10y ago
  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 feedback only encourages this behaviour more. The same phenomenon also happens if you give them a debugger --- they spend plenty of time just stepping through the code without any good sense of the bigger picture. Maybe it feels productive, but it's not. Their attention is too preoccupied with the feedback that they do not think deeply enough about their solution, and as a result, overall code quality often also suffers. Instead, I believe in thinking carefully about the problem. Close your eyes and visualise the program and its data and control flow in your mind, then write the code. Use a whiteboard or even pencil and paper to collect your thoughts and get a good mental model of what you're trying to accomplish. Block out all other distractions and focus on the problem. Many others I've talked to are in disbelief when I tell them I can spend an hour writing several hundred lines of code that compiles and works flawlessly the first time, but this is what careful thought will allow. Even with a very fast feedback loop you may spend several times longer fiddling with the code until you get something that seems to work, but actually doesn't in all cases precisely because you did not ever think about those cases while you were fiddling with it and had your attention focused on getting that next dose of feedback.

djur 10y ago

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.

cracauer 10y ago
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.

watermoose 10y ago

> At the same time I cannot use toy languages that have no compile time type checking This guy seems like and sounds like a serious developer, so I'm totally confused by this statement. Dynamic languages that don't do compile time type checking are not toys. I used to only write in Java or C++, but I think it's a stage of maturity as a developer to realize that you can develop code that can take arguments with the assumption that the objects sent in are of types that will have the behavior you need to work with them. If you argue that the code is faster when it is compiled- that's fine, and I agree, and that's good, if it matters. If you argue that you need types because otherwise you can't be safe, I'm sorry, but that's like being a helicopter-parent. Sometimes maybe you can't trust what is calling your code even when you give it trust, and that's valid; just like as a parent, sometimes the child really needs that level of micromanagement. But, for a lot of if not most of practical web development, you can use dynamic typing, and most children do not need that level of micromanagement. There's nothing wrong with languages that provide type checking, but it isn't necessarily a deficiency when it's not there.

MaulingMonkey 10y ago
> But, for a lot of if not most of practical web development, you can use dynamic typing, and most children do not need that level of micromanagement. I use TypeScript because that level of "micromanagement" saves me more time in avoiding bugs than I spend adding static annotation. Hell, the improved intellisense alone means I no longer need to read docs in a lot of cases, meaning writing code is faster for me too - even ignoring bug rates. (Of course, it's sometimes prudent to check the docs for things like edge cases regardless.) In C++-land, I've started using e.g. clang's threading annotations to good effect in catching some of the most heinous bugs to debug - incorrect multithreaded code that forgets to do simple things like lock mutexes meant to protect data structures. I've dabbled in a toy project in Rust-land. The ability to catch and prevent data races is fascinating, and the ability to stem the tide of null dereferences at runtime seems pretty handy. Have you never had a hell-to-reproduce null deref that only occurs in your release builds? It's pretty bad when it ships to a large number of customers. I see SQL injection vulnerabilities, and wish APIs properly segregated SQL Data from SQL Commands - two entirely different types of things entirely. And yet for awhile I was a lot more forgiving of dynamically typed languages. Until I was able to compare JavaScript vs TypeScript - which I'd argue started as basically JavaScript with static typing tacked on as, effectively, an afterthought. > If you argue that you need types because otherwise you can't be safe, I'm sorry, but that's like being a helicopter-parent. If helicopter parents were as beneficial as static typing, I'd have a lot less against them.

PakG1 10y ago

Relevant XKCD: http://xkcd.com/303/ http://xkcd.com/303/

i336_ 10y ago

I'm reminded of this very amusing C++ compilation speedup trick: cat * > everything.cpp - http://stackoverflow.com/a/318495/3229684 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".

_pmf_ 10y ago

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

GrumpyYoungMan 10y ago
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.
GoToRO 10y ago
There's enough "upfront thinking" to be done on the problem you actually try to solve...