Jag tror vi talar om samma sak. Nyckelorden är alla case-sensitive (lowercase) i C/Python/Java/alla(?) shell-språk/etc.
Det förbättrar både läsbarheten och skrivbarheten när man har “moderna” verktyg med syntax highlighting.
Jag har dock inget emot att Ada, COBOL och SQL är case insensitive. Men jag skulle aldrig skriva ett nytt program i COBOL. Med det sagt tror jag inte heller att Java är ett optimalt språk för ändamålet. Och det var väl det storbankerna försökte använda som ersättare i de mer eller mindre havererade projekten?
Jag läste en del programmering när jag gick I-Linjen på 1980-talet. Gjorde mitt ex-jobb genom programmera en produktionslinje för mikrovågsugnar i Simula och gjorde även en del jobb i Pascal.
Potentiellt kontroversiellt påstående: COBOL är lättläst för någon som begriper engelska.
Efter examen så jobbade jag med införande av ERP-system, Systemet var skrivet i Cobol. När man skulle gå igenom problem på kodnivå så var det enkelt att förstå logiken utan någon erfarenhet av Cobolprogrammering.
Jämför det med att läsa något i Java eller C++…
Jag har faktiskt läst en kurs i Cobol på universitetet också för mycket länge sedan, har dessbättre lyckats förtränga det mesta.
En grundtanke med Cobol var dock att det skulle ligga nära mänskligt språk i syfte att alla skulle kunna förstå och behärska det.
Det de missade då är bara att mänskligt språk inte är lämpligt för att uttrycka exakt och väldefinierad logik. Mänskligt språk är fullt av tvetydigheter och onödigt pratigt.
Det är en nackdel då det leder till mer text att ta in för att förstå vad som verkligen händer. Det såg vi med det enkla Hello world ovan, väldigt mycket text för nästan ingenting.Skalar vi upp det och tar ett verkligt och komplext exempel då blir det än svårare att förstå vad som händer med Cobol än med moderna språk.
Klarna är ju ett “ungt” företag som inte har någon ryggsäck, de valde Erlang just för att det passar så bra in på realtissystem, de var ett aktivt val av grundarna av Klarna.
Erland är lite speciellt då du kan ändra koden i realtid utan att komplicera eller starta om, vilket är en bra funktion i en telefonväxel där det först användes, du kan skriva om koden utan att miljoner stockholmare får sina telefonsamtal avslutade…
Ericsson utvecklar ju Erlang aktivt, men även COBOL är ett högt närvarande språk.
Många tror inte att det finns nya stordatorer idag men det är också en myt, IBM tillverkar fortfarande dessa, men de är såklart väldigt, väldigt mycket modernare idag.
Att det är utdöd teknik är hel fel.
Att man kan ta mer betalt som COBOL eller Erlang utvecklare är också en myt.
De flesta bankerna kör med CICS eller IMS, det är baserat på message passing/actos , vilket är samma
Stil som de flesta andra finanssystem använder även om de inte kör COBOL
Varför detta fokus på programmeringsspråk? Jag är säker på att man kan lära sig COBOL på en vecka. Om man jobbar på stället i 4 år är det 0,5% av tiden. Det är ju miljön runt som tar tid, men det är inte unikt för COBOL — alla ställen har sina system man behöver lära sig.
Det vore spännande att lära sig något helt nytt och jag tror inte jag hade ”behövt en psykolog” heller, det ser mindre bökigt ut än assembly…
Visst blir det mycket text i COBOL, men det ska sägas att alla raderna utom just DISPLAY… i exemplet en bit upp är sådant man har en gång i programmet oavsett om det är 1 eller 10000 rader kod.
Jag ville veta om det var så bra betalt som COBOL-programmerare. Jag letade upp några på LinkedIn som jobbat med COBOL upp till ca 5 år. Sen kollade jag deras löner på Ratsit. Lönerna var ganska mediokra för programmerare, ca 40-45 tusen per månad.
Som vanligt när det är brist på programmerare, så är det brist på folk som har jobbat det här företaget i 25 år. Nya ingenjörer finns det ingen brist på.
Ja sådan overhead bör man förstås bortse ifrån eftersom det bara är en kostnad i ett mycket litet kodexempel. Mer relevant är enkla kodstycken utan sådan overhead som t.ex. detta:
for (i=0; i < 10; i++) {
printf("%d", i);
}
Allt i denna kod som pockar på uppmärksamhet annat än det som verkligen är kärnan är negativt enligt min mening.
Detta enkla exempel görs mer pratigt i vissa språk och mindre pratigt i andra språk. Att t.ex. använda ord som begin och end för kodstycken tar fokus till något som inte är kärnan i vad som utförs.
Ett annat sätt att skriva motsvarande kod i Javascript är detta:
Som sagt, betydligt enklare än assembler, se exempel längre ner.
En liten rolig anekdot: för kanske 20 år sedan så var jag med i en tävling där man skulle skriva ett “masken”-spel i DOS-miljö och målet var att den exekverbara filen (COM-fil) skulle vara så liten som möjligt. Reglerna var att man skulle kunna styra masken med piltangenterna, masken fick bli längre och längre och så fort man körde utanför skärmen eller in i sig själv så var det game over.
Jag jobbade på (i assembler) och var rätt nöjd när min COM-fil var nere på 78 bytes (dvs 78 tecken) stor.
Nu kom ju windows 95 för 30 år sen, vet inte hur länge supporten borde gälla
Sen kan man väl diskutera hur bra det var av Bombardier att installera ett klient-OS när Windows 2000 redan hade kommit…
linux datorer räknar ju sekunder från 1970, epoch känt sedan länge, deras sekunder kommer ta slut 2038… dock bara för äldre versionen som främst kör 32 bitars operativsystem (Men många andra saker kan sluta fungera dock)
Kan inte se någon anledning till att windows 95 skulle visa fel tid, däremot kanske den inte längre kan hantera sommar och vintertid korrekt? eller att datorn har ett BIOS som går på sista versen, eller att batteriet tagit slut…
Oss hos är det så vanligt med gamla Windows versioner så IT avdelningen har gjort i ordning färdiga skyltar som sätts upp vid maskinerna ifråga.
Typ, ”Denna dator får under inga som helst omständigheter kopplas upp på nätverket”.
Annars rolig anekdot på ett av mina tidigare företag fick de efter många års diskussion igenom en investering på att byta affärssystem. Beslutet gick fort när det väl visades sig att den nya VDns lön hade fler siffror än vad lönesystemet klarade av att hantera.
Lite off topic, men det bör nog tilläggas att Klarnas teknik i början utvecklade av externa personer som var experter på just Erlang [1]. Så att kalla det ett aktivt val av grundarna, som var ekonomer, är att slira lite med sanningen. Det kanske hade gått åt pipsvängen med annat språk, men tror mer på att det var den plattform som detta “erlang-gäng” kunde bäst.
Om det faktiskt var ett bra val i längden vet nog bara de team på Klarna som just nu maintainar det.
Men det finns andra aspekter, så som t.ex. läsbarhet. Där exempelvis
console.log(...Array(10).keys());
… är ett ypperligt exempel på kod som är svårbegriplig. Nu har jag 10+ års professionell erfarenhet av javascript, men för någon som kanske är mer bekväm med andra språk och/eller inte lika insatt i just detta språk uppstår omedelbart frågor så som om javascript är 0-indexerat eller ej, dvs kommer den börja räkna på 0 eller 1? Skriver den ut en array? Eller skriver den bara ut siffrorna var för sig? Kommer de på en egen rad? Hur var det nu med spread-operatorn, bygger det på att console.log kan ta emot godtyckligt många argument?
Som konsult och kunnig inom 6-8 språk och van att hoppa in i gammal okommenterad kod kan jag säga att jag skulle föredra kod som är tydlig och enkel att se exakt vad den gör, över en som minst antal bytes boilerplate.
Det är utvecklartiden som är dyr. Kod som är svårbegriplig eller kräver att man kollar upp exakta detaljer om hur exakt vissa specifika inbyggda funktioner fungerar är oerhört mycket dyrare att underhålla jämfört med “enkel” kod även om den är lite mer verbose i sitt syntax.
Men det finns så klart överdriften; när verbositeten gör att man inte ser koden för alla tecken!
Här sätter du fingret på skillnader i tänk när Cobol skapades jämfört med tänket på senare tid.
Då var tanken att man inte ville vara beroende av experter utan man hade idéen om att även en VD skulle kunna förstå denna affärskritiska kod. Därför skulle det vara så nära vanligt mänskligt språk som möjligt.
Senare började man inse att det inte var en bra idé, bättre att höja tröskeln för att kunna förstå koden men när man väl har vissa baskunskaper så blir det så mycket lättare att förstå den. Lätt att kärnan i vad koden faktiskt gör försvinner i en djungel av syntax annars och då blir det svårare att förstå helheten av vad som faktiskt händer.
