Nästa funktion

C.

Det slog mig att nästlade funktioner borde kunna användas för att göra kod mer läsbar. Istället för att deklarera en privat hjälpfunktion som bara används på ett ställe som static och lägga den ovanför den anropande funktionen (eller, om man är en idiot som dricker bärs och lyssnar på skitmusik: efteråt, och med en för-deklaration längre upp), så stoppar man in den direkt i den anropande funktionen.

En sådan nästlad funktion kommunicerar tydligare än en static-funktion: den är uppenbart en privat hjälpfunktion, eftersom den bara kan anropas från den omslutande funktionen. Man slipper att idioter som dricker bärs och lyssnar på skitmusik lägger sina hjälpfunktioner var som helst i filen, använder fördeklarationer och låter bli att göra dem static. (Idioten som dricker bärs och lyssnar på skitmusik skulle givetvis ändå undvika att använda nästlade funktioner, för att göra koden så oläsbar som möjligt.)

Sen att det här är totalt oanvändbart i praktiken, eftersom det bara stöds av GCC, ja, det är ju lite trist. Men i framtiden kommer nog alla använda Lisp, Scala och Python istället för C. Och kanske Ada. Nej, inte Ada. Idioten som dricker bärs och lyssnar på skitmusik skulle antagligen välja Ada. Eller C#.

Lamers, lamers everywhere!

Simon Judge borde veta bättre än att tro att man måste använda Java eller något annat godtydligt högnivåspråk för att skriva portabel kod. Varför skriver man över huvud taget C-kod? Visst, skönhetsupplevelsen finns också där, men i första hand är det för att man är ute efter portabel maskinkod. Seriöst, hur svårt är det att få samma kod att funka på 3 olika little endian 32-bitars processorer? Marketing, marketing, marketing.

Massor av ljud i Python

Jag (erkänner helt öppet att jag) läste senaste numret av Linux Weekly News, där jag hittade nyheten att One Laptop Per Child-projektet har släppt ett samplingsbibliotek med över 8000 samplingar för fri nedladdning. Jag vet inte hur just du skulle reagera på en sådan nyhet, men min reaktion var att jag kände att jag måste skriva ett program som slumpar fram "musik" ur den här högen ljud.

Mina tidigare erfarenheter av att skriva ljudkod i mitt standardspråk C är att det brukar bli för jobbigt och att jag ger upp. Men Python då? Det har jag ju ändå tänkt lära mig någon gång. Att programmera i Python är typ 1000 gånger enklare än C, om man kan det, och det finns rutiner för att ladda och spara ljudfiler i standardbiblioteket. Bara att köra alltså. Jag skrev lite kod för att ladda och spara ljudfiler, vilket tog fem minuter. Mitt nästa steg var att testa lite enkla manipulationer av ljudbufferten. Där tog det stopp i över en timme, medan mr. Python n00b försökte ta reda på hur en int kan tryckas in i en sträng av bytes. I C hade man castat och varit klar. I Python, lärde jag mig till slut, kan man använda struct.pack(). Så nu sitter jag här med ett program på 21 rader som kan vända på en sampling, och känner mig nöjd tills vidare.

Kanske orkar jag vidare imorgon. Det känns som om jag har löst det ena av två svåra problem nu. (Det andra är hur jag ska få tag på 10GB ledigt diskutrymme till samplingarna.)