Futurist Programming Notes
graficaobscura.com
graficaobscura.com
In terms of resource consumption machine capacity has grown exponentially, but who can claim the same for user utility?
This is by now a problem so pervasive that even economists puzzle over (the missing information technology productivity gain)
But this text is part of the problem really, as it is too simplistic and doesnt feel like it identifies fundamental recipes for building better software
My Linux laptop boots in about 20 seconds. CRT TV's took longer than that to warm up.
Maybe I over-value coherence.
> Television - 3 seconds
> Automobile - 2 seconds
> Microwave oven - less than 1 second
> Video game - less than 1 second
> Unix workstation - 120 seconds or more
Yeah, those times are bullshit. Please tell me what platform has a video game boot in less than a second, because it hasn't been true for any generation of console I've played on (which dates back to the Sega Genesis).
This feels like it was written around 1995 (the newest reference is 1994, and the "hot new technology" they're shitting on is C++, which suggests that Java hasn't come out yet). There's a general smug air of "real programmers use assembly." For bonus points, they also criticize computer scientists on the basis of "most NEW ideas are feared and rejected", which is honestly a pretty good summary of the diatribe.
NES might qualify, as it often "loaded" (turned on) right into the title screen.
I also remember some of those being totally skippable as well, not only in the Genesis but also in other consoles. On the Neo Geo, for example (same CPU as the Genesis, 68000), putting a coin completely skips the (kinda long) 7 second logo intro.
That's a pretty unfair metric, then, considering that said delay is entirely artificial and is part of the game itself.
That’s not because of better software though. Games were just so much smaller then.
So if a 128k game loads in less than a second, and the 4.7G DVD version of the same game takes 30 seconds, I would probably wait 30 seconds for the DVD version.
It's a view I shared in the past - it held throughout the entire "desktop computing era", until consoles and PCs started to converge, and the asset bundle size of a typical game inflated rapidly.
The fact that game consoles have become more and more like PCs in terms of user experience over the decades is actually pretty sad.
instant on to command prompt
READY.
boot from floppy disk wait for command prompt
DOS VERSION 3.3
boot hard disk, startup script runs, wait longer for command prompt
C:\>
startup screen, wait for desktop to load, wait even longer to open a command prompt program
$
start up screen, wait for desktop to load, login, wait even a bit longer to open a command prompt program
Password:
start up screen, wait for desktop to load, login, get distracted by web browser, forget to open the command prompt program
www
the battery in my phone is dead.
cf https://en.wikipedia.org/wiki/Futurist_cooking or http://www.designhistory.org/Avant_Garde_pages/Futurism.html
1. https://www.societyforasianart.org/sites/default/files/manif...
You must have had a very crappy CRT TV :) A good TV (or CRT computer monitor) was available near-instantly, and also switched channels much faster than a modern 'digital' TV.
(I'm counting the time it took a TV to show broadcast programming or "normal" cable programming. IIRC cable decoder boxes would introduce some extra delay here for "cold start", but those boxes were all shitty garbage from the same kind of companies that now sell smart TVs, and we didn't use them anyway.)
It was only when they became more like a computer that it started going down. When they started getting remote updates it became a nightmare.
The set-top box I had before cord-cutting was "always on", and consumed quite a lot of power even when "turned off". It was extremely hot all day. Pulling the plug off the wall when not using was enough to save money, but then it take a full minute to power on, and then it had to wait for something from the satellite. I eventually bought a timer so it would turn on at 8am.
> These documents were designed to be viewed in a window that is 564 pixels wide when the scroll bar is visible. If you want to make these pages look the way I designed them, adjust the width of your Web browser until the arrows below are fully visible and centered. If you want to use some other width that's fine too.
The about me [1] page says some (?) documents on the site were published in HTML in 1994, so I guess the actual dates are even older.
> Computer "Science" terms exposed
> Let's look at some boot times:
>
> Video game - less than 1 second
> Unix workstation - 120 seconds or more
The idea of rejecting waste has been largely rejected itself in time of desktop dominance. Who cares if a desktop program runs 100x as slow as it should have if it 1) runs 2) is paid for anyway.
Now, in a cloud, YOU care if your program runs 100x as slow as it could have because you pay the AWS bill. All the waste is now your expense.
Some stuff about SW design is true. Some design criteria are really dogmatic for instance, losing connection with the end value of the product.
Also top futurist programming priorities looks quite ok and an ideal to achieve.
Even luminaries like Alan Kay have been trying (with projects like Viewpoints Research Institute) to make computer software "simpler" (for lack of a better word), but is it really feasible when the whole industry is moving in the complete opposite direction?
A lot of people can make a fast and simple enough Operating System. A lot did when back in the day at https://osdev.org/, and some probably still do. The problem is "drawing the rest of the owl": the apps.
The problem is that it won't work on their hardware without an army of people writing drivers. Even Linux has driver issues despite having huge numbers of people working on it. Arguably that's a bit self inflicted because they insist on having everything in-tree, but still.
People who mind waiting 120 seconds once a day probably should seek a therapist advice.
\s
For some programs, configuration may be necessary (or helpful) too; it really depends what program. (However, compile time configuration is sometimes better than run time configuration, depending on the specific details, probably.)
I do believe object-oriented programming is overused (although it is sometimes helpful, often it isn't).
Programs should be versatile, but this can be done without too much complexity; often just being able to combine with other programs that can do the other things, can be helpful, like UNIX systems with many programs can use pipes together, etc.
Maybe not all types of programs. When I download an App on my smartphone, I never look for the documentation.
Better:
* Type Safe = Almost type safe. You can cast them away.
* Memory Safe = Almost memory safe. Ignore the stack overflows.
* Concurrency Safe = Almost concurrency safe. Only deadlocks are left. And it's blocking.
It's easy to figure out what the authors are saying, provided that you guys have something called "basic reading comprehension". Here's a TL;DR: "software is being judged by the wrong criteria. Focus on the users, dammit. Software should be judged by its usability, speed, bug-freeness, and innovativeness." The authors aren't really picking a bone against structured programming (or object-oriented programming, or whatever), those bullet points sound more like the type of excuse for crapware that you'd hear back in the day.
Also look at the references; the newest one is from '94. This text is probably from '94-'00. Tech reference there should be contextualised to those times, not to 25~30 years later aka now.
Finally, the general tone being used by the text is not serious, it's cheeky and troll-ish. Odds are that the authors intended this as food for thought, not as a dissertation that should be analysed and replied with "ackshyually, this specific example is 0.573% inaccurate lol lmao".
You might have been serious or not when writing that, but framing your comment in a more positive manner will result in better discussion.
>You might have been serious or not when writing that, but framing your comment in a more positive manner will result in better discussion.
Frankly, the users who might get their very, very precious feelings hurt with this "learn to read" are most likely the ones who won't contribute jack shit to the discussion, no matter how polite of a tone you might use with them.
___________________________
Now, yet another thing that those users didn't get is that this text is two, perhaps three decades old. Things have changed and nowadays developers put a bit more of thought into the users. Even then, the general idea - "who cares about your data structure, show results that the users benefit from!" is still important.