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

0 Members and 1 Guest are viewing this topic.

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20885
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #50 on: September 12, 2024, 03:14:01 pm »
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.
« Last Edit: September 12, 2024, 03:16:11 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 SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15540
  • Country: fr
Re: TIOBE Index of programming languages
« Reply #51 on: September 12, 2024, 08:54:04 pm »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20885
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #52 on: September 12, 2024, 09:14:32 pm »
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 :) )
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 radiolistener

  • Super Contributor
  • ***
  • Posts: 4069
  • Country: ua
Re: TIOBE Index of programming languages
« Reply #53 on: September 13, 2024, 07:21:01 am »
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:
Code: [Select]
// 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;
}


Code: [Select]
$ 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
« Last Edit: September 13, 2024, 07:23:46 am by radiolistener »
 

Offline Tation

  • Regular Contributor
  • *
  • Posts: 94
  • Country: pt
Re: TIOBE Index of programming languages
« Reply #54 on: September 13, 2024, 08:57:24 am »
Turing-completeness arose, sometimes unexpectedly, in many other places. For example, all these are Turing-complete:

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.
« Last Edit: September 13, 2024, 10:10:47 am by Tation »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20885
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #55 on: September 13, 2024, 09:06:44 am »
...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.
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: 4613
  • Country: nz
Re: TIOBE Index of programming languages
« Reply #56 on: September 13, 2024, 09:48:15 am »
Turing-completeness arose, sometimes unexpectedly, in many other places. For example, all these are Turing-complete:

Why on Earth is PostScript in this list when it is literally and deliberately a Forth-like programming language? No accident.

Code: [Select]
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$
« Last Edit: September 13, 2024, 10:19:05 am by brucehoult »
 

Offline Tation

  • Regular Contributor
  • *
  • Posts: 94
  • Country: pt
Re: TIOBE Index of programming languages
« Reply #57 on: September 13, 2024, 10:10:22 am »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20885
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #58 on: September 13, 2024, 10:10:51 am »
Turing-completeness arose, sometimes unexpectedly, in many other places. For example, all these are Turing-complete:

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.
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: 4613
  • Country: nz
Re: TIOBE Index of programming languages
« Reply #59 on: September 13, 2024, 10:35:56 am »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4613
  • Country: nz
Re: TIOBE Index of programming languages
« Reply #60 on: September 13, 2024, 11:14:45 am »
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
 

Offline Tation

  • Regular Contributor
  • *
  • Posts: 94
  • Country: pt
Re: TIOBE Index of programming languages
« Reply #61 on: September 13, 2024, 11:22:46 am »

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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20885
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #62 on: September 13, 2024, 11:52:25 am »
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.

Quote
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.
« Last Edit: September 13, 2024, 11:57:57 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 PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1038
  • Country: es
    • Picuino web
Re: TIOBE Index of programming languages
« Reply #63 on: October 07, 2024, 04:59:48 pm »
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
« Last Edit: October 08, 2024, 01:57:56 pm by Picuino »
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 569
  • Country: au
Re: TIOBE Index of programming languages
« Reply #64 on: October 10, 2024, 10:30:10 am »
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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15540
  • Country: fr
Re: TIOBE Index of programming languages
« Reply #65 on: October 10, 2024, 08:26:41 pm »
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 following users thanked this post: cfbsoftware, golden_labels, 5U4GB

Offline cfbsoftware

  • Regular Contributor
  • *
  • Posts: 127
  • Country: au
    • Astrobe: Oberon IDE for Cortex-M and FPGA Development
Re: TIOBE Index of programming languages
« Reply #66 on: October 11, 2024, 04:59:17 am »
Chris Burrows
CFB Software
https://www.astrobe.com
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1038
  • Country: es
    • Picuino web
Re: TIOBE Index of programming languages
« Reply #67 on: November 11, 2024, 03:55:21 pm »
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)
« Last Edit: November 11, 2024, 03:57:58 pm by Picuino »
 

Offline PicuinoTopic starter

  • Super Contributor
  • ***
  • Posts: 1038
  • Country: es
    • Picuino web
Re: TIOBE Index of programming languages
« Reply #68 on: November 11, 2024, 04:34:36 pm »
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.
« Last Edit: November 11, 2024, 05:05:16 pm by Picuino »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20885
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: TIOBE Index of programming languages
« Reply #69 on: November 11, 2024, 04:44:09 pm »
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.
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
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf