I wrote a B compiler: https://github.com/aap/b it generates the original threaded code and has a runtime for amd64, mips32 and riscv64. should get the pdp-11 one working too sometime... Documented the original pdp-7 and pdp-11 implementations here: http://squoze.net/B/

Is this some kind of C--? scnr

I don't know what scnr means, but yes, B is literally `C--` as you put it.

Basically B was based on BCPL, a really early systems language. Then B was rewritten as C. The next iteration of C was called C++ as a joke because it's C plus 1. Though there has since been another language created as an evolution of C called D

From what I gather, B never really got much use outside of Bell Labs. But I might have missed some reports on other people using it.

And BCPL was a cut down version of CPL: https://en.wikipedia.org/wiki/CPL_(programming_language)

Actually designed for Bootstraping CPL.

Lots of interesting details here: http://www.cl.cam.ac.uk/~mr10/cpl2bcpl.pdf

> I don't know what scnr means

Wiktionary tells me it stands for "sorry, could not resist".

https://de.wiktionary.org/wiki/SCNR

Apparently AberMUD (way before my time but developed in Aberystwyth where I was a student) was written in B.

You can kinda see where C's weird i[a] notation for arrays came from, and even why.

What I find interesting is that B uses * for escaping and special characters, eg

  putchar("New line: *n")
  putchar("Escaped double quotes: *"")

The * escape comes directly from BCPL

Pointer variables in C are declared in an odd way, as `int (*a)` rather than `(int*) a`. I suspect this is also due to B's legacy.

In B everything was an integer, and there was no separate pointer type. It had only pointer operators that could be applied to any integer.

Declarators (the name along with pointer, array, etc annotations) in C are written parallel to how they are used, I have always assumed this was to make defining/explaining the language simpler (even though it often defies new learner's expectations), and maybe to reduce the amount of required logic in the compiler.

I think you're right that B is related to this, the reason the brackets were on the right of the name is because no type was mentioned in B (as there was only one type). If types had been named in declarations they probably would have preferred to do what Java does, i.e. `Type[] name`.

The other more archaic reason the brackets are on the right is because in the oldest B compilers the brackets were not there at all, instead when declaring 'local' (auto) vectors you just write the length of the vector after its name, like `auto name 8;` would declare a vector length 8 called 'name'. Once again this syntax makes sense without the type.

In B, declarators had not really matured yet, in some situations you could declare a vector with brackets similar to C arrays, but only of one dimension (which I think is why they were called vectors and not arrays).

One thing that I've noticed when digging into historical programming languages of that time period, is that many of them didn't really treat arrays as a type, but rather as some kind of variable modifier - and then putting the brackets after the variable name makes perfect sense. Notably, Algol-60, the granddaddy of all the C-like languages, already had this syntax:

   begin
      integer x[1:42];
      ...
   end

I like how constrained the language was:

> All arithmetic in B is integer, unless special functions are written. There is no equivalent of the Fortran IJKLMN convention, no floating point, no data types, no type conversions, and no type checking. Users of double-precision complex will have to fend for themselves. (But see ->32 for how to call Fortran subroutines.)

I wonder if it would have been beneficial to continue with this separation. Fortran and C started trying to do everything and they failed. Fortran was never a contender for C for systems programming, and C has not moved in the right direction to be better than Fortran for numerical computing.

>Fortran and C started trying to do everything and they failed

You have an interesting definition of failure.

Fortran has never been used seriously for systems programming. It got text processing capabilities and a ton of other stuff, but we do not see operating systems or web servers written in Fortran.

And C got the floating point operations B did not have, and was actually used for lots of numerical work for a while (and it still is, up to some point), but nobody was totally happy with it so we got C++, new Fortran versions, Python, now Julia... Although it always is an option due to the availability and quality of C compilers, I would not say that C succeeded in becoming the language of choice for scientific computing.

Of course, this does not mean that C or Fortran are failures.

There was at least one operating system programmed in Fortran:

https://en.wikipedia.org/wiki/PRIMOS

There's probably one written in Brainfuck too, doesn't mean it matters in the grand scheme of things though.

So, "at least one operating system programmed in Fortran" doesn't counter "Fortran hasn't been really used for systems programming", if that operating system is some irrelevant research project, or (as in here) a commercial niche system, that maybe ever reached 0.00001% of the OS users space.

Thanks for the info. I did not know this, but it does not surprise me. I am sure there are similar examples.

The first section of the linked article says that Fortran "was an odd choice from a pure computer science standpoint", that they "developed hardware optimized to run FORTRAN", and that large parts of the OS (in particular, the kernel) were eventually rewritten in other languages.

This is, in my opinion, a great example of how Fortran could not compete with C as a systems programming language.

Fortran is not designed to be a systems programming language and you can tell because it lacks the concept of memory address (hardware has been designed to operate by flipping bits at memory addresses for longer than I can remember). Fortran is a higher level language for describing computations on data.

Fortran is NOT a systems programming language. It is a niche language for scientific computing and why it is called (mathematical) Formula Translator (a.k.a Fortran).

Fortran-90 is well constrained for numerical programming and has so much inertia in the scientific community, it’s probably not going away. But C and its derivatives are good enough at numeric work for most users outside of science. Many have tried to dislodge both C and Fortran from their positions, with varying levels of success. Maybe we’ll see it in the next decade as scientists who knew how to code before university dominate and no longer want to use Fortran.

Having learned to code and getting a degree before going to get a job at a shop that had a ton of Fortran floating around, I'd say I grew to appreciate how direct it was for just doing math. And after working at later jobs where the scientists were allowed to write code in more expansive expressive languages than just Fortran, I really came to appreciate how Fortran enabled scientists to do science in such a way that they did not write unholy abominations of python code.

You are absolutely right. To be honest, the current situation is not too different from this hypothetical case. Fortran is used mostly to write numeric routines and then we call them from a Python script, instead of writing text and arguments processing (for example) directly from Fortran. But I still find interesting thinking about where these languages would be if these limits had been consistently respected.

The language it was based on (BCPL), was originally designed to Bootstrap CPL and that was it, it is an historical accident that it got other purposes.