I instinctually agree with nkrisc, but this is an interesting line of thought.
What's an example of something that nobody should be allowed to do e.g. on a laptop? If I buy a system with OS stuff set up from the get-go. What abilities do you withdraw from the user?
If anyone is looking for a clean JS charting framework, I highly recommend Observable Plot.
It's from the creator of D3 and it's much easier than using raw D3. I've been using it outside the Observable platform for debug charts and notebooks, and I find its output crisp and its API very usable.
It doesn't try to have all the bells and whistles, and I'm not even sure if it has animations. But for the kind of charts you see in papers and notebooks I think it covers a lot.
This is a nicely laid out collection of tutorials, but I'm sad that collections like this have drifted away from the very deliberate structure that A Pattern Language introduced. While patterns weren't invented by Alexander and co, they did inspire a lot of what we see in tech these days, inherited via design patterns etc.
In A Pattern Language, each pattern is hyperlinked to other patterns in a kind of hierarchy, where larger patterns (like "house cluster") are broken down into smaller constituent parts ("main entrance") all the way to quite granular details ("low doorway").
This is because you can't just take a pattern on its own; it forms part of a larger whole.
Tech pattern books often focus on small recurring structures (e.g. "command pattern" from this site), but not how they help create some larger pattern, or in the other direction, what are the smaller patterns that help create them.
This sounds like a lot of hard work of course, which is why people don't do it.* I would love to see this accomplished though. If only I had an extra 36 hours in each day.
One thing that A Pattern Language is also great at is motivating each pattern with a specific problem or symptom. This site seems to do a decent job at that, though some problems seem... kind of weakly motivated. For example, the above mentioned "command pattern" is motivated by "what if we need to rename a method?" which... is pretty weak tbh.
*EDIT: also because fitting patterns into a whole, maybe unavoidably, will promote a perspective, or a way of building a whole system. A pattern book for web applications written from an HTMX point of view would be a very different book to one written from a React slant. Maybe one pattern language can accommodate both sets of technologies, or maybe not.
If you're trying to connect Alexander to software patterns like GOF, it's important to include Gabriel's "Patterns of Software" [1] as the first genuine attempt to apply Alexandrian patterns to software. It also introduces the first and probably the best takedown of OO inheritance as not reuse but instead a form of _compression_ that is in many ways worse than just copy-and-paste.
Here's an excerpt from APL showing what I mean about the connections to the other patterns. This isn't the whole pattern, there's a lot between the problem statement and summary. Annotations in brackets are mine.
---
Short Passages (132)
[Context, or pre-links]
The Flow Through Rooms (131) describes the generosity of light and movement in the way that rooms connect to one another and recommends against the use of passages. But when there has to be a passage in an office or a house and when it is too small to be a Building Thoroughfare (101), it must be treated very specially, as if it were itself a room. This pattern gives the character of these smallest passages, and so completes the circulation system laid down by Circulation Realms (98) and Building Thoroughfare (101) and The Flow Through Rooms (131).
[Problem statement]
Long, sterile corridors set the scene for everything bad about modern architecture. In fact, the ugly long repetitive corridors of the machine age have so far infected the word "corridor" that it is hard to imagine that a corridor could ever be a place of beauty, a moment in your passage from room to room, which means as much as all the moments you spend in the rooms themselves.
[Pattern contents here]
[Pattern summary]
Keep passages short. Make them as much like rooms as possible, with carpets or wood on the floor, furniture, bookshelves, beautiful windows. Make them generous in shape, and always give them plenty of light; the best corridors and passages of all are those which have windows along an entire wall.
[Elaboration, or post-links]
Put in windows, bookshelves, and furnishings to make them as much like actual rooms as possible, with alcoves, seats along the edge - Light on Two Sides of Every Room (159), Alcoves (179), Window Place (180), Thick Walls (197), Closets Between Rooms (198); open up the long side into the garden or out onto balconies - Outdoor Room (163), Gallery Surround (166), Low Sill (222). Make interior windows between the passage and the rooms which open off it - Interior Windows(194), Solid Doors With Glass(237). And finally, for the shape of the passages, in detail, start with The Shape of Indoor Space (191)
I think the government making stuff up is worth considering, but isn't it a kind of different threat model?
The hypothetical government isn't going to make stuff up about me, some nobody, on a flight to the US to be a tourist or something. They statistically don't care about me. However, the US morality police might decide to statistically care about everyone who watches porn.
But if I'm a somebody, say a former or potential whistleblower, or a local politician, etc. then a government might have a specific motive to do me dirty and not care about being honest.
I guess there's a wide and blurry line between being a "nobody" the government has no motivation to lie about and being a "somebody" that deserves special malicious treatment.
The moral outrage crowd in the US have no power. The people who can and will act against you will only use morality as an excuse, not a cause. Being some nobody, the government has no interest in you anyway. You can watch porn, they can know it, and nothing changes, because you're still a nobody.
(If you watch porn online, you can be pretty sure they already "know" it, because you're not doing it in the privacy of your own home, you're doing it on a public network with next to no secrecy about who you are or what you're doing).
The author says "skill issue" isn't a defence for Rust, but also says
"C/C++ (Experienced Developer)
Resource management is internalized. It's like driving a manual transmission - you don't consciously think about shifting gears, you just do it."
How is this not saying that C/C++ require highly skilled developers? Why is there not an equivalent "Rust (Experienced Developer)" section for those who internalise the borrow checker model and can use their freed-up cognitive powers for the same things the experienced C/C++ developer can? This is a double standard.
And like wow, CloudFlare had one outage where they messed up config file parsing. Good thing nobody coding in C++ ever shipped a bug that caused an outage!
I actually think I agree with a lot of the substantive criticisms this article makes of Rust, but man, it is so overstated and melodramatic.
Saved money in the short term. But maintenance costs money. Amazon has all of the money in the world and could easily duplicate everything Salesforce does. Yet they use Salesforce internally.
All the money in the world would not be sufficient to cover the cost of seeing human developers duplicate Salesforce on any reasonable time scale. There are simply not enough developers in existence to see that happen, driving the cost towards infinity.
The idea here, however, is that machine developers are changing the calculus. If you need more machine developers it takes, what, a few days to produce the necessary hardware? Instead of 20+ years to produce the legacy human hardware. Meaning, for all intents and purposes, there is no observable limit to how much software machine can create, driving the cost towards zero.
Yeah, sure, the tech still isn't anywhere near capable enough to reproduce something like Salesforce in its entirety. But it is claimed that it is already there for the most trivial of services. Not all SaaS services are Salesforce-like behemoths. Think something more like patio11's bingo card creator. It is conceivable, however, that technology advancement will continue such that someday even Salesforce becomes equally trivial to reproduce.
Maintenance is not a meaningful cost unless you also want to continually have the software do more and more. That could tip the favour towards SaaS — but only if the SaaS service is in alignment with the same future you wish for. If you have to start paying them for bespoke modifications... Have fun with that. You'll be wishing you were paying for maintenance of your own product instead. Especially when said machines drive the cost of that maintenance to near-zero all the same.
I like your analysis but it seems to imply that at one point we can produce near-infinite amount of software and that this will be welcome.
It will not be. Even in this fairly broken state of affairs we are currently in, most non-technical people I spoke to already say that they have too much apps and too much machines with "intelligent" features.
And IMO when we have machines that can crank out a complete-but-better Salesforce, our civilization and race would be in an entirely another level and we would see such things as toys. Who needs that antiquated procurement and tracking expenses software, where's our 174th fusion reactor? What is even that in fact? Oh you mean that nail-sized addon we put on our main processing unit? Yeah we're not interested in ancient software history now. We need more juice to capture those gases around Jupiter for the wireless beaming of energy project! Our DAG-based workflow solver and the 5 AIs around it all said we can't do without it.
...So of course nobody wants to pay programmers. We've been viewed as expensive and unnecessary since the dawn of time. A necessary evil, more or less. But your last paragraph captures why many companies need them -- bespoke solutions. You can only add so many cloud services before your normal staff starts making mistakes on an hourly basis because they have to reconcile data between multiple systems whose vendors will always refuse to make integrations.
And even if many try to have their cake and eat it too -- i.e. have an IT friend they call only for those bespoke enhancements but only pay them during that time and not every month -- then this service will simply become more boutique and expensive, mostly compensating for the lack of salary. You'd do multiple stints for the year that would cover all your expenses and normal lifestyle, it would just not be through a monthly paycheck. Why? Because I think a lot of people will exit programming. So the law of supply and demand will ultimately triumph.
...Or we get a true general AI and it makes all of this redundant in 5 years.
> I like your analysis but it seems to imply that at one point we can produce near-infinite amount of software and that this will be welcome.
It implies that there will be no need to share libraries (which is said including things like networked SaaS services). You can have your legions of machine developers create all the code you need.
Let's face it, sharing code sucks for a long list of reasons. We accept it because it is a significantly better value proposition than putting human labor into duplicating efforts, but if that effort diminishes to almost nothing, things start to change in a lot of cases. There are still obvious exceptions, of course. You probably couldn't throw your machine developers at building a Stripe clone. It's far more about human relationships than code. But bingo card creator?
It says nothing about creating software nobody wants or needs.
I think there's a serious related issue which is that icon packs (font awesome, feather, material icons, whatever you prefer) encourage you to just pick the "closest" icon for a given menu item, rather than an icon that is actually what you want.
At work we do sometimes design custom icons for specific things, but that's very rare and relatively costly. Most developers on our team don't have that capability, and we are left trawling through Google's admittedly-large icon library to find something that seems plausible.
> Sorry, not interested in trivial changes like that.
- bnoordhuis
As a not native English speaker, I think the change itself is okay (women will also occasionally use computers), but saying you're not interested in merging it is kinda cringe, for a lack of a better term - do you not realize that people will take issue with this and you're turning a trivial change into a messy discussion? Stop being a nerd and merge the damn changeset, it won't break anything either, read the room. Admittedly, I also view the people arguing in the thread to be similarly cringe, purely on the basis that if someone is uninterested/opposed to stuff like this, you are exceedingly unlikely to be able to make them care.
Feels the same as how allowlist/denylist reads more cleanly, as well as main for a branch name uses a very common word as well - as long as updating your CI config isn't too much work. To show a bit of empathy the other way as well, maybe people get tired of too many changes like that (e.g. if most of the stuff you review is just people poking the docs by rewording stuff to be able to say that they contributed to project X). Or maybe people love to take principled stances and to argue idk
> ...it’s not the use of the gendered pronoun that’s at issue (that’s just sloppy), but rather the insistence that pronouns should in fact be gendered.
Yeah, odd thing to get so fixated on when the they/them version is more accurate in this circumstance. While I don't cause drama when I see gendered ones (again, most people here have English as a second language), I wouldn't argue with someone a bunch if they wanted to correct the docs or whatever.
He wasn't fired or canceled. It is great to see Gen-Xers and Boomers having all the fun in the 1980s and 1990s and then going all prissy on younger people in the 2010s and trying to ruin their careers.
For those looking for context, this is a regrettable response of mine from nearly three decades ago, resurrected because people disagreed with the way my handling bad community behavior well over a decade ago. And for whatever it's worth, my explanation of all of this from a decade ago still stands[0].
I think more people should read Naur's "programming as theory building".
A comment is an attempt to more fully document the theory the programmer has. Not all theory can be expressed in code. Both code and comment are lossy artefacts that are "projections" of the theory into text.
LLMs currently, I believe, cannot have a theory of the program. But they can definitely perform a useful simulacrum of such. I have not yet seen an LLM generated comment that is truly valuable. Of course, lots of human generated comments are not valuable either. But the ceiling for human comments is much, much higher.
What's an example of something that nobody should be allowed to do e.g. on a laptop? If I buy a system with OS stuff set up from the get-go. What abilities do you withdraw from the user?
reply