different things. adding levels of abstraction is not the same as having a statistical model generate abstractions for you.
you can still call it spec-programming but if you don't audit your generated code then you're simply doing it wrong; you just don't realize that yet because you've been getting away with it until now.
> if you take code from a developer ten years ago and compare it with their output now, you can see improvement.
really? it depends on the type of development, but ten years ago the coder profession had already long gone mainstream and massified, with a lot of people just attracted by a convenient career rather than vocation. mediocrity was already the baseline ("agile" mentality to at the very least cope with that mediocrity and turnover churn was already at its peak) and on the other extreme coder narcissism was already en vogue.
the tools, resources, environments have indoubtedly improved a lot, though at the cost of overhead, overcomplexity. higher abstraction levels help but promote detachment from the fundamentals.
so specific areas and high end teams have probably improved, but i'd say average code quality has actually diminished, and keeps doing so. if it weren't for qa, monitoring, auditing and mitigation processes it would by now be catastrophic. cue in agents and vibe coding ...
as an old school coder that nowadays only codes for fun i see llm tools as an incredibly interesting and game changing tool for the profane, but that a professional coder might cede control to an agent (as opposed to use it for prospection or menial work) makes me already cringe, and i'm unable to wrap my head around vibe coding.
it's not just conditioning, there is likely some biological drive because we evolved as a social species, but he's right, there is also conditioning and it can be dealt with. there is plenty of people that live in solitude and plenitude because they chose or learned to do so.
we're told that we need connection, but what we seek in others is really ourselves: our meaning, our purpose, we need to matter. what we actually find in others is only the illusion of that. it works (usually) and it feels good but not necessarily for everyone and there are ways to do that all by yourself. just be nice to yourself and enjoy existence. some will contemplate you as a weirdo, but that's their conditioning kicking in. it may not be for everyone, but there's really nothing wrong with that.
i was raised in a crowded family. i had dates and got married and got kids. i have a few friends left, some family left, aquaintances, sport comrades, sporadic contact and interaction with all of them ... but i spend most of my time alone and doing my thing, and rarely get bored, days fly. sometimes i might feel empty, lonely, depressed ... well then i reach out, or just soldier on, or distract myself, i know it will pass. and i think everyone has such moments, i had them all my life, being permanently crowded just distracts you from that. all in all, looking back, i'm having the blast of my lifetime and this is how i want to live the rest of it.
we ought to stop these decadent crooks from plunging us into fascism and war just to rescue their waning privilege (again), but somehow i don't think we will. so, yeah, lessons to be relearned ahead.
> They focus on objects when we should focus on morphisms.
if you're building real systems you should focus on both.
> Coupling as Hom-Set Size ... The second interface is easier to implement, test, mock, and evolve.
i would doubt that. this just hides the complexity of multiple interfaces inside single, more general interfaces. if those "arrows" actually exist you will have to test and evolve them anyway, and adding some extra classification level does little apart from adding complexity.
> Pipelines ... Why This Matters ... Testability: Each morphism can be tested independently
i agree ... and this just contradicts the previous point about hom-set size.
> The arrows are what matter.
everything matters. i'm aware of the benefits and appeal of category theory, but i don't see the need to shoehorn it into everything, this just seems an example of evangelization of extremes. iow: if your only tool is a hammer everything looks like a nail, and that's not conducing to good design.
no, it isn't. we need both, they're different aspects of the same thing. hyperfocusing on the former and disregarding the latter is just as bad as doing the inverse, and is exactly the problem i was describing.
i barely got to play with one for a few hours during an "ai" course, so i didn't really figure much of it out but ... oh yeah, it was "cool"! also way-way-way over my budget. i then kept an eye for a while on the atari transputer workstation but no luck, it never really took off.
anyway, i find this article quite out of place. what hordes of romantically spoiled lisp machine nostalgia fanatics harassed this poor guy to the extreme that he had to go on this (pretty pointless) disparaging spree?
that's a bit misleading. it was based on webcore which apple had forked from khtml. however google found apple's addition to be a drag and i think very little of it (if anything at all, besides the khtml foundation) survived "the great cleanup" and rewrite that became blink. so actually webkit was a just transitional phase that led to a dead end and it is more accurate to say that blink is based on khtml.
you can still call it spec-programming but if you don't audit your generated code then you're simply doing it wrong; you just don't realize that yet because you've been getting away with it until now.
reply