If you find that exception-free code that is necessarily littered with exit value checks at every call, which discourages refactoring and adds massive noise, then you can call the decisions to eschew exceptions as “sane” and “clean”, but I find the resulting code to be neither. Or practically speaking, exit codes will often not be checked at all, or an error check will be omitted by mistake, thereby interrupting the entire intended error handling chain. Somehow that qualifies as a better outcome or more sane? Perhaps it is for a code base that is not changing (write-once) or is not expected to change (i.e. throwaway code written in “true microservice” style).
Pouring foundation, installing plumbing and wiring the building is specialized by the physical necessity of these activities, which cannot be repeated without mistake at a great cost. That justifies specialization. Unlike building a bridge, compiling software is essentially free. QA, release engineering and database design can and should be repeated and iterated on by software engineers, because it is a necessary part of the development and removing it from the expected work distorts incentives.
I agree, very cool. I still miss the fast productive workflow of Jeskola Buzz from back in the day. Modular software synth + tracker with pattern sequencing. https://youtu.be/8J8i72a11W4?si=IRic-Z_YMinudnhn
I tried it out and the instructions have tips on what record to pick, they say to pick a well known version of a song (like not a live version etc), and preferably song with a beat, but it says it doesn’t use any 3rd party APIs or libraries, only Apple APIs. So my guess at to what it’s doing is using a ShazamKit recognition behind the scenes and looking at the frequencySkew value of the matched result. It also gives you one answer after listening, instead of a continuous gauge, which seems to corroborate song recognition. It probably won’t work with an obscure record that is not Shazamable. And so I don’t think it can measure wow & flutter as a result.
Still pretty cool for those that need to calibrate a turntable, or verify 33 vs 45 PRM for a record.
Jef Raskin’s “Humane Interface” book was such an eye opener for me—-no modes (that explained why I was always frustrated with vi or emacs), and that computers should never lose your data.
From this post I learned there was a project called Archy implementing Cat in software.
> Computer rage is a familiar phenomenon because computers are so adept at losing your data. At any given moment, you are one innocent step away from destroying minutes, hours, days, months, or years of work.
> Archy never loses your work. This shouldn't be a groundbreaking innovation in computer design, but it is. You never have to save because it's done for you automatically. Your data is stored in such a way that if your computer crashes, your information will still be there the next time you start Archy up.
I think these days we are 70-80% to this groundbreaking innovation—-my computers no longer lose my in-progress e-mail or documents, but sure still keep losing form input here and there, and I still accidentally select all text and type over it in a system with a single-level undo (iOS).
Sad that C is still being utilized with a serious face. If you can't be bothered to develop in C++ and only pay for what you use, RAII is like your last problem.
You can be really productive, expressive and performant in Groovy. So much of the language still works well with @CompileStatic and doesn’t require dynamic typing. Writing clear code that has decent refactoring support in IntelliJ.
Don’t forget traits! When are we getting traits in Java? Probably never.
Optional semicolons and parentheses to cut the line noise and enable internal DSLs.
Though Java has improved implicit typing with `var` and now we have reasonable lambdas, Java is still not a high-level language, but maybe it is now medium-high.
Manual memory management vs garbage collection trades speed of allocation for speed of freeing memory. Freeing memory is expensive in a garbage collected language, but allocation is basically free.
Modern garbage collectors are very good and handle many common use cases rather efficiently, with minimal or zero pauses, such as freeing short-lived objects. Many GC operations are done in parallel threads without stopping the application (you just pay the CPU overhead cost).
Also JITs in both the CLR and the JVM perform optimizations such as escape analysis, which stack-allocate objects that never escape a function’s scope. These objects thus do not have to be GC’d.
So really with a GC’d language, you mostly have to worry about pauses and GC CPU overhead. Most GCs can be tuned for a predictable workload. (A bigger challenge for a GC is a variable workload.)
I don’t think so, because it is the runtime JIT (Just-In-Time) optimizer that is the critical speed advantage that allows the CLR and JVM to beat C and C++.
The inlining of virtual calls is the critical optimization that enables this. Because C/C++ is optimized statically and never at runtime, it is unable to optimize results of function pointer lookups (in C, and thus also virtual calls in C++). However, the JITs can inline through function pointer lookups.
In sufficiently complex programs, where polymorphism is used (i.e. old code that calls new code without knowing about it), this yields an unsurpassed speed advantage. Polymorphism is critical to managing complexity as an application evolves (even the Linux kernel, written in C, uses polymorphism, e.g. see struct file_operations).
+1 … it has a great discussion of structural vs object-oriented vs functional, presenting the trade-offs, it describes different service and module decomposition patterns, with pros and cons for each, without prescribing one.
It’s because all consumer disks are garbage. The way it works is that disks are tested. Disks without failures are sold as “Enterprise.” Those that have failures are labeled and sold as “consumer”, not thrown in the bin.
Declaring throws end up leaking layers of abstractions in practice. Many thrown checked exceptions are not appropriate to pass above certain layers. It is often not OK to expose checked exceptions that are really implementation details up the chain—-it’s not a “similar requirement”—-it is exactly the same requirement and often an inappropriate one at many levels up the chain.
If you just pass exceptions up in throws, you end up causing cascading checked exceptions chain changes and creating a bunch of noise, which is what many times people resort to doing in practice, because they don’t have the experience and it is very rare/almost never done to have any kind of automatic enforcement/linters/static analysis that prohibits implementation detail checked exceptions from propagating past above certain levels.
It is almost never OK to propagate IOException, for example, past maybe 1 or 2 levels of private helper methods, almost never should be propagated past your class boundary and you have to think twice about adding throws to protected methods even, unless your subclass implementations are specifically implementing alternate IO calls.
So yes that’s why checked exceptions have failed. And when you actually take this extreme discipline to your code, yes you end up with a ton of try/catch handling noise and a whole lotta new exceptions classes, and it takes similar extreme discipline to always avoid poor/improper try/catch handlers. Refactoring code across certain boundaries becomes a much bigger hassle, so your end up discouraging refactoring across those boundaries, which leads to code that is more easily stale and design decisions that are much harder to back out of.
Been waiting for my Spectrum Next since I ordered it in Nov 2020. That’s been 31 months and the current “promise” on the Kickstarter page is shipping in Q3.. but the goal posts have been moved so many times that the Q3 shipping date looks like a cruel joke like the Daikatana shipping date.
"What do you get when you cross a computer with a car?" "A computer!"
It's a "Riddle for the Information Age" that in Alan Cooper wrote in 1999 [1] in "The Inmates Are Running the Asylum". One of the riddles is: "what do you get when you cross a computer with an airplane?" but things have gotten much much worse since then, it needs an update with the contents of this article.
He writes: "That something like this slipped through shows that the software inside the car is not coming from the same Porsche that makes the rest of the car... Acceptable levels of quality for software engineers are far lower than those for more traditional engineering disciplines..."
We have seen this coming for 20 years now easily. iDrive happened and excuses were made.
Nobody cares about response times or human-oriented design, it seems, which is incredibly baffling in a car! Where the rest of the controls are supposed to be designed with humans in mind.
My 2022 Subaru's Harman Kardon-built head-unit will block out my entire navigation view for 3 seconds if I dare to brush the volume control with my hand. I've learned to not adjust it after that because doing so only prolongs the time that I can't see where I'm supposed to be going. Also, if I am so unlucky as to lower the volume while the navigation speaks, I end up adjusting the "voiceover volume" and not the "radio/media volume." So when I wonder: "hey why did the navigation stop talking?" I have to remember that I hit the unlucky time to use the invisbily-modal volume knob. Of course, nobody cares and they let this travesty out the door because it's just the "entertainment system."