Live data from Hacker News

Software Development at 1 Hz

medium.com

81–90 of 121 posts

Re: Software Development at 1 Hz

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

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

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

Re: Software Development at 1 Hz

#82

Earlier quoted context omitted.

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?

Those were not my words. I said to discourage all students from using IDEs and debuggers doesn't make sense. I went quite a while with no tools other than a hex editor to type in op codes. I don't think it did anything except hurt productivity. Maybe you learn or work better that way. I don't. And I don't see how you justify assuming all new programmers would.

Discouraging someone to use an IDE is more a symptom of the target language's shortcomings. Xcode provided me with beautiful compile-time errors for both Objective-C and Swift, and forced me to really think about what I was doing. Incidentally, I learned both languages from the IDE.

Would I recommend an IDE for a low level language like C? Probably not, because it forces a kind of laziness on the programmer.

Maybe an IDE isn't the solution, but a starting point to build upon. Something that's an interactive environment like LightTable has, where you can quickly eval blocks of code and see the end result without having re-compile your entire program. Certain languages are better suited to this, and certain paradigms (reactive programming comes to mind).

Re: Software Development at 1 Hz

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

Moving from Grunt to Broccoli helped a lot. 30 sec went down to a few hundreds of milisec. Broccoli is just insane.

Re: Software Development at 1 Hz

#84
post #78
post #76

Earlier quoted context omitted.

I contend that if you have solved 500 ish of those problems, you are a bit beyond the majority of programmers. Also... I don't see how any single Euler problem could have minute plus compiles. No matter the language. :(

I haven't solved 555 problems, just problem #555 [1]. Sorry if I was unclear. I also wasn't saying that any language would get long compile times on Euler questions -- they're far too short for that -- but that theoretically if they did it would cause problems. [1]: https://projecteuler.net/problem=555

That misunderstanding is on me. What you put was perfectly clear, so my apologies.

It is worth noting that many of those problems originate from people that did them by hand. :)

Re: Software Development at 1 Hz

#85

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?

No, that was your interpretation.

Re: Software Development at 1 Hz

#87
post #5
post #2

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.

What are you using now?

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

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

Most interpreted or incrementally compiled systems should be able to do this.

Re: Software Development at 1 Hz

#88
post #5
post #2

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.

What are you using now?

[deleted]

Re: Software Development at 1 Hz

#89

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'm glad I found someone who shares my point of view. You're right about IDEs and debuggers.

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

It's funny how many problems I've solved by writing code on paper/whiteboard when I got stuck doing actual programming. It's so much easier to focus on the problem when there's no code to run.

Another thing I found useful is just reading the code outside of an editor. Either by printing it out and scribbling over it with a pencil, or just reading it on a phone/tablet that can't run the code.

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

I've been having the same experience. Recently at a uni we were given an assignment to write an interpreter for a rather simple imperative language (conditionals, loops, simple recursive functions and stack depth checking). We were given 3 hours to write a program that could interpret a sample program.

Most people struggled to get anything working at all during that time, since each and every one of them I talked to didn't have a clear picture of they were trying to build.

It took me a little over an hour to write the whole thing in almost a single pass, in a modular fashion with separate tokenizer, parser and evaluator with the necessary checks. There was no need to run the code, most of it was rather trivial, implementing simple state machines. It was quite a bit of code (over 1000 lines), but there was almost no thinking required if you knew how the parse tree should look.

In situations like this I'd even say it's hard to make the program not work if you're methodical, working step by step and checking if you've covered all the cases.

Re: Software Development at 1 Hz

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

> In my new team I got it from 30s to 5s and the effects have been amazing.

I was proud of being part of the team that got the compile time for the core of our product from about 2 hours down to about 30 minutes (the same amount of code, loaded into a RAMdisk and built on a 16-core machine builds in about 2-3 minutes today, but most of our full builds take from 20 minutes to 2 hours now).

After you build the core, a fairly simple plug-in on a reasonable development machine will compile+link in about 5 seconds, maybe. How long it takes to test the fix depends on how far into the program's operation a failure is expected to occur...anywhere from a couple seconds in, if it can't contact the server, to an unbounded length of time, if there's a rare bug triggered by some weird pattern in the customer's data or use of the system.

I enjoy hearing about what other people expect from their dev environments. I've worked almost exclusively in large C++ systems.

Post reply on HN