HN user

astral303

1,379 karma
Posts5
Comments372
View on HN

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

The core principles still ring so very true: https://web.archive.org/web/20061025010636/http://rchi.raski...

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

Java 22 Released 2 years ago

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

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

1 - https://www.amazon.com/Inmates-Are-Running-Asylum-Products/d...

I am so excited for such a TV, here are some name ideas for you: plainum-TV, gramseye, you-control-it(still comes with a remote), BarelySmart, SmartEnuff, MindYouTech, AllPane, SimplePaneVision, Plainorama, Plainoramic Vision.

HDMI such an abomination thrust upon the world. Why do we accept a TV going blank for seconds for any reason in 2023. Lawrd help us all. Can you optimize HDMI resync in any way? That would be a major selling point. Maybe blend the output between what was shown and what is about to be shownn (apply a gentle blur filter to the last seen frame for a few moments and fade to black after 3-4 seconds.. float a gentle explainer message “HDMI sync lost….” After 3 seconds)

rotary engines do not really scream at peak power... this is why Mazda has plans to use rotary at peak power to generate electricity for their hybrid EVs.

re 20 years to make a new engine point, compare investment $ in traditional ICE across the car industry vs investment $ into rotary or other alternative engines (the former is order of magnitudes more)

Configuration is code, so the YAML written in your tool is still code, code that developers are consuming and versioning. Making it YAML doesn’t make it not code. Your YAML configuration files are proprietary syntax, it is a proprietary code syntax written in a language (YAML) lacks basic abilities for logic or control flow. In a system of any worthwhile complexity, inevitably custom build logic will have to be expressed, and I can’t imagine it being good when it is being cooked up in a proprietary configuration language based on YAML.

How easy will it be for layers of abstractions to emerge in this system? That’s the ultimate limitation of markup-language-based / configuration-based build systems.

Look up the difference between external DSLs and internal DSLs. The YAML config file is an external DSL. I prefer to express configuration using internal DSLs.

I don’t think self-driving cars lead to fewer people owning cars, in fact it’s quite the opposite. With FSD, those who don’t like driving can deal with owning a car to do necessary transportation tasks (e.g. commuting), instead of giving it up for alternative methods because they don’t want to drive consciously/presently.

There’s a great book by Tom DeMarco that argues for having slack, and for that being critical for innovation: “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency”