Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Lågnivå vs. högnivå språk (en återupptagen diskussion)

Tråden skapades och har fått 6 svar. Det senaste inlägget skrevs .
1
  • Medlem
  • Stockholm
  • 2009-01-11 21:56

Memark och jag hamnade OT i den här tråden, när Memark sade:

Ursprungligen av memark:

Att pekare och manuell minneshantering skulle vara "smidigare och vettigare när man väl lärt sig" har jag svårt att se. Möjligen att det är lite "coolt" att jobba närmare hårdvaran. Men det finns ju en anledning till att programmeringsspråk hela tiden blir mer och mer högnivå, och det man ser till att bli av med är just att behöva sköta sådant manuellt (det tar massor av tid, ger snudd på inga fördelar, och ger hemska buggar när man missar något). Jag är uppriktigt nyfiken på vilka fördelar du ser med att manuellt behöva ägna sig åt detta.

Varpå jag svarade:

Ursprungligen av Ylan:

Tror det är vettigt att känna till hur en dator fungerar på åtminstone det abstraktionslager närmast under det man jobbar på. Om man programmerar med garbage collection, tror jag man kan lyckas skriva ett riktigt slött program om man inte har en aning om hur GC fungerar.

Fördelen med Obj-C är ju att du i någon mening kan välja abstraktionsnivå:

Du kan skriva med GC, och inte bry dig om minneshanteringen alls. Att det fungerar är ju nya Xcode ett exempel på. Men Xcode använder sig av (eller skickar data till) GCC (the Gnu Compiler Collection) för kompilering. Är det möjligt att tänka sig GCC med GC? Skulle det finnas några problem med det? Skulle man kunna tänka sig något spel med GC?

Du kan använda den gamla Obj-C metoden med retain count. Detta kan ju vara vettigt om du skriver ett mycket minnesintensivt program, som riskerar bli alltför långsamt med GC. Risken ökar ju då för läckor och krascher, och det blir något råddigare att programmera.

Du kan optimera en metod genom att skriva den som ren C-kod, eller t. om. göra om en metod till att bli en C-funktion (om en kort metod anropas tillräckligt ofta tillbringar datorn, relativt sett mycket tid med att skicka meddelanden till metoden).

GC måste du välja att slå på eller av för hela ditt program. Men du kan skriva ett helt Obj-C program och bara skriva om en metod i C (förslagsvis den som är flaskhalsen)

Vilket följdes av:

Ursprungligen av memark:

Ylan, jag läser ditt inlägg med intresse. Rent tekniskt har du rätt i det mesta, men jag håller inte med om dina slutsatser. Just möjligheten att "gå ner ett lager" och "optimera metoder genom att skriva om dem i ett lågnivåspråk" åberopas ofta som viktiga instrument men det köper jag helt enkelt inte. Jag har inga siffror, men jag misstänker att det endast är i undantagsfall man nånsin behöver göra detta, och då enbart för t ex extremt beräkningsintensiva program. (Nu är min professionella systemutvecklarkarriär iofs bara inne på sitt tredje år, men jag tror mig ha ganska god koll på branchen.)

Med det sagt ser jag ändå inte hur detta skulle vara en fördel med Obj-Cs (alla äldre C-språks) antika minneshantering. I de allra flesta språk, så även t ex Java och VB/C#.NET kan man, vid behov, ändå använda pekare och allokera minne manuellt om behovet skulle uppstå. Vilket det mycket sällan gör. Det är alltså inte främst GC jag är för, utan möjligheten att helt abstrahera bort det faktum att datorn har ett fysiskt internminne (precis som man redan gjort med nätverksströmmar, filpekare, filallokeringstabeller mm).

Nu hörde jag något i veckans Twit, där Scoble sade något intressant om det som blev Vista (ca. 25 minuter in). Longhorn började skrivas i .Net, och när man hade kommit halvvägs, visade det sig att .Net inte riktigt höll måttet. Det blev därför förbjudet med .Net-kod i Vista, och man skrev om allting i C++. Detta arbete ledde till att Vista inte hann betatestas ordentligt. Han följer upp med att säga att det förvisso är en skillnad att skriva ett operativsystem och ett mindre (jämfört med Vista), företagsanpassat program.

Å andra sidan menar Mike Taylor i senaste avsnittet av Late Night Cocoa (LNC 37) som handlar om portning av program, att man skall skriva så mycket man kan i skriptspråk som Python och Ruby, för att slippa problem när man för över program från en plattform till en annan (förutom de fördelar Memark tagit upp med högnivåspråk).

Kan väl konstatera att Apple lagt sig vinn om att ge utvecklarna flera nivåer, vilka kan samexistera i samma program.

Är det någon som har synpunkter på Memarks och min diskussion, eller på Mike Taylors uppfattning och Scobles inside info från Microsoft?

Är det någon som skrivit för mobiltelefoner i exempelvis Java, och kan jämföra med hur det är att skriva för iPhone i Objective-C?

Vänligen, Ylan

Senast redigerat 2009-01-12 00:24
  • Medlem
  • Stockholm
  • 2009-01-12 01:19

Intressant. Min spontana känsla är att lågnivåspråk måste vara bättre, eftersom... uhm... det har ju alltid varit så. Men samtidigt är högnivåspråken idag såpass avancerade att det går att göra nästan vad som helst även i dem.

Jag antar att det måste mynna ut i frågan "vad ska programmet göra?" Att skriva en vanlig användarapplikation för dagens persondatorer kräver varken prestanda eller stabilitet jämfört med något som ska lira i 4 k RAM och styra en respirator.

Givetvis måste hänsyn tas till flera aspekter, men ju högre krav på programmet, desto lägre nivå på språket. (I min värld innebär lägre nivå bättre kontroll, men det kan jag ha fått om helt fel bakfot.) En grov generalisering från mig som inte arbetat med riktig programmering överhuvudtaget, men som lekt i ett gäng språk.

Inser nu att mitt inlägg kanske inte är så meningsfullt i trådens kontext, så jag återupptar det här i morgon och önskar godnatt.

Without C, we would've been stuck with BASI, OBOL and Pasal. Worst of all, we'd have to drink offee and oke while writing the ode.

Vad är "högnivå"? Det är rätt många saker. Garbage collection? Nackdelen med det är att när man inte kan styra över det så får man prestandasmällar när man inte vill ha det, men visst är det en högnivåfiness. Men det är så mycket mer, t.ex. function och operator overloading, och varför inte smart modularisering som eliminerar namespace-träsket? Bara en sån sak som att hantera strängar snyggt (inbyggt i språket och inte genom nåt harv med "strängobjekt") tycker jag är högnivå. Kan du skriva "Detta"+" "+"är en strängkokatenering" i ditt språk? (Oavsett mindre syntaxdetaljer.) Görs det utan att du måste skapa några objekt? Och så dynamiska arrayer. Ett högnivåspråk låter mig skala om mina arrayer utan att fippla med allokering. Det är en array av vad som helst jag vill ha, bara sätt längden, klart. Inga objektdeklarationer, ingen ärvning, bara deklarera på stacken och kör. Det kallar jag högnivå.

Pekare eller inte känns delvis som "golf eller krocket", sak samma. Vare sig dina pekare är explicit pekare eller själva pekandet döljs från dig så är det samma sak, du måste i alla fall testa att du inte refererar nåt som inte finns. Hur det hanteras ser lite olika ut, förstås. Men det beror lite på sammanhang. Använder man pekare till allting eller när det verkligen behövs? Pekare till objekt och dynamiskt allokerade strukturer tycker jag är naturligt, eller i alla fall en banal skillnad som fångas upp redan vid kompilering. Pekare till småsaker, nej tack. Så det beror på lite. Mycket småfippel mår bäst om man kan abstrahera bort pekarna.

Hej,

Högnivå mot lågnivå är enligt mig framförallt ett val mellan flexibilitet mot utvecklingstid.

Högnivåspråk:
+ Högre abstraktionsnivå=> mindre detaljer att hålla ordning på ger mindre buggar
+ Snabbare utvecklingstid
- Måste ibland kompromissa eftersom du inte kan göra "vad som helst"
- Kan i speciella situationer ge sämre prestanda (men ofta är detta problem överskattat)

Lågnivåspråk:
- Lägre abstraktionsnivå => mer detaljer att hålla ordning på, ger fler buggar
- Längre utvecklingstid
+ Kan utveckla med färre kompromisser
+ Kan ge bättre prestanda (i speciella situationer)

Har själv C++ bakgrund.

/Patrik

Jag pysslar ju mestadels med olika scriptingspråk, vilket somliga ju anser inte vara "riktig" programmering, men en sak jag lärt mig även i dessa "barnsliga" språk är att:

"Prestanda är inte ett problem, förrän det är ett problem"

Med vilket jag vill ha sagt att jag känner som att det finns en risk i att man stirrar sig blind på rent teoretiska optimeringsvinster som sällan har någon inverkan på det man faktiskt försöker lösa.

Herregud så mycket tid jag ägnat mig åt att optimera saker som egentligen är skitsamma, av ren "programmer's pride", jag menar typ hundra timmar på att få saker att rulla acceptabelt på en G3, medan det hade varit billigare och bättre för slutanvändaren att ha ett mindre effektivt program och för utvecklingskostnaden de sparat köpa en ny värstingmaskin. (nu ska jag till mit försvar säga att det är på kundernas önskemål jag gjort såna avvägningar, men deras bedömning har varit fel )

Ser man det så, som att utvecklingskostnaden är den största flaskhalsen, så blir argumenten allt svagare för lågnivåspråk.

  • Medlem
  • Mölndal
  • 2009-01-23 13:42

Det där är så oerhört sant!

Lägg till det gärna den gamla sanningen att ett program tillbringar 90% av tiden i 10% av koden. Vilken kod det är snudd på omöjligt att gissa innan, varför man gör bäst i att första skriva klart programmet och sedan profilera det. Först därefter kan man optimera väl valda delar om det skulle vara nödvändigt.

Dessutom innebär nästan alltid optimeringar att saker och ting blir krångligare. Att optimera redan under utvecklingen är därför ofta en dålig idé.

  • Medlem
  • Stockholm
  • 2009-01-24 00:15

Man kan väl konstatera att det i många fall är fullständigt överlägset att lösa ett problem med skriptspråk, men att man inte bör försöka skriva ett operativsystem i det!

Vänligen, Ylan

1
Bevaka tråden