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

0 Members and 1 Guest 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 #75 on: December 30, 2024, 12:15:50 pm »
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.
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 #76 on: December 30, 2024, 02:03:43 pm »
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.
 

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 #77 on: December 30, 2024, 02:36:42 pm »
Each language has it's use. I figured that if I learnt C++ first Python would come much more naturally when I need it.
 

Offline dobsonr741

  • Frequent Contributor
  • **
  • Posts: 706
  • Country: us
Re: TIOBE Index of programming languages
« Reply #78 on: December 30, 2024, 03:05:18 pm »
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.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: TIOBE Index of programming languages
« Reply #79 on: December 30, 2024, 03:11:39 pm »
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.
 
The following users thanked this post: SiliconWizard

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 #80 on: December 30, 2024, 06:34:35 pm »
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!
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #81 on: December 30, 2024, 07:24:41 pm »
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++.
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 #82 on: December 30, 2024, 08:27:51 pm »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4840
  • Country: nz
Re: TIOBE Index of programming languages
« Reply #83 on: December 30, 2024, 11:07:43 pm »
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.
 
The following users thanked this post: madires, newbrain

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15948
  • Country: fr
Re: TIOBE Index of programming languages
« Reply #84 on: December 30, 2024, 11:15:03 pm »
And: if you don't know how to program but you know which language everyone should use, just become an agile coach.
 
The following users thanked this post: madires, Siwastaja, newbrain

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4840
  • Country: nz
Re: TIOBE Index of programming languages
« Reply #85 on: December 30, 2024, 11:15:27 pm »
If there isn't a midwit meme for this, there should be.
 
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 #86 on: December 30, 2024, 11:23:01 pm »
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.
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 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 #87 on: December 31, 2024, 09:40:23 am »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #88 on: December 31, 2024, 09:49:04 am »
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.

Quote
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.
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 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 #89 on: December 31, 2024, 09:59:46 am »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #90 on: December 31, 2024, 10:17:56 am »
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.
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 #91 on: January 02, 2025, 10:19:44 pm »
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.
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 #92 on: January 02, 2025, 10:59:44 pm »
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.
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 #93 on: January 03, 2025, 12:00:01 am »
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).

Quote
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.
 

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 #94 on: January 03, 2025, 07:39:27 am »
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?
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9475
  • Country: fi
Re: TIOBE Index of programming languages
« Reply #95 on: January 04, 2025, 11:45:54 am »
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.

 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 21465
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #96 on: January 04, 2025, 12:11:58 pm »
... 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.
« Last Edit: January 04, 2025, 12:14:46 pm 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 PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1084
  • Country: es
    • Picuino web
Re: TIOBE Index of programming languages
« Reply #97 on: January 04, 2025, 01:00:20 pm »
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.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9475
  • Country: fi
Re: TIOBE Index of programming languages
« Reply #98 on: January 04, 2025, 01:53:33 pm »
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.
« Last Edit: January 04, 2025, 01:57:28 pm by Siwastaja »
 

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 #99 on: January 04, 2025, 03:06:07 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf