Subj : Lookatthegrouse, Lookatthegrouse!
To   : Mortar
From : Arelor
Date : Fri Jun 06 2025 06:00 am

 Re: Lookatthegrouse, Lookatthegrouse!
 By: Mortar to Arelor on Wed Jun 04 2025 02:52 pm

> Things were a lot different back then.  Programs were much smaller, less
> complicated, needed fewer resources, simpler architechure.  Comparing then
> and now is like comparing a Volkswagon Beatle to a Tesla Model S.
>

And that is kind of my point.

My lameass Ford Orion lasted 25 years without needing spare parts other than tires and a couple of battery replacements. Tesla Model S is more advanced and whatever but I doubt it will reach such old age without needing a change of batteries more expensive that my lameass Ford ever was.

Crappy spreadsheet software in the late 90s was simpler and did what it was supposed to do. Current spreadsheet software takes a computer 200 times more powerful to run, and people is using the same spreadsheets. Yeah, I know, it has more functions and macros and whatever but the point is you used to run a spreadsheet on a toaster and now you can't.

So basically, yes, you can't compare. Old stuff used to be tight, new stuff is a disaster.

> There were indeed assemblers back then.  I used one on a PET 8032 for my
> 6502 Machine Language class in college back in '80-81.  Also, assemblers
> don't deal with high-level languages, just machine language.
>

Well there were games that were coded in hex and given to the operator in order to produce the prototype. I think ant-attack is one of the most famous ones. The original notes with hex are said to still survive.

> From a coding perspective, unless the client is a data center or some such,
> the end-user shouldn't have to care.  All that matters is they get a product
> that works as advertised.
>

The customer should care because when the developer decides to pull a library with 300 dependencies instead of writing half a dozen custom funtions he is forcing the customer to buy more RAM. When the developer uses a bad library that causes excess IO he is forcing the customer to upgrade his storage or networking gear. Basically, new school developing consists on passing on the expenses of inefficiency to the customer. It works because customers suck and deserve to die.

Now try writting a crappy heavy SDN stack with ton of generic dependencies and sell it to Verizon, and tell me how it goes.


--
gopher://gopher.richardfalken.com/1/richardfalken

---
� Synchronet � Palantir BBS * palantirbbs.ddns.net * Pensacola, FL