Author Topic: TIOBE Index of programming languages  (Read 10825 times)

0 Members and 2 Guests are viewing this topic.

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #100 on: January 04, 2025, 03:52:23 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 18132
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: TIOBE Index of programming languages
« Reply #101 on: January 04, 2025, 04:23:58 pm »
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?
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9475
  • Country: fi
Re: TIOBE Index of programming languages
« Reply #102 on: January 04, 2025, 07:10:02 pm »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #103 on: January 04, 2025, 08:11:57 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 18132
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: TIOBE Index of programming languages
« Reply #104 on: January 04, 2025, 08:52:31 pm »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #105 on: January 04, 2025, 09:00:23 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4840
  • Country: nz
Re: TIOBE Index of programming languages
« Reply #106 on: January 04, 2025, 09:03:57 pm »
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.

Code: [Select]
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:

Code: [Select]
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.
« Last Edit: January 04, 2025, 09:10:08 pm by brucehoult »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28508
  • Country: nl
    • NCT Developments
Re: TIOBE Index of programming languages
« Reply #107 on: January 05, 2025, 04:55:58 pm »
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.
« Last Edit: January 05, 2025, 05:16:54 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Postal2

  • Frequent Contributor
  • **
  • !
  • Posts: 826
  • Country: 00
Re: TIOBE Index of programming languages
« Reply #108 on: January 05, 2025, 05:16:40 pm »
... 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).
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #109 on: January 05, 2025, 05:59:49 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28508
  • Country: nl
    • NCT Developments
Re: TIOBE Index of programming languages
« Reply #110 on: January 05, 2025, 07:52:29 pm »
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.
« Last Edit: January 05, 2025, 08:22:58 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #111 on: January 05, 2025, 08:26:27 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15948
  • Country: fr
Re: TIOBE Index of programming languages
« Reply #112 on: January 05, 2025, 09:39:07 pm »
Error handling is the prominent issue in software engineering IMO.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28508
  • Country: nl
    • NCT Developments
Re: TIOBE Index of programming languages
« Reply #113 on: January 05, 2025, 11:40:49 pm »
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).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #114 on: January 05, 2025, 11:52:53 pm »
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".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #115 on: January 05, 2025, 11:58:32 pm »
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.
« Last Edit: January 06, 2025, 12:00:12 am by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9475
  • Country: fi
Re: TIOBE Index of programming languages
« Reply #116 on: January 06, 2025, 10:06:36 am »
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.
« Last Edit: January 06, 2025, 11:06:29 am by Siwastaja »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #117 on: January 06, 2025, 11:26:04 am »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1084
  • Country: es
    • Picuino web
Re: TIOBE Index of programming languages
« Reply #118 on: January 06, 2025, 06:24:28 pm »
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
« Last Edit: January 06, 2025, 06:33:08 pm by Picuino »
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15948
  • Country: fr
Re: TIOBE Index of programming languages
« Reply #119 on: January 06, 2025, 08:00:50 pm »
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.
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 18132
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: TIOBE Index of programming languages
« Reply #120 on: January 06, 2025, 08:01:40 pm »
... 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.
 

Offline Postal2

  • Frequent Contributor
  • **
  • !
  • Posts: 826
  • Country: 00
Re: TIOBE Index of programming languages
« Reply #121 on: January 07, 2025, 04:58:05 am »
... I have done just the board. ...
I understand. Consider also midi devices for control.
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1084
  • Country: es
    • Picuino web
Re: TIOBE Index of programming languages
« Reply #122 on: January 07, 2025, 10:40:37 am »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #123 on: January 07, 2025, 12:07:46 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: cfbsoftware

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1084
  • Country: es
    • Picuino web
Re: TIOBE Index of programming languages
« Reply #124 on: January 07, 2025, 02:51:59 pm »
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.
« Last Edit: January 07, 2025, 02:56:37 pm by Picuino »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf