C och C++ är skitspråk, datorspråkens PC

Inte för att jag är programmerare ... men vilket språk är bra då?

Kan säga vad jag vet och har hört så blir program snabbast om man skriver dem i C.
Jag är inte C guru själv utan gillar med Objectiv C och detta språk har väldigt snygg syntax tycker jag.
Andra språk med snygg syntax

Haskell som skrivet mer eller mindre för matematiker(man tvingas skriva snygg kod, därför tar det lång tid innan kod man skriver fungerar)

AppleScript, lätt läst för alla människor

Jag är lite kär i Java faktiskt, men håller på att lära mig Obj-C. Tycker att Java är trevligt och på tillräckligt hög nivå för att jag ska stå ut. De få gångerna jag har programmerat C så har jag bara blivit irriterad. Om det beror på att jag lärde mig Java först och är van vid att inte behöva tala om för en funktion hur lång strängen jag skickar till den är eller om det är ren frustration över att inte behärska språket lämnar jag osagt...

Tjena. Alla program du använder på din dator nu är skrivna i C eller använder rutiner skrivna i C. Om du inte menar att alla program du använder är dåliga så har du fel.

Man ska använda rätt programspråk för rätt uppgift. C har definitivt sin plats, ibland måste man programmera maskinnära och det är precis det C är designat för.

Jo klart allt handlar om optimering, men tror inte det finns så många kompilatorer som optimerar så bra som C kompilatorer, eftersom C är så stor standard och många år på nacken. Kan tänka mig att backenden i gcc optimerar mycket men den optimerar ju lika mycket oberoende av språk. Så det som gör C snabbare borde ligga i optimeringar i Frontenden antagligen. Har precis börjat koda frontend för språket Enkel i skolan, och har nästan gjort klart en backend, men sitter med ett stort problem nu så kan inte redovisa den än grrr

Ja, jo.

Nu blev det religionskrig.

SJÄLVKLART kan man skriva bra program i C och C++. Man kan t.om. skriva bra program i RISC-assembler.

Därmed inte sagt att det är lätt.

Ju större friheter ett språk ger, desto större diciplin krävs av programmerarna. Så enkelt är det.

Men visst; Ska jag skriva ett stort och multitrådat serverpaket så väljer jag inte C i första hand. Eftersom jag är bekväm så tycker jag ju att GC är ett bra sätt att undvika att lägga veckor på att spåra minnesläckor...

Goto är ett typiskt exempel på en av datavetenskapens dogmer. Man lär unga studenter redan under de första kurserna att de inte ska använda goto. Man uppmuntrar dem inte ens till att själva resonera kring satsen och dra egna slutsatser kring dess existensberättigande.

Vid korta väldokumenterade hopp med tydliga etiketter kan kod som använder goto bli väldigt lättläst jämfört med strukturerad programmering.

Jag tror att det är oklokt att förkasta en användbar konstruktion på grund av att den potentiellt kan användas på ett dåligt sätt. Det är en dålig ursäkt att inte utbilda väldisciplinerade programmerare som har omdöme att avgöra när det är lämpligt att använda den.

Oj, det var en gammal tråd du väckte till liv här.

Jag undviker själv goto. Min åsikt är att det inte är goto i sig självt som är problematiskt, utan labels (etiketter). Dessa försvårar förståelsen av program vid enkel genomläsning.

:
:
a = 42;
return a;
:
:

I exemplet ovan är det lätt att se vad funktionen returnerar vid denna punkt, nämligen 42. Jämför med:

:
:
a = 42;
special: return a;
:
:

Nu vet vi inte längre vad programmet kommer att returnera här med mindre än att vi letar igenom hela funktionen för att hitta alla goto som hoppar till special.

På sätt och vis anser jag labels (som man kan hoppa till varsomhelstifrån) är värre än COMEFROM.

Det är klart att om funktionen är liten och enkel så kan det vara tydligt ändå, men små enkla funktioner är sällan de som "behöver" goto.

Ofta använder man goto för att hantera undantag. Man vill bryta sig ur invecklade nästlade loopar. I dessa fall använder jag oftast return-satsen istället. Jag ser till att funktionen returnerar en speciell felkod t.ex. Ibland har jag en övergripande funktion som anropar funktionen där jobbet görs och sedan tar hand om fel som kan returneras.

Jag är medveten om att många anser att det är av ondo att ha flera return-satser i en funktion. Men jag tycker ändå detta är bättre än att använda labels (och goto).

Jag håller med Ragnemalm. Jag använder C (och håller på att lära mig Obj-C) ofta och är väl en hyfsad C programmerare men har aldrig, hur maskinnära språket än är, gillat det. Det kräver otroligt mycket av den som kodar och visst man blir en liten j-vel på GDB och andra debug metoder men det gör ju inte språket i grunden bättre för det. Ett bra programspråk är effektivt men också lättläst.

Nu kommer säkert en hel del att skrika av ren förskräckelse men kolla in ett gammalt språk som COBOL. Det är historia men är elegant och framför allt är koden lättläst även om det sitter en en icke erfaren programmerare bakom spakarna. Visst det är språk som utvecklades för administrativa uppgifter men det präglar också språket och det är en baggis att lära sig grunderna i filhantering etc. Med C kan man spendera timmar med att försöka förstå logiken i koden , framför allt om man de-buggar andras kod och det kräver att man är noga med att kommentera sina rutiner för att andra ska förstå. Inte blir det mycket enklare med C++.

Förutom COBOL , som jag inte rört på många år nu gillar jag fortfarande konceptet med Pascal. Det har också
ellegans och var relativt lätt att lära och dessutom var koden relativt lättläst. Dessutom tycker jag personligen att Pascal på den tiden jag använde det till dom flesta uppgifter producerade precis lika effektiv kod som C. Om det skiljer en hundra del av sekund i exekvering spelade mindre roll. Tiden för utveckling i Pascal var ofta kortare än att göra samma uppgift i C.

Ett annat språk som jag kodade mycket i förr och som jag gillade för sitt lite omvända tänk är Prolog. Det passar inte dom vardagliga uppgifterna men har ett tankesätt som jag starkt gillar även om koden som producerades inte var särdeles snabb. Prologs idè är lite förenklat att beskriva sitt problem och sedan låta Prologs motor impletementera algoritmen för att lösa problemet Istället för som normalt klura ut hur tusan man impletementerar sin algoritm i ren kod. Men det är ett språk som är nichat mot AI. Fortfarande används LISP istället för Prolog trots att Prolog många gånger skulle ha varit enklare att använda.
(LISP är dock snabbare på att exekvera kod än Prolog) LISP döpte jag iaf snabbt om till Lot's of Independent Stupid Parantheses.

Men det finns många språk som säkert är bättre än både Java och C och C++ som glömts bort i något hörn av en eller annan anledning. Samma sak gäller många operativ som aldrig blev något. Se på BeOS.

Ett tag hörde man på konsultmarknaden bara COBOL , sedan var det bara C sedan blev det C++ (vilket jag hatar!) sedan blev det Java...som med allt annat. Det handlar om smart marknadsföring. Varför blev det DOS och inte CP/M eller varför dog VMS ut och Unix blev stort ? Varför dominerar Microsoft och inte Apple etc..

CP/M var överlägset DOS
VMS har en hel del saker som känns betydligt mer genomtänkt än Unix.
MacOS gillar jag iaf bättre än Microsofts Windows

Mvh
/Ulf

Är inte det givet? Frälsaren är på väg!
Perl6! Perl6! Perl6!

Redan Perl5 är ju trevligt.
Skriv detta på en rad i Pascal...

$olle =~ s/VAR\s+(\S+)\s+\%([^\%]+)\%/$keepers{uc($1)}=$toUpper?uc($2):$2/gei;

Hm, var inte en av Ingvars invändningar att c-kod kan vara svårläslig för andra programmerare än den som skrev koden.

Jo, som en del brukar säga... Perl är det enda språket där koden blir snyggare av att kompileras...

Jo kan hålla med dig faktiskt.

C är ett nice språk men finns många bättre men också många sämre, tror också val av språk har med en smaksak att göra beroende på person till person.

Java känns mest som en förenklad version av C++ där man tagit bort saker som att användaren kan överlagra operatorer och att man slipper minnes hantering, på gott o ont så klart

Själv tror jag att Obj.C är min favorit än så länge iaf.

Personligen så tycker jag att alla språk har sina fördelar och nackdelar. Det går att skriva dålig och bra kod i alla, lättläst eller svårläst kod, etc.

På nåt litet vis så finner jag att det alltid finns nåt som jag gillar i olika språk (C,C++, Java, ML, Modula, Pascal, Fortran, Occam, RB, Perl, Objective C, etc).

Måste dock erkänna att jag har lite svårt för Objective-C syntax (det ser ut som man har utnyttjat pre-processorn för att få C OO). Lite svag är jag för Modula-2 och även Perl (även om det är svårläst)

Anledningen till att C och C++ blivit så pass stora språk och defacto standard har ingenting med Bill Gates att göra, utan
att det är väl spritt, standardiserat och användbart.

Jag är själv uppfödd på Pascal för 20 år sedan och det är ett utmärkt undervisningsspråk, när det gäller procuderala språk ( dvs ej objektorienterade ). Jag har också skrivit stora programsystem i Pascal, men eftersom standarden är väldigt begränsad så hade varje tillverkare lagt till egna utvidgningar; ergo kaos. Knuth hade aldrig tänkt att Pascal skulle bli annat än ett utbildningsspråk. Alternativen på den tiden, främst FORTRAN var rena skräckexempel.

Pascal är ett starkt typat språk, dvs kompilatorn håller efter dig, eftersom vissa operationer endast kan genomföras på vissa datatyper. Så är inte C ( men väl C++ ) eftersom det mesta är tillåtet och du kan bolla med typerna hipp som happ utan konverteringar. Det är ett av de värsta felen med C, ett klassistk exempel är att jämförelseoperator (==) i en if sats av misstag kan skrivas som tilldelning ( = ) vilket är tillåtet men inte ger önskar resultat.
C har en massa funktioner som ger tillgång till t ex bitoperationer på maskinvaran, vilket höjer komplexitetsgraden avsevärt eftersom du även måste förstå vad som händer i hårdvaran. Detta har dock inte så mycket med språket i sig att göra.

C++ är det enda objektorienterade språket som är någorlunda användbart ( med ett litet undantag för Java ). Det är ofantligt stort men svårigheten ligger snarare i att hantera objektorienteringen på ett effektivt sätt än i C++ som språk. Inkapsling och abstraktion som är hörnstenar i objektorientering ger rätt använda en stor flexibilitet och säkerhet, men med en dålig förståelse och design blir det garanterat kaos.

Java är ett bra språk, men man har tagit bort vissa konstruktioner som pekare och multipelt arv ( jmf C++), vilket konstruktören tycker ger mer problem än lösningar. Problemet är att verkligheten har tvingat fram dessa konstruktioner och ett språk som saknar dessa kommer antingen att ge upphov till ett antal ostandardiserade tillägg, eller gå till historíen som ytterligare att abstrakt universitetsprojekt.

I dag ser jag inga trovärdiga alternativ till främst C++ men även C. Ingemar har du några förslag ?

/Göran

Bit operationer finns i de flesta språk. Jag är inte säker på att Java interface skulle vara nåt sämre alternativ än C++ multipelt arv, det är två varianter på en lösning till samma problem. Jag tror att det är fel att säga att C++ lösningen är bättre, det får framtiden utvisa ... det är mycket fråga om vad man är van vid.

Samma sak gäller alternativ till C++ och C, det är inte frågan om att de skulle vara bättre utan snarare vad som är investerat i mjukvara (personer), mjukvara (utvecklingsverktyg) och mjukvara (skriven kod). Även om det kom språk som var fullkomligt överlägsna existerande språk så skulle C++ och C leva kvar i många år framåt.

På den tiden jag programmerade i sådana språk, så var det Pascal som gällde. (Det var för övrigt inte Donald Knuth, utan Niklaus Wirth, från Schweiz, som hittade på det, liksom Modula2). Tycker fortfarande att det är ett elegant språk, som både är läsbart och effektivt. Man kan givetvis inte använda det längre, eftersom det inte finns kompilatorer och utvecklingsmiljöer som stödjer det.
Jag minns att jag var på kurs i 4D en gång i tiden (helt utvecklat i Pascal från början, vilket väl bör visa att språket inte sätter gränsen för vad man kan åstadkomma). Kursen hölls av en av programmerarna bakom 4D. En deltagare frågade varför man inte använde C när man skrev 4D och fick bara en motfråga till svar: Varför skulle man göra det? Det fanns inget man kunde göra i C, som man inte kunde göra i Pascal. Det som behövde programmeras maskinnära skrev man ju ändå i assembler direkt, och det fanns ingen fördel med att använda inline-assembler, jämfört med att köra asm under MPW.
Han påpekade också att inget språk hade någon "inbyggd" hastighet, utan det bestämdes av kompilatorerna och åtminstone på den tiden fanns det lika bra kompilatorer för Pascal som för C.
Hur fort det går att knacka kod beror på hur väl man kan språket och inte språket i sig. Dessutom kan man inte nog understryka att de viktigaste insatserna för att åstadkomma ett snabbt och bra program görs långt innan första raden kod skrivs, i systemeringen och planeringen. Detta är ett ofta bortglömt faktum, inte minst av mig själv...;)

Peronligen tycker jag att det är biblioteken som är den stora grejen. Är biblioteken bra designade? Hur mycket täcker de? Hur mycket behöver man lära sig för att göra X? etc

Rätt, hjärnan snubblade fram på aftonen. Jag har också skrivit en del Modula-2 som jag också tycker är bättre än C. Jag är mer förtjust i Algol språken (Algol, Simula, Pascal, Modula2 mf l ) än i C men de är tyvärr tämligen döda i verkligheten. Däremot är de utmärkta utbildningsspråk vilket INTE C och C++ är.

Jag har programmerat mycket assemblerrutiner som jag länkat med till högnivåkoden, men sedan jag gick över till C har jag skrivit i princip allt ( inklusive drivrutiner ) i C eller C++. Det är faktiskt bättre och blir mer läsbart, hastighetsförlusterna är försumbara.

Visst är Java ( som jag inte kan specillt bra ) lättare än C++, men om jag vill hålla mig till en verktygslåda så får det bli C/C++.

Till syvende och sist så är det programmerarens skicklighet och diciplin som avgör hur bra det skall bli.

/Göran

Återigen måste jag påpeka att Pascal aldrig har varit lämpligt för en källkod som skall portas till flera plattformar. Det här uttalandet kom säkerligen på den tiden som 4D endast fanns för Mac.

Påståendet att språk inte har inbyggda hastigheter kan man lugnt säga är grovt förenklat, om inte rent ut sagt felaktigt. Det går självklart inte att generera snabbare kod för ett block som börjar med en måsvinge istället för BEGIN. Där är det ingen skillnad. Men, nu har det upprepats så många gånger i den här tråden att det inte finns NÅGRA konstruktioner i C som överhuvudtaget gör det snabbar som gör att jag inte kan hålla tyst längre. Om jag minns rätt kan man register-deklarera variabler i C och det kan man inte i Pascal. Pascal kräver att storleken på en array är med i datatypen, vilket gör det omöjligt att skriva en procedur som hanterar en genrella arrayer. I C är det definerat vilken ordning ett logiskt uttryck evalueras, vilket det inte är i Pascal.

Ja, man kan alltså lägga till ett antal teoretiska skäl till varför Pascal skulle kunna generera mindre effektiv kod än C. Jag tycker dock att dom praktiska skälen väger mycket tyngre. Det finns massa fler C-kompilatorer. Dom är sannolikt dom mest optimerade av alla språk. Det finns ett hyffsat stöd för att skriva portabla program.

I modern systemutveckling spelar inte 2% hastighetsökning hit eller dit någon större roll. I vissa exterma fall gör det det. Men, i det stora hela är det buggar som är det stora problemet. I just det fallet så har ju ett starkt typat Pascal en fördel jämfört med C. Men, jag blir upprörd om man säger att C inte har någon fördel över Pascal.

Nu var det ett tag sedan men Ada var (är) väl så där, inte lika rent och fint (enligt mitt tycke) som Modula-2.

Jo, men kanske den nya Perl 6 som de nu jobbar på är kompilerande (dvs kan bygga binärer)

ADA föll på att det var stort, svårt att skriva kompilatorer för ( ialla fall som fungerade på 80-talets begränsade datorer ) och kompilatorerna vansinnigt dyra. När vi valde mellan C och ADA till VAX/VMS ca 1988 så kostade C kompilatorn 60KKR och ADA 300KKR. Lätt val.

ADA har en del bra konstruktioner, t ex operatörsöverlagring ( som i C++ ) men är inte i sin ursprungliga form objektorienterat, däremot tror jag att den senare versionen ADA9X är det.

Jag var ett tag medlem i ADA in Sweden men slutade när inslagen av religiositet började bli alltför markant. På ett möte i Stockholm fick jag på nöten av de renläriga när jag föreslog Modula-2 i stället. Det tyckte att det var ett akademiskt oanvändbart språk, ja ja.....

Tror till och med att Department of Defence som låg bakom ADA:s tillblivelse inte längre insisterar på att det skall användas i skarpa system. I Sverige var det ett tag ett skall krav för nya vapen och ledningssystem, men jag tror att FMV tonat ner det nu.

/Göran

Vill bara trycka på att det var Jean-Pierre Ribreau som pratade om Pascal och 4D, och inte jag...
Nåväl, det är alldeles riktigt att Pascal gjorde det svårt att porta programmen och när 4D skulle släppas i Windows-version, blev man mycket riktigt tvungna att skriva om alltihop i C.