so this article strikes a chord... unixsheikh.com/articles/is-the

but it feels like the author has got the diagnosis right, but landed on a prescription that's 180° wrong:

The entry barrier to programming needs to be high!

no, absolutely not! and if the author looks hard, this is obvious; the entry barrier to programming was higher back then only in terms of obtaining access. in every other sense, it was lower; even the largest computers were so much simpler that one person could grok them almost overnight, operating systems were laughably simple compared with today's, textual interfaces are almost laughably easy to code compared with modern GUIs, network security was just not someone anything cared about...

in contrast, there's a revealing quote from a reply on Hacker News:

At a minimum you need node, npm, webpack, babel, an spa framework, a frontend router, a css transpiler, a css framework, a test runner, a testing functions library, and a bunch of smaller things, and that's just what is "needed" to build a static website with a bit of interaction.

that's a lot of complexity to get on top of! it means that the entry barrier to programming is actually much higher than it was - to the point where people just don't have room in their heads for the high level stuff of web programming and a model of what the computers are actually doing with that stuff.

and yes, a static website with a couple of CGI pages is simpler - as long as you're OK with making every security mistake of the last three decades all over again. because network security is hard, and that's part of what drives the adoption of frameworks.

Show thread

the other part is kind of historical now - it's the mess that browsers were in between about 1995 and 2010, where nothing worked properly from one browser to another and the most widely used browser was hideously broken. a lot of frameworks evolved to hide the complexity of working out what CSS to present to which browser to get a uniform result.

in a way this complexity still exists - it's just, now it's the gulf between finger-steered mobile and mouse-driven desktop browsers.

(somewhere along the way that changed into forcing browsers to present things as though they were spreads in a Saturday magazine, which doesn't exactly help matters - but blame management and their insistence on hiring graphics designers for that. ;-)

the article continues...

Programming is engineering; it's not something where you throw stuff at the wall and see what sticks

trouble is, it's not just engineering. there's a lot of art involved too. that's where things get problematic...

if it were just engineering, then simple solutions would obviously be the best. you don't want an innovative bridge that prioritises form first! and that's the thing: the barrier to designing a bridge is not high. people have been doing it for millennia! the barrier to designing a bridge that won't collapse, ever is high, but only in the sense of "you have to demonstrate an understanding of why innovative bridges are a bad idea before we let you".

but of course, everyone knows how to use a bridge. it doesn't require thinking about. (well, the "three ropes across a ravine" style of bridge does, i guess - and that's where 1970s/early-80s computing was, frankly.)

but coding isn't about that. coding is the head-on collision of engineering, architecture and anything-goes graphic design - and the designers are leading things, which is probably the natural consequence of what the web has evolved into. and that, i suspect, is why things have become so complex.

hmm... i think this might have ended up in a different place from where i started.

the point i was initially intending to make is that the barrier to entry into computing has become unusably high and needs to be reduced again, by fundamentally rethinking how we can achieve the desirable aims without the colossal amounts of cruft that we've seen evolve around delivering them.

but i think where i've ended up is that the barrier of entry has actually become unscalable for people of an engineering mindset, because it's not for us any more. the web people couldn't / wouldn't wait for us to work out how to build proper, thousand-year viaducts - so they built what they needed on a foundation of three-ropes-across-a-ravine, and have been adding stuff to shore that up ever since. and they can't back out now, because they've been working on this stuff for three decades and there's too much of it now for them to do anything but keep piling on.

...buuuut what do i know? i burned out hard nearly two decades ago, and looking at what i'd have to learn in order to get back into the game, it just looks utterly insurmountable. not to mention that i'd need to build stuff to practice, and i don't have the first idea of what to build! so basically i'm stuck at a "give me a computer i can know inside out" level, because anything else just makes me dizzy.

hence my attraction to things like Forth and Lisp. they look tractable. i could rig up a simple Forth in a few KB of code, and extend that gradually up into a complete system... and it looks less daunting to do that than it does to learn how to make a modern Web app.

i suspect the same impulse is driving things like uxn and retro and ForthBox. we have lost tractability; the only people who can get to grips with modern Web programming are folk who don't need tractability - who are able to just use the bits they need and not worry about what's under the hood.

Follow

@millihertz
> we have lost tractability
Exactly! Most of technologies behind the modern web, the file formats, were supposed to be human-readable, but look at the source of any modern "web app" especially the javascript part — it's as readable as a disassembled binary. No one needs that anymore, but it's still there just consuming resources.

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml