The Golden Age of BASIC (2014) | Hacker News Reader

The Golden Age of BASIC (2014)

spectrum.ieee.org

69 pointssusam85 comments

Say what you will about BASIC, but it was (like Python) designed to be a programming language that beginners could learn in an afternoon and do something useful with. It was also compact, which made it scalable to support hundreds of users on a timesharing system, and small enough to fit on tiny, underpowered 8-bit systems and microcontrollers. BASIC, like Lisp, is also simple enough that it is easily implemented.

The computing era of the 1950s-1980s is interesting in that it was assumed as a matter of course that in order to get the most out of a computing system, users would write programs for it. As a result, the systems were fairly programmer-friendly and provided programming languages and instructions for using them in the box, including materials aimed at beginners.

Now that there are zillions of prefabricated apps that you can download almost instantly, there's a whole lot you can do with a computing system without ever touching a programming language. As a result, systems like macOS/iOS/Android/Windows are designed to create app and game users/customers rather than programmers or engineers - educational micro platforms like Raspberry Pi, Arduino, and micro:bit being notable exceptions, and Linux largely retains its programmer-oriented Unix heritage.

It's too bad, because JavaScript is included in every web browser, other languages like Python, Java and C++ are readily available for free on nearly every system, and even BASIC itself is still available from Microsoft in forms such as Visual BASIC, VBA, and SmallBasic. (And there are free and web implementations as well.)

What seems to be missing from iOS, Android, macOS, Windows, ChromeOS, and web browsers is an easy, visible, built-in onramp to programming. For example, Swift Playgrounds is neat, but I expect most iOS and Mac users don't know it exists, and would probably have little interest in it if they did.

I still don't get why Python is considered "easy to learn" as a first programming language, even to the point of coding professionally in it. There are many things about Python that are extremely obscure and that a complete novice can only really hope to work around clumsily, not deal with in a principled way. That's frankly a big turnoff even compared to archaic but somewhat simple and understandable systems, including BASIC.

I'm a heavy Python user, and have worked with a number of colleagues who have learned it as their first language in my group. And BASIC was my first language.

I think Python is easy to use as a scripting language thanks to the proliferation of libraries, meaning that you can get things done without touching the obscure stuff. Many users can be quite productive with precisely the subset of Python that's not too different from BASIC. Python adds features faster than I can learn them, and though I'm a productive user, I scored "average" on a skills test.

Very good points. My Python skills are such that I would be laughed out of a Python job interview for hilarious incompetence, but the small subset of the language I know and am comfortable with has allowed me to automate all sorts of tasks and saved me an enormous amount of time over the years. What I love about Python is the great spectrum of possibilities with it over quite a range of skill levels!

Where my skills lack are in areas that just aren't relevant to my work. The quiz had a lot of questions about the testing infrastructure. Whereas I use Python mostly in Jupyter notebooks, and for laboratory automation.

Still, I'm going to take a refresher course next year. I don't want to be the guy who's teaching Python without knowing it.

At basic linear scripting level it is pretty simple. Import stuff, write code, run it.

But when you get to structuring it whole thing feels quite hacky and weird in places. Like why do I have this empty file here(__init__.py). Or what is the whole point of this "__main__" thing. Two examples of most basics ways of building a more complicated program and both are quite weird.

When Python picked up that reputation it was considerably smaller, with the likes of Java and C++ as the most prominent competition. Also it's easy to think that newer fancier features added over time don't really matter for learnability, since the old style mostly still works; but they do matter some, since when you make a mistake, the interpreter doesn't know that you had no intention of straying from a simpler sublanguage.

Another thing to note is that in modern computing environments there’s infinite distractions. We’re always one click away from YouTube.

Back then, the screen was a playground one could poke and prod—without distraction, with a singular focus. This is especially important for children. Now we’re competing with the nearest iThing.

I always think of the parents who buy their children the latest-and-greatest toys, only to find their child is more interested in the box. Or perhaps a stick and some bugs in the back yard.

Another aspect was that the systems themselves were simple enough to fit in your head completely. Limited hardware, maybe a few special memory addresses or interrupts, and that was it.

If you could read from a keyboard, write to the screen, and load and save files, you could already do everything that almost any commercial software could do.

Going from that to more modern systems (even Windows 95) was a giant change. So many libraries, frameworks, and systems to know about. And you need to know them and work with them in order to create anything remotely like a commercial program. Your programs don't have full control of the entire system.

So yeah, there's a lot more stuff available now, lots of free languages and tools, etc. But it's also a whole lot harder to get into.

Also something that I wasn't aware, given the amount of interpreted based BASICs, and the compilers being mostly commercial, is that the original implementation had a very crude JIT implementation.

When typing stuff on Darthmound BASIC, the instructions would be compiled straight into machine code while on the REPL, just like Lisp and co.

When C, FORTH, Lisp and Pascal got special issues in Byte magazine what I noticed as a BASIC programmer was that all of them uses functions as an organizing principle. It wasn’t so clear to me the difference between languages like Lisp and FORTH where you could fully define new keywords and control structures and languages like C and Pascal where you can just define functions (that do what some of the keywords in BASIC might do.). It didn’t help that the C preprocessor cheats and lets you define ‘keywords’ with macros…

The BASIC dialects that most of us cut out teeth on (ZX Spectrum user here) would indeed have made Dijkstra weep, but they all had a single cardinal virtue that is unmatched by any of its successors - it was trivial to do simple graphics in them using the facilities of the language itself. This was the 'hook' for most of us, as graphs, animations but most importantly games could be dreamed up and implemented so easily. Were these mostly garbage with terrible performance? You bet they were. Did that matter? Not one bit. And, with growing experience and some POKEing you could salt in a bit of hand-assembled machine code to jazz things up, even if you lacked the inline assembler the fancy BBC micro kids had.

This topic comes up on HN from time to time and people often cite Javascript, Processing, Pygame and others as counterexamples, but none of these are remotely as accessible nor as simple to get going on as these crude BASICs were.

True, more languages should include a simple 2D canvas in their standard library. Even something totally unoptimized is better than having to hunt for basic game engines or a 3rd party SDL2 binding.

POKE isn't a "facility of the language" though, it's just a raw memory write. The modern equivalent would be using the lowest-level graphical API's.

Poke was a facility of the language - it was a keyword built right in. I was referring to using it to put a machine code routine into memory via BASIC, but yes you certainly could and did control screen memory directly using it, this was also very accessible because there was typically a fixed region of memory with a simple logic to its layout that made that direct connection and feedback available.

I don't know BASIC, but I would say Processing is very accessible. They tought it in my Middle School and I would say making games is trivially easy with it, even if it is more designed for animations than interactivity.

I would argue the problem is, back then, as a kid, you most probably had access to only one machine, and one PL. Now too many choices can make learning unfocused

My son dabbled with Scratch for a while, where you can conjure up multiple large full color sprites with minimal effort, even animate them, but pretty quickly lost interest in programming altogether.

Whereas when I entered "SET(1,1)" on a TRS80 model-I and got a single white pixel on the screen? That was some Magic, let me tell you.

Maybe the difference is that today it's harder to get the feedback between I-typed-this and that-happened, when there's already a whole lot of that happening all over the screen.

For a kid in 1980, there was a definite dopamine hit to be had from discovering the trail to High Technology, right there at your command. You could make Pong! Or Space Invaders! The possibilities were endless.

I think the real difference is that the excitement came from the technology being brand new. In the 80s this was the future. The future has been around a long time now, and that turns it into the past. Oldies such as us are quite into the past, but kids not so much. The generation before us, it was all electronics and radios.

Kids today want to make the kind of games they play. Except that’s not really possible of course. Roblox, youtube, that’s the kind of thing they can actually do _and_ is the future as they see it. Poor kids. Robotics is the edge I’m trying to push; better than that other crap at least.

The support for graphics depended a lot on the particular computer. The TRS-80 color computer had BASIC commands to draw lines, circles, and flood fills. Appleoft BASIC could draw lines. The C-64 had a great selection of block and line drawing characters you could type on the keyboard but you had to use PEEK and POKE to do dot addressable graphics. For that matter the C-64 had the best sound chip of any computer that that point but using it in BASIC was all PEEK and POKE.

If you had a C64, you had to have that book, The Programmer's Reference Guide. It was all in there. Still have mine here somewhere

It wasn't until the C128 came along that BASIC gave you more amenity than PEEK or POKE to access that GFX and sound but the capability of that system was better than any other computer of its era.

On the VIC20 you had to make the video chip change the address of the character ROM so part of it pointed to RAM. Then you alter that memory to change the pixels in a character (8x8). Then anywhere that character was drawn on screen the altered graphics would show. In order to draw graphics like a bitmap screen you had to use multiple characters in a grid like.

ABCDEF

GHIJKL

MNOPQR

Then you had to calculate the which character held which pixels and then alter the bytes inside that character to alter the exact pixel you wanted. So a pixel at 7,7 would be inside the A but a pixel at 10,10 would be inside the H.

The most widely used version of Basic which these platforms used does not have functions. This makes Basic programs tend to spaghetti and unreadable code, especially considering the constant memory constraints of those platforms. I grew up on these systems, and every time I think back on it I wish something like Forth would have taken its place – i.e. something with a clean and scalable pattern for abstraction. Basic, on the other hand, doesn't do abstractions. It barely has data types and what it calls “functions” are an even more limited form of Python's style of lambdas; every subset of code which can actually do something looks like “GOSUB 11600” when you call it. No naming, no abstractions, nothing. (No parameters or return values, only global variables.)

(This is in some ways even worse than assembler, which usually has labeled goto’s.)

When I programmed in Basic those many years ago, I was stalled when my programs reached a certain level of complexity. I was then mostly halted in my education and development as a programmer for many years, because the language did not make program composition easy. It was not until I had the opportunity to learn other languages with did have proper functions and other methods of program composition that I could break through the barrier, so to speak.

(Reportedly, BBC Basic on the BBC Micro did have proper named functions, and later versions of Basic like on the Atari ST and Amiga also had them. I believe that those versions of Basic would have been vastly more productive and taught people the usefulness of abstracting things as you go, building ever higher abstractions, etc. But this is never the version of Basic which people talk about, or used by all those listings in magazines, etc. These are, for all intents and purposes, not the “80s style Basic” which everybody remembers with such apparent and baffling fondness.)

(Mostly a repost of previous posts of mine, e.g. https://news.ycombinator.com/item?id=25014279)

Many BASICs of that era were limited to two significant characters for variable names, which made the code even less readable. There were some attempts at creating preprocessors that would take more readable code and turn it into something the interpreter could use, but at that point, you might as well go all the way with using a compiled language.

Dartmouth BASIC was compiled yet still had limited variable names for simplicity.

My game Empire started in BASIC, and was then ported to FORTRAN. You can still see the BASIC legacy in the code in the variable names like "Z6".

"My game Empire", he says offhandedly. :) Thanks for that--I fired it up about a year ago. Still fun!

I keep thinking I should upgrade its primitive neural network computer strategy with a modern one. I bet it would kick ass!

BASIC is a fine language as long as it fits on one screen (24 lines). No abstractions are needed for such short programs.

It's not just language abstractions or lack thereof, there was a really fundamental issue, that makes what you say true - at least if we're talking about line-numbered BASICs.

None of those early ones had a proper editor. It struck me sometime after leaving BASIC, that the whole line-numbering thing was really kind of a cheesy substitute for proper text editing. Given the limitations of the day, though, it was adequate. But relating to your point, once your program grew beyond a screen-full, you were stuck typing things like "LIST 300-399" several times a minute, just to look through your code. Today we just page-up/page-down w/o thinking, it doesn't break the flow just to navigate through a program, but in 1980, those line numbers were In Your Face!

For programs that fit on one screen, though, this wasn't such an issue. With something like the PET, you could even cursor around on the screen and change things almost like using Notepad.

BASIC also had to work with hardcopy terminals, like an ASR-33. Screen editors were way in the future!

This is simply not true.

The Basic compiler on DEC PDP’s had Function and Sub and modules you could swap in and out of memory as needed. PDP usage was huge in the 80’s. And Microsoft BASIC 7.1 was a full native compiler with the same language syntax.

The line number versions of BASIC were used for amateur code, but professional systems had full procedural syntax.

Normal people, which are the subject of the article, did not have DEC PDPs. Did any commonly used home computers of the time have Microsoft Basic 7.1?

There were far more people writing code on PDP's in companies than people writing BASIC on PC's at home in the 80's. You may not have known about it, but almost every college had one and there were hundreds of thousands of businesses that ran on PDP BASIC.

Those people are not what the article is about, though. The article is about kids, encountering Basic at home.

I know the article is about 80s BASICs, but QBASIC, first available in 91 and included free in MS-DOS 5.0 and higher, had named functions and subroutines.

Yes, and? Almost all later Basic implementations has those. As I wrote, even some 1980’s Basic implementations had them. But those were not the Basic implementations used by people who owned the popular home computers in the 1980s. And, as a result, it is not what people commonly think of as “Basic”. I feel I am repeating myself here.

QBASIC was free and included with the most popular OS on computers at the time, as IBM-compatible was unifying the hardware landscape and more people than ever were buying PCs. And, as a result, it is what people commonly think of as "Basic."

It’s what you think of as Basic. Young whippersnappers today! Think it all started in the 90s! GWBasic foreeeever…

QBASIC wasn't released until 1991, after the time this article is referring to.

People of a certain age came to computing via machines from Apple, Commodore, Radio Shack, Atari, Sinclair, Acorn and others in the late 1970s and into the 1980s. These people -- what we might call the first digital generation -- largely had to work with one or another version of Microsoft BASIC built into ROM, or the BASIC created by their computer's manufacturers. There were no compilers for kids learning on the machines they got for Christmas. The 90s and QBasic were somewhere in the future. That is what this article is about. There may have been more PDP-8 BASIC programmers than microcomputer BASIC programmers, but they're not what this article was about.

I’m not sure why you are replying to my post, since you seem to be agreeing with me.

I was intending to add my reply to the parent message. Sorry!

I remember a local high school when I was in elementary school having a PDP-8 which could be booted up in a single user or multi user mode to run BASIC that was not much better than a microcomputer BASIC.

I remember using BASIC-PLUS on a PDP-11 running RSTS which I think could manage 20 terminals but the PDP-11 has the serious limitation that user space had a 64k address space just like a micro. This was a line number oriented BASIC like a micro BASIC.

My high school had a VAX which also ran BASIC-PLUS but they taught intro programming with PASCAL and also had FORTRAN. I don’t remember that basic being procedurally oriented (other than GOSUB) but eventually DEC came out with VSI BASIC which let you write procedures and functions that you could link into libraries and call from other languages.

Everyone’s experience is different I guess. I started on Sinclair BASIC, which had no functions (apart from a mathematical DEF FN). The limitations of the language in terms of maximum complexity and speed prompted me to learn Z80 machine language, which also does not have named functions.

I didn’t find this lack of abstraction a hindrance. It actually helped when I moved on to C on a PC. So I don’t find the fondness for the limited 80s BASIC baffling at all.

You allude to it, but I want to highlight an exception:

GfA BASIC, widely used on the Atari ST in the late 1980’s, and later also available on Windows (with a compiler, even), didn’t suffer most of the limitations you mention. It was a great and modern (for the time) language.

See the screenshot on Wikipedia for an impression: https://en.wikipedia.org/wiki/GFA_BASIC

When I was coding on a TRS-80 Color Computer I was read a book that had type in source code for a preprocessor for the IBM PC that would let your write BASIC without line numbers and use control structures like WHILE loops instead of GOTO.

You would edit code with a text editor and transform it into a program you run with the normal interpreter.

I rewrote it for the CoCo which was not very hard because the syntax of BASIC is simple enough that you don’t really need to understand how compilers work to make something like that.

Not going to argue with your points, except to say that I think it was good and useful for a primary school aged level of understanding.

You could learn the entire language, every keyword, by heart. You could get to grips with all the various basic logic flows (if then else, while), understand variables, and you could get instant feedback (essential for the young kid). Scratch provides that learning place now, but basic was good for that first step into programming.

Fully agree that it was easy to outgrow it (at least until things like quickbasic came along).

My first programming language was BASIC in the 1970s.

When I learned C in the 1980s, programming with strings was always a mess and produced a rich bounty of bugs. When initially designing the D programming language, I resolved that D wouldn't be any good until D did strings as easy as BASIC did.

And so strings are easy and bug free in D, and have become a great strength of D. Thanks to BASIC!

BASIC uses garbage collection for its strings. But an ownership approach as found in Rust can give you strings that are almost as easy-to-use as BASIC's, without involving the complexity of a GC.

The early BASICs, on the TRS80, the PET 4032 and the like, were all dreadful, but they were the only game in town. All variables were globals, the nearest thing to a procedure call was the 'GOSUB', there were inexplicable hold overs from punch-card systems like the READ/DATA thing.

Those were the days of typing it in from a listing printed in a book or magazine. 16K of RAM was plenty, because any BASIC program more than 100 lines long was simply incomprehensible w/o some cheat sheet notes on the side.

About the most interesting thing that could be done with those machines was to learn the assembly language for the underlying processor. People said that assembly language was going extinct even in 1980, that it was a step backwards, but BASIC didn't seem to be the way forward, either.

Recalling fondly now the sheer delight of that first university class in Pascal.

BASIC was designed to be learned in an afternoon. Nothing wrong with Pascal, but it's drastically more complex to learn and to implement. The original BASIC user manual was just 23 pages long!

https://www.dartmouth.edu/basicfifty/basicmanual_1964.pdf

The goals on page 1 are particularly relevant: 1) easy to learn, 2) efficient/compiled, 3) stepping stone to more advanced languages (s/Algol/Pascal/), and 4) general purpose.

This simplicity paid off for early microcomputers and microcontrollers which could fit a BASIC interpreter, hardware drivers, and a user program into a few kilobytes of memory, creating a system that could run any of the programs in the above Dartmouth BASIC manual.

BASIC itself was written in Assembler, with the nearest thing to a procedure call was the 'JMP' instruction. It's amazing how any of such scale software was written in Assembler. See here https://github.com/microsoft/GW-BASIC

Most microprocessors include some sort of a procedure call and return instructions, such as CALL and RET on the 8080/Z-80/x86, as well as stack push and pop instructions.

RISC type processors can usually store the return address in a register and jump to an address stored in a register. On ARM you can also do an x86-like return with pop {pc}.

Many large programs such the first Unix kernel, and many video games, were written in assembly language.

My experience is that assembly language seems fine when you're writing it, but it's a pain when you go back some months later and try to read it. Good structure and comments help. I just read and wrote some RISC-V assembly language and it wasn't terrible, even though I'd never used RISC-V before. Writing assembly language makes you appreciate why (and how) programming languages exist.

yes, I just remembered! JMP is more like an if...then. There was a JSR (Jump to Sub Routine) instruction on the good old C64, good times!

Hal Finney (yes, that Hal) wrote a BASIC interpreter in a 2K EPROM in the 1970s. Quite an achievement!

That left no room for error messages. Hal proudly showed me his solution. It was one error message for all errors:

EH?

consuming only 3 bytes!

The 'Level I' BASIC in the TRS80 managed to distinguish three errors

    WHAT?
    HOW?
    SORRY

What a difference 4K made!

Interesting! Are the roms available on any emulator where I could try it?

Basic was better on the IBM PC and clones because you had BASICA or GWBASIC or QBASIC or QuickBasic or Turbo Basic. I had Turbo Assembler and the Microsoft Assembler, Turbo Pascal, Turbo C, etc.

These ranged from the same experience as the Beeb to full functioned text mode IDEs.

Visual Basic from the Win95 era might be the best scripting language to write desktop gui applications that there has ever been.

The most significant of these, the Commodore 64, had a social leveling effect as well. The Apple II and the IBM PC were essentially unaffordable for all but the well off. However, selling 10 million Commodore 64s at essentially 1/4-1/8 the price of the Apple II allowed a generation of working class kids to have upward mobility and real careers. Didn't hurt that in some ways the Commodore 64 was a better computer as well.

With the C64, you just knew what the machine was capable of, from the myriad games to be had, but the BASIC gave no direct support for any of that good stuff. The only graphics you could do from BASIC were the character cell glyphs (line segments, box corners, etc) like some kind of glorified color version of the PET. And forget about sound. Remember the first time you loaded a game that you had to RUN, and instead you did a LIST, only to see

    10 sys(2063)

.. or the like? Yeah, clearly there were Mysteries that needed solving!

It just begged you to use PEEK and POKE, to get at the real goodies. In a way this was an almost ideal precursor for learning assembly language; PEEK and POKE got you used to the idea of loading and storing things to memory or device registers, and then when you loaded up Jim Butterfield's SuperMon (thanks, Jim, wherever you are) and started banging around under the hood, heck, there were LDA and STA, ready and waiting. But a zillion times faster!

Or in my case, the VIC-20. My working class parents got one for me for Christmas in the early 80s. It introduced me to programming BASIC and assembly language at a young age, which formed the foundation of a career that has given me financial stability that they never had.

I grew up on DOS 6.22 and quick basic 4.5, so I have a huge amount of nostalgia for how low friction it was to start programming back in the day.

There's a scene in Stranger Things where Sean Astin's character tries to brute force a code using a basic variant, and it was surprising to me to see code on a popular TV show that was remarkably faithful to the original.

https://specularrealms.com/2021/04/21/strangest-things

Modern IDE's are finally approaching a "low friction" workflow with things like LSP and DAP, which are largely independent of the programming language. The intuitive UX of QuickBasic, VB-DOS, the Turbo series etc. however is still very compelling, in a way that has yet to be comprehensively ported to modern systems.

I liked BASIC not so much because of any particular programming constructs. I liked the large, varied community that formed around BASIC. All sorts of people were dabbling with BASIC at the time trying to code games, utilities, or maybe just noodling with graphics and sound as the potential of the 8-bit home computers was explored.

Yes there was a special magic in those early days of home computers.

There is so much more power and information available trivially now, but we have come to expect that.

Back then, if it wasn't in a written manual, there typically was no other source of information. But that didn't stop us! We simply had to tinker with it, reverse engineer it a bit. I think that was a big part of what made it special.

Imagine your family getting an early home computer, and finding a BASIC book in the pile.

Endless hours exploring that thing, typing commands, bending the computer to your will (and possibly learning some assembly along the way).

BASIC? Yeah, like the author and many in my generation I started with it as it came with the home computer and we kids didn't know any better. Once introduced to Pascal however, I didn't look back.

Until, I rekindled my interest in electronics more than 30 years later. Many of the affordable quality test and measurement instruments, read old ones, come with examples on how to control them via GPIB using BASIC (a variant of Rocky Mountain Basic afaiu). -hp- was big on BASIC. First their minis, then their 'calculators' and even the work stations. Those short examples in the manuals are easily translated into Python today, but sometimes I wished I had a RMB available for Linux.

Timex Sinclair 1000. Because it had graphical characters I was able to make animated shorts using basic. I recall one where a plane was going lower each time it crossed the screen until it hit the ground and there was a big multi-stage explosion followed by an gravestone rising up from the bottom. Good times.

The two books that came with a TI 99/4A:

https://archive.org/details/tibook_beginners-basic

https://archive.org/details/tibook_users-reference-guide

From BASIC, it gives you variables, control flow, keyboard reading, addressable character cell graphics with color and custom characters, and multi-voice sound. You can do a whole lot with that, and that was the book you opened when you plugged it into your TV and started figuring out what you could do with this thing. (I wanted to make video games, and I did.)

Around 1978, my dad brought me a blue book: 'introduction to BASIC' from Digital Equipment Corporation. He then _typed my programs_ for me into a DEC-20 at his office, and brought me the output to debug. Batch style programming with an interactive language! The other book that was instrumental in my downfall was 101 Basic Games, also published by DEC.

Later, in high school, we had a PDP-8 with DEC EDUsystem BASIC on it, later replaced with a small PDP-11. This was right around the time that Apple ][ and TRS-80 were just appearing on the scene. Until then, programs were entered on printing terminals like Teletypes, GE Terminet, and DECwriter II.

This is not that long ago, in a relative sense.

Another small BASIC story, mine (partial, because I also programmed in BASIC on other personal conputers, apart from the IBM PC Jr. mentioned in the posts below):

https://jugad2.blogspot.com/2012/09/lissajous-hippo.html

And a related HN comment by me that may be of interest because of the mTCP stack that Mike Brutman developed for the IBM PC Jr.:

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

Discussed at the time (of the article):

The Golden Age of Basic - https://news.ycombinator.com/item?id=7680045 - May 2014 (11 comments)

I am definitely from the Golden Age of Visual Basic.

Delphi

Yep, Visual Basic was very much under-appreciated. That, combined with a great IDE, Visual Forms, and a very decent compiler. Then .Net came and ruined a good thing.

When WinRT got released, I thought, they finally did it the right way.

AOT compilation, with managed languages on top of COM, in a sense bringing back VB 6, and an approximation of C++ Builder.

Then management messed it all up.

VB 6 was my 1st exposure for desktop programming (MSVC was harder). Then I met Delphi 6, and Lazarus.

These days, when I want to build cross platform desktop apps quickly, Lazarus is #1 choice.

P.S: I don't write desktop apps profesionally anymore, used to write a few in Java Swing and FX.

My first language I delved any time into was (Speccy's) BASIC. Despite now being very much a programming polyglot there's no real language I've sunk my teeth into that I outright dislike.

There's an exception. And that's the BASIC dialects. I don't have very much fondness for it, even calculating for nostalgia.

The first seventeen years of my career were PC Basic, DEC PDP/VAX Basic, and Visual Basic. I switched to C# and object-oriented programming in 2002. I still have MS Pro Basic code in production from ‘90.

I wouldn’t wish GOTO/GOSUB on anyone, but the latter procedural versions of BASIC were very productive tools.

DEC’s BASIC was a surprisingly capable language. It was what I wrote my first recursive code in. I remember being annoyed that you couldn’t do the same in AppleSoft.

MSX Basic home user here ;)

However, the big emphasis was on Logo in primary schools at my time.

Speaking of which, does anyone know of a MSX-Logo English version ROM available for download? Can only find it in Dutch...

Holy shit, BASIC that allowed inline assembly. So jealous.

I'm "reverse engineering" the BASIC source for Super Star Trek right now for a Rust port. Brings back memories, that's for sure.

I was 9 years old when I got the TRS-80 Colour Computer 2 and started with Basic, I had the Edasm+ assembler cartridge but was too young to understand how to program in assembler - or at least I didn't have a mentor that could explain how the computer actually worked, it was always a point of shame for me. During Covid I found a TRS80 emulator I wrote a simple scrolling road game (driving a car) and then put my mind to learning the CPU (6809), memory map and I/O for joysticks (and learning how to poll them). It was not difficult at all, and the sheer volume of books on the internet archive is awesome. I'd ported the simple BASIC program to assembler, used Edasm+ to assemble and was absolutely blown away by how much faster the program ran in machine code. Moreover, the sense of achievement I got on behalf of my 9-year-old self was one of the coolest things I've ever done... Basic programmers were lamers back in the day, and over a few days - learning assembly - I'd taken my first steps to dropping that title and the shame of my youth.

As a side note - AMOS on the Amiga was awesome, and PDS on DOS (with SVGA libraries) both me to start my first business when I was 15 (through-the-window real-estate listings). Even then the shame of being a basic programmer stayed with me, I would deliberately compress, use a 3rd party linker & hex edit the beginnings of compiled programs (on PC) to ensure nobody could work out that I was using compiled QBX (quick basic). I continued with VB, Blitz and the like until learning C# with Unity... then I felt the shame of not being able to do the equiv. of 80's assembler (shader programming).

Perhaps one day I'll get over myself and believe I'm not a lamer at heart :-)

I often think I was born a few years too late, things moved so quickly and I was a bit too young... TRS-80 -> Amstrad -> Amiga by the time I was 14 - and the Amiga was really complicated with it's custom chips.

Anyhow. Just a bit of a rant ;-) Thanks for reading.

p.s. Oh, just thought I'd add that I also played with RISCOS and BBC Basic during the period mentioned above and was blown away by how all the OS functions and so on were exposed to BBC basic, for me, this has always been the problem with Basic variants. Doing SVGA graphics on the PC with QBX required 3rd party libraries, proper TCP/IP under VB required IP/Works, and so on... back then I was always struggling - not with optimisation - but with access to features I needed that weren't offered through whatever dialect of basic I was using. BBC Basic on the other hand seems to be done right, I expect you could write any application you cared to without resorting to C or assembler.

Reply on news.ycombinator.com