mboost-dp1
Most Popular Programming Languages 1965 - 2019
Fandt lige den her igen.
Ret sjovt.
En kort opsummering for dem som ikke bryder sig om videoer.
1965 Q1:
Fortran 58
Cobol 14
Algol 10
assembler 5
1970 Q1:
Fortran 25
Cobol 6
Algol 5
assembler 5
1975 Q1:
Fortran 25
Cobol 12
Lisp 7
Pascal 6
Basic 6
Algol 5
1980 Q1:
Fortran 24
Pascal 24
Basic 15
Cobol 12
Lisp 9
C 9
assembler 5
1985 Q1:
Pascal 36
C 35
Ada 31
Lisp 23
Fortran 20
Basic 17
assembler 12
C++ 9
Cobol 9
1990 Q1:
C 54
Ada 36
Pascal 26
C++ 16
Lisp 15
Fortran 13
Basic 8
assembler 7
Cobol 6
1995 Q1:
C 71
C++ 20
Fortran 9
Pascal 8
VB 8
Basic 8
Ada 7
asembler 6
Perl 5
2000 Q1:
C 38
Java 22
JavaScript 19
C++ 14
Perl 11
PHP 11
VB 11
Delphi 6
2005 Q1:
Java 35
JavaScript 23
PHP 23
C 13
C++ 11
C# 8
VB 7
Perl 6
Python 5
2010 Q1:
Java 32
JavaScript 20
PHP 18
C++ 12
C 11
Python 9
C# 9
VB 5
2015 Q1:
Java 27
JavaScript 22
Python 14
PHP 12
C# 10
C++ 8
C 7
Objective-C 7
Swift 5
2019 Q3:
Python 24
JavaScript 23
Java 22
C# 8
PHP 7
C++ 7
C 5
Ret sjovt.
En kort opsummering for dem som ikke bryder sig om videoer.
1965 Q1:
Fortran 58
Cobol 14
Algol 10
assembler 5
1970 Q1:
Fortran 25
Cobol 6
Algol 5
assembler 5
1975 Q1:
Fortran 25
Cobol 12
Lisp 7
Pascal 6
Basic 6
Algol 5
1980 Q1:
Fortran 24
Pascal 24
Basic 15
Cobol 12
Lisp 9
C 9
assembler 5
1985 Q1:
Pascal 36
C 35
Ada 31
Lisp 23
Fortran 20
Basic 17
assembler 12
C++ 9
Cobol 9
1990 Q1:
C 54
Ada 36
Pascal 26
C++ 16
Lisp 15
Fortran 13
Basic 8
assembler 7
Cobol 6
1995 Q1:
C 71
C++ 20
Fortran 9
Pascal 8
VB 8
Basic 8
Ada 7
asembler 6
Perl 5
2000 Q1:
C 38
Java 22
JavaScript 19
C++ 14
Perl 11
PHP 11
VB 11
Delphi 6
2005 Q1:
Java 35
JavaScript 23
PHP 23
C 13
C++ 11
C# 8
VB 7
Perl 6
Python 5
2010 Q1:
Java 32
JavaScript 20
PHP 18
C++ 12
C 11
Python 9
C# 9
VB 5
2015 Q1:
Java 27
JavaScript 22
Python 14
PHP 12
C# 10
C++ 8
C 7
Objective-C 7
Swift 5
2019 Q3:
Python 24
JavaScript 23
Java 22
C# 8
PHP 7
C++ 7
C 5
#2
Og sjovt nok har jeg i alle de udvalgte år et vist kendskab til over halvdelen.
1965 Q1: 58 ud af 87
1970 Q1: 25 ud af 41
1975 Q1: 31 ud af 61
1980 Q1: 57 ud af 98
1985 Q1: 100 ud af 192
1990 Q1: 109 ud af 181
1995 Q1: 108 ud af 142
2000 Q1: 91 ud af 132
2005 Q1: 95 ud af 131
2010 Q1: 91 ud af 116
2015 Q1: 78 ud af 112
2019 Q3: 73 ud af 96
Og sjovt nok har jeg i alle de udvalgte år et vist kendskab til over halvdelen.
1965 Q1: 58 ud af 87
1970 Q1: 25 ud af 41
1975 Q1: 31 ud af 61
1980 Q1: 57 ud af 98
1985 Q1: 100 ud af 192
1990 Q1: 109 ud af 181
1995 Q1: 108 ud af 142
2000 Q1: 91 ud af 132
2005 Q1: 95 ud af 131
2010 Q1: 91 ud af 116
2015 Q1: 78 ud af 112
2019 Q3: 73 ud af 96
2000 Q1: 58 ud af 132 (Java, JavaScript, PHP, Delphi)
2005 Q1: 89 ud af 131 (Java, JavaScript, PHP, C#)
2010 Q1: 79 ud af 116 (Java, JavaScript, PHP, C#)
2015 Q1: 66 ud af 112 (JavaScript, Python, C#, C++, Objective-C, Swift)
2019 Q3: 30 ud af 96 (JavaScript, C++)
Det eneste Java jeg har skrevet i over 10 år var da jeg hjalp min bror med hans programmeringsopgaver på universitetet: https://gist.github.com/clausjoergensen/fc0d6ff0dd... (memoization i Java er messy)
2005 Q1: 89 ud af 131 (Java, JavaScript, PHP, C#)
2010 Q1: 79 ud af 116 (Java, JavaScript, PHP, C#)
2015 Q1: 66 ud af 112 (JavaScript, Python, C#, C++, Objective-C, Swift)
2019 Q3: 30 ud af 96 (JavaScript, C++)
Det eneste Java jeg har skrevet i over 10 år var da jeg hjalp min bror med hans programmeringsopgaver på universitetet: https://gist.github.com/clausjoergensen/fc0d6ff0dd... (memoization i Java er messy)
#2 I korte træk:
Dinosaur tidsalder: Fortran dominerer
Unix tidsalder: C dominerer
Internet tidsalder: Java dominerer
Moderne tid: Javascript og Python tager føringen
Af disse sprog må jeg sige at C er mit foretrukne, så jeg er åbenbart tilhørende Unix tidsalderen. Nr. 2 for mig er Python, HVIS man har en god IDE eller noget linting sat op.
Dinosaur tidsalder: Fortran dominerer
Unix tidsalder: C dominerer
Internet tidsalder: Java dominerer
Moderne tid: Javascript og Python tager føringen
Af disse sprog må jeg sige at C er mit foretrukne, så jeg er åbenbart tilhørende Unix tidsalderen. Nr. 2 for mig er Python, HVIS man har en god IDE eller noget linting sat op.
Jeg har også stor respekt for Dennis Ritchie's arbejde og føler et vist skæbnefællesskab. Han prøvede at få det bedste ud af en situation med begrænset hardware uden at svæve højt i en teoretisk og snobbet computer-science sky, og skabte på pragmatisk vis C som tog verden med storm.
Som embedded udvikler har jeg også skullet presse det yderste ud af minimal hardware nogle gange. Har f.eks. været nødt til at implementere egne ultrakompakte komprimeringsalgoritmer. Den slags er faktisk ret sjovt.
(kompakt i den forstand at udpakningskoden heller ikke måtte fylde for meget, så samlet binary blev så lille som mulig)
Som embedded udvikler har jeg også skullet presse det yderste ud af minimal hardware nogle gange. Har f.eks. været nødt til at implementere egne ultrakompakte komprimeringsalgoritmer. Den slags er faktisk ret sjovt.
(kompakt i den forstand at udpakningskoden heller ikke måtte fylde for meget, så samlet binary blev så lille som mulig)
#7
Tog verden med storm er måske lidt overdrevet.
C er fra 1972 og der gik en del år inden det blev populært. Med det her mål kom det i top fem i 1980 Q2 og blev nummer et i 1986 Q4.
Og ikke så overraskende. Tidlig C aka K&R C manglede noget standardisering og havde nogle små uhensigtsmæssigheder.
Tog verden med storm er måske lidt overdrevet.
C er fra 1972 og der gik en del år inden det blev populært. Med det her mål kom det i top fem i 1980 Q2 og blev nummer et i 1986 Q4.
Og ikke så overraskende. Tidlig C aka K&R C manglede noget standardisering og havde nogle små uhensigtsmæssigheder.
#9 Der var tale om at vise grafik med transparans og få farver, som jeg valgte at gemme med et simpelt runlength encoding scheme, kodet med nøje udvalgte bit mønstre så det fyldte så lidt som muligt med de farver og runlengths der var typiske. Konceptet betød også at microcontrolleren kunne tegne grafikken meget effektivt med hurtige løkker for runlength og direkte at springe pixels over ved transparans.
Det forekom mig hurtigere at kode det selv end at finde et eksisterende format plus kode der kunne den slags. Brugte Python til at konvertere billederne til formatet.
Et andet typisk eksempel er at gemme et array af integers som typisk er måske 0 til 100, men ind imellem har større værdier. Her kan man bruge en continuation kodning hvor f.eks. 0b0000000 til 0b01111111 repræsenterer 0 til 127 mens MSB sat betyder at flere bytes skal sættes sammen så større værdier kan gemmes. LZW er overkill i disse situationer IMO.
Det forekom mig hurtigere at kode det selv end at finde et eksisterende format plus kode der kunne den slags. Brugte Python til at konvertere billederne til formatet.
Et andet typisk eksempel er at gemme et array af integers som typisk er måske 0 til 100, men ind imellem har større værdier. Her kan man bruge en continuation kodning hvor f.eks. 0b0000000 til 0b01111111 repræsenterer 0 til 127 mens MSB sat betyder at flere bytes skal sættes sammen så større værdier kan gemmes. LZW er overkill i disse situationer IMO.
arne_v (8) skrev:#7
Tog verden med storm er måske lidt overdrevet.
C er fra 1972 og der gik en del år inden det blev populært. Med det her mål kom det i top fem i 1980 Q2 og blev nummer et i 1986 Q4.
Og ikke så overraskende. Tidlig C aka K&R C manglede noget standardisering og havde nogle små uhensigtsmæssigheder.
C *tog* verden med storm efter nogle revisioner og modning, så meget at adskillige moderne sprog valgte at efterligne C's syntax. Successen skyldes vel at det var et enormt praktisk sprog, nemt at lave en oversætter til, høj performance og nem interfacing til hardware. De mere fancy sprog var bare ikke nær så ikke praktiske.
#13
Det afhænger vel af formålet. C var (og er) ikke et sprog du vil bruge til f.eks. penge beregninger pga. floating-pointer precision (or lack of thereof)
COBOL havde mere præcise typer til penge beregninger allerede da C blev opfundet. Java og C# har BigInteger.
C er heller ikke et godt sprog at udtrykke algoritmer i. Sprog som ML (der blev opfundet året efter C) er bedre.
Men som du siger, nem interfacing til hardware er nemmere/bedre i C end i COBOL/Fortran. Og det var vigtigt på det tidspunkt.
Selv i dag bruges C vel stort set udelukkende på det niveau.
Det afhænger vel af formålet. C var (og er) ikke et sprog du vil bruge til f.eks. penge beregninger pga. floating-pointer precision (or lack of thereof)
COBOL havde mere præcise typer til penge beregninger allerede da C blev opfundet. Java og C# har BigInteger.
C er heller ikke et godt sprog at udtrykke algoritmer i. Sprog som ML (der blev opfundet året efter C) er bedre.
Men som du siger, nem interfacing til hardware er nemmere/bedre i C end i COBOL/Fortran. Og det var vigtigt på det tidspunkt.
Selv i dag bruges C vel stort set udelukkende på det niveau.
C er dog et ret dårlig sprog i forhold til 2021 standards, og ligesom COBOL, beviser vel næsten en hypotese om at programmeringsprog ikke bør leve mere end 50 år.
COBOL og main frames skalere elendigt i forhold til microservices i cloud.
C har sikkerhedsproblemer der har plaget computer brugere siden det første C program blev skrevet.
Sprog som Rust der kan erstatte sprog som C er _nødvendige_ for at verden kan videreudvikle sig.
COBOL og main frames skalere elendigt i forhold til microservices i cloud.
C har sikkerhedsproblemer der har plaget computer brugere siden det første C program blev skrevet.
Sprog som Rust der kan erstatte sprog som C er _nødvendige_ for at verden kan videreudvikle sig.
C er et forholdsvist transparant lag oven på maskinkode, på godt og ondt.
Ja, til kritisk kode bør man nok ikke vælge C i dag. Men der er sikkerhedsstandarder man kan overveje som MISRA-C.
Rust er meget lovende, men stadig et ungt sprog og som jeg forstår det meget tungt at compile. Hvor lang tid ville et rust projekt på størrelse med Linux kernel mon tage at compile?
Ja, til kritisk kode bør man nok ikke vælge C i dag. Men der er sikkerhedsstandarder man kan overveje som MISRA-C.
Rust er meget lovende, men stadig et ungt sprog og som jeg forstår det meget tungt at compile. Hvor lang tid ville et rust projekt på størrelse med Linux kernel mon tage at compile?
arne_v (8) skrev:
Og ikke så overraskende. Tidlig C aka K&R C manglede noget standardisering og havde nogle små uhensigtsmæssigheder.
Omend for Fortran's vedkommende er sprogets brug stort set omvendt proportional med kvaliteten.
I og II : horrible men totalt dominerende
IV = 66 : primitiv og noget tricky men stadig dominerende
V = 77 : primitiv, ikke dominerende men stadig stor
90/90/2003/2008 : moderne men niche sprog
larsp (12) skrev:
Et andet typisk eksempel er at gemme et array af integers som typisk er måske 0 til 100, men ind imellem har større værdier. Her kan man bruge en continuation kodning hvor f.eks. 0b0000000 til 0b01111111 repræsenterer 0 til 127 mens MSB sat betyder at flere bytes skal sættes sammen så større værdier kan gemmes. LZW er overkill i disse situationer IMO.
Modellen er ret udbredt. UTF-8 !!
LZW giver nok mest mening til tekst.
Claus Jørgensen (14) skrev:
Det afhænger vel af formålet. C var (og er) ikke et sprog du vil bruge til f.eks. penge beregninger pga. floating-pointer precision (or lack of thereof)
Floating point til penge er en katastrofe som stadig ses en gang imellem.
Et problem er mangelende præcision i single precision floating point.
Men et andet problem er at de er 2 baseret ikke 10 baseret. Man kan ikke repræsentere 1/10 og 1/100 eksakt i floating point. Og man har altså valgt at bruge decimale tal for penge.
Claus Jørgensen (14) skrev:
COBOL havde mere præcise typer til penge beregninger allerede da C blev opfundet. Java og C# har BigInteger.
Cobol packed decimal (COMP-3), Java BigDecimal, .NET decimal, Python Decimal etc..
Claus Jørgensen (14) skrev:
Men som du siger, nem interfacing til hardware er nemmere/bedre i C end i COBOL/Fortran. Og det var vigtigt på det tidspunkt.
Selv i dag bruges C vel stort set udelukkende på det niveau.
C bliver brugt til rigtigt meget. Også en del som det ikke burde bruges til.
Arven fra Unix, universisterne og RISC workstations er svær at ryste af sig.
Claus Jørgensen (17) skrev:#16
Du kan kompilere Linux på 8 minutter på en moderne computer. Hvis Rust tager 16, så kan jeg ikke se problemet.
Hvis det bare var x2. Jeg har indtryk af at man nærmere taler om x10 i sammenligning med C (gæt). Bare ikke det skalerer eksponentielt når projektet stiger i størrelse.
#19, Gud ja, det er jo det samme som UTF8.
larsp (16) skrev:C er et forholdsvist transparant lag oven på maskinkode, på godt og ondt.
Ja, til kritisk kode bør man nok ikke vælge C i dag. Men der er sikkerhedsstandarder man kan overveje som MISRA-C.
Rust er meget lovende, men stadig et ungt sprog og som jeg forstår det meget tungt at compile.
Rust er langt sikrere end C.
Men der har været alternativer til C før.
Ada er fra 1980 og kan bruges til at skrive meget sikker kode.
De fleste foretrak altså at bruge C fremfor Ada.
Nu må vi se hvordan det går med Rust.
Et andet problem for Rust er legacy kode. Vi kan gruppere kode i 4 kategorier:
A) Kode hvor man hverken vælger C eller Rust
B) Ny kode hvor man vælger Rust
C) Gammel kode i C hvor man vælger at fortsætte med C for kun at bruge 1 sprog
D) Gammel kode i C hvor man vælger at skrive ny funktionalitet i Rust fordi de er bedre
Rangordner vi dem efter størrelse så er det #A størst, #C i midten og #B plus #D mindst.
#22 Pascal og Ada kom aldrig til at dominere, og nye sprog emulerer ikke syntaxen.
Gad vide hvor stor en del af forklaringen er brugen af omstændige keywords som "begin" "end" "function" osv. Det forekommer mig at 25% - 50% af karakterne går til den slags fyld.
Vandt C style syntaxen fordi den er så letvægtig og folk er dovne? (pre moderne IDEer)
Gad vide hvor stor en del af forklaringen er brugen af omstændige keywords som "begin" "end" "function" osv. Det forekommer mig at 25% - 50% af karakterne går til den slags fyld.
Vandt C style syntaxen fordi den er så letvægtig og folk er dovne? (pre moderne IDEer)
#23
Pascal og Ada havde faktisk en storhedstid - se f.eks. 85 Q1 og 90 Q1 statistikken ovenfor!
Men de sygnede hen.
Jeg er ikke overbevist om at årsagen er at folk er for dovne til at skrive begin end og foretrækker {}. Men jeg kan ikke afvise det.
Mine bud er dog.
Pascal:
* sproget (Wirth Pascal og ISO Pascal) er designet til undervisning ikke til faktisk brug - Wirth's sprog til faktisk brug var Modula-2
* de forskellige varianter var meget lidt kompatible idet de alle have forskellige extensions
* der var ingen gratis compiler til Unix dengang (FPC kom senere)
Ada:
* det er et vanskeligt sprog - Ada 83 var svært og Ada 95 er rigtigt svært hvilket afskrækker mange
* sproget blev populært meget hurtigt da det amerikanske forsvarsministerium begyndt at kræve at software til dem skulle laves i Ada - og mistede populariteten lige så hurtigt da kravet blev droppet
Pascal og Ada havde faktisk en storhedstid - se f.eks. 85 Q1 og 90 Q1 statistikken ovenfor!
Men de sygnede hen.
Jeg er ikke overbevist om at årsagen er at folk er for dovne til at skrive begin end og foretrækker {}. Men jeg kan ikke afvise det.
Mine bud er dog.
Pascal:
* sproget (Wirth Pascal og ISO Pascal) er designet til undervisning ikke til faktisk brug - Wirth's sprog til faktisk brug var Modula-2
* de forskellige varianter var meget lidt kompatible idet de alle have forskellige extensions
* der var ingen gratis compiler til Unix dengang (FPC kom senere)
Ada:
* det er et vanskeligt sprog - Ada 83 var svært og Ada 95 er rigtigt svært hvilket afskrækker mange
* sproget blev populært meget hurtigt da det amerikanske forsvarsministerium begyndt at kræve at software til dem skulle laves i Ada - og mistede populariteten lige så hurtigt da kravet blev droppet
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund