• Lookatthegrouse, Lookatthegrouse!

    From Mortar@VERT/EOTLBBS to Arelor on Wed Jun 4 14:52:32 2025
    Re: Re: Cobol/gnucobol
    By: Arelor to Boraxman on Tue Jun 03 2025 12:24:44

    Back in the 80s coders were developing games using straight opcodes with no assembler nor nothing because if you used high level languages people would complain about performance.

    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.

    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.

    Today, the people paying does not give a damn, therefore the people who codes does not either.

    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.

    ---
    þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
  • From Arelor@VERT/PALANTIR to Mortar on Fri Jun 6 06:00:01 2025
    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
  • From Nightfox@VERT/DIGDIST to Arelor on Fri Jun 6 09:33:57 2025
    Re: Lookatthegrouse, Lookatthegrouse!
    By: Arelor to Mortar on Fri Jun 06 2025 06:00 am

    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.

    Generally efficiency is good, but there's an idea in software development that in general, you shouldn't re-invent the wheel. Writing all of your own functions for everything takes time to develop and test, and when you're working for someone, that time is money. In many cases, a lot of companies can justify using libraries if it can save them time and money.

    Nightfox

    ---
    þ Synchronet þ Digital Distortion: digitaldistortionbbs.com