Making illegal states unrepresentable sounds like a great idea, and it is, but I see it getting applied without nuance. “Has multiple errors” can be a valid type. Instead of bailing immediately, you can collect all of the errors so that they can be reported all together rather than forcing the user to fix one error at a time.

Is this not `Result<Whatever, List<Error>>`? There's nothing enforcing that the error side needs to be the value-based equivalent of a single instance of an Exception class.

The important part is not to expose a "String -> Whatever" function publicly.

A generic rejection is more than I got for feedback; I never heard back. Still, I thought the process of writing the materials was great. I don’t usually take the time to think about the arc of my experience in a holistic way. Do it for yourself if you do it at all; don’t go into it with high expectations for feedback and you won’t be disappointed.

I just reached out to them after the 4 to six weeks had passed. got my decision a few days later

Yeah. I tried that at the eight week mark, but I heard nothing back. Obviously not a process-heavy company, but that’s part of their appeal.

I used a Sun workstation as late as 2008, but by that time it was ancient and kept around only for the expensive engineering software that wouldn’t run anywhere else. Even at the time, using CDE felt like a blast from the past. I didn’t dig too deep because I wasn’t using it for long, but I’m pretty sure the vi was original.

IDE vim support suffers from three problems. First, performance. I have yet to try an IDE that can match the responsiveness of vim. You can obviously tank vim’s performance with plugins, but you don’t have to. Second: clutter. Modern displays are gigantic, and yet most IDE users don’t have more than 40 lines of code on the screen at a time. The rest is occupied by a file picker, command palette, integrated terminal, LLM chat interface, and so forth. You have to go to some effort to reclaim those pixels; big context is not yours by default. Third: uncanny valley effect. Vim implementation is usually incomplete, especially when it comes to ex-style colon-prefixed commands. It’s jarring to run into a spot where your muscle memory doesn’t work.

In short, IDE vim support does not measure up to the experience of using the real thing.

Yeah, why would billionaires sell us something that lets us chill out all day, instead of using it themselves and capturing the value directly? You claim to have a perpetual motion machine and a Star Trek replicator rolled into one, what do you need me for?

Those ads are not for workers, they're for the employers.

I could not agree less. The line of reasoning here is: relying on the type system to prevent error lets people writer fewer tests. Tests are the only way to assure quality. Therefore fewer tests is bad, and powerful type systems are bad too, because they cause you to act against software quality.

Furthermore, Uncle Bob sets up this weird opposition between the programmer and the type system, as if the latter is somehow fighting the former, rather than being a tool in their hand.

I think that sadly this is just the narrative of a man whose life’s work consists of convincing people that there is a silver bullet, and it is TDD.

What you’ve described is very much not writing code though. It’s the tedious and unpleasant outcome of having a flaky or under resourced CI setup or pulling in a misbehaving dependency. Neither of those is typing code per se. I don’t think it’s fair to conflate that kind of problem with the creative work involved in implementation itself.

“Writing code is boring and tedious” says more about the speaker than it does about programming.

So helps with all of it. I’ve had AI fix flakey builds multiple times in one shot. Big time saver.

Ooof, good luck. Civ3 copy protection was intense. I had to get out my old Win2k disk and stand up a VM. Attempts to rip an iso will be complicated by the fact that they deliberately wrote bad data to the disk. All of this is surmountable, but unless you enjoy a very particular kind of fun, you may prefer to spend $2 on GoG.

I know competent adults whose login flow for most websites is “forgot password.” Might be better off writing your passwords on post it notes at that point.

I've seen a few sites where the login flow is simply entering your email address and you get a time-limited login link sent to you. You never create any password at all. I was skeptical at first but I've found it seems to work pretty decently.

This could not be a more picture perfect example of a Wirth-suboptimal engeneering decision as per the article if it were designed for that. The amount of slowdown to run to the emails, wait for reception, open, copy, paste instead of using the sensible flow of password manager integration is huge. But people will use wasteful processes if they just don't need to change them, so what are you gonna do?

well, yeah, I mean a local 2fa code app (or integrated passwd manager as you say) is definitely simpler. the "just enter an email and paste in the code you got emailed" is the most foolproof because people don't lose access to their email nearly as often as they lose their phone (2fa app) or forget their password. /shrug

Whenever some website asks me to use specific weird characters in my password. I have to write it down on a post-it note and put it in the top drawer of my desk.

The irony is that the websites which require such passwords are often low-importance.

Access is not as dead as you might hope. The long tail of internal tools written with Access continues to shamble along. I had to figure out how to dump MDB files on Windows last year for just this reason. As an industry I think we often fail to grasp how much outsider art there is, in the form of internal departmental tools.

LLM coding is going to create a cambrian explosion of these tools. It’s going to be very interesting to see the remnants of this wave 30 years down the line.

One of the key questions here - will LLM coding decrease the proliferation of app-specific Excel files (by for example accelerating and simplifying Excel-to-webapp conversion) or would result in an opposite outcome by making feasible managing even orders of magnitude more of those disparate Excel files :)

I wouldn’t bet against cramming more and more business processes into Excel. The guy who was copying cells from one workbook to another yesterday, tomorrow can have a single mega-workbook with all the macros more or less deconflicted.