I struggle to conceptualise a modern form of it - something that's perhaps a cross of Hypercard, Visual Basic, and Unity.
On home computers throughout the 1980s, BASIC WAS the OS.
I also found it bizarre, how you can't even use modern computers costing hundreds of dollars as a simple calculator if the OS can't boot up.
I wish Apple would bundle something like iOS Swift Playgrounds with macOS, considering they already include Script Editor, Automator, Pages, Numbers, GarageBand etc.
I remember a version of MS C in the late 80s coming with 5,500 pages of printed documentation! And it was easy to find what you needed
Sadly today with (internet) online documentation things are still not as good - even if often there is more information, it is scattered all over the place, often repeating (parts of) itself and slow to find and access. The main reason why i prefer to have a WIN32.HLP file from (i think) some Borland product whenever i need some Win32 function than search Google for it for MS Docs (the test is 99.9% of the cases the same anyway). Also why i have Zeal[0] installed with the docs of a few things i use and i download offline copies of whatever specs and documentation i can find for other things.
But in terms of help systems, i think CHM was the peak (in terms of functionality - the HTML-based content is a bit of unnecessary overhead and something like HLP's hypertext should have been good enough, but Microsoft wanted to shove IE4 everywhere so they can claim it was an integral part of Windows 98 back then).
I still reach for p5.js when I need to throw up a quick visual demo of something.
The author of AMOS / STOS is bringing back and he did an interview here.
https://www.youtube.com/watch?v=Hs-QOu8EAWY
He seems to have gone the browser route which I am not keen on though.
There needs to be something that is simple like QBasic where you can just start programming and have a crack at doing something fun.
The C=64, Atari ST, etc. all had decent BASICs and large communities.
GW-BASIC (no built-in help, incompatible with most library books, no real editor: hard for a kid to teach themselves from nothing)
-> QBasic (Help! Graphics programs that crashed didn't leave you in graphics mode! Proper editor!)
-> QuickBasic (bigger programs, compile to .exe)
-> Turbo Pascal (help, compile-time errors, programs ran fast in comparison, proper modular code, good editor (great in 6.0), advanced graphics (for the time) totally within reach, and that's where a lot of high-school lunch hours went).
Once Windows started to catch on, Visual Basic and Delphi (both had integrated help), then C++ (though I'd done some of that in DOS too, with Turbo C++).
Integrated help systems were almost essential before the internet, and Microsoft and Borland did them well.
I do agree that a lack of both, however, is crazy to think about. Yet I hired a developer not long ago who did basically that while shopping JCL Cobol for a student loans company.
Can also be a ward against the insecurity of unknown unknowns - where there's a lot of moving parts and the problem isn't well isolated (we'd all like it to be, but maybe previous developers didn't design the system like that) or the OS or one of your libraries is betraying you.
I think there's a kind of reverse Amdahl's law at work here. Situations where there is a nice clean crash into the debugger that tells you what's going on are easy - so they don't take up much time. Situations where that doesn't work take much longer - maybe the problem doesn't replicate when you're using the debugger. And there have been situations where simply doing the data-gathering to establish that a bug was real consumes weeks. My own personal one of those was missed touchscreen events; because they were so infrequent we eventually had to set up a robot to press the screen 10,000 times, resulting in 9,999 touch events, and record a huge amount of data up and down the stack in order to work out what had happened.
And I don't think it's heresy to say that many people just don't like the current crop of debuggers out there, especially when you write in dynamic (and weakly typed) languages. Which is another bunch of bananas, but sometimes we don't get to pick what code we write in, especially in my industry.
What I'm trying to say is, sometimes you need all the help you can get. And even an awful debugger is better than doing it in your head.
For third party libs I work with the vendor to unshit their shit. Or I switch, yes.
I write code that has to run out in BFE for 5-10 years. I can’t be sloppy about it.
Meh. BASIC-like languages are "clear and relatively foolproof", but not because of their syntax. The genuinely "clear" elements that they do have, such as the use of numeric labels, turn out to be poorly scalable, and the syntax itself also accretes all sorts of warts as it's extended beyond trivial functionality. Mostly, they are just simple enough that it is feasible to grok and fully internalize the functioning of the system as a whole, even for novices.
"Getting graphics onscreen quickly" came with the territory on MS-DOS systems. The basic hardware functionality was standardized and there was no multi-processing to step on your toes, so just set the graphics mode you want, call some pre-made drawing routines, and you're set.