Jump to content
Kurt Lekanger

Vokste raskere enn Python: C ble årets programmerings­språk i 2019

Recommended Posts

Sitat

Tiobe skriver at «alle trodde Python ville bli årets programmeringsspråk for andre år på rad» – men faktisk er det den gamle traveren C som vinner prisen. 

hvorfor c går forran c++ er jo spørsmål i seg selv. Folk foretrekker det gamle?

Share this post


Link to post

Jeg er ikke overrasket. Det er lite som erstatter C når det kommer til maskinnære språk. Rust virker ut som en god kandidat, men som en innenfor industrien så har jeg det ikke travelt med å kvitte meg med C.

LMH1 skrev (32 minutter siden):

hvorfor c går forran c++ er jo spørsmål i seg selv. Folk foretrekker det gamle?

C++ er dårlig optimalisert for embeddedutvikling. Man ønsker å unngå heap allokeringer og kostbare biblioteksfunksjoner. Det C++ tilbyr er kjekt for programmere, men er kaos for en som ønsker kontroll over systemet sitt.

  • Like 2

Share this post


Link to post
3 minutes ago, Gavekort said:

C++ er dårlig optimalisert for embeddedutvikling. Man ønsker å unngå heap allokeringer og kostbare biblioteksfunksjoner. Det C++ tilbyr er kjekt for programmere, men er kaos for en som ønsker kontroll over systemet sitt.

Tror ikke dette er den egentlige grunnen. Det er nok av ressurser på hvordan man skal lage god C++ for embedded, og språket har flere konstruksjoner som gjør at man kan skrive veldig effektiv kode utenom mye om og men.

Tror til syvende og sist det handler om hva hardwaretilbydere tilbyr for embedded. Det er nok betydelig enklere å bare lage en liten C-kompilator til plattformen, enn å måtte styre med C++. Hedersunntaket er dog arduino med venner, men de måtte nok gjøre sitt for at det skulle bli mer folkevennlig.

Share this post


Link to post
PingEnt skrev (Akkurat nå):

Tror ikke dette er den egentlige grunnen. Det er nok av ressurser på hvordan man skal lage god C++ for embedded, og språket har flere konstruksjoner som gjør at man kan skrive veldig effektiv kode utenom mye om og men.

Tror til syvende og sist det handler om hva hardwaretilbydere tilbyr for embedded. Det er nok betydelig enklere å bare lage en liten C-kompilator til plattformen, enn å måtte styre med C++. Hedersunntaket er dog arduino med venner, men de måtte nok gjøre sitt for at det skulle bli mer folkevennlig.

Det er grunnen til at jeg avslår C++ i prosjektene vi har. Det er lite vits i å bruke C++ om man ikke kan heap-allokere eller bruke STL, og hvorfor skal jeg drive å abstrahere bort deler av prosjektet jeg ønsker å ha kontroll over? C++ toolchain finnes til både STM32, AVR og SAM, så det står ikke på det for min del.

Share this post


Link to post
Sitat

...basert på hvor mange som søker på ulike begreper på søketjenester som Google, Bing, Wikipedia og Youtube. 

Føler ikke helt kildene til statistikken er representativ for overskriften... "Årets vanskeligste språk" kunne ha passet like bra til denne statistikken/kildene ?

 

  • Like 5

Share this post


Link to post
1 hour ago, Gavekort said:

Det er grunnen til at jeg avslår C++ i prosjektene vi har. Det er lite vits i å bruke C++ om man ikke kan heap-allokere eller bruke STL, og hvorfor skal jeg drive å abstrahere bort deler av prosjektet jeg ønsker å ha kontroll over? C++ toolchain finnes til både STM32, AVR og SAM, så det står ikke på det for min del.

Heap-allokering unngår du like greit i C++ som i C. Med mindre du kalller biblioteksfunksjoner som allokerer på heapen (for eksempel via en ny std::vector), får du ikke noen nye heap-allokasjoner.

Det er også deler av STL som er helt trygt for embedded, helt uten heap-allokering, som f.eks. std::array og std::optional. 

Når det er sagt, har jeg forståelse for at man kanskje ikke manisk vil lese kompilatorspesifikasjoner eller sjekke assembleroutput for hver bidige kodelinje for å sjekke at man fikk det man ønsket :)

Share this post


Link to post
PingEnt skrev (53 minutter siden):

Heap-allokering unngår du like greit i C++ som i C. Med mindre du kalller biblioteksfunksjoner som allokerer på heapen (for eksempel via en ny std::vector), får du ikke noen nye heap-allokasjoner.

Det er også deler av STL som er helt trygt for embedded, helt uten heap-allokering, som f.eks. std::array og std::optional. 

Hva sitter man igjen med da? C med klasser og uten offisiell toolchainstøtte?

Kontroll handler ikke om å studere kompilatoroutput. Det handler om å ha kontroll over runtime, concurrency og minnebruk, noe man mister med første smart pointer eller STL-datastruktur, som er halve argumentet til å velge C++ i utgangspunktet.

Edited by Gavekort

Share this post


Link to post
23 minutes ago, Gavekort said:

Hva sitter man igjen med da? C med klasser og uten offisiell toolchainstøtte?

template, operatoroverloading, function overloading, en del nifty features via std::array osv, metaprogramming kan også være kjekt, spesielt når du virkelig vil tyne ut hver minste lille instruksjon og kopiering. 

Men hvis toolchainstøtten ikke er offisiell er det egentlig grunn nok til å ikke bruke C++, enig i det.

Quote

Kontroll handler ikke om å studere kompilatoroutput. Det handler om å ha kontroll over runtime, concurrency og minnebruk, noe man mister med første smart pointer eller STL-datastruktur, som er halve argumentet til å velge C++ i utgangspunktet.

Hva slags kontroll mener du du mister ved bruk av std::array, std::optional eller til og med std::unique_ptr?

Edited by PingEnt

Share this post


Link to post
PingEnt skrev (21 minutter siden):

Hva slags kontroll mener du du mister ved bruk av std::array, std::optional eller til og med std::unique_ptr?

Stackdybde, kostnad, og bruk til MMIO. Alt det som er annerledes fra å bruke et vanlig stack-allokert array og vanlige minnepekere. I 95% av tilfellene så stinker man bare til koden med å gå opp og ned i abstraksjonsnivå. Forskjellen mellom embedded C og vanlig C er at i førstnevnte så er du faktisk veldig oppmerksom på hva som er bak en peker, og bruker det ikke bare som et abstrakt konsept slik som C++ bygger tungt på.

Share this post


Link to post

Du innser vell at C++ kan gjøre alt C kan? Du kan gjøre akkurat det samme i C++ som du kan i C. For ikke å nevne at du kan kompilere og kjøre det i akkurat samme hastighet.

Share this post


Link to post

Vi snakker om nytten av utvidelsene C++ tilbyr. Dere må huske på at for hver unntakelse dere gjør med C++ desto mindre nyttig er det. Det er selvsagt kjekt med templates og overloading, men det er ikke nok til å overtale konservative embeddedutviklere til å bytte ut hammeren sin med en spikerpistol.

Share this post


Link to post

Ser at Verilog ikke er på listen i det hele tatt, mens VHDL kun er nevnt som et fotnote, selv om de faktisk nevner IoT som en pådriver for enkelte språk? Resultatene blant de andre språkene her er også noe merkelige.

Så leser man hva dette egentlig er, en særdeles upålitelig indeks, basert på noen resultater fra de største søkemotorene, med andre ord fullstendig verdiløs for å kunne si noe som helst om veksten til et programmeringsspråk, annet enn at noen språk ser ut til å ha marginalt flere søk enn i fjor osv.

 

Edited by 0laf

Share this post


Link to post
18 hours ago, alpha547 said:

Føler ikke helt kildene til statistikken er representativ for overskriften... "Årets vanskeligste språk" kunne ha passet like bra til denne statistikken/kildene ?

 

Ja, Rust ville til eksempel kommet mye høyere opp om de telte med antall ganger kompilatoren ga så god informasjon at Google ikke ble konsultert. :)

Share this post


Link to post

Stoler svært lite på disse tallene. Se f.eks. visual basic .net som har samme tall som c# og dobbelt så mye som javascript.

Har du noen erfaring med noen av de språkene burde man vite at det ikke er virkelighetsnært i det hele tatt.

Share this post


Link to post
Guest Slettet+987132984
1 hour ago, Martin Hansen said:

Stoler svært lite på disse tallene. Se f.eks. visual basic .net som har samme tall som c# og dobbelt så mye som javascript.

Har du noen erfaring med noen av de språkene burde man vite at det ikke er virkelighetsnært i det hele tatt.

Hva tror du tallene viser, da? Dette handler ikke om "beste språk" - i tilfelle du trodde det. ?

(Å telle antall søk i Google, Bing osv. er for øvrig ikke en soleklar indikator på bruk eller popularitet. )

Edited by Slettet+987132984

Share this post


Link to post
On 1/9/2020 at 1:13 PM, Gavekort said:

Jeg er ikke overrasket. Det er lite som erstatter C når det kommer til maskinnære språk. Rust virker ut som en god kandidat, men som en innenfor industrien så har jeg det ikke travelt med å kvitte meg med C.

C++ er dårlig optimalisert for embeddedutvikling. Man ønsker å unngå heap allokeringer og kostbare biblioteksfunksjoner. Det C++ tilbyr er kjekt for programmere, men er kaos for en som ønsker kontroll over systemet sitt.

Det er feil. Det er bare å unngå STL med sine allocators. I mange tilfeller er det ikke engang støttet så problemet løser seg selv.

Share this post


Link to post
l0mf0mgl0mbl0og skrev (24 minutter siden):

Det er feil. Det er bare å unngå STL med sine allocators. I mange tilfeller er det ikke engang støttet så problemet løser seg selv.

Heap-allokering var bare ett argument mot, og å droppe STL er ett argument mindre for å gidde å bruke C++.

Share this post


Link to post
1 minute ago, Gavekort said:

Heap-allokering var bare ett argument mot, og å droppe STL er ett argument mindre for å gidde å bruke C++.

Du heap-allokerer i C hvis du vil, du heap-allokerer i C++ hvis du vil. Men hvis du liker C bedre, flott for deg :)

Share this post


Link to post
l0mf0mgl0mbl0og skrev (7 minutter siden):

 

Vi snakker ikke om C. Vi snakker om C++ i sammenheng med embedded der 90% av hva du kanskje forbinder med C++-programmering er tvilsom bruk. Du kan sikkert krangle deg frem til en eller annen innsnevret variant av C++ som kunne tilfredsstilt mine krav for gadgets som templates og overloading, men ærlig talt så har tiden allerede løpt ut for salgspitchen.

 

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...