TIOBE Index of programming languages

[nctnico]

Indices of popularity are marketing tools more so than anything else.
If your job is marketing development tools, then they are probably useful.

Yes and no. If you choose an obscure language for a project, then it will be hard to find people to work on the project. And thus making the project expensive to create and expensive to maintain. So there has to be a really, really, really good reason to choose that particular programming language. In that respect, an index of popular programming languages can help to make a good selection.

[Infraviolet]

"So there has to be a really, really, really good reason to choose that particular programming language"
If it is an obscure language yes, you'd ned very good reasons, but if it is any of the common languages then what you pick will be less a choice and more like something automatically determined by whether there's any existing library you particularly want to use (for example Fortran is still popular with X-ray astronomers specifically because someone wrote a bunch of x-ray spectrometry libraries for it, Python is good if you want to make use of Tensorflow for AI stuff or use stuff derived from Blender to handle 3d graphical functionality), or by what you're already most familiar with (and can thereby reuse sections of code and functions from things you've written before).

[tggzzz]

"So there has to be a really, really, really good reason to choose that particular programming language"
If it is an obscure language yes, you'd ned very good reasons, but if it is any of the common languages then what you pick will be less a choice and more like something automatically determined by whether there's any existing library you particularly want to use (for example Fortran is still popular with X-ray astronomers specifically because someone wrote a bunch of x-ray spectrometry libraries for it, Python is good if you want to make use of Tensorflow for AI stuff or use stuff derived from Blender to handle 3d graphical functionality), or by what you're already most familiar with (and can thereby reuse sections of code and functions from things you've written before).

Fortran is still popular with the high performance computing mob (who have been pushing hardware and software since the 50s!) because (1) the language predictably allows correct extreme optimisations on all sorts of hardware (2) solid numerical computation properties (3) lots of existing high quality libraries.

Of course, if you aren't concerned with speed or quality of numerical computation/results, then Fortran looks unappealing.

Similar things can be said, I believe, about statistical calculations and languages like R.

Then there's the high frequency trading mob, who like to code their trading algorithm business logic in hardware description languages.

[Picuino]

The Tiobe index is also a good excuse to comment on trends in programming languages, as Paul Jansen does.

This month is a good opportunity to talk about the decline of the C language in favor of other safer languages, such as Rust. So far Rust has managed to get into the linux kernel (quite an achievement) and, as far as we in electronics are concerned, we should be watching to see how it gets into the world of microcontrollers.

[Picuino]

The text also comments that, as embedded applications become larger and larger, c presents problems that can be solved with C++ object-oriented programming.

Here I think there is also a lot to talk about. I believe that a new programming language (C+) is missing. This new hypothetical language would be more powerful than C, but without reaching the many capabilities of C++, which also make it not very maintainable.

Linux Torvalds controversy about using C vs C++ in the Linux kernel:
https://medium.com/nerd-for-tech/linus-torvalds-c-is-really-a-terrible-language-2248b839bee3

[SiliconWizard]

Indices of popularity are marketing tools more so than anything else.
If your job is marketing development tools, then they are probably useful.

Yes and no. If you choose an obscure language for a project, then it will be hard to find people to work on the project. And thus making the project expensive to create and expensive to maintain. So there has to be a really, really, really good reason to choose that particular programming language. In that respect, an index of popular programming languages can help to make a good selection.

If you use TIOBE to pick a language for a serious project in a professional setting, you have a serious problem. Probably indicative of being an MBA guy rather than a tech lead.

[tggzzz]

Indices of popularity are marketing tools more so than anything else.
If your job is marketing development tools, then they are probably useful.

Yes and no. If you choose an obscure language for a project, then it will be hard to find people to work on the project. And thus making the project expensive to create and expensive to maintain. So there has to be a really, really, really good reason to choose that particular programming language. In that respect, an index of popular programming languages can help to make a good selection.

If you use TIOBE to pick a language for a serious project in a professional setting, you have a serious problem. Probably indicative of being an MBA guy rather than a tech lead.

Precisely.

[nctnico]

Indices of popularity are marketing tools more so than anything else.
If your job is marketing development tools, then they are probably useful.

Yes and no. If you choose an obscure language for a project, then it will be hard to find people to work on the project. And thus making the project expensive to create and expensive to maintain. So there has to be a really, really, really good reason to choose that particular programming language. In that respect, an index of popular programming languages can help to make a good selection.

If you use TIOBE to pick a language for a serious project in a professional setting, you have a serious problem. Probably indicative of being an MBA guy rather than a tech lead.

You can kick & scream all you want about keeping on using your favorite programming language and forcing that on other people but in the end you'll need several people to get a big software project going. At this moment it is easier to get 10 people who are proficient at Python compared to getting 10 people who are proficient with C. There is only so much a single person can do and you don't want to end up relying on a unicorn. In the end choosing a programming language is very much a logistics / human resource problem. Indexes like TIOBE but also looking at job offerings for various programming languages can show you what are easy languages to get people to code in and which are the harder ones to find people for. For sure there is a positive feedback loop going on where popularity of programming lanuages amplifies itself.

[nctnico]

The text also comments that, as embedded applications become larger and larger, c presents problems that can be solved with C++ object-oriented programming.

Here I think there is also a lot to talk about. I believe that a new programming language (C+) is missing. This new hypothetical language would be more powerful than C, but without reaching the many capabilities of C++, which also make it not very maintainable.

Linux Torvalds controversy about using C vs C++ in the Linux kernel:

I'd take anything Linus claims with a large shovel of salt. Fact is that most of the Linux kernel is object oriented and it is a mess due to overly using void pointers to all kinds of random structs. C++ would make the Linux kernel easier to maintain and a lot faster due to early binding. The way the Linux kernel is now means that going from a driver to user space, a chain of -give or take- 10 pointers (either data and function) needs to be walked through which can be espensive time wise due to cache misses. C++ can squash that chain of pointers into a much thinner layer and thus gaining a lot of speed. A while ago I rewrote such a piece of C code in C++ and the execution speed increased so much that I needed a delay loop counting to 350 to slow the new code down to the speed of the old code.

Then again, C++ may not be the ultimate answer for microcontroller use. Without the STL libraries C++ isn't worth much. Recently I've been working on a microcontroller project which uses Micropython to implement the high level logic. This actually works pretty good and Micropython is properly sandboxed which C++ is not.

[tggzzz]

The text also comments that, as embedded applications become larger and larger, c presents problems that can be solved with C++ object-oriented programming.

Here I think there is also a lot to talk about. I believe that a new programming language (C+) is missing. This new hypothetical language would be more powerful than C, but without reaching the many capabilities of C++, which also make it not very maintainable.

Linux Torvalds controversy about using C vs C++ in the Linux kernel:

I'd take anything Linus claims with a large shovel of salt. Fact is that most of the Linux kernel is object oriented and it is a mess due to overly using void pointers to all kinds of random structs. C++ would make the Linux kernel easier to maintain and a lot faster due to early binding. The way the Linux kernel is now means that going from a driver to user space, a chain of -give or take- 10 pointers (either data and function) needs to be walked through which can be espensive time wise due to cache misses. C++ can squash that chain of pointers into a much thinner layer and thus gaining a lot of speed. A while ago I rewrote such a piece of C code in C++ and the execution speed increased so much that I needed a delay loop counting to 350 to slow the new code down to the speed of the old code.

Then again, C++ may not be the ultimate answer for microcontroller use. Without the STL libraries C++ isn't worth much. Recently I've been working on a microcontroller project which uses Micropython to implement the high level logic. This actually works pretty good and Micropython is properly sandboxed which C++ is not.

I was writing (crudely) OOP code in C ~1984, i.e. before C++ appeared.

Even with STL libraries, C++ isn't worth much  You can write valid C++ programs that can never finish compiling - because as part of the compilation process the compiler emits the sequence of prime numbers. The people designing C++ templates refused to believe that, until Erwin Unruh rubbed their noses in it. That's a big red flag that Something is Very Wrong-headed There!

Using a decent HLL (i.e. not C nor C++) is a good pragmatic decision, provided that it is possible to design and maintain a sane split between hardware, C and the HLL.

[SiliconWizard]

You sure can write different levels of software in different languages, and often that makes sense. The idea of using the one programming language that will do it all and save the planet is like the quest for the unifying physics theory ("theory of everything"). It doesn't get very far but burns a lot of cash, and if you're on the receiving end, I guess that's not too shabby.

[radiolistener]

You can write valid C++ programs that can never finish compiling - because as part of the compilation process the compiler emits the sequence of prime numbers. The people designing C++ templates refused to believe that, until Erwin Unruh rubbed their noses in it. That's a big red flag that Something is Very Wrong-headed There!

this is interesting, can you show an example of such source code that will never finish compiling?

[tggzzz]

You can write valid C++ programs that can never finish compiling - because as part of the compilation process the compiler emits the sequence of prime numbers. The people designing C++ templates refused to believe that, until Erwin Unruh rubbed their noses in it. That's a big red flag that Something is Very Wrong-headed There!

this is interesting, can you show an example of such source code that will never finish compiling?

Search for "erwin unruh template metaprogramming". Various versions are widely discussed.

[golden_labels]

It’s worse than that. In a general case it’s undecidable whether a C++ source can be compiled.

Of course both statements, mine and tggzzz’s, are true only while ignoring memory limitations. In practice any compilation eventually runs out of memory, even if it’s theoretically terminating.

[SiliconWizard]

Curious to see if you can have the same kind of fun with Rust macros.

[brucehoult]

It’s worse than that. In a general case it’s undecidable whether a C++ source can be compiled.

Right. For example a template function can compute the "Hailstone number" [1] of some input. It is currently undecidable whether this will terminate.

On the other hand, you can also implement the Ackermann function, which will always terminate, but with even rather small arguments can take longer than the heat death of the universe to do so.

[1] take a number, n. If it is even divide it by two, if it is odd multiply it by three and add one. Repeat until you get one (which gives a cycle 1 -> 4 -> 2 -> 1). Does it always terminate? We don't know. No one has been able to prove it. All numbers actually tried have eventually terminated but some take a long time. For example, obviously a 2^N takes N steps to reach 1 e.g. 32 takes 5 steps. But 27 takes 111 steps!

[SiliconWizard]

Yep, but does it not just come from the fact that the template 'sub-language' is Turing-complete? Obviously you can write stuff that will never terminate. I'm sure you can with Rust macros as well or any other language that has compile-time functions.

Some compilers may restrict the time/number of iterations/stack depth/whatever to avoid endless compilation, but restricting that on a language level requires severly restricting what you can do with it.

Surely C++ templates are a monster, but even just a much simpler macro system with loops can get you infinite compile time. So, is that something really against it? I dunno.

[brucehoult]

Yep, but does it not just come from the fact that the template 'sub-language' is Turing-complete? Obviously you can write stuff that will never terminate.

Well, exactly, but the point is that C++ templates were not designed to be Turing-complete and that they were came as a complete surprise to the community and language committee when it was pointed out in 1994, five years after templates were introduced in CFront 2.0 and the Annotated Reference Manual in 1989.

I don't myself object to compile-time Turing completeness (and potential non-termination). What I object to is

1) having to do it using awful syntax and semantics compared to the base language, and

2) the performance being many orders of magnitude worse than implementing the same algorithm in the base language

This is something Lisp macros have had right for half a century, and if the Lisp implementation is JITed then so are the macros.

Historically, it has been generally much better engineering in the C/C++ world to have the build process compile and run some C code that processes some input file in a DSL and outputs C code that is then #included in some other C code.

Having the ability to indicate that certain functions can be used at compile time is good if they are compiled/JITed. Are they, in GCC/Clang? I don't know. I haven't actually followed that stuff.

[radiolistener]

Search for "erwin unruh template metaprogramming". Various versions are widely discussed.

it appears that these samples are not working with modern compilers, just not compilable. Is there any working example?

[tggzzz]

Yep, but does it not just come from the fact that the template 'sub-language' is Turing-complete? Obviously you can write stuff that will never terminate.

Well, exactly, but the point is that C++ templates were not designed to be Turing-complete and that they were came as a complete surprise to the community and language committee when it was pointed out in 1994, five years after templates were introduced in CFront 2.0 and the Annotated Reference Manual in 1989.

I don't myself object to compile-time Turing completeness (and potential non-termination). What I object to is

1) having to do it using awful syntax and semantics compared to the base language, and

2) the performance being many orders of magnitude worse than implementing the same algorithm in the base language

This is something Lisp macros have had right for half a century, and if the Lisp implementation is JITed then so are the macros.

Historically, it has been generally much better engineering in the C/C++ world to have the build process compile and run some C code that processes some input file in a DSL and outputs C code that is then #included in some other C code.

Having the ability to indicate that certain functions can be used at compile time is good if they are compiled/JITed. Are they, in GCC/Clang? I don't know. I haven't actually followed that stuff.

The key point is indeed that the C++ experts designing C++ templates initially refused to believe the templates were Turing complete. They only backed down when Erwin Unruh rubbed their noses in it. If the C++ experts don't understand what they are creating, what chance to mere mortals have? C++ becomes part of the problem, not part of the solution.

The point about LISP macros being better is a good example of the other problem with the C++ community for an unacceptably long time. They chose to be ignorant of what had been discovered over the decades in other languages and environments, and arrogantly asserted C++ was better. That lead them to re-invent many wheels, but make them elliptical. The committee's attitude was "throw in the kitchen sink and let developers (who are swimming in the swamp with alligators) sort it out". Part of the problem, not part of the solution.

An excellent counter-example was Gosling's 1996 Java Whitepaper. That explicitly took many concepts from other languages that had been proven in action, and practically and theoretically worked together harmoniously. Inharmonious concepts or concepts that had problems were deliberately omitted.

TL;DR: Gosling had wide experience and which lead to good taste. OTOH the C++ committee...

[tggzzz]

Search for "erwin unruh template metaprogramming". Various versions are widely discussed.

it appears that these samples are not working with modern compilers, just not compilable. Is there any working example?

I suspect you have glanced at a few references on StackOverflow, seen "does it work today?", and not looked further.

I haven't used C++ for half a lifetime, so I don't know the ways in which newer versions of the language are incompatible with older versions. N.B. the C++ committee traditionally trumpeted "backwards compatibility is vital".

[brucehoult]

Search for "erwin unruh template metaprogramming". Various versions are widely discussed.

it appears that these samples are not working with modern compilers, just not compilable. Is there any working example?

I suspect you have glanced at a few references on StackOverflow, seen "does it work today?", and not looked further.

I haven't used C++ for half a lifetime, so I don't know the ways in which newer versions of the language are incompatible with older versions. N.B. the C++ committee traditionally trumpeted "backwards compatibility is vital".

Glancing quickly at it, we're all running 64 bit desktop machines these days, while that old code is mixing int and void*. Just a thought.

[tggzzz]

Search for "erwin unruh template metaprogramming". Various versions are widely discussed.

it appears that these samples are not working with modern compilers, just not compilable. Is there any working example?

I suspect you have glanced at a few references on StackOverflow, seen "does it work today?", and not looked further.

I haven't used C++ for half a lifetime, so I don't know the ways in which newer versions of the language are incompatible with older versions. N.B. the C++ committee traditionally trumpeted "backwards compatibility is vital".

Glancing quickly at it, we're all running 64 bit desktop machines these days, while that old code is mixing int and void*. Just a thought.

Presumably such horrors are explicitly allowed (one way or another), so the "proven in the field" code still works. Mixing those was entertaining (from a distance) on the segmented '286. The c/c++ complier flags required really should be considered part of the source code, but that's another can of worms.

Some of the search results indicate that template metaprogramming is still used, and some think that's A Neat Trick. In that case, simple mods to Unruh's original ought to restore the capability of ensuring the compilation can never complete. Just a thought

[nctnico]

Yep, but does it not just come from the fact that the template 'sub-language' is Turing-complete? Obviously you can write stuff that will never terminate. I'm sure you can with Rust macros as well or any other language that has compile-time functions.

Some compilers may restrict the time/number of iterations/stack depth/whatever to avoid endless compilation, but restricting that on a language level requires severly restricting what you can do with it.

Surely C++ templates are a monster, but even just a much simpler macro system with loops can get you infinite compile time. So, is that something really against it? I dunno.

Agreed. Along the same line you can argue a car is useless because you can steer it into a solid piece of concrete/rock at full speed.

[radiolistener]

I remember in my youth I loved all sorts of tricks with C++ templates until I encountered an annoying bug where one trick worked differently on different compilers. Since then, I’ve avoided template trickery.