B# programming language

[SiliconWizard]

It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)

Other than assembly language, only 3 languages pass the test of time:  FORTRAN, COBOL and C.  Everything else is just a passing fad. 

FORTRAN 1957 - still used for scientific computing
COBOL 1959 - still used in banking
C 1972 - A newcomer but it seems to have staying power.  We’ll have to watch and see.

As I said in the Rust thread, it's interesting to try and understand why this is so, and why we have basically failed to design new languages with as much popularity (I would keep COBOL outside of it, as I guess it's mainly legacy stuff still running, and maintained, but I'm not sure there are a lot of new full developments in COBOL, whereas there clearly are in C and FORTRAN.)

Sure both C++ and Java look like candidates. But not quite IMO. There are many possible reasons why they won't be.

C++ has become a huge monster. Much too complex. Whereas it has gotten some traction for embedded development (although relatively little), it looks like the majority is running away from it, in favor of Java, Go, maybe now Rust... so its future is really unknown to me.

Java is suffering from other problems. One of them is fragmentation. Java is of course heavily tied to its runtime. Each new runtime environment version may break compatibility in various ways. It's a broken approach IMO as a language.

And sure there will always be languages that last in niche areas, such as Ada, or even more niche, Forth.

[rstofer]

It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)

Other than assembly language, only 3 languages pass the test of time:  FORTRAN, COBOL and C.  Everything else is just a passing fad. 

FORTRAN 1957 - still used for scientific computing
COBOL 1959 - still used in banking
C 1972 - A newcomer but it seems to have staying power.  We’ll have to watch and see.

As I said in the Rust thread, it's interesting to try and understand why this is so, and why we have basically failed to design new languages with as much popularity (I would keep COBOL outside of it, as I guess it's mainly legacy stuff still running, and maintained, but I'm not sure there are a lot of new full developments in COBOL, whereas there clearly are in C and FORTRAN.)

Sure both C++ and Java look like candidates. But not quite IMO. There are many possible reasons why they won't be.

C++ has become a huge monster. Much too complex. Whereas it has gotten some traction for embedded development (although relatively little), it looks like the majority is running away from it, in favor of Java, Go, maybe now Rust... so its future is really unknown to me.

Java is suffering from other problems. One of them is fragmentation. Java is of course heavily tied to its runtime. Each new runtime environment version may break compatibility in various ways. It's a broken approach IMO as a language.

And sure there will always be languages that last in niche areas, such as Ada, or even more niche, Forth.

I started with essentially Fortran IV and I can still use that simple style in Fortran 77 or Fortran 90.  If I don't want to use the new features, I'm not compelled to do so.  Similarly, there's nothing in C++ that prevents it from taking C code (I could be way wrong on this, I don't use C++).

I have always thought of the other OO languages as kind of an elitist deal.  See how smart we are?  We think we understand C++!  Good luck with that!

So, I like simple languages.  If I want a variable to exist, I don't mind declaring it and I don't see where polymorphism plays into embedded programming.  I suppose you could abstract a serial port, but why?  Setting up two ports, in the same C file, using common code with different register locations isn't too much to ask.  I really don't need a UART class to get the job done.

Science people (and aerospace, and math types) want a simple language that will allow them to play with equations.  There is clearly a lot of this being done in MATLAB and wxMAXIMA but a lot is still being done fast in Fortran.  The other day I was playing with Euler's Method for evaluating differential equations.  I did it with MATLAB using script code (a lot like Fortran without the declarations) and using the built-in ODE45 method.  But I also did it in Fortran just for giggles.  There is something satisfying about Fortran 77 under BSD Unix or the Photran package (up to Fortran 90) for Eclipse.  Oddly, all 4 methods got the same results!

I think people like, and want, simple languages.  Too many features lead to too much frustration and not much productivity.  We look back at K&R C and think it is rather Spartan.  Well, yes, it is!  But it was a nice language for creating Unix and that was the goal for the language.  I think the authors are amazed that it is still in use.  Dennis Ritchie passed away several years ago but apparently Brian Kernighan is still around.  He's only 4 years older than me so he must have been very young when we worked on C.  Smart guy!

Python actually might have a future.  It is a fairly simple language with a lot of packages for various classes of work.  The built-in data structures are useful without being overwhelming.  There are a lot of things to dislike but I'm gradually getting into using it.  Slowly...

So to the language inventors of the world:  Keep It Simple - Stupid!  The KISS principal.  Don't create the next DEBE language (Does Everything But Eat).

ETA:

Here's something cool:  The same Fortran IV code that will run on my FPGA reincarnation of the IBM 1130 will also run on F77 under 2.11BSD Unix on my PDP11 emulations (simh) and the Photron package (gfortran) under Eclipse on Windows 10.  That's pretty nice portability!

[SiliconWizard]

Similarly, there's nothing in C++ that prevents it from taking C code (I could be way wrong on this, I don't use C++).

Indeed, that's mostly wrong. C and C++ are definitely two different languages with a different set of rules.
Unless you write C that *complies* with C++ rules, it won't compile as C++. A typical C project would need a lot of adjustments to compile as C++. Not worth it.

So, I like simple languages.

Simple is good. Wirth agrees. As simple as possible, but not simpler!
Multiple inheritance, for instance, is a plague that many serious computer scientists have asked to avoid at all costs.
OO-programming is pretty old stuff actually. It became popular as a hype, but has existed long before it became popular. Unfortunately, the whole hype around it pushed the release of atrociously complex languages that went way too far to solve inexistent problems by creating new ones.

So to the language inventors of the world:  Keep It Simple - Stupid!  The KISS principal.  Don't create the next DEBE language (Does Everything But Eat).

Keeping things simple yet useful and consistent is a tough thing. That's been Wirth's battle for most of his life.

Popularity is a special beast as well. C has been popular because it's simple enough (thus simple to code for, and write compilers for...), does the job and has been well thought out. C++ became popular (even though maybe not as much) because it was the first language supporting OO paradigms that was at the same time almost as low-level and flexible as C (thus piggy-backing on C's merits). Java became popular mainly thanks to its "run anywhere" promise.

All in all, for a language to succeed, it has to solve problems that could not be solved before, or at least a lot less conveniently.
Many attempts at creating the next PL have failed mainly, IMO, because they didn't really solve anything that hadn't been solved already. Or because they were way too complex to handle. Or often both.

Some attempts should have had better luck though... but they were probably there either too early or too late.
Take a look at Modula-3 for instance. A serious look.

[rstofer]

I am a huge fan of Niklaus Wirth, particularly his Pascal project.  A lot of companies took his P4 compiler and built the interpreter and were off to the races.   UCSD Pascal looks suspiciously like P4.

I think his book "Algorithms + Data Structures = Programs" should be required reading.  Yes, it uses Pascal but that is less important than the lessons learned about the various algorithms.  There's even a tiny Pascal compiler in the back of the book.  Very limited but it demonstrates the clarity of the code.  Truly elegant!

As to Modula 2 and Oberon, the lack of a 'free' toolchain kept me away because I simply didn't need the languages even though they are truly elegant.  I like code that looks pretty and reads well.

There is an Oberon compiler for ARM and it isn't terribly overpriced and, in fact, is FREE for personal use.  I don't know why I'm not using it.  I just saw where it can do 'mbed' style drag and drop programming of certain boards.  That is terrific, no JTAG!  It also produces code that works with ST-Link.

https://www.astrobe.com/Cortex-M7/matrix.htm

Cortext M7, that's the new Teensy 4.0

I'll look at Modula 3 but I mostly write code for embedded systems.  I'll have to see if there is an ARM version.

[SiliconWizard]

As to Modula 2 and Oberon, the lack of a 'free' toolchain kept me away because I simply didn't need the languages even though they are truly elegant.  I like code that looks pretty and reads well.

Yes, that's the problem with most Wirth's languages after Pascal. The lack of available compilers.

There is an Oberon compiler for ARM and it isn't terribly overpriced and, in fact, is FREE for personal use.

Yes, Astrobe is interesting. I think the guy behind it actually worked with Wirth, if I'm not mistaken. A book was released about Oberon on ARM, before Astrobe became a product.
It supports the latest "version" of Oberon, Oberon-07.

If you're interested in Oberon, there are a couple open source Oberon to C translators. One which is still actively maintained is OBNC. I experimented a bit with it, and it's pretty nice.
Given that it produces C code, it should be doable to use it for embedded development. I've looked a bit at this actually.

I'll look at Modula 3 but I mostly write code for embedded systems.  I'll have to see if there is an ARM version.

The only thing you'll find is this I think: https://modula3.elegosoft.com/cm3/

[rstofer]

What I found amazing about Wirth's syntax diagrams and his P4 compiler was the correlation between the two.  The compiler block outline was derived exactly from the syntax diagrams.  In my view, the syntax diagrams are far superior to BNF or EBNF.  If you have all the diagrams, you can start writing a recursive descent compiler directly.

The ability to do this a predicated on a particular non-ambiguous grammar but that is not a limitation as the language clearly proves.

[SiliconWizard]

The ability to do this a predicated on a particular non-ambiguous grammar but that is not a limitation as the language clearly proves.

For simple parsing, a completely context-free grammar is required. Grammars of many languages, including C, are not context-free, so that makes parsers a hell to write with many context-dependent cases.

One fun example is the parsing of C types. Compare that to parsing Pascal (and all derivatives) types...
For some fun: https://cdecl.org/

Really, as much as I like C, I think Ritchie must have been high on some heavy stuff when designing the declaration of C types. That was the early seventies and all...