Varför Modula-2?
Jag har ofta blivit tillfrågad om varför jag har valt att koda FtpServer i Modula-2. Alla andra verkar använda C eller C++, så varför inte jag?
Det korta svaret är att jag inte ger mycket för argumentet "Alla andra använder det". Om popularitet skulle vara viktigare för mig än tekniska meriter, skulle jag inte använda OS/2.
Det långa svaret finns i ett dokument kallat "The Case Against C", som kan hittas på http://murray.newcastle.edu.au/users/ftp/pub/reports/CaseAgainstC.ps.Z. Det är en komprimerad Postscript fil. Om du inte kan hantera komprimerad Postscript, finns en text version ( CaseAgainstC.txt) som också kan hittas i samma katalog.
Och det medium långa svaret finns på den här sidan.
För att börja med, effektiviteten hos en run-time modul är inget större problem som många människor verkar tro att det är. Med modern kompilator-teknologi, ger de vanligaste programmeringsspråken (undantaget BASIC och dess släktingar) ungefär samma effektivitet hos en run-time. C och C++ förlorar lite på grund av deras låg-nivå konstruktion som gör det svårt för kompilatorn att göra ett bra jobb med optimering; siffror som jag har sett visar att ett program som är skrivet i Modula-2 körs lite snabbare än samma program skrivet i C eller C++. Emellertid, skillnaden är typiskt mindre än 5%, och knappast något att bry sig om. Så den stora frågan är effektiviteten i utvecklingsarbetet. För ett jobb som detta kan vi direkt diskvalificera språk som BASIC och REXX eftersom de är lite för primitiva; och vi kan också diskvalificera språk som Fortran eftersom de inte stöder "System-programmering". Vi kan dessutom diskvalificera mindre kända språk eftersom de inte finns tillgängliga för OS/2 som kompilator. Då återstår Pascal, Ada, Oberon, Modula-2, C, och C++.
Jag använder inte Pascal eftersom Modula-2 i grunden är en uppgraderad Pascal, och jag kan lika gärna använda den förbättrade versionen.
Jag har inte sökt efter tillgängligheten till Ada kompilatorer för OS/2; men i vilken fall som helst tycker jag inte om Ada eftersom det är för komplicerat. Ju större ett språk är, ju fler saker kan gå snett.
Oberon är en mera subjektiv sak. Några människor kommer att påstå att Oberon är efterföljaren till Modula-2, och är ett förträffligt programmeringsspråk. Min personliga uppfattning är att Oberon har tagit bort några av de goda egenskaper som gör Modula-2 till ett bra språk. Jag håller däremot med om att detta ärende inte är helt klarlagt.
Det för oss till C och C++. Jag har gjort en hel del C och C++ programmering under åren, och det gett mig en känsla av att dessa språk är stora hinder för effektivitet i programmeringen. Det tar mig grovt räknat dubbla tiden att få ett C eller C++ program att fungera jämfört med ett Modula-2 program. (För vissa projekt har jag fört logg för att kunna verifiera påståendet.) Tiden för kodningen är ungefär den samma, men det är en avgörande skillnad i tiden för debugging. Varenda människa jag känner skriver buggiga program i C och C++, och sedan får de spendera oändligt mycket tid på att försöka hitta felen. Några utvecklare ger upp och säljer programmen som dom är inklusive buggarna.
Det finns två huvudskäl till att C program är så utsatta för buggar.
- Brist på säkerhet för typer. C är konstruerat på ett sådant sätt att kompilatorn inte kan utföra
särskilt mycket kontroll av fel, kompilatorn ger inga varningar för saker som, i ett typ-säkert språk skulle rapporteras
som fel under kompileringen. Du kommer inte att se felen före exekveringen av programmen, och då blir du lämnad undrande vad det
var som orsakade felet.
- Dålig support för modulär programmering. Om du bryter upp ett C program i moduler, är dom inte riktigt oberoende av varandra. En mindre ändring i en modul kan få katastrofal effekt på andra moduler. När ett projekt ökar i storlek tappar du kontrollen över din egen kod.
C++ är lite bättre i dessa två avseenden, men C++ har sina egna problem. De som designade språket försökte överföra hög-nivå egenskaper till ett låg-nivå språk, och resultatet blev en mängd inkonsekvenser. En typisk referensmanual för C++ är åtskilliga gånger så tjock som för andra språk därför att varje regel har ett virrvarr av undantag och specialfall.
Dessutom har jag noterat att flera C++ programmerare verkar ha anammat filosofin "Låt oss prova och hoppas att det fungerar". Vanan att inte skriva kod som man inte förstår verkar ha blivit omodern. Kanske det är språkets fel (och dess kataloger), kanske inte, men det inte sättet som jag föredrar att arbeta på.
Slutligen, orsaken till att jag använder Modula-2 är att den låter mig få applikationerna användbara snabbt, den ger mig kontroll över stora projekt och den tvingar mig inte att spendera mängder av tid på debugging. Jag är för gammal för att uppskatta jakten på obskyra buggar. Jag gillar att få något fungerande, och sedan vara fri att ägna mig åt andra projekt.
Naturligtvis är det svårt att garantera att något som helst dataprogram är buggfritt, oberoende av vilka utvecklingsverktyg som använts. Men jag kan det näst bästa, vilket är en acceptabelt låg felfrekvens.