For those of you who enjoy a heaping meal of architectural commentary sprinkled with a generous portion of sarcasm, check out the author's blog [1]. Literally LOL every time I get a chance to read it.
No, it's not worth it. Modern IDEs make so many things easier than vi / vim / emacs ever did.
vi / vim / emacs can be useful in certain situations (Unix / Cygwin command lines, low level embedded systems that don't have a desktop, etc), but for most code, the modern IDE GUIs blow them away. Code navigation / inspection / contextual browsing is much, much better, easier, and far more productive using Eclipse, CLion, Visual Studio, etc.
The goto has gotten a bad rap over the years because of Dijkstra's paper. And that paper has unduly influenced a lot of incorrect thinking. There are valid use cases for goto, and this is certainly one of them.
I use it all the time like the example above. Particularly because it makes my life so much easier when developing and debugging embedded C code across various tool chains, some of which have less functionality than others.
Unfortunately, C does get a lot of hate on HN. I suspect it has to do with this site's demographics. Many (not all) of the HN clan seem to be oriented towards / mostly familiar with web based technologies. I suspect that for many who have tried, going from a web dev environment to a C oriented dev environment feels like a robust shock to the system.
I'd also be willing to bet that there's an age bias at play here; C has been around, like, forever. It is certainly not the new hotness. Most (not all) people that I know who enjoy it and are proficient at it, are 40 or older. Much of the web based dev crowd that hang around HN seem to be in their 20s, and as it is a time honored tradition to poo-poo the ideas / methods / tech of the older generation(s), it's not surprising that C doesn't get a lot of love.
Yes, I realize I'm painting with broad strokes here. It'd be interesting to see a survey or three that correlates age ranges and tech used on a day-to-day basis to see if these assumptions or legit. (Anyone got any survey data up their sleeve they'd be willing to share?)
Me personally - I love it all. C, C++, Java, Python, Javascript, Rust, Haskell, Scheme, etc. Making computers do things for you, and for other people, by writing detailed instructions is quite possibly one of the funnest things in the world. Double bonus for getting paid to do it!
So bummed to read this. Even though I wasn't going to directly benefit from Google Fiber, it was sure nice to have a non-entrenched player tackle this market.
From the big G's standpoint, it makes good biz sense to exit this market. I sure hope the subtext in the article comes to fruition ie that Google / Alphabet has figured out a better way to get high speed internet to homes in the US sans fiber.
In an ideal world, this fast fiber internet ought to be a municipally managed utility, with my tax dollars paying for the fiber in the ground. Then, my take home dollars paying for whatever competing service(s) I choose to light up said fiber to bring me access to the net.
Wow - that. looks. exhausting. And like an overall pretty ineffective use of engineer's time. At least for the kind of SW development that I generally do.
I can imagine certain limited scenarios where this kind of problem solving approach might be useful, but on a day-to-day basis? Nope. No way.
For me, if I'm ever working in assembly, which is pretty rare these days, it's usually on an overall "smaller" system. Ie an embedded system where all the SW, HW, and tools can be grokked by a single person with out multiple cascading levels of increasing complexity and abstraction.
Good times for sure, though to be real, the good part usually comes after many moments of banging-head-against-brick-wall.
As many others have mentioned, having a consistent bug reproduction methodology is vital, a strong mental model of the SW and its various components is important, and a willingness to dive deep and question assumptions is critical. Ie don't always expect your compilers or various OSes to be infallible.
Wrt Perl being readable / legible; I think most find Perl hard to read because there are 3-4 different ways to do the same thing. And many of the more "advanced" ways of doing things rely on short, terse single characters that act essentially like magic and behave differently in different situations. At least this is what I remember as I climbed the Perl ladder.
Contrast this with say, Python, where readability is highly valued and they have a one-way-to-do-certain things mentality, like sorts for example, means code is generally easier to grok, debug, and extend.
Thus, readability becomes especially important when you have to deal with someone else's big ball o' mud and you need to fix a high stress, high visibility, lines down issue at one in the morning because the original programmer is long gone, didn't leave any comments in their code, and decided to play "look at me, I'm so clever with how I use this operator", but forgot to account for a certain scenario that manufacturing decided to roll out the other day without telling anyone. Can I get an amen?
I'm assuming you are referring to the Arduino family when you say "8-bit AVR controllers"? If yes, they do in fact do a great job at making things somewhat easy for the dabbler, and have many resources available online to peruse for help.
Taking the next step to full-on embedded development (STM32 in this case), as you are finding out, is quite a big leap. Not that it can't be done, but that it really is challenging.
Guess it depends on your background and your familiarity with software development and/or hardware in general.
Depends on how deep down the embedded rabbit hole you want to go.
Personally, an article like this, with its main diagram and high level descriptions, would have been enormously useful back when I was just starting to learn the dark arts of computer programming.
If your Point of Sale systems are running some embedded form of Linux, and all HW access is abstracted away from you, then you're probably right.
On the other hand, if you are writing code that deals with external HW signals, performant memory access, ISRs, an RTOS and their many features, etc, then this article serves as a good basic foundation for the "software" side of things. Ie what actually happens when you hit the "build" button in your IDE.
I also want to thank you. For making me bust out some google-fu to figure out what "Poe's law" and a "fugue" are. And for the lulz of course. That goes with out saying.
This article is absolutely hilarious! I rarely laugh out loud when I'm reading stuff, but this line just got me.
"Because I’m overeducated and insecure, I package my banal observations in semantic finery, so I feel a kinship with lines like ‘‘Earthling inserts to chalice the green cutchie/Groundation soul finds trust upon smoking hose,’’ which is a fancy way of saying ‘‘a guy smokes some weed.’’ The thesis of ‘‘Dopesmoker’’ may boil down to ‘‘smoke dope,’’ but first-time listeners should be forgiven for wondering if it’s actually an anthropological study of Qedarite tribes in the pre-Christian Sinai Peninsula."
Totes hilare. Any song with lyrics that complex and earth shattering, deserves a listen. Plus - metal. Ya. Rocking out to the epic tune now!
For those of you who enjoy a heaping meal of architectural commentary sprinkled with a generous portion of sarcasm, check out the author's blog [1]. Literally LOL every time I get a chance to read it.
[1] http://www.mcmansionhell.com/