Learning to program does not equate to learning to architect and evolve over many years a non-trivial system, operate it, document it, train others on it, scale it, etc. - “unmotivated” is a bit reductive. In the same way I might enjoy some DIY here and there but don’t want to and shouldn’t be trusted to build new houses, the same goes for non-trivial systems - sometimes you really do just need professionals.
That’s not to say you can’t give areas with guardrails to non-software-engineering-professionals if you can teach them git.
Well, sure, it's under-specified, I said "unmotivated (for whatever reasons)", eh?
I agree with you. When it comes to programming computers it's one of the few areas where I am unabashedly elitist ( https://sforman.srht.site/AnyoneCanCode.html "For most people learning anything more complicated than Excel is counter-productive." )
My point is that it's not that hard to learn to program, not that it's easy to program well (it's not. I've been at it for over a quarter of a century and I'm still barely capable.)
My additional point is that the barrier to entry (other than apathy or disinterest) is the complexity (just to make a website you need to know three or four computer languages!?)
My third point is that that complexity is about to vanish in a haze of linear algebra and massive data (the computers can talk now.)
The difference is that nobody has to actually accept updates that the core team make - and this has happened a few times, resulting in forks, although those cases were for things the core team refused to do - how can you “fork” a security? What is the common enterprise when forking a PoW chain?
Exactly the same way you fork a non-security. Security is a legal designation, not a description of how a particular asset is implemented (in a forkable structure like a blockchain).
> What is the common enterprise when forking a PoW chain?
The developers/promoters of the fork, potentially.
> Even if this leads to humourously Java-esque code, it's worth it
Some people seem to get mad about the verbose naming common in Java - but it’s one of the biggest blessings I’ve ever experienced. If you name things after what they do, and that name is stupid, then it’s the quickest indicator of bad design I’ve ever seen. Good design is where every name is patently obvious and encompasses the entire purpose of the class / record / method / whatever.
I think it's not the verbose names that are the problem in stereotypical Java-esque names, but rather the large amount of "scaffolding" classes that implement design patterns - a wealth of middleware that becomes apparent thanks to the verbose naming. That is, it's not the ProcessedWidget::QueryStructuralIntegrityPercent() that's the issue - it's the associated WidgetFactory, ProcessedWidgetBuilder, ProcessedWidgetProcessingManagerDelegateProxy, etc. that bloat the code and tax cognitive memory, and which exist only because the language isn't (or used to not be) expressive enough to express those patterns without giving them a name.
There's nothing like ProcessedWidgetProcessingManagerDelegateProxy in Java or the standard library. I feel that Java gets whacked with a cudgel that should be aimed at middleware authors.
There's nothing in JavaScript forcing you to use 500 dependencies across 100 000 folders either. Opinions on a programming language are often, for better or worse, opinions on the language plus its community/ecosystem. And correct me if I'm wrong, but isn't the company responsible for maintaining Java (Sun, now Oracle) also one of the worst offenders in terms of naming things in its middleware?
> If you name things after what they do, and that name is stupid, then it’s the quickest indicator of bad design I’ve ever seen.
I agree it’s a smell, but I’d caution that it’s also very situational.
Sometimes the domain has a recognizable category of like-things which don’t have a name for their likeness within the same domain, and choosing even a stupid-sounding name is a good start towards choosing a better name.
Other times, a targeted portion of an existing codebase might have a common theme which doesn’t necessarily line up with the domain, but needs to be named something to untangle what outlived its WET shelf life. You can recognize it’s a stable abstraction, you can recognize it's entirely divorced from any domain concern except by happenstance. You just have to give it a name, or let it be an increasingly unnecessary burden.
It’s easier to take such a hard line on the design quality implications of naming when you have a vocabulary to reference and/or compose, or when you have extant design attitudes relatively aligned with that principle. It’s especially difficult to apply the principle in systems with extant design problems of this nature, because whatever established or emergent abstractions do exist might not align with any principle you’d apply, and you can’t move them in that direction without some intermediate step no matter how flawed. You have to name what is before you name what should be.
IMHO what makes it harder in git (for many people committing into the same branch) is that each team member has its own local history which needs to be synchronised via push and fetch (which quickly gets out of control for 'non-technical' team members). This separate step doesn't exist in centralized version control systems like SVN where everybody is always on the same timeline.
Working exclusively on branches and then merging into a common main branch pretty much fixes this problem though (that's why the PR workflow make a lot more sense in git than svn).
> and what everyone wanted most was a stable relationship, a job they enjoyed and to be able to afford a modest house.
> It's reassuring that in a seemingly insane world, the kids who are coming up seem have their heads screwed on straight.
One might say that the reason is because this is seemingly becoming harder than ever in Western countries.
That's certainly part of it, but also I think that, in the face of infinite gender/relationship/careers possibilities, they're (rather sensibly) leaning on tradition for guidance.
> spend 4 hours putting a webflow site on top of GPT APIs
GPT _is_ AI though, no? I would think that this would count. Might violate "a re you exaggerating what your AI product can do" or "are you aware of the risks" instead though.
Not all of us would agree. We would only take that expression for a rhetoric simplification (a shortening for "part of a broad AI realm"). We would pivot near the concept of "AI" as "a problem solver that could do the job of a professional". This in way excludes e.g. "build convincing text", because it is not (or should not) be a professional task - though it can surely be part of research.
Doubts are possible on all four FTC points - plus more in the linked guidance post from E. Jillison (e.g. "Do more good than harm" - difficult measure on engines which have "relaxed sides").
You still have to do all that with cloud though - instead of firewalls and IP tables it’s VPCs, IAM, security groups, auto scaling groups, etc etc. The reason I think it’s still probably better for Sprocket Masters to go cloud is purely because those skills are easier to hire for.
Having and independent schema file being one to one with the proto files is not quite as nice, but then you still can get bindings in each language to the proto.
The goal is to avoid defining the table schema in each language, like ORMs, where things can be out of date.
There may even be some benefits to this, as you might have some lifecycle hooks around migrations to keep the proto up to date with the current schema. You could do this with just protoc plugins to hide fields in the language bindings or you could do it turing the edgedb schema to proto translation.
That’s not to say you can’t give areas with guardrails to non-software-engineering-professionals if you can teach them git.