EEVblog® Electronics Community Forum
Products => Computers => Programming => Topic started by: Picuino on June 11, 2024, 01:12:22 pm
-
TIOBE Index (https://www.tiobe.com/tiobe-index/)
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular web sites Google, Amazon, Wikipedia, Bing and more than 20 others are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. The definition of the TIOBE index can be found here (https://www.tiobe.com/tiobe-index/programminglanguages_definition).
June 2024 Headline: C++ surpasses C for the first time in history
C++ is the new number 2 in the TIOBE index. Originally, dubbed as the better and object-oriented version of C, it took C++ 39 years after its inception to beat C's popularity. C++ has never been that high in the TIOBE index, whereas C has never been that low. C++ started a new life as of 2011 with its consistent 3 yearly updates. Although most compilers and most engineers can't take up with this pace, it is considered a success to see the language evolve. The main strenghts of C++ are its performance and scalability. Its downside is its many ways to get things done, i.e. its rich idiom of features, which is caused by its long history and aim for backward compatibility. C++ is heavily used in embedded systems, game development and financial trading software, just to name a few domains. Other highlights of the TIOBE index this month are Go, which is at position #7 for the first time, and Rust with an all time high at position #17. --Paul Jansen CEO TIOBE Software
-
People love things looking sciencey and rationalistic. Without ever considering, if they make any sense.
I point everybody’s attention to position 16 on that list.
-
At what age did you start programming and with what language?
In my case 12 / BASIC and I wish it had been Scratch instead of BASIC.
-
I'm please to see that after 60 years COBOL is still rising in popularity.
More seriously, its interesting that it still scores more than 10% of the score for Java.
-
Not sure, if I understand the intentions of Picuino’s question right. So for now I will answer that directly.
Hard to tell, but certainly(1) before turning 12. My first steps were in DOS Batch. Then a very short period of VBA, followed by VB6. VB6 was also the first language I used to earn money (around 2002). I recall that was a pretty sudden change: just like 2–3 years earlier I was afraid of computers. Almost cried after closing Program Manager in Windows 3.11 (https://en.wikipedia.org/wiki/Program_Manager), thinking I broke the computer and my mother will have to pay for it. Then I discovered I can edit savegames and strings in games on my father’s computer, and got hooked instantly. The first programs were launchers for games using BE.EXE (https://en.wikipedia.org/wiki/Batch_Enhancer).
(1) I was expelled from school in 5th grade, which corresponds to 1997. At that point I was already programming and I’m from 1985.
-
It is strange that a language ‘for children’ is in 16th place and this might seem to detract from the credibility of the ranking. But... Scratch is a great language for kids to learn programming. It has concepts of imperative programming, subroutines, variables, event-driven programming, parallel (concurrent) programming, and so on.
We won't be able to make very serious programs with scratch, but we will be able to do something very important: learn easily. I really like that Scratch is in 16th place in popularity.
Now I use Scratch to teach programming to my students, but I wish I could have had that language at my disposal to learn programming when I was young.
-
This index is all about "popularity" in the "what people search online" sense. So the list is neither surprising, nor indicative of particular usefulness or even relevance, especially in the professional world.
-
Who decided that COBOL gets a dinosaur as its icon? That's just mean! I'm happy to see it coming back, I may end up doing it. Pretty surprising to see Ruby so high, or to see Kotlin so far below Swift. I would have guessed the latter two to be reversed.
-
It is strange that a language ‘for children’ is in 16th place and this might seem to detract from the credibility of the ranking.
I appreciate TIOBE for providing the index. I do, because I love when organizations can take a lighthearted approach, have fun, and aren’t focused on optimizing system down to the last penny. But too often I see TIOBE Index discussed as something serious, of real value, providing deep insight.
One may create any ranking they wish. But it’s not neccessarily useful. Nor represents what people assume it does. TIOBE Index at least reveals their methodology. Which I count as a huge advantage. Most rankings just claim the use of Expert Magic Dust™. Unfortunately even most openly explained and perfectly calculated ranking may not represent anything of use. Worse, if it resembles useful data until one looks closely. It’s like looking at a smortnet-generated image or PR text. At a first glance it makes total sense. But the closer you look, the more you see it makes no sense or has no real content.
“The index can be used to check whether your programming skills are still up to date”: do you consider your programming skills to not be up to date, because Scratch surpassed a language you use? “to make a strategic decision about what programming language should be adopted when starting to build a new software system”: PHP is falling fast, we should use Scratch for websites. “Rewrite it in Scratch” is the new “Rewrite it in Rust”, given Rust is even less popular now. “(…) is an indicator of the popularity of programming languages.” Obvious, right? Until you realize that “popularity” is a nebulous concept. And how popularity — understood in any way you wish — corresponds to your skills being up to date?
Take it as a fun anecdote? Great. Discuss it with any degree of seriousness? Eee… nah. This is the same kind of fun I had when producing the chart in attachment. Shows what Google suggested for prefix “I’m N years old and…”; just note that the original was in Polish and this is a rough translation, hence it’s a bit awkward.
But... Scratch is a great language for kids to learn programming. It has concepts of imperative programming, subroutines, variables, event-driven programming, parallel (concurrent) programming, and so on. (…)
That I don’t deny. My comment wasn’t about Scratch. Certainly not criticizing it.
-
People love things looking sciencey and rationalistic. Without ever considering, if they make any sense.
Indeed.
Where do these rankings come from?
Wikipedia: "The index is calculated from the number of search engine results for queries containing the name of the language. The index covers searches in Google, Google Blogs, MSN, Yahoo!, Baidu, Wikipedia and YouTube."
Actually, TIOBE tells us exactly:
Basically the calculation comes down to counting hits for the search query
+"<language> programming"
https://www.tiobe.com/tiobe-index/programminglanguages_definition/ (https://www.tiobe.com/tiobe-index/programminglanguages_definition/)
Ok, that's some kind of measure of current popularity. Even if simply in the sense of, as Stroustrup says "There are only two kinds of languages: the ones people complain about and the ones nobody uses."
There are other organisations who report programming language popularity by the number of job advertisements. And others by projects or commits on github.
-
At what age did you start programming and with what language?
In my case 12 / BASIC and I wish it had been Scratch instead of BASIC.
Access to computers didn't exist for kids when I was 12 in 1975. Certainly not in the rural far north of New Zealand.
I wanted to learn, but even the library in the nearest small city had virtually no books on programming. Amazingly, the most informative source I found was Encyclopaedia Britannica. BYTE magazine started publishing in 1975 and often had program listings in various languages and assembly languages. Electronics Australia and Electronics Today International and Wireless World had construction projects based around the latest microprocessors, and program code for them.
Actual, physically touching a machine to program it:
1978 (age 15): HP97 desktop calculator with mag card storage at a friend's high school
1979: bought my own TI-57. 50 program steps, 8 memories. It was possible to program something like finding the root of an equation, or Simpson's rule integration. Richer friends got TI-58 or Casio FX-501 both with much bigger program/data space. We all tried each others' machines
1980: FORTRAN on B1900 minicomputer, mostly punched cards but sometimes in person late at night with our teacher
1980 December: BASIC on Apple ][. Got frustrated by its limitations and slow speed withing days and taught myself 6502 machine language by reading the ROM listing in the back of the manual
1981: Pascal on PDP-11/34. Also assembly language.
1982 December (to 1983 Feb): COBOL on Pr1me minicomputer, paid summer holiday job
-
July 2024 Headline: Rust is preparing itself for the top 10
This month, high-performance language Rust jumped from position #17 to position #13 in the TIOBE index. This is an all time high for Rust. Gaining 4 positions might seem a small change, but Rust has been "the talk of the town" the last couple of years without making much progress in the TIOBE index. Rust is finally moving up. After the tailwind of the US government, which recently announced to recommend moving from C/C++ to Rust for security reasons, things are going fast for Rust. The community is growing, including the number of third party libraries and tools. In short, Rust is preparing itself for a top 10 position in the TIOBE index. --Paul Jansen CEO TIOBE Software
-
Yeah, Delphi and even Fortran are still ahead. :-DD
-
Based on searches it just shows Python is a pain to program compared to COBOL.
I did some code work with an Amiga, then DOS Batch stuff. I did some PHP/HTML/CSS stuff. I tinker with stuff. Not a real coder, my brain doesn't work that way to be good at it. I am rubbish at most things but better than most at many things.
-
Based on searches it just shows Python is a pain to program compared to COBOL.
Good point, this index being based on whatever people talk about the most online, what it shows is twofold: first, sure, that the language has traction (otherwise no one would care), but second, that the language requires a lot of support, as experience shows that most online activity on technical matters tends to be about asking questions.
So, until they are able to classify the type of content about programming languages and give more detailed indices, its real meaning has limited value, and, for all we know, may just show that, at least among maybe the top 20 languages listed, the first listed are the most problematic to work with.
-
Based on searches it just shows Python is a pain to program compared to COBOL.
I like that MACBETH language. It seems to fit perfectly:
To-morrow, and to-morrow, and to-morrow,
Creeps in this petty pace from day to day,
To the last syllable of recorded time;
And all our yesterdays have lighted fools
The way to dusty death. Out, out, brief candle!
Life's but a walking shadow, a poor player
That struts and frets his hour upon the stage
And then is heard no more. It is a tale
Told by an idiot, full of sound and fury
Signifying nothing.
-
ucPython on my Casio graphing pocket calculator.
I still don't know if it was a good idea :-//
I used Pascal and wrote crazy stuff, even OOP, back when Garbage was my favourite rock band(1)
Now that I do 90% of the things in C, I don't miss Pascal, but I miss the radio appearances on BeShare by Jean-Louis Gassée (founder of Be inc), when he was looking to convince people to switch to C++, and he almost did, since 90% of BeOS is written in C++...
(1) discontinued in 2007, the band reunited in 2011, but the sound is no longer the same as it was in the 90s.
-
The language HP introduced in its Prime (and actually in the 39GII just before that) is IMO a more appropriate language for a pocket calculator. But, that's not in TIOBE's index.
C++ appears to know renewed interest lately (and it's not just from TIOBE). Not sure what I think of this, but I do find it somewhat funny, as Rust proponents must not like that very much. For some fun about it all, watching conferences on C++ and on Rust these days are (often) both pretty hilarious, I recommend it, even if one has no interest in either.
When I switched from Pascal to C, I certainly didn't miss the "limitations" of Pascal, but "modern" Pascal is actually a very decent tool. It's just that there aren't many compilers available (pretty much either fpc or commercial Delphi), and it's (AFAIK) not directly possible to use it for embedded stuff. Otherwise that could be fun.
-
When I switched from Pascal to C, I certainly didn't miss the "limitations" of Pascal, but "modern" Pascal is actually a very decent tool. It's just that there aren't many compilers available (pretty much either fpc or commercial Delphi), and it's (AFAIK) not directly possible to use it for embedded stuff. Otherwise that could be fun.
I haven't tried them myself as I switched from Pascal to Modula-2 / Oberon many years ago but I do know that MIKROE sell Pascal compilers for ARM, PIC, AVR and more. e.g.
https://www.mikroe.com/mikropascal-arm (https://www.mikroe.com/mikropascal-arm)
-
When I switched from Pascal to C, I certainly didn't miss the "limitations" of Pascal, but "modern" Pascal is actually a very decent tool. It's just that there aren't many compilers available (pretty much either fpc or commercial Delphi), and it's (AFAIK) not directly possible to use it for embedded stuff. Otherwise that could be fun.
I haven't tried them myself as I switched from Pascal to Modula-2 / Oberon many years ago but I do know that MIKROE sell Pascal compilers for ARM, PIC, AVR and more. e.g.
https://www.mikroe.com/mikropascal-arm (https://www.mikroe.com/mikropascal-arm)
Ah, true.
Also, worth mentioning, GCC now officially supports Modula-2. I had just tested it quickly. That could be directly usable for embedded development too.
-
I haven't tried them myself as I switched from Pascal to Modula-2 / Oberon many years ago but I do know that MIKROE sell Pascal compilers for ARM, PIC, AVR and more. e.g.
MIKROE Pascal is nice, and not too expensive (~ 250 euro).
I tried it (7 days trial offer) for PIC32 (which is MIPS-core), but I didn't like that it requires Windows, because I cannot use in on my RISC workstations.
MIKROE supports
- PIC
- dsPIC
- PIC24
- PIC32 <---------------- I tried this one
- ARM
- AVR
- FT90x
- 8051 (not sure if it also supports 80c390 and 80c400)
-
TIOBE Index for August 2024
August Headline: Python is chasing Java's TIOBE index records
This month, Python has a ranking of more than 18% for the first time in its history. The last time a language hit more than 18% was Java in November 2016. Java is also the language with the highest ranking ever: 26.49% in June 2001. Runner up C++ is now exactly 8% behind Python, and that difference between position #1 and position #2 is also almost a record. The highest difference ever between position #1 and position #2 was in November 2016 when Java was 9.55% ahead of C. In summary, Python's hegemony is now undeniable. It is likely that it is Python's next step to become the most popular programming language ever. Is there any new language expected to come close to Python soon? Possible contenders Rust and Kotlin are approaching the TIOBE index top 10 fast, but it will take a lot of time before they become a real threat to Python. --Paul Jansen CEO TIOBE Software
-
TIOBE Index for September 2024
September Headline: Programming language C at lowest position ever
One of the mothers of all programming languages, C, has dropped one position in the TIOBE index this month. C is currently at position #4, which is its lowest position ever since the start of the TIOBE index in 2001. Is C losing its mojo? C is a relatively small programming language, which generates very performant code. As a consequence, it has been the favorite of embedded systems for a very long time. The only serious drawback of C so far was that it is not designed to scale. Large C programs are hard to maintain because of the lack of object oriented features. Now that embedded systems tend to grow in functionality and thus in code size, and since more and more embedded compilers have good C++ support, there is tendency to switch from C to C++. Recently another threat for C raised its head. The US government wants to put a ban on memory unsafe languages such as C in favor of memory safe languages such as Rust. This is the other tendency I observe. Companies are checking out Rust as an alternative for C. C might lose its mojo, but it will stay in the TIOBE index top 10 for a very long time. Its installed base is incredible and it is part of a zillion of safety-critical systems around the world.
Author: Paul Jansen, Chief Executive Officer
-
All that cargo-cult science index indicates is any permutation of:
- how do I do X? (any popular language, especially in the presence of PEBCAK)
- what's the language doing now? (especially C++, cf the last words on cockpit voice recorders)
- which spurious buzzwords should I put in job adverts this month
- history of popularity (cf quality)
- etc
Ignore such indices, except for amusement.
-
Indices of popularity are marketing tools more so than anything else.
If your job is marketing development tools, then they are probably useful.
-
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.
-
"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).
-
"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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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 >:D 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.
-
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.
-
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?
-
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.
-
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.
-
Curious to see if you can have the same kind of fun with Rust macros.
-
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 2N takes N steps to reach 1 e.g. 32 takes 5 steps. But 27 takes 111 steps!
-
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.
-
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.
-
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?
-
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...
-
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".
-
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.
-
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 :)
-
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.
-
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. :)
-
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.
The interesting lesson from C++ templates is that the car designers refused to believe their car could be driven into a solid piece of concrete/rock at full speed - until someone put them in a car and demonstrated it.
Come to think of it, that's much like "autonomous" cars and their proponents.
-
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.
The interesting lesson from C++ templates is that the car designers refused to believe their car could be driven into a solid piece of concrete/rock at full speed - until someone put them in a car and demonstrated it.
Come to think of it, that's much like "autonomous" cars and their proponents.
Well, that's the "fascinating" part indeed, but in their "defense", C++ templates are so convoluted that the fact designers themselves never fully understood them is not surprising.
What is always surprising, as an engineer, is designing something that you don't understand yourself.
-
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.
The interesting lesson from C++ templates is that the car designers refused to believe their car could be driven into a solid piece of concrete/rock at full speed - until someone put them in a car and demonstrated it.
Come to think of it, that's much like "autonomous" cars and their proponents.
Well, that's the "fascinating" part indeed, but in their "defense", C++ templates are so convoluted that the fact designers themselves never fully understood them is not surprising.
What is always surprising, as an engineer, is designing something that you don't understand yourself.
Oh, it isn't surprising that they weren't understood. But that's not a "defense" :)
The problem isn't creating something you don't understand; that's not necessarily bad. The problem is creating a mess and then being sufficiently arrogant (and/or ignorant) to believe you do understand the consequences.
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” ― C. A. R. Hoare
Tony Hoare repeatedly simplified things and concepts, to the benefit of all. (Exception: when he invented his billion dollar mistake, NULL :) )
-
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.
There are too many errors. I tried googling for a working example but had no success. There are many links claiming to provide a 'fixed version,' but none of them compile with modern compilers. That's why I'm asking if a working version exists for modern compilers.
Here is original code that I found:
// Erwin Unruh, untitled program,
// ANSI X3J16-94-0075/ISO WG21-462, 1994.
template <int i>
struct D
{
D(void *);
operator int();
};
template <int p, int i>
struct is_prime
{
enum { prim = (p%i) && is_prime<(i>2?p:0), i>::prim };
};
template <int i>
struct Prime_print
{
Prime_print<i-1> a;
enum { prim = is_prime<i,i-1>::prim };
void f() { D<i> d = prim; }
};
struct is_prime<0,0> { enum { prim = 1 }; };
struct is_prime<0,1> { enum { prim = 1 }; };
struct Prime_print<2>
{
enum { prim = 1 };
void f() { D<2> d = prim; }
};
void foo()
{
Prime_print<10> a;
}
$ g++ test.cpp
test.cpp:25:1: error: an explicit specialization must be preceded by ‘template <>’
25 | struct is_prime<0,0> { enum { prim = 1 }; };
| ^~~~~~~~~~~~~~~~~~~~
| template <>
test.cpp:26:1: error: an explicit specialization must be preceded by ‘template <>’
26 | struct is_prime<0,1> { enum { prim = 1 }; };
| ^~~~~~~~~~~~~~~~~~~~
| template <>
test.cpp:27:1: error: an explicit specialization must be preceded by ‘template <>’
27 | struct Prime_print<2>
| ^~~~~~~~~~~~~~~~~~~~~
| template <>
test.cpp: In member function ‘void Prime_print<2>::f()’:
test.cpp:30:25: error: conversion from ‘Prime_print<2>::<unnamed enum>’ to non-scalar type ‘D<2>’ requested
30 | void f() { D<2> d = prim; }
| ^~~~
test.cpp: In instantiation of ‘struct is_prime<0, 2>’:
test.cpp:14:52: required from ‘struct is_prime<3, 2>’
test.cpp:20:25: recursively required from ‘struct Prime_print<9>’
test.cpp:20:25: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<0, 2>’ used in nested name specifier
14 | enum { prim = (p%i) && is_prime<(i>2?p:0), i>::prim };
| ^~~~
test.cpp: In instantiation of ‘struct is_prime<4, 3>’:
test.cpp:20:25: recursively required from ‘struct Prime_print<9>’
test.cpp:20:25: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<4, 3>’ used in nested name specifier
test.cpp: In instantiation of ‘struct is_prime<5, 4>’:
test.cpp:20:25: recursively required from ‘struct Prime_print<9>’
test.cpp:20:25: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<5, 4>’ used in nested name specifier
test.cpp: In instantiation of ‘struct is_prime<6, 5>’:
test.cpp:20:25: recursively required from ‘struct Prime_print<9>’
test.cpp:20:25: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<6, 5>’ used in nested name specifier
test.cpp: In instantiation of ‘struct is_prime<7, 6>’:
test.cpp:20:25: recursively required from ‘struct Prime_print<9>’
test.cpp:20:25: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<7, 6>’ used in nested name specifier
test.cpp: In instantiation of ‘struct is_prime<8, 7>’:
test.cpp:20:25: recursively required from ‘struct Prime_print<9>’
test.cpp:20:25: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<8, 7>’ used in nested name specifier
test.cpp: In instantiation of ‘struct is_prime<9, 8>’:
test.cpp:21:36: required from ‘struct Prime_print<9>’
test.cpp:20:25: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<9, 8>’ used in nested name specifier
test.cpp: In instantiation of ‘struct is_prime<10, 9>’:
test.cpp:21:36: required from ‘struct Prime_print<10>’
test.cpp:35:21: required from here
test.cpp:14:52: error: incomplete type ‘is_prime<10, 9>’ used in nested name specifier
-
Turing-completeness arose, sometimes unexpectedly, in many other places. For example, all these are Turing-complete:
- C++ template metaprogramming
- LaTeX (and, thus, TeX): https://web.archive.org/web/20160110102145/http://en.literateprograms.org/Turing_machine_simulator_%28LaTeX%29 (https://web.archive.org/web/20160110102145/http://en.literateprograms.org/Turing_machine_simulator_%28LaTeX%29)
- PostScript https://cs.unh.edu/~charpov/programming-primes.html (https://cs.unh.edu/~charpov/programming-primes.html)
- x86 not using registers https://mainisusuallyafunction.blogspot.com/2014/02/x86-is-turing-complete-with-no-registers.html (https://mainisusuallyafunction.blogspot.com/2014/02/x86-is-turing-complete-with-no-registers.html)
- x86 MOV assembly instruction https://github.com/xoreaxeaxeax/movfuscator (https://github.com/xoreaxeaxeax/movfuscator)
- x86 MMU https://news.ycombinator.com/item?id=5261598 (https://news.ycombinator.com/item?id=5261598)
- Notepad++ find+replace (using regex) https://github.com/0xdanelia/regex_turing_machine (https://github.com/0xdanelia/regex_turing_machine)
- Many One Instruction Set Computer (OISC) https://esolangs.org/wiki/OISC (https://esolangs.org/wiki/OISC)
- Sendmail https://okmij.org/ftp/Computation/sendmail-as-turing-machine.txt (https://okmij.org/ftp/Computation/sendmail-as-turing-machine.txt)
- sed, awk and m4 are all turing complete. find + mkdir is also Turing complete https://ogiekako.vercel.app/blog/find_mkdir_tc (https://ogiekako.vercel.app/blog/find_mkdir_tc)
- HTML+CSS+mouse clicking https://notlaura.com/is-css-turing-complete/ (https://notlaura.com/is-css-turing-complete/)
- PowerPoint animations https://www.youtube.com/watch?v=uNjxe8ShM-8 (https://www.youtube.com/watch?v=uNjxe8ShM-8)
constexpr is also Turing-complete and nobody is ranting about it. So the problem is not C++ templates being Turing-complete, the problem is them being ugly, hard to debug, overly complex and abused by many.
-
...constexpr is also Turing-complete and nobody is ranting about it. So the problem is not C++ templates being Turing-complete, the problem is them being ugly, hard to debug, overly complex and abused by many.
There are many many things that are Turing complete; that is in no way a problem.
C++ templates are ugly and hard to debug, which is distasteful, but no more.
The damning point is that the C++ committee refused to believe they were Turing complete, until Erwin Unruh rubbed their noses in it. That means the C++ committee was ignorant and would have preferred to remain ignorant. That is, arguably, indicative of the quality of the language they emitted.
-
Turing-completeness arose, sometimes unexpectedly, in many other places. For example, all these are Turing-complete:
- PostScript https://cs.unh.edu/~charpov/programming-primes.html (https://cs.unh.edu/~charpov/programming-primes.html)
Why on Earth is PostScript in this list when it is literally and deliberately a Forth-like programming language? No accident.
bruce@i9:~/programs$ cat primes.ps
2 {
true
2 1 3 index sqrt {
2 index exch
mod 0 eq {
not exit
} if
} for
{dup =} if
1 add
} loop
bruce@i9:~/programs$ gs -q primes.ps | head -20
2
3
5
7
11
13
17
19
23
29
31
37
41
43
47
53
59
61
67
71
bruce@i9:~/programs$
-
PostScript is in the list not for being accidentally Turing-complete, it is by design, but for being "curious" that a "document" sent to the printer is executed by it to, say, generate and print the sequence of prime numbers.
-
Turing-completeness arose, sometimes unexpectedly, in many other places. For example, all these are Turing-complete:
- PostScript https://cs.unh.edu/~charpov/programming-primes.html (https://cs.unh.edu/~charpov/programming-primes.html)
Why on Earth is PostScript in this list when it is literally and deliberately a Forth-like programming language? No accident.
Just so. There's an old PostScript program containing the instructions that cause the printer to generate a Smith Chart. You can hand modify the code to put markers on the chart :)
I remember when the "8 queens problem" was a standard microbenchmark for AI systems. Executing it on an Apple LaserWriter was faster than on the contemporary Mac Plus :) Now that was curious.
Turing completeness is not a problem.
-
PostScript is in the list not for being accidentally Turing-complete, it is by design, but for being "curious" that a "document" sent to the printer is executed by it to, say, generate and print the sequence of prime numbers.
If that is "curious" then it is on a completely different axis of curiosity.
Every printer ever made interprets what is sent to it as a mixture of literal characters to be printed interspersed with commands to e.g. 1) return the print head to column 0, or 2) advance the print head to the next tab stop, or 3) advance the paper by 1 line, or 4) advance the paper to the next page. Etc etc.
Even before PostScript in the first LaserWriter, HP's PCL in the original LaserJet had (much the same as HP pen plotters) commands to draw lines, polygons, Bezier curves, bitmapped images. move the output cursor to an arbitrary position on the page etc.
CNC machine tools similarly interpreted a language (G-Code, 1963) with commands for changing tools, moving in three dimensions, rates of movement etc. G-code even has variables and macros.
There was nothing curious about the notion that a peripheral had an embedded CPU in it to interpret these languages.
All that PostScript added was conditional and looping constructs, and a more readable syntax.
-
I remember when the "8 queens problem" was a standard microbenchmark for AI systems. Executing it on an Apple LaserWriter was faster than on the contemporary Mac Plus :) Now that was curious.
Maybe if the Mac Plus was running an interpreted Lisp. Not if you programmed the 8 queens in Think Pascal (generating native 68000 code) etc.
The LaserWriter had a 68000, same as the Mac Plus, it was just running at 12 MHz instead of 7.83 MHz. So it was faster, but not THAT much faster.
Note that the Mac Plus ($2599, 1 MB RAM, 1 floppy) was introduced 10 months after the LaserWriter ($6995), but of course the Mac 128k was a year before it, and the 512k "Fat Mac" was six months before the LaserWriter.
I bought the first LaserWriter in NZ, the same one as was used to demo at the launch. It was my first year out of university. I was programming a Data General MV/10000 [1] in PL/1 to generate line graphs for financial data vs time e.g. stock prices, foreign exchange rates, first on an HP pen plotter and then on the original LaserJet. The LaserJet could print bitmap data inside a rectangle [2] but only a total of 56KB (?) of data per page (including actual text, formatting commands etc), with a full A4 page at 300 DPI being about 1 MB, so it only had about maximum 5% coverage of the page using bitmapped graphics. It was very painful trying to print a full page line graph (plus axes, labels etc) by enclosing parts of the line graph with lots of tiny rectangles.
I showed my boss an article about the new Apple LaserWriter, showing example PostScript programs, and told him we needed one. "How much?" "NZ$18000" "It will do the job we need?" "Yup" "Get it". Instant decision. All that remained was to make up a custom cable to connect one of the DG's RS-232 terminal lines to the LaserWriter's RS-422, and convert my programs to generate PostScript instead of PCL or HP-GL (pen plotter language).
In fact, as a first version, it was easy to write a PostScript program that could be simply concatenated in front of an HP-GL disk file, sent to the LaserWriter, and the PostScript program interpreted the HP-GL.
[1] a VAX competitor, advertised as twice as fast as an 11/780 at maybe half the price. It was 32 bit but binary compatible with 16 bit Nova & Eclipse machines. It still had only 4 GPRs, two of which could be used as pointers.
[2] actually a rectangle with a ragged right edge as each line could be a different length
-
If that is "curious" then it is on a completely different axis of curiosity.
If something is curious or not to somebody is absolutely subjective, so above in nonsensical.
I also find curious why some people insist on, always, say the last word, even becoming ridiculously (also, an objective quality) picky.
Done with me, thanks.
-
I remember when the "8 queens problem" was a standard microbenchmark for AI systems. Executing it on an Apple LaserWriter was faster than on the contemporary Mac Plus :) Now that was curious.
Maybe if the Mac Plus was running an interpreted Lisp. Not if you programmed the 8 queens in Think Pascal (generating native 68000 code) etc.
The LaserWriter had a 68000, same as the Mac Plus, it was just running at 12 MHz instead of 7.83 MHz. So it was faster, but not THAT much faster.
The LaserWriter also had twice as much RAM: a whopping 2MB.
The benchmark was done by a university doing AI research, so they would have taken delight in subverting things[1]. They would have been comparing AI languages and implementations, possibly a compiled Prolog.
I have a working Mac Plus, and a lot of floppies. I only use it to remind myself of my introduction to OOP: Apple's Smalltalk implementation. It is glacially slow, and that's being charitable. If you want to try it, you would be better off running it in a Mac emulator :)
[1] ISTR the professors telling me, with a wry grin, that one of their students had told them he knew the upcoming exam questions. They had worked out a way to sniff the traffic on the ?AppleTalk? network on the way to the printer.
I bought the first LaserWriter in NZ, the same one as was used to demo at the launch. ... to generate line graphs for financial data vs time
...
I showed my boss an article about the new Apple LaserWriter, showing example PostScript programs, and told him we needed one. "How much?" "NZ$18000" "It will do the job we need?" "Yup" "Get it".
The financial mob tend to be like that.
Nowadays they compile business rules to VHDL/Verilog and run them in big FPGAs, install their own dedicated trans-Atlantic cables, and buy up the microwave link towers between Chicago and New York because the speed of light is faster in air than fibre. Milliseconds are very expensive, and worth eliminating.
-
October 2024 Headline: Rust is slowly but steadily approaching the TIOBE index top 10
In today's world, the amount of available data of whatever kind is increasing rapidly, and the demand to harvest this data is increasing accordingly. Hence, there is now a need for programming languages that are good in data manipulation, number crunching and being fast. Next to this, there are two other important characteristics high on everybody's list: languages should be easy to learn and should be secure. "Easy to learn" because the resource pool of skilled software engineers is drying up and "secure" because of continuous cyber threats. Languages that have these three traits (being fast, being secure and easy to learn), have a good time now.
King of all, Python, is easy to learn and secure, but not fast. Hence, engineers are frantically looking for fast alternatives for Python. C++ is an obvious candidate, but it is considered "not secure" because of its explicit memory management. Rust is another candidate, although not easy to learn. Rust is, thanks to its emphasis on security and speed, making its way to the TIOBE index top 10 now.
The cry for fast, data crunching languages is also visible elsewhere in the TIOBE index. The language Mojo, which is a mix of Python and Swift, but much faster, enters the top 50 for the first time. The fact that this language is only 1 year old and already showing up, makes it a very promising language.
Author: Paul Jansen, Chief Executive Officer
-
People love things looking sciencey and rationalistic. Without ever considering, if they make any sense.
I point everybody’s attention to position 16 on that list.
Yup. The TIOBE Index is a bit like summing the first few terms of a divergent series and then publishing the results.
-
I like to illustrate that with this site: https://tylervigen.com/spurious-correlations
Great pedagogical tool, unfortunately I wonder if some politicians use it as a source of inspiration.
-
As always XKCD has some interesting / amusing insights e.g. for Python:
https://www.explainxkcd.com/wiki/index.php/353:_Python (https://www.explainxkcd.com/wiki/index.php/353:_Python)
https://www.explainxkcd.com/wiki/index.php/1987:_Python_Environment (https://www.explainxkcd.com/wiki/index.php/1987:_Python_Environment)
-
November 2024 Headline: Go is here to stay
The Go language is making its way up in the TIOBE index. After having been in the top 10 for quite some time now, it is now holding position #7. This is an all time high for Go. What makes Go unique in the top 10 is that Go programs are fast and easy to deploy while the language is easy to learn. Python for instance is easy to learn but not fast, and deployment for larger Python programs is fragile due to dependencies on all kind of versioned libraries in the environment. If compared to Rust for instance (another contender for a top position), Go is a tiny bit slower, but the Go programs are much easier to understand. The next hurdle for Go in the TIOBE index is JavaScript at position #6. That will be a tough one to pass. JavaScript is ubiquitous in software development, although for larger JavaScript systems we see a shift to TypeScript nowadays. If annual trends continue this way, Go will bypass JavaScript within 3 years. Let's see what the future has in store for Go.
Author: Paul Jansen, Chief Executive Officer
https://en.wikipedia.org/wiki/Go_(programming_language) (https://en.wikipedia.org/wiki/Go_(programming_language))
-
I like to illustrate that with this site: https://tylervigen.com/spurious-correlations
Great pedagogical tool, unfortunately I wonder if some politicians use it as a source of inspiration.
The TIOBE index is not going to put Pascal as a mainstream language today, but it was in the 1990s.
It's not an exact science, of course, but it does give you an idea of its popularity and usage.
This month's focus is on GO, because it is making its way to the top of the list of popular and widely used languages. I don't know what it means exactly, but I like it when someone draws my attention to this language that more and more programmers are using.
-
I like to illustrate that with this site: https://tylervigen.com/spurious-correlations
Great pedagogical tool, unfortunately I wonder if some politicians use it as a source of inspiration.
Excellent; thanks for that.
-
December Headline: Python is about to become the language of the year
Next month, TIOBE will reveal the programming language of the year 2024. This award is given to the programming language with the highest increase in ratings in one year. Since Python gained 10% ratings in one year, it will probably receive this prestigious title next month. Runners up Java and JavaScript made a year to year jump of +1.73% and +1.72% respectively. That is positive, but it seems marginal if compared to the gigantic leap of Python in 2024. Python is unstoppable thanks to its support for AI and data mining, its large set of libraries and its ease of learning. Now that some say that the AI bubble is about to burst plus the fact that demand for fast languages is rapidly increasing, Python might start to plateau. Let's see whether this happens.
Author: Paul Jansen, Chief Executive Officer
TIOBE Programming Community Index Definition (https://www.tiobe.com/tiobe-index/programminglanguages_definition/)
-
FORTRAN up two places, breaks into the top 10.
COBOL up four places, breaking into the top 20.
Gentlemen, prepare your resumes...
-
Top 8 Most Demanded Programming Languages in 2024
https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ (https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/)
-
IEEE Spectrum. The Top Programming Languages 2024.
https://spectrum.ieee.org/top-programming-languages-2024
-
The whole ranking thing is silly. What would python be without C or C++.
I started to look at python but realized that really I was just learning about a dumbed down C++ implementation so switched to C++ as it feels like I'd do better learning C++ before I play loose and fast with python.
python is the language that seems to have more books written about it that promise you untold wealth etc if you learn it. I even saw one claiming that you could learn enough in a week to totally change your career......
Having spent quite some time doing C on micros with me coming on here asking if such and such would work to make my life easier and being told, yes you can do that in C++ but not C I thought it time. Also I would like to get into proper computer programming and C++ does give more options in terms of what I want or python. But python always lags C++, why? well because as I understand it, it has to be written in C or C++ before it can be used on python.
I see why python is popular and I suspect that it is more about people trying to get into programming the fast and loose way. Maybe C++ is starting to overtake C for the same reasons I am choosing it over C for my new adventures.
-
The whole ranking thing is silly. What would python be without C or C++.
...
Having spent quite some time doing C on micros with me coming on here asking if such and such would work to make my life easier and being told, yes you can do that in C++ but not C I thought it time. Also I would like to get into proper computer programming and C++ does give more options in terms of what I want or python. But python always lags C++, why? well because as I understand it, it has to be written in C or C++ before it can be used on python.
The whole ranking thing thing is not silly: it is stupid. Or at least a sensible as ranking spoons, knives, chopping boards, and other kitchen utensils. The key point is to choose the most appropriate tool for the current requirements.
Realising that also makes it clear that "language X being written in C means C is better than X" is also fallacious thinking. You might as well claim "analogue components are better than digital components, since digital components are merely analogue components with constrained inputs and outputs".
If you think C++ is the answer, then read the C++ FQA; the questioned answers would be entertaining if they weren't so serious. https://yosefk.com/c++fqa/ Don't use C++ until you understand those questions and (lack of) answers.
-
Python is not only popular, it is also in high demand for job offers.
In the world of electronics and microcontrollers it is not widely used. There are microPython implementations, but it is not widely used.
I use Python to create my web page (with sphinx), to collect data and visualize it in graphs (with matplotlib), to automate web data collection (with selenium), to automate the generation of javascript and json code for web pages (with Jinja2 and pyyaml), to automate image processing (with Pillow), to automate the location and renaming of data files, etc. etc.
I could not use my computer without Python.
-
Each language has it's use. I figured that if I learnt C++ first Python would come much more naturally when I need it.
-
Generative AI is going to make language choices less important—just a parameter for how a developer’s intent gets translated to fit conventions or legacy systems. In three years, I bet prompt engineering for Gen AI will be a top skill and a core part of coding and rising on this list.
-
Generative AI is going to make language choices less important—just a parameter for how a developer’s intent gets translated to fit conventions or legacy systems. In three years, I bet prompt engineering for Gen AI will be a top skill and a core part of coding and rising on this list.
I don't believe that. Not even in ten years.
-
Generative AI is going to make language choices less important—just a parameter for how a developer’s intent gets translated to fit conventions or legacy systems. In three years, I bet prompt engineering for Gen AI will be a top skill and a core part of coding and rising on this list.
You over estimate the internet! How will this AI be trained? if it's by making it read the internet it will put out garbage. How each problem is approached requires skills that AI does not have. Like ADHD never was a thing more poorly named!
-
Each language has it's use. I figured that if I learnt C++ first Python would come much more naturally when I need it.
That's like thinking a spoon will come more naturally if you learn a fork first. Remember the old adage: you can write Fortran in any language.
And do read the C++ FQA. You can choose to read it before you have problems with C++ or when you need to realise the cause of the problems you are having with C++.
-
Each language has it's use. I figured that if I learnt C++ first Python would come much more naturally when I need it.
That's like thinking a spoon will come more naturally if you learn a fork first. Remember the old adage: you can write Fortran in any language.
And do read the C++ FQA. You can choose to read it before you have problems with C++ or when you need to realise the cause of the problems you are having with C++.
Alrigtht so I read enough to get the jist. C++ is apparently crap. If you have been keeping tabs on threads I started over the last year you will know that I have been see-sawing around trying to work out what to use beyond C and have considered C++ and python. The best of 2 books I have on python the author makes many mistakes and can't do algebra. I'm not saying that this makes me think badly of python but.... My use case is to create machine HMI's for a start and deal with CAN bus data. Every graphical library I have found uses C++, sure Qt has a python implementation too.
So What would you suggest? I have been round this circuit many times and I just keep coming back to the same thing. Everyone has a preference, many have opinions based on how things used to be and so opinions about the same language conflict for that reason alone rightly, everything else is just down to personal feelings about one language or the other. So I don't know which way to go. I can't make up my mind until I can see for myself, and I can't do that while I don't know at least one language well enough.
-
So What would you suggest? I have been round this circuit many times and I just keep coming back to the same thing. Everyone has a preference, many have opinions based on how things used to be and so opinions about the same language conflict for that reason alone rightly, everything else is just down to personal feelings about one language or the other. So I don't know which way to go.
If you know how to program, it doesn't matter which language you use.
If you don't know how to program, it doesn't matter which language you use.
-
And: if you don't know how to program but you know which language everyone should use, just become an agile coach.
-
If there isn't a midwit meme for this, there should be.
-
So What would you suggest? I have been round this circuit many times and I just keep coming back to the same thing. Everyone has a preference, many have opinions based on how things used to be and so opinions about the same language conflict for that reason alone rightly, everything else is just down to personal feelings about one language or the other. So I don't know which way to go.
If you know how to program, it doesn't matter which language you use.
If you don't know how to program, it doesn't matter which language you use.
That's an excellent starting point, but I'd modulate it with some secondary points...
Different languages have different opinions of how computation should be expressed and therefore designed. For example, there are procedural, functional, object-oriented, Horn-clause (i.e. Prolog), event-driven FSM, declarative, pattern matching, and other languages. It is highly beneficial to work out the best way to express your solution, and thereafter to choose the appropriate class of language. Once you've done that, it is easy to swap between languages in the same class.
Having said that, some languages have mis-features that make the language part of the problem rather than part of the solution. Such languages are best avoided.
-
if you want to use a particular library you need to program in the language it interfaces to..... that is my dilemma.
Learning to program is what I am trying to do, or at least learn about the programming environment. I wrote a CAN open master that runs on a M0+ in C but what I learnt there has not much to do with programming in an operating system and dealing with libraries.
-
if you want to use a particular library you need to program in the language it interfaces to..... that is my dilemma.
... languages ...
Interfacing can be direct function calls, but there are other techniques. The obvious one is a shim to convert the library API to another comms mechanism or language.
Learning to program is what I am trying to do, or at least learn about the programming environment. I wrote a CAN open master that runs on a M0+ in C but what I learnt there has not much to do with programming in an operating system and dealing with libraries.
IMNSHO with C++ you will spend far more time fighting C++ than fighting your application. I know which I find more timewasting and more valuable.
I once (c1994) saw a talented team spend several years creating an application where a GUI input was 50% of the objective (an SDL diagrams to C "compiler"). That was significantly slowed down by choosing C++ for the interface. If they had used a better language (Smalltalk then, Java now) then they would have halved the timescale and effort - and been able to concentrate on the benefit not the tool.
-
Well maybe I should continue with python and the guy who wrote a book but struggles to explain himself. At least I'll be playing with all the cool kids then I can look at what else I should learn.
-
Well maybe I should continue with python and the guy who wrote a book but struggles to explain himself. At least I'll be playing with all the cool kids then I can look at what else I should learn.
I can't comment on that, other than to say "bugger the kewl kids"; that's why some chose C++ when Smalltalk would have been better. I wouldn't expect (or worry about) a book about Python not being very good at teaching algebra.
-
So What would you suggest? I have been round this circuit many times and I just keep coming back to the same thing. Everyone has a preference, many have opinions based on how things used to be and so opinions about the same language conflict for that reason alone rightly, everything else is just down to personal feelings about one language or the other. So I don't know which way to go.
If you know how to program, it doesn't matter which language you use.
I'll bite: famous last words... Modern day programming languages lean heavily on more advanced data structures (like Python dictionaries) and supporting libraries so knowing how to write a for-loop or printing 'hello world' doesn't get you very far. Just getting to grips with all the libraries which come with a language or framework takes years if you want to become an expert / a super efficient programmer. And this has been true for at least 2 decades. Look at the Microsoft foundation classes (MFC) for example.
-
So What would you suggest? I have been round this circuit many times and I just keep coming back to the same thing. Everyone has a preference, many have opinions based on how things used to be and so opinions about the same language conflict for that reason alone rightly, everything else is just down to personal feelings about one language or the other. So I don't know which way to go.
If you know how to program, it doesn't matter which language you use.
I'll bite: famous last words... Modern day programming languages lean heavily on more advanced data structures (like Python dictionaries) and supporting libraries so knowing how to write a for-loop or printing 'hello world' doesn't get you very far. Just getting to grips with all the libraries which come with a language or framework takes years if you want to become an expert / a super efficient programmer. And this has been true for at least 2 decades. Look at the Microsoft foundation classes (MFC) for example.
Yes and no...
Yes, you need to understand that the libraries do X, because that means you don't have to do X.
No, because many libraries do fundamental things that will be very similar in all different languages. Collection classes like Dictionaries, Sets, Bags, Strings are the classic examples. In the early 90s, after having those provided in Smalltalk and Objective-C, the thought of me having to reimplement them yet again in C or C++ was not a pleasant thought. That Java came complete with those when C++ had failed to provide them for a decade was a very strong point in Java's favour.
Yes, because some libraries provide functions that are required on a specific platform. Such libraries (e.g. MFC) are a drag on a programmer's productivity.
No, because a large application's high level architecture should be based on concepts and strategies that are common across all platforms. The platform-specific stuff should be very limited.
-
So What would you suggest? I have been round this circuit many times and I just keep coming back to the same thing. Everyone has a preference, many have opinions based on how things used to be and so opinions about the same language conflict for that reason alone rightly, everything else is just down to personal feelings about one language or the other. So I don't know which way to go.
If you know how to program, it doesn't matter which language you use.
I'll bite: famous last words... Modern day programming languages lean heavily on more advanced data structures (like Python dictionaries) and supporting libraries so knowing how to write a for-loop or printing 'hello world' doesn't get you very far.
"Knowing how to program" is something far beyond "knowing how to write a for-loop or printing 'hello world'". Those are both first day of learning how to program stuff, and I've been learning how to program for 45 years. I'd say I would probably have counted as "knowing how to program" by the end of my second year at university, by which time I'd written a full screen VT100 text editor, and Rubik's Cube on-screen (VT100 again) simulator and solver (both in 1st year, in Pascal on an 11/34), a 6502 emulator (in VAX Pascal) that ended up being used by my entire class as access to the AIM65 boards was limited, and got a summer job writing COBOL at my home town's city council.
Advanced data structures are largely just implementations of key=>value lookup with various special cases and performance characteristics e.g. if the keys are contiguous integers then use an array, if the keys are a fixed set of strings then use a struct, if you need to iterate lexically then use a list or tree, if accesses are random (other than sometimes extracting the full set of keys in arbitrary order) then use a hash table (an array where the keys are a mathematical function mapping arbitrary values into small integers).
Just getting to grips with all the libraries which come with a language or framework takes years if you want to become an expert / a super efficient programmer. And this has been true for at least 2 decades. Look at the Microsoft foundation classes (MFC) for example.
I had a contract programming with MFC on NT 3.51 on a Pentium Pro thirty years ago. What a joke thin layer on top of WIN32! I was using far more comprehensive frameworks such as Apple's MacApp (Object Pascal at first, then ported to C++) a decade earlier, and the THINK Class Library and the really very beautifully designed (maybe still the cleanest ever) Metrowerks PowerPlant in between.
There is absolutely no need to know all of a framework or library. You need to know how it is organised, and the most commonly-used parts, but the rest you can look up as needed.
Knowing how to read a manual or what keywords to use in a search is actually one of the key skills of a programmer.
-
Well I've had to create my own CAN open object library management in C. So would this have been any easier on other languages that still don't support the CAN open object dictionary type?
-
Well I've had to create my own CAN open object library management in C. So would this have been any easier on other languages that still don't support the CAN open object dictionary type?
Easier? Yes, maybe? But by how much - not significantly.
The ugly truth is that more advanced languages which look much simpler on synthetic examples demonstrating those points, are not significantly easier in the big picture. Even if you have to implement some more complex data type in C yourself from scratch (say, hash table), that will be still <1% of the total you are spending on the project. (And nothing prevents you from downloading and using uthash, for example.)
I'm not saying a modern language should not include better data types than C does, built-in, just saying people overestimate the time savings from more advanced languages. But this is excluding extreme cases: programming in Brainfuck, or using MSPAINT to apply colors pixel-by-pixel to create x86 machine code, would be truly difficult.
-
... just saying people overestimate the time savings from more advanced languages. ...
Once upon a time I had similar thoughts.
They changed after I had built several applications[1] with complex data structures (both modelling and implementation) and comms requirements. Having solid easily usable libraries made my life a lot easier, the project implementation shorter, and the result better (particularly w.r.t. extension and modification).
In that context "easily usable" excluded C and C++.
[1] e.g. delving into and understanding how and where cellphone cells were becoming iffy, and high performance telecom soft realtime systems.
-
In my experience, high-level languages like Python not only reduce application development time, they also improve maintenance time (which may be even more important). And it definitely doesn't make any sense for you to start programming an implementation of lists and dictionaries in C for your application, when you already have them implemented in other languages natively.
-
In my experience, high-level languages like Python not only reduce application development time, they also improve maintenance time (which may be even more important). And it definitely doesn't make any sense for you to start programming an implementation of lists and dictionaries in C for your application, when you already have them implemented in other languages natively.
Python does not reduce application development time because of list datatype; but because of good availability of large-granularity libraries: meaning, it is simple to do a large task by a simple call to a library.
A honest question though: if application developer writes 20 lines of Python, which runs 100 000 lines of C code, is the application "written in Python" or "written in C"?
And that question is relevant because Python is really an interesting exception. Most other programming languages can implement their own core libraries in said language itself. For example, Erlang libraries can be written in Erlang. C# libraries can be written in C#. Rust libraries can be written in Rust. Ada libraries can be written in Ada.
But Python libraries are written in C, and this is because Python and its runtime is colossally inefficient; and while it is often said that speed is not always primary aim, when something is really 100 to 1000 times slower, that is too slow. So Python really is frontend to C libraries. Which, when you think about it, kinda makes sense, because:
In that context "easily usable" excluded C and C++.
this is kinda true. Especially for inexperienced programmers or very small projects (throwaway code), integrating existing C (and C++ is much worse) libraries is somewhat tedious. You can get used to it but I understand the need for a "C frontend", what Python really is. It allows mixing very large granules (like, a library which does a lot of image processing on a single call) and mid-sized granules (like matrix operations) of library operations, all written in C. And because the granularity is large enough, execution speed is decent: CPU is mostly executing native binary code (compiled from C) and only occasionally coming back to the Python interpreter.
As soon as you try to do so-called systems programming on Python - or develop a new algorithm from scratch which has to do customized data crunching e.g. a lot of looping or recursion - you realize that Python is completely incapable of doing that. But you can do it in C, and add Python bindings to it.
The reason for Python's popularity is not that it's "better than C". Hundreds of languages are "better than C". Python is popular because it has efficient way of C bindings. Python gives easy access to software written in C, without having to write C.
-
precisely and this is what leaves me a little uneasy about it. If I did want to write a load of my own code which I do (a CAN open master for starters) then I'd also have to learn how to write the C for python.
My main criteria for a language is that I can use the stuff that I need to with it. OK by default that is python but I have just added another layer between me and getting hardcore stuff done, it will be slow or i will have ta almost learn a new language.
-
precisely and this is what leaves me a little uneasy about it. If I did want to write a load of my own code which I do (a CAN open master for starters) then I'd also have to learn how to write the C for python.
My main criteria for a language is that I can use the stuff that I need to with it. OK by default that is python but I have just added another layer between me and getting hardcore stuff done, it will be slow or i will have ta almost learn a new language.
A key part of any design is to understand in general and decide for your project which functions must/could/should be implemented in gate level logic, FPGAs, time critical software, single threaded or multi-threaded software, time non-critical software[1]. In general push as much functionality to the latter as possible. It is easier to create more complex/complicated functionality in the latter, and latency/jitter sensitive functionality in the former.
Once that is decided, the API between each of those is designed and implemented.
[1] I've done all those and more, but that seems to be uncommon.
-
OK, to put it another way, looking at the system design as a whole. Now I tried this a long time ago and bought a great big book called "The linux programming interface" but was told that i was wasting my time with that. What I did gather from it is that there are several mechanisms for different programs to communicate (ports/sockets and more). So at what level of complexity do I divide my system up into multiple programs so that each can be written in whatever language best suits that or will the complexity of getting things to talk to each other outweigh the total development unless it is a seriously complicated system?
-
So at what level of complexity do I divide my system up into multiple programs so that each can be written in whatever language best suits that or will the complexity of getting things to talk to each other outweigh the total development unless it is a seriously complicated system?
I'm afraid there is no generic answer; it really depends on what you are exactly doing. I.e., best tool for the job, and also (maybe to a lesser degree), what you are familiar with - sometimes even a non-optimal tool is best for you as long as it's not too unsuitable: as an example, I often use C for even small throwaway tests/tools on PC when I could write them in Python maybe 30% faster, if I was more familiar with Python, that is, but using MS Excel for those programs would probably be a seriously wrong solution and maybe take 10x the time even for an Excel guru; but then again, Excel would be right solution for some other problem.
-
OK, to put it another way, looking at the system design as a whole. Now I tried this a long time ago and bought a great big book called "The linux programming interface" but was told that i was wasting my time with that. What I did gather from it is that there are several mechanisms for different programs to communicate (ports/sockets and more). So at what level of complexity do I divide my system up into multiple programs so that each can be written in whatever language best suits that or will the complexity of getting things to talk to each other outweigh the total development unless it is a seriously complicated system?
There is no generic answer, merely a range of possibilities based on the task and your experience.
Having multiple people, or companies, or geographic distribution sometimes indicates sensible boundaries. Those boundaries may, or may not, be boundaries between different languages.
Timing, especially allowable latency between event and response, can indicate boundaries.
Sometimes there is a natural conceptual boundary. For example, given an language neutral comms mechanism, an event could be generated in one language and consumed in another. (Major benefit: also allows easy unit testing upwards and downwards).
Sometimes design concepts are better expressed in one language than another, e.g. complex interacting constraints or statistical processing, or deductive inferencing.
Sometimes it would take longer to reimplement a subset of the application functionality in one language than another.
The application specification is never written in a computer language. Informal English plus domain-specific terminology and concepts is often used. A good design enables those terms and concepts to be directly visible at the top level of the implementation. That tends to push that level to be expressed in a high level language. Where some of the implementation cannot be done in that language, drop to a lower level language for small specific parts of functionality.
So, start by stating non-technical project boundaries, application domain conceptual boundaries, implementation conceptual boundaries, timing boundaries, testability boundaries. Then decide.
-
what I am saying is, will inter process/program communication something that comes with more headaches or is this fairly simple to implement.
To try and gain some control over the chaos at work I have started to break functionality into separate boards. Silly as it sounds I have a single board just to deal with push buttons and encoders, these could be handled on the display board as the two will invariably go together but it makes it easier to reuse things and change things late in the project. These boards communicate over CAN bus in CAN Open "style". When I told my boss the plan he said won't that be more work? I lied and said no, of course the biggest part of the first project i used this system on was to sort out communication, deal with timings of things so that each time a function ran to deal with data that had been presumably received that data was actually there and was not stale. It was quite a task for me to establish how to do this. Each board is almost like a dedicated program to a task that has to communicate with the other boards running their own programs.
So with this not quite behind me yet I wonder if it is worth implementing the same concept on a single computer. Write each thing that i need to do as a separate program and then rely on inter process communication to link the whole thing together.
-
what I am saying is, will inter process/program communication something that comes with more headaches or is this fairly simple to implement.
Depends on the language and environment. xC on xCORE is based on multiple communicating sequential processes, so it is trivial. But it does require a change in thinking, which seems inappropriate in your situation.
Trying to use technology to solve non-technical problems (political, social, corporate, orig chart) usually fails.
-
what I am saying is, will inter process/program communication something that comes with more headaches or is this fairly simple to implement.
There are many ways to implement IPC, and it can be very simple.
bruce@i9:~$ cat /proc/cpuinfo | grep MHz | awk '{print $4}' | sort -rn | uniq -c
1 3255.476
1 2872.828
1 2865.956
1 2592.633
1 2505.530
1 1504.742
1 1353.431
1 1108.002
1 801.379
23 800.000
Behold! IPC with five cooperating processes, coordinated by a 6th (bash).
Or, you can do it all in one process:
bruce@i9:~$ perl -ne '/^cpu MHz[\s]+: ([0-9.]+)/ and $mhz{$1}++; END {for (sort {$b <=> $a} keys %mhz){print "$mhz{$_}\t$_\n"}}' /proc/cpuinfo
1 3900.018
1 1233.901
1 1191.584
29 800.000
You can see the difference in the number of active CPUs...
The second is arguably quite a bit more efficient, the first is a lot shorter to type and easier to think about, and develop iteratively -- by adding one program at a time to the pipeline.
Either is probably Good Enough for most applications.
-
what I am saying is, will inter process/program communication something that comes with more headaches or is this fairly simple to implement.
To try and gain some control over the chaos at work I have started to break functionality into separate boards. Silly as it sounds I have a single board just to deal with push buttons and encoders, these could be handled on the display board as the two will invariably go together but it makes it easier to reuse things and change things late in the project. These boards communicate over CAN bus in CAN Open "style". When I told my boss the plan he said won't that be more work? I lied and said no, of course the biggest part of the first project i used this system on was to sort out communication, deal with timings of things so that each time a function ran to deal with data that had been presumably received that data was actually there and was not stale. It was quite a task for me to establish how to do this. Each board is almost like a dedicated program to a task that has to communicate with the other boards running their own programs.
So with this not quite behind me yet I wonder if it is worth implementing the same concept on a single computer. Write each thing that i need to do as a separate program and then rely on inter process communication to link the whole thing together.
For that you'd use an OS and interprocess communication. A simple pattern is to have an event queue between two processes (threads) and a semaphore. When a process wants something from the queue, it waits for the semaphore to become signaled by a process pushing an event into the queue. But don't use seperate processes (programs) but use threads instead so functions between threads can be called directly (using mutexes to synchronise data access). But only IF you really need processes to be asynchronous. Otherwise use a loop which does several sub-tasks.
Seperating a project into several parts / processes may seem to make things easier but in reality it becomes more complex because you are also decoupling the fault conditions. One of the bigger projects I have been working on involves converting a system with a whole bunch of seperate processes (polling the crap out of eachother through shared memory and IPC) into one big monolythic piece of software which uses events and direct function (API) calls between the various blocks.
-
... Silly as it sounds I have a single board just to deal with push buttons and encoders, ...
It sounds smart. Possible someone have told you, if you evaluate such a solution negatively yourself. I bought this thing specifically for this purpose (photo from the store).
-
what I am saying is, will inter process/program communication something that comes with more headaches or is this fairly simple to implement.
To try and gain some control over the chaos at work I have started to break functionality into separate boards. Silly as it sounds I have a single board just to deal with push buttons and encoders, these could be handled on the display board as the two will invariably go together but it makes it easier to reuse things and change things late in the project. These boards communicate over CAN bus in CAN Open "style". When I told my boss the plan he said won't that be more work? I lied and said no, of course the biggest part of the first project i used this system on was to sort out communication, deal with timings of things so that each time a function ran to deal with data that had been presumably received that data was actually there and was not stale. It was quite a task for me to establish how to do this. Each board is almost like a dedicated program to a task that has to communicate with the other boards running their own programs.
So with this not quite behind me yet I wonder if it is worth implementing the same concept on a single computer. Write each thing that i need to do as a separate program and then rely on inter process communication to link the whole thing together.
For that you'd use an OS and interprocess communication. A simple pattern is to have an event queue between two processes (threads) and a semaphore. When a process wants something from the queue, it waits for the semaphore to become signaled by a process pushing an event into the queue. But don't use seperate processes (programs) but use threads instead so functions between threads can be called directly (using mutexes to synchronise data access). But only IF you really need processes to be asynchronous. Otherwise use a loop which does several sub-tasks.
Seperating a project into several parts / processes may seem to make things easier but in reality it becomes more complex because you are also decoupling the fault conditions. One of the bigger projects I have been working on involves converting a system with a whole bunch of seperate processes (polling the crap out of eachother through shared memory and IPC) into one big monolythic piece of software which uses events and direct function (API) calls between the various blocks.
Shared memory is the distributed version of global variables, and if you don't understand what that leads to then you haven't worked on a large complex project. Polling is only a decent technique in simple and constrained circumstances. In other words it sound as if it might be a poorly architected application where the major problems are concealed by oncentrating on the myriad of small faults.
You'll have to explain why decoupling fault conditions is (a) a bad thing and (b) worse with either of the implementations you mention. Don't forget to include consideration of how arguably the largest and most complex machine made by humans works well with distributed and decoupled faults. (I.e. the telecom system)
Amongst other things, decoupling fault conditions makes it easier to point the finger. I've found that very beneficial when working with other companies; it was clear that lawyers would not help the other company :) Ditto other divisions in the same company. Concentrating minds like that enables the project to move forward faster.
-
With decoupling fault conditions I mean that the cause of a fault gets obscured when there are too many layers (software layers or different processes) between the place where the fault occurs and where it is presented to the user. The more layers you have, the more information needs to go back & forth. This is also where the OSI model tends to fall apart.
As an example: A very long time ago I implemented an ISDN protocol stack. The phone application talks to layer3 (which sits on top of the data layer and physical layer) and if it can't establish a call layer3 just says 'can't do it'. If you want to know why, you need to query the lower layers. If you implement the layers as seperate programs, the lower layers need to make a whole lot of status information available through layer3 to give the user a sensible answer. Contrary, if you implement everything in a single, monolythic program (which doesn't exclude the use of threads), the phone application can access the lower layers directly (while still ensuring data integrity through mutexes) to request status information in order to tell the user what could be wrong.
Many systems are prone to giving meaningless errors because the actual cause is buried somewhere deep in the system. Quite typical for Microsoft where you get a message and a number which have no relation to the cause. Or my solar inverter: it gives an error code saying a DSP board needs replacement when it is turned on without the panels supplying power (when it is dark outside).
I always advice people not to implement a distributed system (using several microcontrollers) unless they really have to for physical constraints. There are potential pitfalls with timing between the processes and diagnosis of problems gets harder because that information also needs to be conveyed to a central control node.
-
That also happens in monolithic single thread applications. Simple example: a divide by zero occurs; how should that be reported? As a /0 fault, a tan(90degrees) fault or matrix with a determinant of zero fault or singular matrix fault or user input error fault etc?
Fault propagation and reporting is a problem that is independent of computational architecture.
I had hopes that Java's checked exceptions would strongly encourage helpful fault reporting. Unfortunately too many weenie developers whine "too much typing" or "too much to think about" or "I don't want to think about faults" or "there's no use case for faults so I'm not rewarded for considering them".
I.e. the problem is in the corporate rewards and/or developer mentality, not in the software architecture.
-
Error handling is the prominent issue in software engineering IMO.
-
That also happens in monolithic single thread applications. Simple example: a divide by zero occurs; how should that be reported? As a /0 fault, a tan(90degrees) fault or matrix with a determinant of zero fault or singular matrix fault or user input error fault etc?
Input checking. But it is a whole lot easier to call a function called 'check_input' together with a dataset (to check) compared to needing to convey that through a bunch of IPC calls (or even communicate that between computers / microcontrollers). If that happens by accident, it is again a whole lot easier to produce the error message on a 'local' output compared to a remote one (which needs the messaging infrastructure to propagate the error in a meaningful way).
-
Error handling is the prominent issue in software engineering IMO.
Not on too many projects :(
"The green light is on because it has passed all the tests, therefore it works". But were any "non-functional" fault detection and recovery tests specified by the client? If not then then they have no value to the person with the gold. And we know.what the golden rule is :(
First you have to acknowledge the possibility of faults and partial failures, including in components you didn't know existed. That's a corporate and personality issue, not a technical one.
Then you have to be able to define a fault and detect when it has occurred. That's a technical project management issue.
Then you have to define the response.
All that is a wider subject than a typical definition of "software engineering".
-
That also happens in monolithic single thread applications. Simple example: a divide by zero occurs; how should that be reported? As a /0 fault, a tan(90degrees) fault or matrix with a determinant of zero fault or singular matrix fault or user input error fault etc?
Input checking. But it is a whole lot easier to call a function called 'check_input' together with a dataset (to check) compared to needing to convey that through a bunch of IPC calls (or even communicate that between computers / microcontrollers). If that happens by accident, it is again a whole lot easier to produce the error message on a 'local' output compared to a remote one (which needs the messaging infrastructure to propagate the error in a meaningful way).
Input checking is necessary but cannot be sufficient.
Please define how you can check inputs sufficiently thoroughly to prevent inversion of a matrix that turns out to be singular.
Ditto that a computer that you don't know exists doesn't fail halfway through a communication. Then consider the "split brain" problem. After solving those, collect the Turing Award.
Etc.
-
Error handling is the prominent issue in software engineering IMO.
Yes, and I believe there is no shortcut; it requires work. But people seem to want some kind of magical silver bullet solution, like a new language which "handles errors". Yet in reality "handling errors" is application-specific, it means "Doing The Right Thing" to recover automatically and do something sensible, or report the problem and wait for new instructions from user; both of which require design.
-
Error handling is the prominent issue in software engineering IMO.
Yes, and I believe there is no shortcut; it requires work. But people seem to want some kind of magical silver bullet solution, like a new language which "handles errors". Yet in reality "handling errors" is application-specific, it means "Doing The Right Thing" to recover automatically and do something sensible, or report the problem and wait for new instructions from user; both of which require design.
Indeed.
What I want to know is "this fault might happen, so consider what if anything you do about it", enforced by the compiler.=> Checked exceptions that must be explicitly handled or rethrown.
What I don't want is an undefined or poorly documented error deep inside a library manifesting itself at runtime.=> Some languages with exceptions bolted on as fashionable afterthought.
What I don't want is the presumption that any and every error cannot be handled, and the best thing to do is throw up your hands, surrender, and hope some undefined entity can work something out. => Unchecked exceptions for everything as in Spring.
-
January 2025 Headline: Python is TIOBE's programming language of the year 2024!
Programming language Python has won the title "TIOBE's programming language of the year 2024". This award is given to the programming language with the highest increase in ratings in one year time. Python gained a whopping 9.3% in 2024. This is far ahead of its competition: Java +2.3%, JavaScript +1.4% and Go +1.2%. Python is everywhere nowadays, and it is the undisputed default language of choice in many fields. It might even become the language with the highest ranking ever in the TIOBE index. Python's only serious drawbacks are (and thus leaving room for competition) its lack of performance and that most errors occur run-time.
Apart from this, two interesting things happened in the TIOBE index top 10 in 2024. The C language lost a lot of popularity and was surpassed by C++ and Java. The main reason for this is that C is replaced by C++ in a lot of embedded software systems. Java and C++ are currently fighthing for the top 2 position. The other interesting thing is that PHP said a final farewell to the top 10 and is replaced by Go, which is a top 10 keeper.
Lots of eyes were on Rust and Kotlin this year. Did they live up to their promises in 2024? Rust is still getting more popular. Despite the amazing speed of Rust programs, its steep learning curve will never make it become the lingua franca of the common programmer unfortunately. Kotlin, on the other hand, disappointed: it didn't break through and even lost (possibly permanently) its top 20 position in 2024.
Further down the list we see two new promising languages: Rust's competitor Zig climbed from #149 to #61 in 2024, whereas Mojo, the faster Python, jumped from position #194 to #68. Especially Mojo, which was first released only 2 years ago, addresses exactly what is needed in the programming field. I have high hopes that it will get close to a top 20 position in 2025.
Author: Paul Jansen, Chief Executive Officer
-
Error handling is the prominent issue in software engineering IMO.
Yes, and I believe there is no shortcut; it requires work. But people seem to want some kind of magical silver bullet solution, like a new language which "handles errors". Yet in reality "handling errors" is application-specific, it means "Doing The Right Thing" to recover automatically and do something sensible, or report the problem and wait for new instructions from user; both of which require design.
Handling every (reasonably) possible failure case is 80% of the development of any robust software IMHO.
An entire generation of developers have been taught to care only about the "happy path" and have been sold silver bullets that were supposed to magically allow it.
But the problem also started when software became an industry of its own rather than just be a part of product design. It started feeding off itself and making "apparent" productivity a key metric.
-
... Silly as it sounds I have a single board just to deal with push buttons and encoders, ...
It sounds smart. Possible someone have told you, if you evaluate such a solution negatively yourself. I bought this thing specifically for this purpose (photo from the store).
it is, you can buy CAN Open encoder+button units for over £200. OK, these come as a unit with the buttons and encoder that can go straight into a dashboard, I have done just the board. But still it is far cheaper and customizable.
-
... I have done just the board. ...
I understand. Consider also midi devices for control.
-
January 2025 Headline: Python is TIOBE's programming language of the year 2024!
It is difficult to say anything about Python under these circumstances. It takes almost a quarter of all programming language popularity. Despite all its limitations and despite the fact that it is an interpreted language (slow and without compile-time error validation). For my part I'm glad I learned this language years ago, although a little late (after fighting a lot with Pascal, with C and with AWK to be able to make programs inferior to what I can do with Python).
Congratulations to all Python users, because the language still has a lot of life ahead of it.
-
It takes almost a quarter of all programming language popularity.
Popularity is a spurious reason for choosing any technology.
There can, of course, be reasons derived from that which are perfectly valid. A classic example is the Hindustan Ambassador, the most popular car in India. Horribly outdated, but there were so many sold and running that every mechanic anywhere in India knew how to repair them and spares were readily available.
-
I didn't choose Python because of its popularity.
In fact when I started learning Python decades ago, Perl was much more popular and it took me a while to decide to learn Python even though it was less popular.
Today the balance has changed and I'm glad about that because it means that Python will continue to receive updates, libraries and community support.
-
I didn't choose Python because...
Wait a minute, you chose Python? What does this even mean? Chose for what, to do what?
-
At that time I had to validate a program written with visual blocks to control hundreds of emergency stop buttons. Being visual programming, the program was done manually and validated manually, so it could have failures due to human error.
The fact is that the Siemens visual programming tool used a Pascal-like language (SCL) as an intermediate language to compile later to a PLC.
It occurred to me that the SCL code generated automatically by the tool could be used to validate that all signals ended up generating a safety stop. This involved interpreting the code written in high-level SCL language to apply several validation tests to rule out errors that might have been missed in the visual and field tests.
I wrote the code validation program in Python with a tendency to be very sensitive to any errors and report them. The result was a long list of errors that we had to subsequently validate manually. Most were due to non-standard cases, but they worked fine. We also found a couple of signal connection errors that had been overlooked, which thanks to the Python validation program we were able to correct.
So the first application I used Python for was SCL code validation for a safety PLC.
SCL: https://en.wikipedia.org/wiki/Structured_Control_Language
PLC: https://en.wikipedia.org/wiki/Programmable_logic_controller
-
At first I tried to make the tool with AWK, which I already knew, but AWK was not powerful enough.
Then I considered switching to Perl, but after struggling several days with this language, a colleague recommended me to talk to the team in charge of summarizing and presenting the daily commissioning data, which was using Python. After talking to them they convinced me and I ended up choosing Python to develop the validation program.
Attached is the popularity index of that time.
https://web.archive.org/web/20040605110328/http://www.tiobe.com/ (https://web.archive.org/web/20040605110328/http://www.tiobe.com/)
-
Python macro to extract Tiobe Index image of 20 first languages from the web.
import os
import time
import datetime
from PIL import Image
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager
from selenium.webdriver.common.action_chains import ActionChains
from selenium.webdriver.common.by import By
browser_width = 600
browser_height = 1000
image_width = browser_width - 35
image_1_height = 650
image_2_height = 490
first_scroll = 780
tiobe_index_url = "https://www.tiobe.com/tiobe-index/"
def main():
year_month = datetime.datetime.now().strftime("%Y_%m")
print(f'Date: {year_month}')
image_name_1 = f'tiobe_index_{year_month}_a.png'
image_name_2 = f'tiobe_index_{year_month}_b.png'
image_name_3 = f'tiobe_index_{year_month}.png'
extract_images(image_name_1, image_name_2)
join_images(image_name_1, image_name_2, image_name_3)
def join_images(image_name_1, image_name_2, image_name_3):
if os.path.exists(image_name_3):
return
margin_top = 80
im_1 = Image.open(image_name_1)
im_2 = Image.open(image_name_2)
im_3 = Image.new('RGB', (image_width, image_1_height + image_2_height), 'white')
im_1_crop = im_1.crop((0, margin_top, image_width, margin_top + image_1_height))
im_2_crop = im_2.crop((0, margin_top + 2, image_width, margin_top + 2 + image_2_height))
im_3.paste(im_1_crop, (0, 0))
im_3.paste(im_2_crop, (0, image_1_height))
im_3.save(image_name_3)
def extract_images(image_name_1, image_name_2):
if os.path.exists(image_name_2):
return
driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()))
driver.get(tiobe_index_url)
driver.set_window_size(browser_width, browser_height)
time.sleep(5)
element = driver.find_element(By.LINK_TEXT, 'here')
actions = ActionChains(driver)
actions.move_to_element(element).perform()
driver.execute_script(f'window.scrollTo(0, window.scrollY + {first_scroll})')
time.sleep(1)
driver.save_screenshot(image_name_1)
driver.execute_script(f'window.scrollTo(0, window.scrollY + {image_1_height})')
time.sleep(1)
driver.save_screenshot(image_name_2)
driver.quit()
main()
You must click “Allow All” or “Deny” cookies when the banner appears. The program waits 5 seconds for it.
The rest of the operation is automatic.
-
That's an interesting story. Sounds like an application for which many languages work, but not all very well and some are more horrible than others. Domain-specific languages like AWK are, as name suggests, specific to a domain, so work very well for a certain thing but not general purposes. Some languages like Perl or TCL apparently give PTSD to many; they are something very few chose to use, but had to use them because of external requirements (e.g., Perl as the only server-side web language in some configurations near the turn of millennium, or TCL as the only scripting language supported by some EDA tooling).
Python seems to enjoy quite wide acceptance by actual software developers choosing it because they like it, not because it's the only possibility. I don't really understand all the hype, but yeah sure, it is good enough and the shortcomings are not too disastrous. (I don't like the v2/v3 incompatibility mess and the usual library maintainability mess such that everything breaks all the time because library interfaces change for every version and you need to basically dockerize Python interpreter plus libraries with certain versions, but it seems every other popular language (like Rust) do the same and people just accept this as being the new normal. I guess it's the price you need to pay for non-ancient library interfaces. C standard library is stable and standardized, but very old and poorly thought out initially so you need to implement many small and trivial things for yourself from scratch.)
-
Yes, there should be a middle ground between standardization and actuality.
Python's lack of standardization is a headache. For my website I have made a "virtual environment" with versions from years ago, which I don't update because it breaks compatibility with the version of theme that is customized. Recently I wanted to install a new library (rst2pdf) to print the whole web page to PDF, but the new version of the Jinja2 library is incompatible with the old version of Sphinx.
So, I've decided to upgrade all the libraries (Sphinx, Read the Docs, rst2pdf, etc) to a current version and customize the theme (Read the Docs) again. It is a tedious and laborious work that can leave errors in the web site until I correct them all, but it has been more than 10 years since I last upgraded the libraries and an update is needed.
-
Yeah, let's have some fun.
https://www.youtube.com/watch?v=BgxklT94W0I (https://www.youtube.com/watch?v=BgxklT94W0I)
-
There is a saying that explains it well: "People only throw stones at the tree with fruit".
Concerning Perl, nobody tell anything.
-
Concerning Perl, nobody tell anything.
It's nearly forgotten now, that's why. I remember that still 10 years ago one could hear comments like "thank God I don't have to deal with Perl anymore".
I have never written more than a few lines of Perl myself, so I don't really understand why it is considered such horrible language; on surface, it does not look like one; in fact I see a lot of similarity with Python. But I guess the fact that most were happy to replace it with PHP tells a sad story.
-
Concerning Perl, nobody tell anything.
It's nearly forgotten now, that's why. I remember that still 10 years ago one could hear comments like "thank God I don't have to deal with Perl anymore".
I have never written more than a few lines of Perl myself, so I don't really understand why it is considered such horrible language; on surface, it does not look like one; in fact I see a lot of similarity with Python. But I guess the fact that most were happy to replace it with PHP tells a sad story.
I don't get it. I like Perl. There is a certain class of problem -- generally quite small programs -- for which it is excellent.
Here's a Perl program I wrote: https://hoult.org/logbook
It processes a file like this ....
serial date rego hours minutes launch crew comment
1 07/09/85 KN 15 A P2
2 07/09/85 KN 20 A P2
3 07/09/85 KN 15 A P2
4 28/09/85 HW 59 A P2
5 29/09/85 HW 1 4 A P2
6 20/10/85 KN 16 A P2
7 20/10/85 KN 16 A P2
8 20/10/85 KN 15 A P2
9 17/11/85 KN 18 A P2
... and a file like this ...
rego type
274KS ASK21
EX Ka6CR
EY Ka6CR
DG DG1000
FQ T53
FY ASK13
GA Phoebus C
GZ Std Libelle
HT Blanik
... both easily edited in any spreadsheet or text editor, into this ...
Logbook stats from flight 1 to 9999
Glider Flights Total PIC
====== ======= ====== ======
LM 81 70:51 64:09
IP 36 56:55 56:55
PJ 76 45:13 44:21
GR 87 44:43 44:13
EX 19 25:24 25:24
KN 56 24:13 12:49
WN 18 19:39 19:39
HT 32 12:18 8:46
GZ 9 9:32 9:32
WZ 12 9:06 7:58
HW 16 7:33 3:54
TA 20 7:24 5:46
WG 7 6:39 6:39
274KS 6 2:42 2:42
DG 1 2:30 0:00
MS 4 2:09 2:09
NE 2 2:00 2:00
LV 16 1:52 0:14
IJ 3 1:32 1:15
NW 5 1:31 0:00
N4793N 1 1:13 1:13
N57CG 1 1:07 0:00
PC 1 1:02 0:00
EY 2 1:02 1:02
SH 2 0:46 0:43
N999KS 1 0:45 0:45
FY 6 0:38 0:28
FQ 1 0:37 0:00
NP 1 0:35 0:00
IN 1 0:34 0:00
GA 1 0:33 0:33
MY 1 0:30 0:00
JT 1 0:19 0:19
KW 1 0:09 0:00
Glider Type Flights Total PIC Avg
=============== ======= ====== ====== ===
DG1000 164 92:26 88:34 34
Janus 83 71:37 64:52 52
Club Libelle 36 56:55 56:55 95
Blanik 110 46:56 27:38 26
Ka6CR 21 26:26 26:26 76
PW-5 25 26:18 26:18 63
Grob 103 37 20:48 16:57 34
Std Libelle 9 9:32 9:32 64
ASK21 7 3:27 3:27 30
ASK13 9 2:10 1:43 14
Ka7 16 1:52 0:14 7
Grob 109 5 1:31 0:00 18
Duo Discus 1 1:07 0:00 67
Puchacz 1 1:02 0:00 62
T53 1 0:37 0:00 37
Phoebus C 1 0:33 0:33 33
Pirat 1 0:19 0:19 19
Crew Flights Time Avg
==== ======= ====== ===
P 93 120:03 77
P1 321 203:25 38
P2 113 40:08 21
Launch flights
====== =======
A 496
S 5
W 26
Total flights: 527
Total Time : 363:36
Total PIC : 323:28
-
There is a saying that explains it well: "People only throw stones at the tree with fruit".
Concerning Perl, nobody tell anything.
I don't know about "nobody", but this guy also has a comedy sketch for Perl programmers:
https://www.youtube.com/watch?v=0jK0ytvjv-E (https://www.youtube.com/watch?v=0jK0ytvjv-E)
-
I prefer Python code.
I know it is slower, but it is much easier to read.
import sys
from collections import defaultdict
start_flight = int(sys.argv[1]) if len(sys.argv) > 1 else 1
end_flight = int(sys.argv[2]) if len(sys.argv) > 2 else 9999
print(f"Logbook stats from flight {start_flight} to {end_flight}")
def get_file(filename):
data = defaultdict(dict)
with open(filename, 'r') as f:
headers = f.readline().strip().split("\t")
for line in f:
fields = line.strip().split("\t")
for i, field in enumerate(fields):
data[fields[0]][headers[i]] = field
return data
def print_header(*args):
print("\n\n" + "\t".join(args))
print("\t".join("=" * len(arg) for arg in args))
def hhmm(minutes):
hh = minutes // 60
mm = minutes % 60
return f"{hh:3}:{mm:02}"
flights = get_file("flights")
gliders = get_file("gliders")
total_flights = 0
total_time = 0
total_time_pic = 0
by_glider = defaultdict(lambda: defaultdict(int))
by_type = defaultdict(lambda: defaultdict(int))
by_crew = defaultdict(lambda: defaultdict(int))
by_launch = defaultdict(int)
for f in flights.values():
serial = int(f['serial'])
time = int(f['hours']) * 60 + int(f['minutes'])
if serial < start_flight or serial > end_flight:
continue
crew = f['crew']
pic_time = time if crew != "P2" else 0
rego = f['rego']
glider = gliders[rego]
glider_type = glider['type']
launch = f['launch']
total_flights += 1
total_time += time
total_time_pic += pic_time
by_glider[rego]['flights'] += 1
by_glider[rego]['time'] += time
by_glider[rego]['timePIC'] += pic_time
by_type[glider_type]['flights'] += 1
by_type[glider_type]['time'] += time
by_type[glider_type]['timePIC'] += pic_time
by_crew[crew]['flights'] += 1
by_crew[crew]['time'] += time
by_launch[launch] += 1
print_header("Glider", "Flights", " Total", " PIC")
for rego in sorted(by_glider, key=lambda k: by_glider[k]['time'], reverse=True):
print(f"{rego}\t{by_glider[rego]['flights']}\t"
f"{hhmm(by_glider[rego]['time'])}\t"
f"{hhmm(by_glider[rego]['timePIC'])}")
print_header("Glider Type ", "Flights", " Total", " PIC", "Avg")
for glider_type in sorted(by_type, key=lambda k: by_type[k]['time'], reverse=True):
avg = int(by_type[glider_type]['time'] / by_type[glider_type]['flights'] + 0.5)
print(f"{glider_type:<15}\t{by_type[glider_type]['flights']}\t"
f"{hhmm(by_type[glider_type]['time'])}\t"
f"{hhmm(by_type[glider_type]['timePIC'])}\t{avg}")
print_header("Crew", "Flights", " Time", "Avg")
for crew in sorted(by_crew):
avg = int(by_crew[crew]['time'] / by_crew[crew]['flights'] + 0.5)
print(f"{crew}\t{by_crew[crew]['flights']}\t"
f"{hhmm(by_crew[crew]['time'])}\t{avg}")
print_header("Launch", "Flights")
for launch in sorted(by_launch):
print(f"{launch}\t{by_launch[launch]}")
print(f"\nTotal flights: {total_flights}")
print(f"Total Time : {hhmm(total_time)}")
print(f"Total PIC : {hhmm(total_time_pic)}")
-
I prefer Python code.
I know it is slower, but it is much easier to read.
Possibly, but it doesn't like interpreting an empty string as an integer
File "/Users/bruce/people/bruce/gliding/logbook/calc.py", line 42, in <module>
time = int(f['hours']) * 60 + int(f['minutes'])
~~~^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
Which version of Python is required to run that code? Does it need 3, or will 2 do?
-
File "/Users/bruce/people/bruce/gliding/logbook/calc.py", line 42, in <module>
time = int(f['hours']) * 60 + int(f['minutes'])
~~~^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
Try
time = int('0' + f['hours'], 10) * 60 + int('0' + f['minutes'], 10)
or
time = int('0' + f.get('hours', ''), 10) * 60 + int('0' + f.get('minutes', ''), 10)
instead.
I personally prefer awk for these. It was designed for this kind of thing, after all. (You will want to read all but the largest data file in BEGIN handler, though.)
My personal avoidance of Perl stems from having had to maintain/extend/support a horrible Perl web service code base for a few years, written by people I really do like. I'm a simple man, and don't deal well with such complicated emotions! :D
The reason for many switching from Perl to PHP for server-side scripting was more due to PHP providing a cgi interpreter and web hotels providing PHP backends, and PR work by the Zend and PHP folks, than anything else. Of course, many more learners were drawn toward PHP (instead of Perl) because of the perceived ease of use of PHP compared to Perl; Perl syntax is much more dense/varied/detailed than PHP's, which is quite close to BASIC or C in its (lack of) complexity. (I mean, compare the complexity of the lexers/parsers for these languages.)
-
I used to program a lot of tasks in AWK before I learned Python. Then, to help learn Python, I dropped AWK. I often miss it for its simplicity and power in this type of task. The problem is that I haven't used it in years and I'm very rusty on AWK.
-
It looks like the examples you gave can be written using Lua with relative ease, without the hundreds of MB, all the headaches due to dependencies and the whitespace nonsense. And much easier to read than Perl.
But Lua is not in TIOBE's top 20, so I guess it's off-limits.
-
Lua is great!
Position 27 of Tiobe index in january, 2025.
It has few libraries, which is its weak point.
January 2025 Tiobe Index. Other programming languages.
21 Prolog 0.92%
22 Classic Visual Basic 0.89%
23 SAS 0.79%
24 Lisp 0.75%
25 Kotlin 0.74%
26 Ada 0.65%
27 Lua 0.59%
28 (Visual) FoxPro 0.55%
29 Transact-SQL 0.54%
30 Scala 0.49%
31 Julia 0.49%
32 Perl 0.49%
33 Dart 0.48%
34 Haskell 0.46%
35 Objective-C 0.36%
36 VBScript 0.33%
37 Bash 0.29%
38 ABAP 0.27%
39 Solidity 0.26%
40 GAMS 0.24%
41 PowerShell 0.22%
42 TypeScript 0.22%
43 PL/SQL 0.22%
44 Elixir 0.18%
45 D 0.16%
46 Logo 0.16%
47 RPG 0.15%
48 Awk 0.15%
49 ML 0.15%
50 X++ 0.15%
The following list of languages denotes #51 to #100.
Since the differences are relatively small,
the programming languages are only listed
(in alphabetical order).
ABC, ActionScript, Algol, Apex, APL, CFML,
CHILL, Clipper, CLIPS, Clojure, Curl, Elm,
Erlang, F#, Forth, Groovy, Hack, Icon, Inform,
Io, J#, JScript, LabVIEW, Ladder Logic,
Modula-2, Mojo, MQL5, NATURAL, Nim,
OCaml, Occam, OpenCL, OpenEdge ABL,
PL/I, PostScript, Q, Ring, S, Scheme,
Simulink, Smalltalk, SPARK, SPSS, Stata,
SystemVerilog, Tcl, Vala/Genie, VHDL,
Wolfram, Zig
-
time = int('0' + f['hours'], 10) * 60 + int('0' + f['minutes'], 10)
That's simpler than the ternary operator I was thinking of, which is rather verbose in Python.
Though it looks to me as if this Perlish idiom works too:
time = int(f['hours'] or 0) * 60 + int(f['minutes'] or 0)
I personally prefer awk for these. It was designed for this kind of thing, after all. (You will want to read all but the largest data file in BEGIN handler, though.)
Perl is strictly more powerful than awk. All awk scripts can be trivially converted to Perl, and indeed Perl has always come with converters for awk and sed.
I'm not sure, but I may have written this Perl script before Python existed, or at least became popular. Certainly before Python 2. It could well have been in 1992 when I started flying a lot more, and in different types of aircraft (Ka6, Libelle).
-
On Gentoo, talking about Catalyst:
Perl is more problematic than awk.
Python is more problematic than Perl.
Awk is faster than Perl.
Perl is faster than Python.
Conclusion: I prefer awk scripts :D
-
This is ChatGPT's translation of the Perl program into AWK language. I think you can easily see the difference with Python and why I didn't go back to using AWK.
BEGIN {
# Initialize variables
startFlight = ARGV[1] ? ARGV[1] : 1
endFlight = ARGV[2] ? ARGV[2] : 9999
totalFlights = 0
totalTime = 0
totalTimePIC = 0
print "Logbook stats from flight " startFlight " to " endFlight
# Function to format time in hh:mm
function hhmm(minutes) {
hh = int(minutes / 60)
mm = minutes % 60
if (hh < 10) hh = "0" hh
if (mm < 10) mm = "0" mm
return hh ":" mm
}
# Read the flights file
while ((getline < "flights") > 0) {
split($0, fields, "\t")
flightData[fields[1]] = fields
}
# Read the gliders file
while ((getline < "gliders") > 0) {
split($0, fields, "\t")
gliderData[fields[1]] = fields
}
}
# Process each flight
{
flight = $0
flightDetails = flightData[$1] # Get flight details
if (flightDetails == "") next # If no data, skip this line
serial = flightDetails[1]
time = flightDetails[2] * 60 + flightDetails[3]
if (serial < startFlight || serial > endFlight) next
crew = flightDetails[4]
PICtime = (crew != "P2") ? time : 0
rego = flightDetails[5]
glider = gliderData[rego]
type = glider[1]
launch = flightDetails[6]
totalFlights++
totalTime += time
totalTimePIC += PICtime
# Track data by glider
byGlider[rego, "flights"]++
byGlider[rego, "time"] += time
byGlider[rego, "timePIC"] += PICtime
# Track data by glider type
byType[type, "flights"]++
byType[type, "time"] += time
byType[type, "timePIC"] += PICtime
# Track data by crew
byCrew[crew, "flights"]++
byCrew[crew, "time"] += time
# Track data by launch type
byLaunch[launch]++
}
END {
# Print data by glider
print "\n\nGlider", "Flights", " Total", " PIC"
for (glider in byGlider) {
if (byGlider[glider, "time"] > 0) {
printf "%s\t%d\t%s\t%s\n",
glider,
byGlider[glider, "flights"],
hhmm(byGlider[glider, "time"]),
hhmm(byGlider[glider, "timePIC"])
}
}
# Print data by glider type
print "\n\nGlider Type", "Flights", " Total", " PIC", "Avg"
for (type in byType) {
if (byType[type, "time"] > 0) {
avg = int(byType[type, "time"] / byType[type, "flights"] + 0.5)
printf "%-15s\t%d\t%s\t%s\t%d\n",
type,
byType[type, "flights"],
hhmm(byType[type, "time"]),
hhmm(byType[type, "timePIC"]),
avg
}
}
# Print data by crew
print "\n\nCrew", "Flights", " Time", "Avg"
for (crew in byCrew) {
avg = int(byCrew[crew, "time"] / byCrew[crew, "flights"] + 0.5)
printf "%s\t%d\t%s\t%d\n",
crew,
byCrew[crew, "flights"],
hhmm(byCrew[crew, "time"]),
avg
}
# Print data by launch type
print "\n\nLaunch", "flights"
for (launch in byLaunch) {
printf "%s\t%d\n", launch, byLaunch[launch]
}
# Print totals
print "\nTotal flights: " totalFlights
print "Total Time : " hhmm(totalTime)
print "Total PIC : " hhmm(totalTimePIC)
}
-
What about Ruby?
-
I think Ruby is very similar to Python and, if Python didn't exist, I would use Ruby as an alternative.
For me the problem with Ruby is that I knew it existed when I had already learned Python, so I didn't have much incentive to learn this language.
When I have some time I will translate the program to Ruby.
start_flight = ARGV[0]&.to_i || 1
end_flight = ARGV[1]&.to_i || 9999
puts "Logbook stats from flight #{start_flight} to #{end_flight}"
def get_file(filename)
data = {}
File.open(filename, "r") do |file|
headers = file.readline.chomp.split("\t")
file.each_line do |line|
fields = line.chomp.split("\t")
key = fields[0]
fields.each_with_index do |field, i|
data[key] ||= {}
data[key][headers[i]] = field
end
end
end
data
end
def print_header(*headers)
puts "\n\n" + headers.join("\t")
puts headers.map { |h| "=" * h.length }.join("\t")
end
def hhmm(minutes)
hh = minutes / 60
mm = minutes % 60
format("%3d:%02d", hh, mm)
end
flights = get_file("flights")
gliders = get_file("gliders")
total_flights = 0
total_time = 0
total_time_pic = 0
by_glider = Hash.new { |h, k| h[k] = { flights: 0, time: 0, time_pic: 0 } }
by_type = Hash.new { |h, k| h[k] = { flights: 0, time: 0, time_pic: 0 } }
by_crew = Hash.new { |h, k| h[k] = { flights: 0, time: 0 } }
by_launch = Hash.new(0)
flights.values.each do |f|
serial = f["serial"].to_i
time = f["hours"].to_i * 60 + f["minutes"].to_i
next if serial < start_flight || serial > end_flight
crew = f["crew"]
pic_time = crew != "P2" ? time : 0
rego = f["rego"]
glider = gliders[rego]
type = glider["type"]
launch = f["launch"]
total_flights += 1
total_time += time
total_time_pic += pic_time
by_glider[rego][:flights] += 1
by_glider[rego][:time] += time
by_glider[rego][:time_pic] += pic_time
by_type[type][:flights] += 1
by_type[type][:time] += time
by_type[type][:time_pic] += pic_time
by_crew[crew][:flights] += 1
by_crew[crew][:time] += time
by_launch[launch] += 1
end
print_header("Glider", "Flights", " Total", " PIC")
by_glider.sort_by { |_k, v| -v[:time] }.each do |rego, data|
puts "#{rego}\t#{data[:flights]}\t#{hhmm(data[:time])}\t#{hhmm(data[:time_pic])}"
end
print_header("Glider Type", "Flights", " Total", " PIC", "Avg")
by_type.sort_by { |_k, v| -v[:time] }.each do |type, data|
avg = (data[:time] / data[:flights].to_f).round
puts "#{type.ljust(15)}\t#{data[:flights]}\t#{hhmm(data[:time])}\t#{hhmm(data[:time_pic])}\t#{avg}"
end
print_header("Crew", "Flights", " Time", "Avg")
by_crew.each do |crew, data|
avg = (data[:time] / data[:flights].to_f).round
puts "#{crew}\t#{data[:flights]}\t#{hhmm(data[:time])}\t#{avg}"
end
print_header("Launch", "Flights")
by_launch.each do |launch, count|
puts "#{launch}\t#{count}"
end
puts "\nTotal flights: #{total_flights}"
puts "Total Time : #{hhmm(total_time)}"
puts "Total PIC : #{hhmm(total_time_pic)}"
-
Having used Smalltalk in the 80s, I looked at Ruby, decided it was a me-too language with insufficient benefits over established languages, and hence only worth learning when necessary. As with other such languages Delphi, C#, I never regretted that decision.
Ruby has the disadvantages of untyped languages with none of the advantages, and is single threaded. Plain old Java (not J2EE nor Spring) is much better in all respects.
-
January 2025 Tiobe Index. Other programming languages.
21 Prolog 0.92%
22 Classic Visual Basic 0.89%
23 SAS 0.79%
24 Lisp 0.75%
25 Kotlin 0.74%
26 Ada 0.65%
27 Lua 0.59%
28 (Visual) FoxPro 0.55%
29 Transact-SQL 0.54%
30 Scala 0.49%
31 Julia 0.49%
32 Perl 0.49%
33 Dart 0.48%
34 Haskell 0.46%
35 Objective-C 0.36%
36 VBScript 0.33%
37 Bash 0.29%
38 ABAP 0.27%
39 Solidity 0.26%
40 GAMS 0.24%
41 PowerShell 0.22%
42 TypeScript 0.22%
43 PL/SQL 0.22%
44 Elixir 0.18%
45 D 0.16%
46 Logo 0.16%
47 RPG 0.15%
48 Awk 0.15%
49 ML 0.15%
50 X++ 0.15%
69 Inform
70 Io
71 J#
72 JScript
73 LabVIEW
74 Ladder Logic
75 Modula-2
76 Mojo
77 MQL5
78 NATURAL
79 Nim
80 OCaml
81 Occam
82 OpenCL
83 OpenEdge ABL
84 PL/I
85 PostScript
86 Q
87 Ring
88 S
89 Scheme
90 Simulink
91 Smalltalk
92 SPARK
93 SPSS
94 Stata
95 SystemVerilog
96 Tcl
97 Vala/Genie
98 VHDL
99 Wolfram
100 Zig
What happened to 51-68? Which did you use to massage this data? PERL, AWK, Python, ...? ;)
-
I formatted them by hand with Excel and made a mistake. It is now corrected.
-
I formatted them by hand with Excel and made a mistake. It is now corrected.
I think if "by hand in Excel" was a valid option in TIOBE index, it would be close to #1 in popularity.
-
;D
Also don't forget that the "popularity" as estimated by TIOBE is just based on statistics of how often people talk about a given language online, and it doesn't look like their algorithm is particularly sophisticated. So, as we have probably already said numerous times, while it'll be reasonably correlated with how much people use a given language worldwide compared to others, the reasons people talk about it are undoubtedly varied, and a language that has many quirks is more likely to be talked about online more often than others, as people overall tend to talk more about their problems/look for solutions and the negative side of things, rather than the positive one.
If I was the author/maintainer of a programming language, I would be happier seeing how many projects there are with it, and I'd be more concerned seeing how much it's talked about online, knowing that 80% of what's being talked about would probably show how badly designed it is. Well designed tools should require minimal assistance. ;D
-
If I was the author/maintainer of a programming language, I would be happier seeing how many projects there are with it
https://landscape.cncf.io/stats
Although this particular source is problem domain specific and will naturally exclude important use-cases which would greatly alter the balance, such as embedded development. However, it does give a useful insight if comparing apples to apples.
-
There's also this, which purports to be sourced from GitHub pull requests. Which if so, would reflect a much wider range of problem domains and on a far greater scale.
https://madnight.github.io/githut/#/pull_requests/2024/1
-
There is a problem with the method of using search engines on the amount of entries that exist about a language. Since ChatGPT appeared two years ago, the visits on stackoverflow have dropped significantly. There is a growing tendency to ask questions to large language models (LLMs) instead of asking questions to other programmers.
-
February 2025 Headline: Fast, faster, fastest!
Now that the world needs to crunch more and more numbers per second, and hardware is not evolving fast enough, speed of programs is getting important. Having said this, it is not surprising that the fast programming languages are gaining ground in the TIOBE index. Programming language C++ climbed to position 2 recently, Go has become a steady top 10 player, and Rust is at an all-time high of 1.47%. Moreover, fast languages Mojo and Zig are knocking on the top 50 door at positions #51 and #56, respectively.
You might wonder how Python, known as a slow language, is able to survive next to these race monsters. This is because there is another driver nowadays except for performance: how easy is it to learn a new programming language. Apart from crunching more numbers, the world also needs more programmers. Developing applications completely in AI is not possible yet. Hence, the demand for new programmers is still very high. Since the number of graduated software engineers is lower than is needed, all kind of non-software engineers are jumping on the programming bandwagon, and their favorite language is Python. This is why Python is here to stay.
Author: Paul Jansen, Chief Executive Officer
-
March 2025 Headline: The dinosaurs strike back
It is interesting to see that very old languages are sneaking into the TIOBE index top 20. Fortran and Delphi are competing for a top 10 position, whereas COBOL and this month's new entry Ada are a little bit further down the list. All of them show an uptrend. Why is this? Why aren't the new and promising languages shining instead?
I think that it has to do with the many vital legacy systems that keep the world running. Most of them are developed with the aid of these dinosaur languages. Now that the last of the core developers of these systems are about to retire, companies avoid any risk and choose to keep the existing systems and even extend them rather than replacing them by newer systems based on more modern languages. Note that we name these languages dinosaurs, but they have evolved over time and are pretty up to date. All of them have new language definitions. Check out Fortran 2023, Delphi 12 (released in 2024), Ada 2023 and COBOL 2023. We might frown to see these languages being in the TIOBE index top 20, but they definitely serve a purpose and deserve credit.
Author: Paul Jansen, Chief Executive Officer
-
April 2025 Headline: Former top 20 players Kotlin, Ruby and Swift have a hard time
The programming languages Kotlin, Ruby and Swift all held very stable top 20 positions in the TIOBE index until recently. But now they seem to have lost traction and are likely to go out of fashion. Kotlin and Swift have the same reason why they are declining. They are both mainly used for one particular mobile platform, Android and iOS, respectively, whereas there are other sufficiently good languages and frameworks to develop cross platform nowadays. Yes, Swift can be used for Android development but it is pretty difficult. And Kotlin on iOS never really took off. Ruby is another story. For many years Ruby has been competing with Python and Perl. While Perl was declining, Ruby stabilized. But now that Python has become the lingua franca in the programming world, there is not much room left for Ruby.
Another interesting observation is that the programming language world is in a consolidation phase. The top 20 languages currently cover 83.56% of the total market. This is a very high number; it usually is around 75%. This means that the market is a bit defensive, preferring proven technology to trying out new technologies.
Author: Paul Jansen, Chief Executive Officer
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular web sites Google, Amazon, Wikipedia, Bing and more than 20 others are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.
TIOBE Programming Community Index Definition (https://www.tiobe.com/tiobe-index/programminglanguages_definition/)
-
People are forgetting Rust. I'm enjoying this :-DD
-
I like seeing Object Pascal much higher up than Rust. :-DD
-
Here is yet another way to compare programming languages. Note: Don't let the use of the subjective word "popularity" in the title mislead you:
https://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity/Full_list
-
People are forgetting Rust. I'm enjoying this :-DD
14, 13, 14, 18 so far this year. Peaked?
-
People are forgetting Rust. I'm enjoying this :-DD
14, 13, 14, 18 so far this year. Peaked?
And 17 13 14 14 13 14 14 last year from June to December, with "Year ago" figures between 17 and 20.
Never ask a man if they use Rust [1] .. if they do they'll already have told you. If they don't, why offend them?
[1] see also from Sparta, from Texas, do crossfit, use cryptocurrency, drink craft beer, are a gamer etc
-
May 2025 Headline: Python rules the world
Python's popularity increased with another whopping 2.2% last month to 25.35% in total. This 25.35% is the highest share a programming language ever had in the history of the TIOBE index, except for Java in June 2001 (which was the first month of the TIOBE index with much fewer languages being tracked) and October 2001. Python also broke another record: it is the first time a language has such a big lead over the rest, i.e. more than 15% difference if compared to number 2 C++. The only reason other languages still have a reason for existing is because of Python's low performance, and the fact that it is interpreted and thus prone to unexpected run-time errors. This means that safety-critical and/or real-time systems still have to rely on other languages, but in most other domains Python is slowly but surely finding its way to the top.
Author: Paul Jansen, Chief Executive Officer
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular web sites Google, Amazon, Wikipedia, Bing and more than 20 others are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.
TIOBE Programming Community Index Definition (https://www.tiobe.com/tiobe-index/programminglanguages_definition/)
-
Rust keeps falling, soon off the top20 list :-DD :-DD :-DD
-
Rust keeps falling, soon off the top20 list :-DD :-DD :-DD
meanwhile it's making more and more damage, replacing bits and pieces in ubuntu. Even though to me people deserve that for using anything canonical, it's a risk for any other distro out there.
-
Rust keeps falling, soon off the top20 list :-DD :-DD :-DD
meanwhile it's making more and more damage, replacing bits and pieces in ubuntu. Even though to me people deserve that for using anything canonical, it's a risk for any other distro out there.
Yes. The more concerning part is the attempt to push it into the Linux kernel itself.
-
Rust keeps falling, soon off the top20 list :-DD :-DD :-DD
meanwhile it's making more and more damage, replacing bits and pieces in ubuntu. Even though to me people deserve that for using anything canonical, it's a risk for any other distro out there.
Yes. The more concerning part is the attempt to push it into the Linux kernel itself.
It's almost like how in the 80s we head-faked the soviets into using Ada, except this time it's probably the other way around.
-
Rust keeps falling, soon off the top20 list :-DD :-DD :-DD
meanwhile it's making more and more damage, replacing bits and pieces in ubuntu. Even though to me people deserve that for using anything canonical, it's a risk for any other distro out there.
Yes. The more concerning part is the attempt to push it into the Linux kernel itself.
I've looked a bit at the various Rusty bits in the kernel, and I must say I would be much more interested in having a pure Rust port/rewrite/reimplementation of the core Linux kernel, than mixing the two in the same codebase.
Even having a Rust-only subsystem would be fine by me. It's using two different programming languages "randomly" to implement similar things, and all the necessary compatibility/interface mess and long-term maintenance debt it causes, that makes me believe it is wasted effort. In a way, it very much reminds me of how PHP became the mess it is.
-
In my opinion, Rust is ok for userspace tools and apps, but I wouldn't recommend it for writing any firmware.
-
I wouldn't recommend it for anything, but those interested in a full Rust OS can have a look at Redox: https://www.redox-os.org/ (https://www.redox-os.org/)
-
In my opinion, Rust is ok for userspace tools and apps, but I wouldn't recommend it for writing any firmware.
I think the opposite. The BDSM is ok for things such as medical devices, aerospace, nuclear or things when it's ok to spend infinite amounts of time polishing code because a billion people are going to run it all day.
But regular apps mostly want safety combined with productivity in being able to write a lot of functionality quickly. Dynamically-typed languages with garbage collection are much better for that than languages where you have to prove to the compiler that you know the type and lifetime and ownership of every single value.
-
Rust? DO178b is problematic with it.
Test reports are difficult to manage.
-
June 2025 Headline: Where is SQL going?
SQL has a remarkable history in the TIOBE index. When the TIOBE index started in 2001, SQL was one of the 20 languages that were tracked. It was a serious top 10 player at that time. In the beginning of 2004, somebody noted that SQL was not a programming language. After lots of debates, it was decided to take SQL from the list. It was in 2018 that somebody else pointed out to us that SQL is Turing complete, albeit in a tricky way. And if you are Turing complete, you are considered to be a programming language. Hence, as of that moment SQL was readded to the TIOBE index and, since databases and SQL go hand in hand, SQL became a top 10 player again.
Remarkably, SQL has started dropping slowly recently. This month it is at position #12, which is its lowest position in the TIOBE index ever. SQL will remain the backbone and lingua franca of databases for decades to come. However, in the booming field of AI, where data is usually unstructured, NoSQL databases are often a better fit. NoSQL (which uses data interchange formats such as JSON and XML) has become a serious threat for the well-defined but rather static SQL approach. NoSQL's popularity is comparable to the rise of dynamically typed languages such as Python if compared to well-defined statically typed programming languages such as C++ and Java.
Author: Paul Jansen, Chief Executive Officer
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular web sites Google, Amazon, Wikipedia, Bing and more than 20 others are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.
TIOBE Programming Community Index Definition (https://www.tiobe.com/tiobe-index/programminglanguages_definition/)
-
Rust history update: 17 13 14 14 13 14 14 14 13 14 18 19 18
Dead cat bounce?
-
https://nindalf.com/posts/stop-citing-tiobe/
Should i reply with this every time this thread gets bumped? TIOBE is a retarded concept, it should not merit any attention
-
https://nindalf.com/posts/stop-citing-tiobe/
Should i reply with this every time this thread gets bumped? TIOBE is a retarded concept, it should not merit any attention
You can hit the "IGNORE TOPICS" button on it and never see it again. I do to a dozen threads a day.
-
https://nindalf.com/posts/stop-citing-tiobe/
Should i reply with this every time this thread gets bumped? TIOBE is a retarded concept, it should not merit any attention
You can hit the "IGNORE TOPICS" button on it and never see it again. I do to a dozen threads a day.
https://xkcd.com/386/
:)
-
It's just been pointed out on Reddit that in the latest ranking assembly language has overtaken Rust.
-
October 2025
[attachimg=2]
-
Apparently recent GO for windows requires crypto libraries to compile a minimal program.
(Incidentally a library that is not available for W7)
I'm not impressed.
https://forum.arduino.cc/t/ports-not-recognized-by-arduino-ide-on-windows-7/1413296/6