In the 80s home computers shipped with a programming language as their OS (BASIC language to be precise) - today the browser dev tools are the closest equivalent. You can use them on any PC with no additional software - wished it was made more obvious so everyone could experiment with programming like those of us who got their first computer experience 25-30 years ago could do.
But if you have internet access then you can get almost any dev tool and documentation, but if you don't have access then you probably don't have Chrome or Firefox, and even if you have the browser, it has no offline documentation.
The 80s was different because internet access wasn't so widespread.
>, but if you don't have access then you probably don't have Chrome or Firefox, and even if you have the browser,
Not sure why your reply is framed in terms of Chrome & Firefox.
If one buys a Mac laptop with no intention of connecting it to the internet, the preinstalled OSX will include the Safari web browser which has the Web Inspector tool.
If one buys a Windows pc that will never connect to the internet, it will include Internet Explorer which has the F12 Developer Tools.
The web browser (regardless of flavor) dev tools is still the closest equivalent we have today to the BASIC that was preinstalled in the ROM of 1980s home computers.
> it has no offline documentation.
The BASIC included with Commodore 64 and IBM PC also didn't include offline documentation (in the sense of copying MSDN doc library from DVDs on to local harddrive). Unless you meant "offline" such as the spiral bound hardcopies that came with the 1980s computer. Yes it's true that one can't go to Barnes & Noble to buy a "Web Browser Dev Tools 2016 for Dummies". On the other hand, the dev tools change so quickly that no publisher would find it profitable to sell books that would be out of date before it hits the physical shelves.
The dev tools built into browsers also tend to be rather bloated and sluggish; opening Firefox's debugger on my 2010 Core2 Duo laptop pegs the firefox process at 40% CPU just idling. Scrolling is painful.
Passable for making a quick change to test an idea but I wouldn't use it as an introduction to an IDE.
Then again I suppose I should be grateful it runs at all; Servo browser won't start because it requires a certain level of OpenGL support from the chipset. That makes me worry about the future hardware requirements of browsers and is another reason for splitting dev tools off from the client UI.
> The dev tools built into browsers also tend to be rather bloated and sluggish
> Scrolling is painful.
> Passable for making a quick change to test an idea but I wouldn't use it as an introduction to an IDE.
I have the same experience, albeit in Chrome. Using it on "about: blank" and restricting yourself entirely to the console helps (e.g. no debugger, not using the feature described in OP, etc). But at that point it's just a REPL, not an IDE.
The browser has always been the one of the easiest ways of tinkering with programming, but these days our browsers come with sophisticated developer tools unlike anything else installed on an average person's PC.
Back when I didn't know anything about compilers I wanted to write 'C++' but didn't understand how I could produce an executable, I instead saved html and js into folder and loaded them up in the browser -- and any changes were visible on refresh.
And actually, these days this tinkering doesn't even have to take place locally. With sites like jsfiddle, anyone can develop remotely while still being able to debug the execution from the browser.
2000s: Computers come with a web browser that can run JS
2010s: Computers come with a web browser that can run JS and has some other tools
But what was available in the early 1990s, when IBM-compatible PCs had become cheap enough to have at home, but ~everyone ran DOS+Windows? I don't remember there being any way (unless you count BAT files) to easily get started writing programs.
For those who got their first taste of programming in the 90s, what language and compiler/IDE did you use?
Thanks for mentioning QB64. While I haven't tried it out (yet), having an integrated IDE and DOS emulation does sound pretty cool for nostalgia!
Personally, many many years ago when I was fed up with QB's limitations, first versions of FreeBasic[1] were published and I made the switch. I haven't been following its development closely for some years now, but it seems the language has come a long way since then, e.g. supporting OO. It still can be told to behave QB-compatible, though. Maybe this is interesting for anyone looking for an open, more modern implementation of Basic.
I don't remember there being any way (unless you count BAT files) to easily get started writing programs.
The DEBUG utility would let you write small utilities in Asm, and PC magazines would publish source code listings in a format suitable for use with it --- the assembler had no labels so any address calculations needed to be done manually, but IMHO that just made it easier for people to see how "code" and "data" are really the same thing interpreted in different ways. It was limited to producing "flat binary" COM files up to 64K in size, but you quickly realise that when using Asm, 64K is a lot of code and a lot of interesting things can be done with far less; most of these utilities were in the hundreds of bytes to single-digit-kilobytes range.
Compare that with today when a compiled "Hello world" binary in C is already larger than the majority of the utilities supplied with MS-DOS...
Visual basic for applications (VBA) was really useful for making very basic stuff, like putting code into spreadsheets. Unfortunately you couldn't write a standalone program from it that has an independent ui. But as a high school student, it was good enough as a tool to by pass the security put on the school labs,e.g, you can launch programs on a CD ROM. I remember the fun times where bunch of friends were able to play age of empires LAN games, even though the computers were locked down.
Not true , 80s OS language for home computers was 100% Assembly, z80 assembly to exact. Basic was provided as an easy to use scripting language. Modern web tools and languages and frameworks are bloated and fragmented. Actually the only thing that keeps the 80s nostalgia is modern implementations of Smalltalk if you come from Amiga , or lisp if you come from command line CP/M OS. Web Dev is a huge pile of mess and I am surprised how you consider anything but the exact opposite of the 80s home computers.
I think what Kyriakos means is, the Basic environment was how you operated the machine. On my Amstrad CPC, if I wanted to see what was on a disc, I'd use the Basic command CAT. I wouldn't type "dir" or "ls" into a command line or click on a folder icon. If I wanted to run a program, I'd have to type a Basic command.
I use Chrome dev tools as a general coding environment all the time. I have a blank HTML page on my computer which loads jQuery and few other things, and I just load it up and open the dev tools. I have a bunch of snippets for generating Java boilerplate for work(!), transforming various things into JSON, etc. etc. It just sort of evolved over time into my personal coding environment. Of course I'd rather have something like the Symbolics Lisp machine:) but it's a fun little system.
Seriouly, does EVERYONE need dev tools in their browsers? As a casual web-developer, I use it quite often. It is questionable for most people if they are using the dev tools in Chrome or Firefox. Not to mention when someone accidentally press F12, something scary for them will appear. Personally thining, Making dev tools as an add-on would be more appropriate.
I, for one, like being able to answer someone when they ask me "why doesn't this work?", and I fire up the console and see what happened.
Given that error handling is left completely up to the client application (the web page), I think it makes sense to include tools to see what's going on, not in the least if you suspect the application is doing something malicious (just reload and check the network log).
The browser really is a lot like its own OS, and in this context the developer tools are more analogous to strace or dmesg than gcc, I would argue.
