Oldgamle APL lever og har det godt i finansverdenen

... they just fade away. APL har den fordel i forhold til de fleste ældre sprog, at det er meget højniveau, så det ikke bliver irrelevant samtidigt med den hardware, det blev udviklet til. APL har haft stor indflydelse på blandt andet funktionsprogrammeringssprog, og der har været flere forsøg på a modernisere APL, blandt andet ved at fjerne dets afhængighed af specielle tastaturer og tegnsæt. Dette aspekt er dog efter min mening en mindre hindring, da alle computere nu har højopløsningsskærme og -printere, så man ikke behøver specielle terminaler eller printere til at vise APL. Og givet APL's høje kodedensitet er det ikke noget stort problem at skulle bruge tastekombinationer eller skærmkeyboards til at taste programmerne ind.

Jeg betvivler ikke, at APL kan bruges til at programmere en løsning på en masse problemstillinger som artiklen også antyder med reference til bl.a. ExxonMobil m.m. Jeg er interesseret i høre om alt det som følger med APL: Givet et alm. større projekt i dagens Danmark: 1) Er det nemt at få supporteret APL kode ude i byen eller har jeg ved brug af APL reelt tvunget min organisation til at beside specialist viden med dyre nøgleressourcer til følge? 2) Hvor nemt vil det være for mig at skaffe nye udviklingsressourcer ind som jeg ikke først skal sende på kursus + on-the-job-training? 3) Hvornår kan jeg reelt spare noget ved at vælge APL frem for et andet sprog ala' C/Haskell/Java/F#/C#/...? 4) Kan jeg nemt få APL kompileret til binær kode som jeg kan bruge fra C#/Java/... kode? Altså skal jeg lave alt i APL eller findes der udviklingsværktøjer m.m. som gør at andet kode kan APL kode? 5) Hvor modne er APL kompilere? Kan de konkurrere med C++ kompilere med hensyn til optimering m.m. Ken

[quote]1) Er det nemt at få supporteret APL kode ude i byen eller har jeg ved brug af APL reelt tvunget min organisation til at beside specialist viden med dyre nøgleressourcer til følge?[/quote] I dagens Danmark tror jeg ikke der er ret mange konsulenter derude der kan APL. Simcorp har "altid" været et APL hus, men jeg ved ikke om de også gør i bodyshopping. Så svaret er nok - det skal du selv kunne - men produktiviteten er måske en faktor 10 højere end traditionelle programmeringssprog som PL/1, COBOL. Jeg har ingen fornemmelse af hvordan det er med f.eks. Java og lign. Det betyder at dit team er meget mindre - hvilket du selvfølgelig kan vælge at sige bare gør problemet værre :-) [quote]2) Hvor nemt vil det være for mig at skaffe nye udviklingsressourcer ind som jeg ikke først skal sende på kursus + on-the-job-training? [/quote] Jeg ved ikke om de underviser mere i APL på det der i sin tid hed Stærkstrømsafdelingen på DTU, men ja det bliver nok problemet. Eller opgaven. [quote]3) Hvornår kan jeg reelt spare noget ved at vælge APL frem for et andet sprog ala' C/Haskell/Java/F#/C#/...?[/quote]APL er fortolkende hvad det indebærer af effektiv debugging (du kan stoppe programmet et bestemt sted, undersøge alle værdier både globale variable og lokale, evt. sætte nye værdier og så køre videre. Som anført er koden meget tæt, bl.a. fordi du med enkelt operator kan operere på et helt n-dimensionelt array osv. Det er et helt andet paradigme end meget andet. [quote]4) Kan jeg nemt få APL kompileret til binær kode som jeg kan bruge fra C#/Java/... kode? Altså skal jeg lave alt i APL eller findes der udviklingsværktøjer m.m. som gør at andet kode kan APL kode?[/quote]Spørgsmålet er egemntlig stillet forkert :-). Der er mange der har prøvet at lave en APL kompiler således at når koden er OK, så kunne man kompilere den og få en performance gevinst ud af det. Men dels er der med mange moderne (!!!) APL implementeringer så avanceret fortolkning, at den ikke bare slavisk fortolker de nøgne operatorer, men man har i APL nogle "standard konstruktioner" kaldet idiomer, og i hvert fald IBM APL2 kunne genkende sådanne idiomer og sprang således en masse fortolkning over. På (IBM) mainframes har men en vektorfacilitet, som er specielt gearet til at regne på arrays. Den er selvfølgelig specialt god til store komplekse ingeniørberegninger og hertil brugte man tidligere Fortran. Fortran (og andre sprog på Mainframe) skulle ved kompilering anføres om koden skulle benytte vektor faciliteten eller ej. Ved små arrays er opstartsprisen for vektorfaciliteten for højh i forhold til gevinsten, men der ved store arrays er en stor fordel. APL kan, fordi den fortolker, vælge om den vil fyre op under vektor faciliteten eller bare køre det på den alm. måde. Der var solide gevinster i APL's favør ved dette. APL har en facilitet der hedder "Auxilery Processors". Det er en slags plug-ins til forskellige ting uden for APL - for eksempel GUI interfacet i Windows, DB2, OS-kommandoer mm. Og APL kan kaldes med parametre hvor en er det workspace den skal loade og hvilken funktion der skal autostartes. Derved kan du faktisk godt starte APL fra et andet miljø. AP er dokumenteret, så du kan skrive dine egne AP'er. [quote]5) Hvor modne er APL kompilere? Kan de konkurrere med C++ kompilere med hensyn til optimering m.m.[/quote]Som sagt ved jeg ikke om der findes kommercielle APL kompilere - som jeg husker det var holdningen for 20 - 25 år siden da jeg førte mig frem "i miljøet" at ud over det stred imod sprogets eller miljøets ånd, så var det langt fra givet at en kompilering ville give de performancegevinster som man håbede på. Og i lyset af at jeg har set en APL*Plus køre helt fornuftigt på en 4.88 Mhz PC XT, så kan jeg slet ikke forestille mig at en 4 GHz quadro processor med 4 eller 8 GB RAM skulle kunne opleves langsom - overhovedet. Tror jeg vil bruge aftene iaften med at finde ud af om man stadig kan få IBM APL2 for Windows og så lege lidt med den :-)

Advarsler: Langt indlæg. Debattøren lever af at designe, implementere og sælge APL-systemer. Michael Deichman har allerede givet sit svar på mange af spørgsmålene - men jeg har en lidt anderledes vinkel på mange af dem, så jeg håber at I tilgiver dette lange indlæg. [quote]Men kan det lave kaffe?[/quote] Jeg vil ikke anbefale at man bruger APL til at brygge kaffe. Men hvis man skal optimere produktionen eller transporten af kaffe-bønnerne (specielt hvis man tror man har en ny ide hvor der ikke allerede findes standard-biblioteker til at finde løsningen), så kan APL være et godt hjælpemiddel. Hvis man vil udvikle nye kaffe-sorter, eller finde ud af om man virkelig tjener penge på at sælge kaffen, så ville jeg helt klart se på APL som et potentielt værktøj til analyserne. Ser man derimod på software-udviklere som en billig ressource som blot oversætter specifikationer til kode, og nemt skal kunne udskiftes (eller måske endnu bedre outsources), så er det ikke sandsynligt at man vil få ret meget glæde af APL. Det scenarie, hvor de aller største gevinster høstes, er der hvor APL anvendes af personer som har direkte indsigt i det fagområde, hvor der skal udvikles nye software-løsninger. Typisk taler vi om aktuarer, økonomer, kemi- og elektro-ingeniører, fysikere etc. Med mindre disse personer samtidig har en IT-baggrund, viser vores erfaring at de faktisk hurtigere bliver produktive med APL, end med traditionelle sprog. Og vigtigere: Det bliver muligt for dem at løse problemer, som de bare ville give op over for, hvis de enten skulle skrive dem i Java/C – eller prøve at ”specificere” dem, så et hold af Java/C eksperter kunne løse dem. For ”opfinderen” er det sidste faktisk tit sværere end at skrive det selv. Det er ikke nemt at hyre og fyre disse personer. Det ER lidt af en udfordring for en leder at skulle forvalte den slags "raw power" - men problemerne kan sagtens løses - og sådan er det altid når man løber stærkt. Forklaringen på produktiviteten ligger i at APL er en matematisk notation som er designet til undervisning i naturvidenskabelige emner - og til at beskrive af matematiske ”processer”. Den første fortolker blev først udviklet nogle år efter at sproget havde været anvendt i undervisning. Skal man være grov, tager designet af de fleste andre sprog udgangspunkt i at man nemmest muligt skal kunne skrive effektive compilere til dagens hardware – eller undgå bestemte typer af fejl hos udviklere som arbejder med store projekter. Ikke ligefrem noget, det hjælper udvikleren med at tænke kreativt eller undgå "forståelsesfejl". De fleste store virksomheder, som bruger APL, ansætter normalt mest økonomer eller ingeniører (plus enkelte deciderede softwareudviklere, se nedenfor). Det tager måske 3-4 uger at lære dem nok APL til at de bliver produktive. Jeg vil våge den påstand at det tager en smule længere tid for en typisk C- eller Java udvikler at sætte sig ind i (for eksempel) økonomiske teorier og skattelovgivningen omkring aktier og obligationer - eller petrokemi. Man kan selvfølgelig ikke forvente at en økonom eller ingeniør uden en egentlig IT-baggrund kan konstruere store og velfungerende systemer (selv om det er forbløffende, hvad de til tyder lykkes med). De kan ikke tage de nødvendige hensyn til overordnede sikkerheds- og performance-hensyn – eller andre krav til ”indpakning”. Derfor bør ”domain-eksperterne” pakkes ind i et hold, hvor der er tilstrækkeligt med folk der både forstår APL-udviklernes arbejdsbetingelser OG de krav som der ellers stilles til moderne IT-systemer. I vore dage er der ingen problemer med integration af komponenter skrevet i APL: Moderne APL-systemer (som Dyalog APL - se http://www.dyalog.com), kan generere COM og .NET moduler, implementere WebServices, WCF komponenter, bruges som ”scripting language” på websider – i det hele taget pakkes ind i alle de interfaces som et programmerings-sprog forventes at benytte i dag. DotNet klasser skrevet i APL kan indgå i hierarkier som er delvist implementeret i andre sprog, etc etc. Men hensyn til modenhed / kompilering: Vores fortolker fejrede 25 års jubilæum i år, så den er efter hånden ”vellagret”. Der findes delvis kompilering eller oversættelse til for eksempel C#. – men ingen ”komplette” compilers til APL (i og med at grænsen mellem kode og data er meget grå i APL, kan man faktisk ikke lave en 100% kompilering). Man kan også anvende APL som et specifikations-sprog og så skrive applikationer om til andre sprog i hånden, når de har stabiliseret sig og problemerne er fuldstændig kortlagte: ExxonMobil anvender en teknik hvor en del optimeringer løses ved at APL-koden genererer FORTRAN (fordi FORTRAN compilerne fremdeles er dem der løber aller hurtigst på mange numeriske metoder), som benyttes som input til optimerings-rutiner skrevet i andre sprog. Faktisk viser det sig at mange applikationer som afvikles i APL faktisk har bedre performance end konkurrerende produkter baseret på C++. Man kan selvfølgelig ALTID skrive et program som har bedre performance i C eller C++, hvis man bevarer overblikket. Men source-koden vokser tit med en faktor 10 eller mere, og den dekomponering i objekt-modeller etc som normalt finder sted betyder tit at man har let for at overgeneralisere og ender op med noget kode som selv verdens bedste compiler ikke kan få til at køre så hurtigt som kompakt APL. Som Michael nævnte havde IBMs "APL2" support for mainframens vector facility (som det første IBM produkt), og i dag er arbejdet godt igang med at udnytte multi-core maskiner og computation grids fra APL. Det er selfølgeligt ikke altid tilfældet at APL kører super stærkt – men runtime ydelse er heller ikke altid det vigtigste. Der hvor APL anvendes er det normalt ”time to market” – evnen til at tilpasse produkter til nye markedsbetingelser, tit i løbet af dage eller uger - som er den vigtigste parameter. Denne hastighed kan simpelthen ikke opnås hvis der kommer for mange lag ind i processen mellem dem der virkelig forstår problemerne, og den endelige løsning. Hvis man i et land som Danmark ønsker at være konkurrencedygtig i fremtiden, bliver det efter min mening nødvendigt at satse på software med et højt niveau af indebygget (teknisk) viden. Der er MANGE penge i at inddrage andre end ”programmører” direkte i udviklings-processerne. Selv om APL har 40 år på bagen er det fremdeles et pænt stykke "forud for sin tid" på dette område.