Varför är C det mest populära programmeringsspråket enligt TIOBE?

Permalänk

Varför är C det mest populära programmeringsspråket enligt TIOBE?

https://www.tiobe.com/tiobe-index/

C är mest populära programmeringsspråket. Sedan kommer Java. Java har fallit lite, men har börjar stabilisera sig något. Python har ökat rejält på grund utav bildigenkänning med mera. C++ har fallit, lika väl som C#.

Men varför just C populärt?
Okej, visst, språket har sina rötter från 60-talet's B-programmering, ett språk som än idag används vid mystiska tillfällen.
C är enkelt att plocka upp och är anpassat efter programmera hårdvara.

Så är detta orsaken varför C är populärast? Hårdvarans tid är kommen? Eller är det något annat som har gjort så C börjar bli populärt?

Permalänk
Medlem

C är snabbt och har varit med länge. Det fanns egentligen inga rimliga alternativ innan Rust kom om man ville skriva hårdvarunära kod och vara produktiv samtidigt.

Vad menar du med "börjar bli populärt"? C har varit populärt i flera årtionden.

Permalänk
Medlem

Om man tittar på siffrorna där så är det egentligen inga större skillnader någonstans sedan förra året.
Så mest brus i statistiken skulle jag gissa på.

Permalänk
Datavetare

C är programmeringsvärldens lingua franca, vilket i praktiken säkerställer att C kommer vara relevant under överskådligt framtid. Med extremt få undantag (Go är nog det enda jag kan komma på) använder alla programspråk C som interface mot övriga systemet. C ABI används också som brygga mellan olika språk och som brygga till extensioner (ta Java som exempel, hur fungerar JNI?).

Ovanpå det finns i praktiken väldigt få språk som i praktiken används för operativsystem och systemprogrammering. C++ var länge det enda rimliga alternativet som systemspråk. Som OS-språk fungerar i praktiken inte standard C++ utan man får köra en nedskalad variant (bl.a. MacOS tillåter en nedskalad delmängd av C++ i kärnan, samma gäller flera RTOS).

Idag kan man lägga till Rust och Swift som systemspråk., Rust kommer ha, men är inte klart än, "bare-metal" stöd som del av standarden vilket även gör det vettigt som OS-spårk. Men de är allt för "nya" för att hunnit få någon bredd inom dessa områden. Flera OS, bl.a. Windows och Linux, undersöker idag möjligheten att bl.a. kunna skriva drivare i Rust (det då det fångar många vanliga fel folk gör i C redan vid kompilering).

Fast sen mäter inte TIOBE vad många nog tror det mäter. Man mäter hur mycket sökningar som görs på olika programspråk. Rätt säker att de som jobbar med C lång mer sällan behöver söka på saker jämfört med t.ex. C++, Java och C# programmerare då de senare språken är absolut gigantiska jämfört med C. Frågan är också hur det påverkar ett språk som Go där en av huvudkriterierna för designen är att man ska hålla språket enkelt, Google hävdar att erfarna programmerare kan lära sig hela Go-språket på en dag eller två (något som inte kan sägas om C och definitivt inte om C++, Java och C#). Om det är så enkelt kanske man inte söker lika mycket runt språket.

Kikar man på githubs lista över hur språkanvändningen ser ut där består pallen av JavaScript, Python och Java. Men inte heller det lär vara speciellt korrekt gradering då just systemkod oftare inte läggs ut som öppen källkod, likaså gäller väldigt mycket kod som används i inbyggda system. Så rimligen är C och C++ betydligt mer populära totalt sett än dessa mätningar ger sken av. I Sverige verkar C# vara betydligt populärare än det är i världen i stort, gissar att väldigt mycket C# skrivs på konsultbasis här som kod vi inte ser på github.

Permalänk
Medlem

Men kan enkellt säga att C mappar väldigt bra mot den faktiska hårdvaran vilket gör det lämpligt till applikationer där du vill ha kontroll över minneshantering, prestanda osv. Därav att flera OS byggs i C och att flertalet språk är utvecklade i C. Mycket av detta stämmer även in på C++ kan tilläggas.

Permalänk
Skrivet av dlq84:

C är snabbt och har varit med länge. Det fanns egentligen inga rimliga alternativ innan Rust kom om man ville skriva hårdvarunära kod och vara produktiv samtidigt.

Vad menar du med "börjar bli populärt"? C har varit populärt i flera årtionden.

Men är inte Rust något beta hipsterspråk? Tycker det ser krångligt ut och jag har inte hört att Rust brukar användas på inbyggda system.

Permalänk
Medlem
Skrivet av heretic16:

Men är inte Rust något beta hipsterspråk? Tycker det ser krångligt ut och jag har inte hört att Rust brukar användas på inbyggda system.

Rust är nytt. Det finns inte ännu samma mängd kompilatorer, bibliotek och liknande som det finns för C. Vänta ett decennium eller två så får vi se.

Permalänk
Skrivet av Erik_T:

Rust är nytt. Det finns inte ännu samma mängd kompilatorer, bibliotek och liknande som det finns för C. Vänta ett decennium eller två så får vi se.

Jag tror inte på Rust. Det låter för "hipster"-acktigt. Minns när "Boo language" kom till. Detta skulle vara revolutionerande. Även Ruby skulle spöa Python.

Vi ser hur det gick.

Permalänk
Hedersmedlem
Skrivet av heretic16:

Jag tror inte på Rust. Det låter för "hipster"-acktigt. Minns när "Boo language" kom till. Detta skulle vara revolutionerande. Även Ruby skulle spöa Python.

Vi ser hur det gick.

Du verkar inte ha mycket mer än känsloargument att komma med. Varför spelar det roll vad du känner?

Permalänk
Medlem
Skrivet av Yoshman:

Fast sen mäter inte TIOBE vad många nog tror det mäter. Man mäter hur mycket sökningar som görs på olika programspråk.

Värre. Man kontrollerar hur många resultat respektive sökterm ger.

Deras egen FAQ erkänner i princip att måttet är fullständigt meningslöst:

Citat:

Q: What happened to Java in April 2004? Did you change your methodology?

A: No, we did not change our methodology at that time. Google changed its methodology. They performed a general sweep action to get rid of all kinds of web sites that had been pushed up. As a consequence, there was a huge drop for languages such as Java and C++.

Permalänk
Medlem
Skrivet av Erik_T:

Rust är nytt. Det finns inte ännu samma mängd kompilatorer, bibliotek och liknande som det finns för C. Vänta ett decennium eller två så får vi se.

En annan grej med Rust som gör det väldigt spännande är konceptet om "ownership", vilket betyder att utöver att hålla koll på vilka typer (och se till att det följs) variabler är kan det även veta om en variable har delats med någon annan eller om man är ensam ägare om den. Det hjälper till väldans mycket när man skriver program som använder sig utan flera trådar eftersom det tvingar en att antingen _aldrig_ dela variabler med andra, eller om man nu måste det gör det på ett sätt som är tråd-säkert med t ex mutexes.

Rust har även väldigt bra stöd för att interopa med C-bibliotek vilket gör att man kan begränsa sitt program till att bara göra saker som anses farliga (inte trådsäkra) i speciellt sektioner i koden, vilket gör att om du får ett `segmentation fault` så finns det bara några få ställen där det kan ha hänt.

C är mysigt, men det känns väldans bekvämt att ha en kompilator som kan stoppa en från att göra dumma saker

Permalänk
Medlem
Skrivet av inquam:

Men kan enkellt säga att C mappar väldigt bra mot den faktiska hårdvaran

Något som till stor del beror på att mycket hårdvara designed från 80-talet och framåt är designad just för att C skall mappa bra mot den.
Det är ingen naturlag att hårdvara behöver vara sådan att C mappar bra till den, och för äldre arkitekturer så gör det inte alltid det.

Permalänk
Medlem
Skrivet av Yoshman:

Ovanpå det finns i praktiken väldigt få språk som i praktiken används för operativsystem och systemprogrammering. C++ var länge det enda rimliga alternativet som systemspråk. Som OS-språk fungerar i praktiken inte standard C++ utan man får köra en nedskalad variant (bl.a. MacOS tillåter en nedskalad delmängd av C++ i kärnan, samma gäller flera RTOS).

Om de inte ändrat något nyligen så är detta undantag om begränsad C++ endast för IOKit, annars är det C som gäller.

Linux (alltså kerneln, inte alla distributioner) är också i C, och lär förbli så så länge Linus Torvalds bestämmer.

Permalänk
Medlem
Skrivet av heretic16:

Men är inte Rust något beta hipsterspråk? Tycker det ser krångligt ut och jag har inte hört att Rust brukar användas på inbyggda system.

Det är fortfarande så pass nytt, det är därför. Rust vinner mer respekt (välförtjänt) i communityn och bland storföretagen hela tiden. Microsoft sneglar på det och det pågår diskussioner om att tillåta subsystem och eller drivrutiner för Linux-kärnan att skrivas i Rust. Bilda dig en egen uppfattning istället för att lyssna blint på haters.

Permalänk
Skrivet av Shimonu:

Du verkar inte ha mycket mer än känsloargument att komma med. Varför spelar det roll vad du känner?

Jag har programmerat i många år och jag vet hur trenderna går inom programmeringsvärlden. Nya progressiva språk brukar oftast falla mer eller mindre.

Permalänk
Hedersmedlem
Skrivet av heretic16:

Jag har programmerat i många år och jag vet hur trenderna går inom programmeringsvärlden. Nya progressiva språk brukar oftast falla mer eller mindre.

Men om du inte vet varför C är så populärt, hur kan du förutspå att Rust inte kommer bli populärt? Du verkar heller inte satt dig in i Rust, så hela ditt argument verkar bygga på att Rust är nytt så därför kan det inte bli bra. Har du något mer konkret?

Permalänk
Skrivet av Shimonu:

Men om du inte vet varför C är så populärt, hur kan du förutspå att Rust inte kommer bli populärt? Du verkar heller inte satt dig in i Rust, så hela ditt argument verkar bygga på att Rust är nytt så därför kan det inte bli bra. Har du något mer konkret?

För att ett språk ska bli stort så måste stora företag ha en väldigt bra anledning att byta språk.
Du byter inte från C till Rust bara för att Rust är nyare.

Permalänk
Medlem
Skrivet av heretic16:

För att ett språk ska bli stort så måste stora företag ha en väldigt bra anledning att byta språk.
Du byter inte från C till Rust bara för att Rust är nyare.

Inte exklusivt stora företag som avgör om ett programmeringsspråk blir populärt eller inte.
Anledningen till att byta från C till Rust är att Rust löser en del av de problem som C har, inte för att det är nyare.

Permalänk
Skrivet av Erik_T:

Inte exklusivt stora företag som avgör om ett programmeringsspråk blir populärt eller inte.
Anledningen till att byta från C till Rust är att Rust löser en del av de problem som C har, inte för att det är nyare.

Då är jag intresserad vad C inte kan, som Rust kan?

Permalänk
Medlem

TIOBE har en luddig uppfattning vad 'populärt' innefattar, kopplat med en sammanblandning av språk för vitt skilda uppgifter: hårdvarunära utveckling ("drivrutiner"), applikationsprogrammering och ren scriptning. Det är därför listan är så missvisande.

Ett bättre sätt att få en korrektare lista över popularitet är att mäta var och en av dessa tre kategorier separat utifrån kurser som ger högskolepoäng inom yrkesområdet. Denna lista kommer alltid att lagga efter 5-10 år eftersom universiteten och högskolorna måste adoptera nya språk efter merit, och i många fall kan det dröja länge innan allvarliga brister upptäcks.

Ett annat sätt att mäta som också är mer rättvisande är att utgå från behov som krävs av släppta mjukvaruprodukter, som tillfredsställs av det språk som använts i produkten. Minneshantering, felhantering, plattformsstöd, utvecklings- och underhållskostnad. Då sållas språk som C, Visual Basic och Assembler bort helt från topplistan som språk som programmerare måhända tycker vore kul att lära sig eller fortsätter att programmera i för att inte behöva lära sig, men som inte finns på kartan i jobbannonser för nya mjukvaruprodukter.

Per kategori kan det hända att det inte finns någon rimlig ersättare för de mest etablerade språken, då standarder (som t.ex. utvecklingsmiljöer som följer med eller till och med krävs av plattformen) etablerats.

Hårdvarunära programmering kan utföras i de allra flesta språk, eller kan i alla fall utökas till att göra det, då det är väldigt lite som behöver läggas till för att stödja det. I en del språk har man medvetet avgränsat dessa möjligheter för att det ses som en "säkerhetsrisk". Under 90-talet blev C/C++ standardspråket för OS, drivrutiner och till och med applikationer, i en tid då applikationer var relativt små.

Idag är det extremt få som utvecklar hela applikationer i C/C++ (utanför Linux, som har en väldigt liten del av mjukvarumarknaderna). Java hade en topp kring 2014 men idag torde C# vara populärast. Kanske kan Rust bli populärt, för de som vill göra C++ great again?

Bland scriptspråken har Javascript varit en nödvändighet ända sedan år 2000, bland annat p.g.a. webbläsare som gjort det till standard. Javascript torde förbli det mest populära scriptspråken inom överskådlig framtid, tills något annat scriptspråk ersätter det i webbläsare. På webbapplikationssidan har vi PHP, Ruby, ASP.net m.m. På applikationssidan, Python, Lua och Javascript.

SQL och liknande rena databasfrågespråk kan inte appliceras på någon av de tre kategorierna och borde inte vara med på listan över programmeringsspråk - ytterligare en luddighet från TIOBE.

Permalänk
Datavetare
Skrivet av mpat:

Om de inte ändrat något nyligen så är detta undantag om begränsad C++ endast för IOKit, annars är det C som gäller.

Linux (alltså kerneln, inte alla distributioner) är också i C, och lär förbli så så länge Linus Torvalds bestämmer.

Att det inte används på andra ställen är inte så konstigt, Apples OS är ju ett hopplock av BSD, NeXT och lite nya saker. IOKit hade tydligen en föregångare i NeXT där man körde ObjC, men till MacOS blev det alltså en nedskalad variat av C++ (de vanliga sakerna när C++ används i realtidsfall är borta, exceptions, RTTI och lite sådant).

Är just det IOKit används till, d.v.s. drivers, som man primärt tittar på eventuellt tillåta Rust i Linux och Windows.

Sedan finns det egentligen inget alls som hindrar någon från att skriva vilka delar som helst i Linux-kärnan i C++ (förutsatt att man slår av exceptions, RTTI etc) eller Rust (no_std varianten som är en den av standarden, "no_std" refererar till "inget standardbibliotek utan bara språket").

Så för egna saker behövs egentligen inget stöd i ett OS för att använda de språk som saknar beroende på "runtime". D.v.s. de språk som kan fungera även om man bara skapar passiva bibliotek och där det finns en rimlig väg att interagera med C ABI. "Ingen runtime" diskvalificerar i praktiken alla språk med GC, de går att modifiera (har gjorts med bl.a. Java) men vad är poängen för då har man ju skapa något nytt som inte längre följer någon standard...

Skrivet av heretic16:

Då är jag intresserad vad C inte kan, som Rust kan?

Då väldigt få utanför embedded implementerat C11 kan man t.ex. inte skapa ett multitrådat program i standard C, det går i standard Rust.

Lite coolare är att om jag ändå har C11 (eller C++11, Java eller C#) så kommer kompilatorn gladeligen kompilera program som innehåller potentiella data-races. I Rust kommer ett sådan program inte kompilera i normalfallet (då det är ett systemspråk finns är det ändå möjligt att öppna vapenskåpet om man verkligen vill skjuta sig i foten).

Då du gillar Java: på många sätt förhåller sig Rust till (modern) C++ som Kotlin förhåller sig till Java.

Modern C++ har fixat till många av vårtorna och lagt till saker som man idag känner är självklara delar. Men då det finns brutalt mycket existerande C++ kod måste man göra alla nyheter inom ramen att fortfarande behålla bakåtkompatibilitet. Man är väl medveten om hur bedrövlig Python 2 till Python 3 övergången gick just p.g.a. att man släppte bakåtkompatibilitet. Väldigt mycket som kommit in i senaste versionerna i C++ och saker som är plannerade för C++20 och C++23 finns redan i Rust.

Rust är C++ "done right", i bemärkelsen att båda riktar in sig på prestandakritisk systemprogrammering och man interagera med C till noll kostnad (även om i princip alla programspråk kan använda C är det långt ifrån effektivt).

Java har samma problem här, finns allt för mycket skrivet i Java för att man ska kunna bryta bakåtkompatibilitet. Mycket saker som läggs till i Java finns redan i Kotlin, men en rad vårtor i Java som man undvikit i Kotlin kommer stanna i Java då man annars bryter bakåtkompatibilitet. Kotlin är "Java done right".

Men är bara i projekt där man startar from scratch där språk som Rust och Kotlin kan bli aktuella. Vi lär veta om 10-20 år om folk tyckte det var tillräckligt värdefullt så dessa är mer normen då. C lär stanna dels då det idag är en portabel assembler samt är det definierar den ABI i princip alla andra språk kommunicerar med omvärlden.

Permalänk
Skrivet av Yoshman:

Att det inte används på andra ställen är inte så konstigt, Apples OS är ju ett hopplock av BSD, NeXT och lite nya saker. IOKit hade tydligen en föregångare i NeXT där man körde ObjC, men till MacOS blev det alltså en nedskalad variat av C++ (de vanliga sakerna när C++ används i realtidsfall är borta, exceptions, RTTI och lite sådant).

Är just det IOKit används till, d.v.s. drivers, som man primärt tittar på eventuellt tillåta Rust i Linux och Windows.

Sedan finns det egentligen inget alls som hindrar någon från att skriva vilka delar som helst i Linux-kärnan i C++ (förutsatt att man slår av exceptions, RTTI etc) eller Rust (no_std varianten som är en den av standarden, "no_std" refererar till "inget standardbibliotek utan bara språket").

Så för egna saker behövs egentligen inget stöd i ett OS för att använda de språk som saknar beroende på "runtime". D.v.s. de språk som kan fungera även om man bara skapar passiva bibliotek och där det finns en rimlig väg att interagera med C ABI. "Ingen runtime" diskvalificerar i praktiken alla språk med GC, de går att modifiera (har gjorts med bl.a. Java) men vad är poängen för då har man ju skapa något nytt som inte längre följer någon standard...

Då väldigt få utanför embedded implementerat C11 kan man t.ex. inte skapa ett multitrådat program i standard C, det går i standard Rust.

Lite coolare är att om jag ändå har C11 (eller C++11, Java eller C#) så kommer kompilatorn gladeligen kompilera program som innehåller potentiella data-races. I Rust kommer ett sådan program inte kompilera i normalfallet (då det är ett systemspråk finns är det ändå möjligt att öppna vapenskåpet om man verkligen vill skjuta sig i foten).

Då du gillar Java: på många sätt förhåller sig Rust till (modern) C++ som Kotlin förhåller sig till Java.

Modern C++ har fixat till många av vårtorna och lagt till saker som man idag känner är självklara delar. Men då det finns brutalt mycket existerande C++ kod måste man göra alla nyheter inom ramen att fortfarande behålla bakåtkompatibilitet. Man är väl medveten om hur bedrövlig Python 2 till Python 3 övergången gick just p.g.a. att man släppte bakåtkompatibilitet. Väldigt mycket som kommit in i senaste versionerna i C++ och saker som är plannerade för C++20 och C++23 finns redan i Rust.

Rust är C++ "done right", i bemärkelsen att båda riktar in sig på prestandakritisk systemprogrammering och man interagera med C till noll kostnad (även om i princip alla programspråk kan använda C är det långt ifrån effektivt).

Java har samma problem här, finns allt för mycket skrivet i Java för att man ska kunna bryta bakåtkompatibilitet. Mycket saker som läggs till i Java finns redan i Kotlin, men en rad vårtor i Java som man undvikit i Kotlin kommer stanna i Java då man annars bryter bakåtkompatibilitet. Kotlin är "Java done right".

Men är bara i projekt där man startar from scratch där språk som Rust och Kotlin kan bli aktuella. Vi lär veta om 10-20 år om folk tyckte det var tillräckligt värdefullt så dessa är mer normen då. C lär stanna dels då det idag är en portabel assembler samt är det definierar den ABI i princip alla andra språk kommunicerar med omvärlden.

Men brukar inte alla dessa språk, C, C++, Java, C# ändra sig med åren för att inte just bli utkonkurrerad?
Det har ju hänt mycket sedan Java 8.

Permalänk
Medlem
Skrivet av heretic16:

Men brukar inte alla dessa språk, C, C++, Java, C# ändra sig med åren för att inte just bli utkonkurrerad?
Det har ju hänt mycket sedan Java 8.

Språk ändras över tiden, men inte så mycket av den anledningen.
Användare av programmeringsspråk vill "alltid" ha nya features i språket. Resultatet blir oftast att efter några rundor av att lägga till allas favoritutökningar så blir språket ett ohanterligt och oöverskådligt härke som närmast faller samman av kravet att vara bakåtkompatibelt.

Permalänk
Datavetare
Skrivet av heretic16:

Men brukar inte alla dessa språk, C, C++, Java, C# ändra sig med åren för att inte just bli utkonkurrerad?
Det har ju hänt mycket sedan Java 8.

Om de ändrar sig för att inte bli utkonkurrerade lär det gå illa. Förhoppningsvis ändrar de saker för att förbättra de vassa hörn man upptäcker allt efter att mer kod skrivs.

Ovanpå det ändras ju sättet att skriva kod med tiden, i alla fall vad som är trendigt. Här får man fundera lite om det är vettigt att hela tiden följa med, kan leda till okontrollerad tillväxt av finesser i språket då man inte kan ta bort de tidigare varianterna utan att bryta bakåtkompatibilitet (C++, Java och C# är alla en bra bit nere i detta träsk).

Vissa språk har som självändamål att inte ändras just för att undvika fällan att skapa något som blir helt oöverblickbart. Exempel är C och Go. Den strategin verkar fungerar rätt bra för C givet vad du upptäckt och Go har givet sin ålder också lyckats väldigt väl (massor med "molninfrastruktur" är utvecklat i Go, t.ex. Kubernetes).

Ta det Rust gjort för att kunna hitta de flesta av våra absolut vanligaste buggar i C, C++, Java, C#. Det är helt omöjligt att fixa till de andra språket på motsvarande sätt och fortfarande kunna kompilera existerande kod, närmaste man kan komma är bättre linters.

Uppenbara nackdelen att hoppa på något nytt språk är ju att man då får lämna all "gammal" kod bakom sig, vilket sällan fungerar ekonomiskt. Varje nytt språk som folk fortfarande visar intresse för ett decennium efter släpp är nog ett bra filter för att sålla bort "hipster språken".

Enda sättet att kraftigt accelerera intåget av språk är att göra som Apple gjort med Swift och Android Studio gjort med Kotlin: sätta det nya språket som förval för de flesta kommer köra med förvalet. Enligt detta dominerar fortfarande Java bland existerande appar, allt fler appar lever väldigt länge. Men Kotlin har passerat 50 % av "Market share in top apps".

Java fungerar bra för många saker, men just Android utveckling tycker i alla fall jag gick från "WTF" till "nu är faktiskt riktigt trevligt" väldigt mycket p.g.a. bytet av språk. På iOS var det än större lyft, från "WTF³" (ObjC) till "riktigt trevligt".

Permalänk
Skrivet av Yoshman:

Om de ändrar sig för att inte bli utkonkurrerade lär det gå illa. Förhoppningsvis ändrar de saker för att förbättra de vassa hörn man upptäcker allt efter att mer kod skrivs.

Ovanpå det ändras ju sättet att skriva kod med tiden, i alla fall vad som är trendigt. Här får man fundera lite om det är vettigt att hela tiden följa med, kan leda till okontrollerad tillväxt av finesser i språket då man inte kan ta bort de tidigare varianterna utan att bryta bakåtkompatibilitet (C++, Java och C# är alla en bra bit nere i detta träsk).

Vissa språk har som självändamål att inte ändras just för att undvika fällan att skapa något som blir helt oöverblickbart. Exempel är C och Go. Den strategin verkar fungerar rätt bra för C givet vad du upptäckt och Go har givet sin ålder också lyckats väldigt väl (massor med "molninfrastruktur" är utvecklat i Go, t.ex. Kubernetes).

Ta det Rust gjort för att kunna hitta de flesta av våra absolut vanligaste buggar i C, C++, Java, C#. Det är helt omöjligt att fixa till de andra språket på motsvarande sätt och fortfarande kunna kompilera existerande kod, närmaste man kan komma är bättre linters.

Uppenbara nackdelen att hoppa på något nytt språk är ju att man då får lämna all "gammal" kod bakom sig, vilket sällan fungerar ekonomiskt. Varje nytt språk som folk fortfarande visar intresse för ett decennium efter släpp är nog ett bra filter för att sålla bort "hipster språken".

Enda sättet att kraftigt accelerera intåget av språk är att göra som Apple gjort med Swift och Android Studio gjort med Kotlin: sätta det nya språket som förval för de flesta kommer köra med förvalet. Enligt detta dominerar fortfarande Java bland existerande appar, allt fler appar lever väldigt länge. Men Kotlin har passerat 50 % av "Market share in top apps".

Java fungerar bra för många saker, men just Android utveckling tycker i alla fall jag gick från "WTF" till "nu är faktiskt riktigt trevligt" väldigt mycket p.g.a. bytet av språk. På iOS var det än större lyft, från "WTF³" (ObjC) till "riktigt trevligt".

Så C är inte felfritt? Jag tolkar C som grundernas språk och det är speciellt utformat av datavetare på hårdnära nivå. Det är därför C inte har färdiga klasser och man kan ej göra trådar i C. Det är inte det som är tanken med C. Tanken med C är att man ska kunna skriva assemblerkod, fast i C. Allt assembler kan, det kan även C.

Jag skulle rekommendera Flutter istället för Andriod Studio. Men jag skulle inte rekommendera mobilappar över huvudtaget. Bättre med webbappar.

Permalänk
Medlem
Skrivet av heretic16:

Så C är inte felfritt? Jag tolkar C som grundernas språk och det är speciellt utformat av datavetare på hårdnära nivå. Det är därför C inte har färdiga klasser och man kan ej göra trådar i C. Det är inte det som är tanken med C. Tanken med C är att man ska kunna skriva assemblerkod, fast i C. Allt assembler kan, det kan även C.

C har mängder med brister - precis som alla andra programmeringsspråk.

Långtifrån alla processorer har ett assemblerspråk som mappar bra till C. Många äldre processorer har jättefiffiga instruktioner som aldrig genereras av en C kompilator för att det helt enkelt är för svårt att mappa C-konstruktioner till hur hårdvaran vill ha det. Modernare processorer har färre sådana instruktioner eftersom de ofta är designade explicit för att kompilatorer skall kunna generara effektiv kod för dem, och skippar det mesta som en kompilator inte kan utnyttja.

Oavsett processor så finns det nästan alltid en del saker som inte går att göra från något högnivåspråk, inklusive C - i alla fall inte utan hårdvaruspecifika utökningar.

Det ligger ingen djup tanke bakom grunddesignen av C.
Utvecklarna av Unix behövde något programmeringsspråk för att skriva alla de olika utilities som behövdes. Det fanns naturligtvis inga kompliatorer för detta nya OS på den tiden, så Dennis Ritchie och Ken Thompson skrev en ny för en förenklad version av BCPL. Det språket kallades B och visade sig inte fungera så bra, så en förbättrad version utvecklades och kallades C.
Notera att C inte i första hand utvecklades för riktigt hårdvarunära programmering även om det visat sig fungera bra som sådant.

Permalänk
Skrivet av Erik_T:

C har mängder med brister - precis som alla andra programmeringsspråk.

Långtifrån alla processorer har ett assemblerspråk som mappar bra till C. Många äldre processorer har jättefiffiga instruktioner som aldrig genereras av en C kompilator för att det helt enkelt är för svårt att mappa C-konstruktioner till hur hårdvaran vill ha det. Modernare processorer har färre sådana instruktioner eftersom de ofta är designade explicit för att kompilatorer skall kunna generara effektiv kod för dem, och skippar det mesta som en kompilator inte kan utnyttja.

Oavsett processor så finns det nästan alltid en del saker som inte går att göra från något högnivåspråk, inklusive C - i alla fall inte utan hårdvaruspecifika utökningar.

Det ligger ingen djup tanke bakom grunddesignen av C.
Utvecklarna av Unix behövde något programmeringsspråk för att skriva alla de olika utilities som behövdes. Det fanns naturligtvis inga kompliatorer för detta nya OS på den tiden, så Dennis Ritchie och Ken Thompson skrev en ny för en förenklad version av BCPL. Det språket kallades B och visade sig inte fungera så bra, så en förbättrad version utvecklades och kallades C.
Notera att C inte i första hand utvecklades för riktigt hårdvarunära programmering även om det visat sig fungera bra som sådant.

Själv kör jag C, men det har med att jag är för lat att lära mig något nytt. Tycker funktioner fungerar mycket bra. Det blir dock bökigt när man måste använda OOP-teknik. Men då kör jag Java istället.

Visste du att B-programmeringsspråk används fortfarande vid mystiska tillfällen?

Permalänk
Medlem
Skrivet av heretic16:

Visste du att B-programmeringsspråk används fortfarande vid mystiska tillfällen?

Förvånar mig inte, men jag kan inte tänka mig att det används särskilt ofta.