The difference seems to be that there's been a greater divergence between "professional" tools and "kids/intro tools" whereas Turbo C++ (or Turbo Pascal in my days) were kinda both.

[0] https://processing.org/

If we really think basic / turbo pascal has this right. Why don’t we just teach our kids those things. We can get the environments running I am sure.

https://pico-8.fandom.com/wiki/Circ

But I'm just not sure if pixel-by-pixel drawing is the right abstraction layer at this point in time.

Free Logos are available even today.

#lazyweb

I guess it would be something like this in pseudo code:

  var dynamic = 5

  function foo() {
    print(dynamic)
  }
  
  function bar() {
    var dynamic = 6
    // foo() prints 6 due to the binding above
    foo()
    // After bar() exits, "dynamic" will go back to being 5
  }

If you search around there are some pretty decent "download InteliJ and go" things.

A kid in the early to mid-80's could get enough working that they could imagine it possible to match a store bought game.

Once hardware capabilities went up, so did the need for more specialized skills and longer development cycles. Even though it might have still been possible to draw a box on the screen with a single command, the relationship of that box to a valuable outcome was a lot less obvious.

https://news.ycombinator.com/item?id=39323511

I have a ~20 line html harness which sets up a page with a full screen canvas element and gives you global window width & height variables. That’s all you need to get started. And it’s real JavaScript - so students learn a useful programming language as a result, and the advanced students can go nuts and add sprites, sound and networking if they really want to.

http://josephg.com/canvas_f.zip

I tell people to leave the html file alone and edit the javascript, using the canvas API to make it draw whatever they want. Canvas supports text, shapes and images and translations / transformations. If they want, I show them how to animate their work as well.

People make fun cursed things like this:

https://home.seph.codes/public/niamh/

Or Python for 3D stuffs.

Back in the day I heard about of a friend who claimed to write some 2d framework which was faster than Direct2D -- that was a pretty early version of Direct2D I think.

SDL3 is going to have a general purpose 3D API with its own shader language AFAIK.

In my experience, if what you want is to just get a window open and render some sprites, have some basic low level stuff handled and not have your hand held, SDL2 is ridiculously easy for it. There's also Raylib[0] and SFML[1], neither of which I've used but I hear good things about.

[0]https://www.raylib.com/

[1]https://www.sfml-dev.org/

Yeah I made half of a Ultima spinoff with SDL2 and it's pretty easy. Basically I load a texture which is a spritesheet and it's trivial to present a tilemap.

That still reigns as my favorite IDE of all time by a country mile.

Thankfully a professor pointed us to XEmacs, which I managed to get my Borland experience back, which became my UNIX companion until KDevelop, Eclipse, Netbeans came to rescue.

And everybody kept in mind that if we ever started making money from our hobby, one of our first investments would be into buying properly licensed copies of the tools we used.

This might be my biggest disappointment with "modern" programming. I want direct access to the hardware with stuff like $100 1GHz 100+ core CPUs with local memories and true multithreaded languages that use immutability and copy-on-write to implement higher-order methods and scatter-gather arrays. Instead we got proprietary DSP/SIMD GPUs with esoteric types like tensors that require the use of display lists and shaders to achieve high performance.

It comes down to the easy vs simple debate.

Most paradigms today go the "easy" route, providing syntactic sugar and similar shortcuts to work within artificial constraints created by market inefficiencies like monopoly. So we're told that the latency between CPU and GPU is too long for old-fashioned C-style programming. Then we have to manage pixel buffers ourselves. We're limited in the number of layers we can draw or the number of memory locations we can read/right simultaneously (like how old arcade boxes only had so many sprites). The graphics driver we're using may not provide such basic types as GL_LINES. Etc etc etc. This path inevitably leads to cookie cutter programming and copypasta, causing software to have a canned feel like the old CGI-BIN and Flash Player days.

Whereas the "simple" route would solve actual problems within the runtime so that we can work at a level of abstraction of our choosing. For example, intrinsics and manual management of memory layout under SSE/Altivec would be substituted for generalized (size-independent) vector operations on any type with the offsets of variables within classes/structs decided internally. GPUs, FPUs and even hyperthreading would go away in favor of microcode-defined types and operations on arbitrary bitfields, more akin to something like VHDL/Verilog running on reprogrammable hardware.

The idea being that computers should do whatever it takes to execute users' instructions, rather than forcing users to adapt their mental models to the hardware/software. Cross-platform compilation, emulation, forced hardware upgrades that ignore Turing completeness, vendor/platform lock-in and planned obsolescence are all symptoms of today's "easy" status quo. Whereas we could have the "simple" MIMD transputer I've discussed endlessly in previous comments that just reconfigures itself to run anything we want at the maximum possible speed. More like how a Star Trek computer might run.

In practice that would mean that a naive for-loop on individual bytes written in C would run the same speed as a highly accelerated shader, because the compiler would optimize the intermediate code (i-code) into its dependent operations and distribute computation across a potentially unlimited number of cores, integrating the results to exactly match a single-threaded runtime.

The hoops we have to jump through between conception and implementation represents how far we've diverged from what computing could be. Modern web development, enterprise software, a la carte microservice hoards like AWS that eventually require nearly every service just to work, etc etc etc, often create workloads which are 90% friction and 10% results.

Just give me the good old days where the runtime gave us everything, no include paths or even compiler flags to worry about, and the compiler stripped out everything we did't use. Think C for the Macintosh mostly worked that way, and even Metrowerks CodeWarrior tried to have sane defaults. Before that, the first fast language I used, called Visual Interactive Programming (VIP), gave the programmer everything and the kitchen sink. And HyperCard practically made it its mission in life to free the user of as much programming jargon as possible.

I feel like I got more done between the ages of 12 and 18 than all the years since. And it's not a fleeting feeling.. it's every single day. And forgetting how good things were in order to focus on the task at hand now takes up so much of my psyche that I'm probably less than 10% as productive as I once was.