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

[Kurt Lekanger]

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

[LMH1]

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?

[Gavekort]

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.

[Gjest Slettet+5132]

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.

[Gavekort]

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.

[alpha547]

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 ?

 

[Gjest Slettet+5132]

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

[Gavekort]

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.

Endret 9. januar 2020 av Gavekort

[Gjest Slettet+5132]

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?

Endret 9. januar 2020 av Slettet+5132

[Gavekort]

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

[sdiujqiweu]

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.

[Gavekort]

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.

[0laf]

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.

 

Endret 9. januar 2020 av 0laf

[Anders Jensen]

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. :)

[Martin Hansen]

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.

[Gjest 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. )

Endret 10. januar 2020 av Slettet+987132984

[l0mf0mgl0mbl0og]

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.

[Gavekort]

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

[l0mf0mgl0mbl0og]

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

[Gavekort]

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.