In defence of BASIC

[GoatFoam]

I don't have much love for BASIC from a language design point of view but it did get people writing code and that counts for a lot.

We had a generation of people who grew up knowing that computers weren't magic and could be bent to their will, and then we seemingly lost the knowledge again.

[grue]

We had a generation of people who grew up knowing that computers weren't magic and could be bent to their will, and then we seemingly lost the knowledge again.

This.

I've been learning C [very slowly] and I kind of feeling this again.

[noodles]

I don't have much love for BASIC from a language design point of view but it did get people writing code and that counts for a lot.

We had a generation of people who grew up knowing that computers weren't magic and could be bent to their will, and then we seemingly lost the knowledge again.

You can blame Java for that. If I was designing a programming course today, I would have to go with Basic for kids and C for teenagers/adults.
I would also encourage them to mess around with 8 bit machine code to actually understand how a processor works and so instinctively
program in a way that is as performance conscious as possible.

[tufty]

BASIC? C? * bit machine code? That's one of those "I wouldn't start from here, mate" things.

Yeah, we started on BASIC, mostly because we didn't have anything else. And most of us moved from BASIC to what was then mostly referred to "machine code" because BASIC was so goddamn horrible. C got popular because it was pretty much a portable "machine code". But it came with a significant number of the horrible problems that "machine code" brought. And we all know where that has gone. If you don't know where it's gone, go look at cve.org.

As for "understanding how the processor works" and "instinctively programming in a way that is performance conscious", that went away with the early 32 bit processors. You don't write performant or safe code for modern processors using 16 bit or 8 bit practices.

[Dio]

Sure. But then what's the alternative?

Everything out there is rubbish in some way or another: Python is awesome for the first couple of hours on a project but hardly usable for anything but scripts and toys, Rust might as well be Brainfuck for anyone who doesn't understand why all the hoops you need to jump through are useful and Java, well, no thanks.

(Unless the argument is that it really doesn't matter, and doing anything is better than nothing. That one I can get on board with).

[venusian]

The engineers who build bridges have been doing their thing for a good deal longer than software engineers. I'll feel inadequate once they have a unified bridge speccing, designing and building pipeline that never, ever fails.

But it's certainly true that software engineering tools are crap, especially for heterogeneous distributed systems i.e. anything on the web.

[noodles]

You disagree on C or learning 8 bit machine code but I notice you have nothing to propose as an alternative.

[Dio]

The engineers who build bridges have been doing their thing for a good deal longer than software engineers. I'll feel inadequate once they have a unified bridge speccing, designing and building pipeline that never, ever fails.

But it's certainly true that software engineering tools are crap, especially for heterogeneous distributed systems i.e. anything on the web.

We're not civil engineers. We don't have access to the same tools that they do. (Notably, safety margins - it's easy to over-construct in civil engineering; there's really no equivalent concept in software engineering, because individual items are a very binary right or wrong but enough right things still makes for a usable product, and so all products are at least slightly flawed).

A very small amount of software is built with safety in mind, but it is clearly ludicrous to apply those standards to all software, it's not affordable.

A better comparison for software engineering is military engineering. It's a discipline where safety is still critical but enough good things make the result acceptable.

[tufty]

Sure. But then what's the alternative?

That's a very good question, and one I didn't cover.

I would suggest that students are taught not one language, or two, but a multitude of them. You're not learning to program C, or BASIC, but you're learning to program.

Python is horrible, but it has its uses, one of which would be to learn about the absolute (if you'll permit the pun) basic constructs of programming. Comparisons, branching, mathematical precedence. A machine language of some description (although a modern one) to look at the low level representation of data, and in passing to look at what happens fundamentally when you do branching and those mathematical operations. A functional language to look at the ideas of what functions are, scope of state, recursion (tail and otherwise), mutation of global state vs non-mutating code. Several object oriented languages using different paradigms to look at state and functional encapsulation. Relational databases at the same time (or before) to cover Codd and data modelling. There's a need for something that actively exposes multi-threaded and / or multi-processor code, not sure about that. A lisp-like to go through interpreting vs compiling, basically going through SICP or LiSP.

That covers a multitude of sins, from syntax to concepts, and none of it is 8 bit.

[Dio]

Right. But C++ has a purpose in that.

(Indeed, it seems to be roughly the curriculum of the lad's CS A-level. Which is surprisingly comprehensive.)

[tufty]

C++, yeah, maybe. But again, that only covers a small part of what I'm talking about. And I'd use it as a cautionary tale; it has all the horrors of design by accretion built on a horribly unsafe base. It's like a more performant PHP. If you want to cover the OO approach used in C++, there's a bunch of other languages to get that across without having to deal with al the other bits. C# or Java would be my preference, and I don't like them much either.

I missed Go for the multithreaded stuff above, it's pretty solid for that.

[noodles]

I would suggest that students are taught not one language, or two, but a multitude of them.

All at the same time ? For beginners ? Or A-level students ? I don't think so.
You've described a multi-year university-level course on programming, not an introduction to programming for the younger ones.
Learning by doing stuff (the spirit of BASIC) means learning one chosen language first and then moving on since no one language is perfect.

[skab]

I just remembered, back in my days (feels like 100 years ago) in something like 9th grade there was a optional/voluntary computer/programming class, and there they taught LOGO on Apple IIs.

This is another simple, easy, and very visual language (the turtle!). And it's a functional, list-based language, so quite different from the usual BASIC, C, Java line of thought.

Later on, from 11th grade on we got Pascal on DOS PCs. Another made-for-education language and actually quite nice as a beginner's language.

In my university days the language of choice wasn't that different, it was Modula-2. They unis all later switched to Java, and that's where all those crap programmers of today learned their "chops".

But what took me completely off-guard was a course on the curriculum further down the line: Programming in PL/I. Who the fuck thought that would be a useful skill in the mid-90s?

[Little stoned kiwi]

This person uses Arch, btw.

[KlaxonCow]

I agree with tufty that programming languages don't actually matter.

It's the concepts - the algorithms, the thought process, etc. - that actually defines programming, and the programming language is just the tool you use to get there.

I needed to export some geometry from Blender in my own particular format for loading into my little OpenGL game engine I was messing with, and Blender uses Python for scripting. So I looked up the syntax and the API, and had something working by the end of the evening, though I'd never touched Python before.

But this is just because I've used so many programming languages, on different platforms, that I don't really care about them anymore. Like, I'm playing with the mess that's HTML / CSS / JavaScript by day, in my job. Add PHP for when I make websites as a side hustle. Play with C / C++ on my own time - and, as mentioned, needed to learn Python well enough to make an extension as part of that. I also sometimes have to make tools and I'll use Qt for that, because you can throw a UI together quickly in that.

I'd actually agree that this is really what you should aim for: Using so many programming languages, on so many different platforms, and switching between them that you no longer care one iota. Sure, I know certain things way better than I do others. But if you say "this has to be done in Pascal on a microcontroller" or whatever then, okay, that's what I've got to use today, it seems.

Honestly, most of programming is looking up library or API calls - whatever the programming language - as you're usually coding to something in particular or within some kind of framework. That, in my experience, dominates things far more than programming language does.

But that, in a sense, is C's insight. Its deliberate design decision to externalise pretty much everything but the minimal basics, and off-load it from the language.

It does not attempt to bring everything inside the language. To have a billion built-in features. All that stuff should be coming from the OS, or the libraries, or the API or whatever.

And C fits that mentality - it's barely more than "portable assembly", letting you make function calls (and most of those function calls, whatever language you're using, tend to be C function calls because it set a basic standard that everything could use) and then the very basic ALU stuff. Arithmetic, conditionals, binary operations and not much else.

That's deliberate. It's laid out in K&R's "The C Programming Language" that this is the case. They note that C doesn't have garbage collection or any built-in fancy composite objects or anything like that. It's not a mistake or an omission. It's left out because they believe that it's not the language's responsibility to do that.

If you want garbage collection, then there's libraries for that. If you want memory safety, then you can wrap a pointer, overload the index operator and so forth to create that in C++ (or use a library that's already doing this stuff). But, equally, if it's not necessary, then don't.

This is what recommends C. Why it's the OG and pretty much everything post-C is "C syntax" or robs its ideas wholesale. It does exactly what it needs to do, and no more than that.

And let's be frank that Java, JavaScript, PHP, C++, C#, Objective-C, Go and a ton of other languages are just variants of C. Different people's attempts to update and modernise C, fixing some of its "flaws". Even those languages that are not overtly "C syntax" are still usually stealing its ideas wholesale - every language that has include files, packages, separates its libraries from its language and such are all copying C's precedent, but are just trying to do it a little bit better and neater.

Like, even if you never code a single line in anger for any reason, every coder really ought to mess and learn with some kind of assembly language and C.

I know, I know. "Folks don't really need to know how the machine actually works anymore, because compilers are so amazing, hardware's so amazing, et cetera, et cetera". But I'd say "yes and no". Yes, anyone can throw something functional together without giving a shit about the underlying system. But, no, the person who does understand the underlying system (and takes advantage of it) will do a better job of it, as they'll naturally lay it out in a way that suits the machine, so it's better and faster.

Like, a human being can always be as good as or better than any compiler. Because the human can use the compiler, so they can't do a worse job of it. But if they have a higher level insight - an optimisation, which can often be higher level than the code itself, so the machine cannot see it - then they might be able to do better, by laying it out in a more appropriate manner. And that's a "by definition" kind of thing - the human can always use the compiler, so they can't ever do worse than it, because they can always just use the compiler output.

I also think it's important to differentiate between the fact that, in practice, I'm using a compiler and I'm using this framework and I'm not messing around with optimising it to the nth degree because I have a deadline, and what, in an ideal world where money and time are no obstacle, would be the truly optimal thing to do.

I don't disagree. In practice, to earn my wage, I'm throwing some shit together with JavaScript and PHP - which are often awful - just to get shit done by next week.

And you have to do that because time and money are not infinite. You can't be a perfectionist, doing everything optimally, because reality doesn't afford you the luxury.

But I feel it's real important to differentiate that from any notions that this is actually optimal. That less knowledge somewhat could ever beat more knowledge. That the programming language that lets you dodge most of the fine details, in the interests of speeding you along, is "better".

What I don't like is the attempt to justify what industry does as if that's perfect and optimal when, no, that's just pragmatic. Because we don't have the money and time for perfect and optimal, so we take shortcuts.

But they are shortcuts. They are sub-optimal for that.

Like, due to an economic crisis, the company has to cut jobs to stay afloat. That's just pragmatic. What I would object to is some kind of jargonistic bollocks from HR or marketing (who are, let's be clear, the "psychological manipulation department" of any company) trying to pretend that sacking people is somehow a good thing. No, it's a bad thing. But sometimes a pragmatic necessary evil to afford continued survival.

Making cuts is bad for the business itself as well. Because, sure, you can comfort yourself with the savings made - but you are also cutting the company's capacity. For example, if - as a bus company - you cut half the buses on your routes then, sure, you're saving all that money on the buses and the wages of the drivers. But your bus company literally can only now carry half as many people - sell half as many tickets, maximum - which is actually limiting your maximum capability to make profits. It's not actually "good" for the company either, but it's often the only thing you can do, so it has to be done.

You might well have to do it. But swallow the reality pill that it's a compromise. It's not "good", but just an unwanted "necessary evil" that's required. Don't try to fool yourself, or others, that this is somehow a great idea or "optimal" or even desirable. Invent fancy jargon and pretend it's all happiness and rainbows, and what every organisation should aim for.

Nope, it's just pragmatic. That's all.