5 programmeringssprog jeg gerne ville lære - hvis jeg havde tid

Java og C# er ganske brugbare, men er ikke lige den slags sprog, der giver point at bringe på banen omkring kaffeautomaten. Så hvis jeg havde tid, ville jeg lære noget nyt.

Hvilke programmeringssprog ville du lære, hvis du kunne sætte dig ned og begynde fra Hello World?

Først en tilståelse: Jeg er temmelig grøn som programmør. Ikke som i umoden, men snarere sådan lidt muggrøn, fordi jeg aldrig kom til at bruge det Java, jeg lærte lige før, vi fik svar på, om Y2K ville føre til vor civilisations endeligt. Så bær over med mig.

Mens Java, C#, Javascript og mange andre populære programmeringssprog nok skal klare jobbet, så er de også så mainstream, at de ikke ligefrem kan bruges til at indlede en programmør til programmør-samtale ved kaffeautomaten. Det er der derimod en række andre sprog, der kan.

Så her følger min liste over sprog, jeg gerne ville lære at kende, ud fra lige dele teknisk fascination og almindelig nysgerrighed:

5. Julia

Anvendelsen af Julia er langt uden for mit domæne, men jeg er vild med et sprog, der både vil lidt shell og samtidig vil måle sig med C og Fortran til tunge regneopgaver. Listen over ting, Julia indeholder og gerne vil er alenlang, og det må man respektere.

Ulemperne er, at dokumentationen henvender sig til øvede programmører, og så er det ikke ligefrem et sprog, man trækker op af hatten til at løse enhver opgave.

4. Lua

Lua er et scriptsprog, som udmærker sig ved at være understøttet gennem udvidelser til en stribe forskellige formål og ved at være så kompakt, at det kan køre på næsten hvad som helst. Det kunne være et ret godt valg til Internet of Things. Lua er også scriptsproget for machine learning-frameworket Torch. Nå ja, og så bruges det også til World of Warcraft.

Den væsentligste ulempe er, at der er mindre dokumentation tilgængelig online, så hvis man vil lære sproget, så er man næsten nødt til at have fat i en bog.

3. COBOL

Bare det, at navnet står med versaler, indikerer alderen på COBOL, der er uløseligt forbundet med gamle mainframesystemer og programmer, ingen tør pille for meget ved. Men netop den mytologi, der er omkring COBOL, er dét, der gør sproget fascinerende. Måske er det lidt som en hipster, der vil lære at køre på væltepeter.

Ulempen er selvfølgelig, at det arkaiske format i COBOL ikke rigtig er relevant, hvis man ikke har en mainframe stående.

2. Swift

Det er måske lidt poppet i forhold til de andre sprog på listen - sådan lidt som popsangerinden med efternavnet Swift. Men der er noget om hypen, for Swift er ikke bare populært til at kode applikationer til Apples platforme, men er også på vej ind mange andre steder, efter Swift blev open source i november 2015. I modsætning til de øvrige sprog på min liste har Swift en klar anvendelse i kommercielle sammenhænge.

Til gengæld er Swift stadig hovedsageligt et Apple-projekt, selvom IBM også er gået ind i det, og spørgsmålet er, hvor meget af hypen omkring Swift der stammer fra app-manien.

1. Rust

Der er dem, der hævder, at al software burde skrives i Rust. Det er lige nu det bedste bud på et programmeringssprog, der både ser ud til at kunne holde, hvad det lover, når det gælder sikkerhed, og være brugbart til applikationer. Specielt for sikkerheden er det spændende, at sproget hjælper med at gøre det rigtigt, men uden bare at rydde op efter dine fejl som med garbage collection.

Rust har dog også af samme grund et lidt helligt skær over sig, som kan være trættende, og ligesom flere andre nye sprog, er dokumentationen bedst for de øvede.

Hvilke sprog ville du gerne lære, hvis du skulle tage et afbræk fra Java, C#, C++, PHP, Javascript eller hvad du ellers normalt færdes inden for?

Følg forløbet

Kommentarer (55)

Jakob Sørensen

Måske ikke særlig eksotisk, snarere grænsende til mainstream, men jeg kunne godt tænke mig at få lært Ruby. Måske man en dag også får tid til det...

Andri Oskarsson

Personligt har jeg lyst til:

  1. Elixir: Ruby inspireret funktionelt sprog på Erlang virtual-maskinen. Nok mit næste backend sprog.
  2. Elm: Funktionelt sprog i browseren, kompilerer til JS. Giver dig statiske typer og compile-level-check på alle ting (HTML, CSS, Elm koden). Den har også indbygget React lignende virtuelt-dom som gør det at man kan fokusere på hvordan dataen skal renderes, ikke hvordan DOM skal ændres.
  3. R: Statistik, fordi... det kunne være sjovt at lære noget lidt anderledes.
  4. Rust: Fordi nogen gang har man lyst til at lave lidt low-level og hvis du lærer et nyt sprog i 2016, burde det være memory-safe. Rust har alle evner for at erstatte C++ og muligvis også C.

Der udover sker der rigtig meget indenfor databaser, containere, cloud-løsninger og andre IT ting. Slet ikke tid nok til alle de nye ting. Kan også varmt anbefale Go(lang) til servere og lidt backend (det var på listen for 2 år siden).

For de dovne, links. Elixir, Elm, R, Rust

Jimmie Jensen

Jeg har beskæftiget mig med primært ObjectiveC og tildels Java og C# de sidste år, og relativt for nyligt kastet hænder og hoved over Swift - jeg vil anbefale at prøve det af hvis muligheden byder sig. Det kan være sig i en "playground", eller nogle af de mini-webserver projekter der findes på Github.

Sidenote:
App-projekter hvor Swift og ObjectiveC blandes, kan være lidt udfordrende til tider, tooling'en er ikke som den kunne være, men det er i småtingsafdelingen, og problemer som kan løses.

Lars Pedersen

I mine dage som programmør hos Rovsing (i 80erne), havde vi et programmeringssprog kaldet SWELL (= SoftWare Engeneering Low level Language).
I korthed bestod det af Pascal datastrukturer, men helt uden runtime. Koden operede således på assembler-niveau, hvilket gav strukturede programmer, der var nemme at læse, samtidig med at det gav assembler performance.
Eks:
Tal1 => R3 "flyt Tal1 ind i register 3
Tal2 => R01*R3 => Tal3 "flyt Tal2 ind i dobbeltregistret 01, gang med R3, gem i Tal3

Desværre er det nok af rent historisk interesse!

Søren Schrøder

The Compiler Language With No Pronounceable Acronym, abbreviated INTERCAL

Bare det at man skal huske et "PLEASE" engang imellem, for at forblive gode venner med compileren (men ikke for meget, for så ved den at man bare fedter for den), er på sin plads. Der er mange der bare tager compileren for givet !

Min Wu

Har lært Swift og Go for nyligt, kan varm anbefale de to, og rust bliver den næste.

Swift er bedst til at lave app i øjeblikke, og jeg tror det vil overrasker mange om et par år, når swift bliver udbrede som steppebrand på Linux og konkurrere med C++. Og Swift føler mere som skrive code i ruby, Python, javascript, men performance er ikke lange fra C++, og der er ingen garbage collector. Og der mangler nogen optimering her og der, mere kompatibilitet med Linux, og det er bare spørgsmål om tid.

Go er bedst til cloud løsning, high performace backend. Java æder alt for meget hukommelse. Go routine er fantastisk, når det gælder concurrency, og at håndtere mest muligt load, især ved peak spike, hvor andre system typisk vil bukker under. Og mange vil sige hvorfor ikke scala, scala er bedre end java, men det kører stadig på JVM.

Rust er allerede hurtigere eller på niveau med C++, men hukommelse forbrug er stadig lidt for højt sammenligne med C++, men kan beat java anytime. Der mangler bare mere community til at drive den frem som Swift gøre. Swift er blevet open souce og tage sin indtog på Linux, så rust udbredelse vil stå under press.

Jeg er for længst komme væk med standard java/c#/php syndrom. Det er hele sikke god nok til at løs nogen problem og får sig en job i Danmark. Men det er ikke længere de bedst programmering sprog i år 2016. Min rejse har være C - Java - C# - php/javascript - Python - C++ - objective-C/node.js - Swift/Go/Rust.

gert bo thorgersen

Jeg savner LISP, med dets ovenfor kendte øgenavn, ikke var blandt de 5. For mig er det det bedste at bruge i AutoCAD, og det er vel stadig et af de udvalgte til kunstig intelligens, altså robotter.
De andre jeg også kan lide er Assemble og C++, for for mig er det dem jeg har fundet bedst til hvert deres arbejdområde.

Kim Henriksen

Nå ja, og så bruges det også til World of Warcraft.

Lua er meget almindeligt at bruge i forbindelse med MMO spil.

Det gør det nemt at programmere/rette quests, NPC'er, våben, items etc.

Eksempelvis http://www.swgemu.com/forums/index.php bliver der brugt LUA.

SWGEmu er en Star Wars Galaxies server emulator kodet fra bunden, som blev skabt fordi SOE(Sony)/LucasArts lukkede spillet.

Sebastian Paaske Tørholm

Jeg er nok påvirket af, at jeg lige har været en tur til POPL-konferencen, men et par sprog jeg er blevet nysgerrig om i den sammenhæng er:

Racket

Scheme-variant der lader til at være det hotte sprog indenfor programmeringssprogsforskning.

F*

F#-variant der kompilerer ned til F# eller Ocaml. Finten er, at den har et noget vildere typesystem og en inbygget SMT-solver, så man kan producere beviser om sine programmer, samtidig med at man koder noget der ligner F#. Det virker ret lækkert.

Michael Zedeler

Har du nogensinde set et erlang stacktrace? Hvis du har og stadigvæk er interesseret i elixir, er du enten meget modig eller også kender du erlang i forvejen.

Erik Hougaard

Den væsentligste ulempe er, at der er mindre dokumentation tilgængelig online, så hvis man vil lære sproget, så er man næsten nødt til at have fat i en bog.

Lua bliver primært udviklet af én mand, Roberto, og salget af hans bog, PiL (Programming in Lua http://www.amazon.com/Programming-Lua-Roberto-Ierusalimschy/dp/859037985X ) er klart den bedste måde at støtte sproget på, og samtidigt får man så også en super velskrevet bog.

Troels Henriksen

Alle bør lære mange programmeringssprog. Jo flere jo bedre! Og også gerne designe nogle selv - det lærer man meget af. Hvis jeg skulle nævne tre sprog jeg gerne ville lære, så må det være:

Forth: Det er et stort hul i min dannelse at jeg aldrig har lavet konkatenativ/stakprogrammering. Det må der rettes op på!

APL (eller en dialekt som J eller K): Jeg kan godt noget APL, men jeg har aldrig brugt det til større ting. Arrayprogrammering er en fascinerende model der kan nogle imponerende ting, og det har potentiale til at køre ret hurtigt.

Rust: Nævnt af andre før mig. Lader til at være det bedste bud på en bedre C.

Jn Madsen

Jo da.
Jeg er kun hygge-programmør,- men da jeg skulle udse mig 2 sprog (alle siger man skal lære 2 forskellige),- så udså jeg mig primært Python og sekundært Haskell.
Det der med monads virkede så underligt, at det skulle der kigges nærmere på.
Jeg er ved at få Python under neglende efterhånden,- Haskell sejler desværre stadigvæk :)
For 20 år siden lærte jeg lidt assembler,- det er helt og aldeles glemt.

Jeg tror helt grundlæggende ikke på, at man kan være god til mange sprog ... eller mange ting på samme tid.

Michael Zedeler

Jeg tror helt grundlæggende ikke på, at man kan være god til mange sprog ... eller mange ting på samme tid.

Det er jeg ikke enig i. Jo flere forskellige sprog, man kan, jo bedre bliver man til dem allesammen. Jeg har udviklet professionelt i 20 år og på hobbybasis i 30. Listen over sprog, jeg har rodet med, er meget lang (men jeg kan sige at den starter med basic og assembler på tre forskellige arkitekturer) og jeg kan bare se at jo flere sprog, jeg har set, jo nemmere bliver det at læse og forstå kode - uanset om det er et sprog jeg kender, eller ej.

Men selvfølgelig kommer det også an på hvad du mener med "god".

Jesper Louis Andersen

Har du nogensinde set et erlang stacktrace? Hvis du har og stadigvæk er interesseret i elixir, er du enten meget modig eller også kender du erlang i forvejen.

Det er ikke fair overfor Elixir, fordi de omskriver Erlang stack-traces så de i højere grad ligner stack traces fra andre sprog.

Grunden til at de kan det er iøvrigt at Erlang stack traces er forud for deres tid på 2 afgørende måder. Dels er de strukturelle, maskinlæsbare og det forventes at du shipper dem til en central enhed der kan indexere dem. Det er så småt ved at ramme mainstream sprog med strukturel logging gennem e.g., logstash. Det er også derfor det er så nemt for Elixir at omforme dem til noget der er mere mainstream.

Den anden grund er at en fejl i et Erlang program ikke bare er et stacktrace. Det er sådan set et mini-coredump for den fejlende proces. Du har også tilstanden omkring processen ud over stack tracet selv. Så det forventes lidt at du kan læse "maskinnært" output når du skal regne ud hvad der går galt. Denne ide er også ved at finde sin vej ind i mainstream, så småt gennem arbejde Joyent laver med mdb og deres S3 storage klon, Manta: en fejl i dit program laver et coredump og det indexes så centralt. Du kan nu senere loade det coredump og lave post-mortem debugging. Men det er akkurat hvad Erlang systemer går i deres crash report systemer.

Troels Henriksen

1ML

Det ser faktisk meget interessant ud - jeg kan huske at Bob Harper også mente at moduler og datatyper skulle smeltes sammen.

Og lidt ironisk, at jeg for tiden er interesseret i SMLs modulsystem netop fordi det ikke er det samme - det garanterer nemlig at funktorer og funktorapplikation kan oversættes væk, hvilket har nogle interessante konsekvenser hvis man gerne vil generere hurtig kode.

Sascha Dibbern

Fordi det kan udvides til og med ethvert andet programmeringssprog, eller sagt med andre ord (frit oversat fra Larry Wall) ... ethvert programmeringssprog er en derivat-sprog af Perl6 ;-)

P.S. Perl6 er efter over 15 års sprogudvikling fastlagt og releaset

Ivan Skytte Jørgensen

Målet med INTERCAL er bl.a. at kun have features som ingen andre sprog har (og ingen ønsker at have). Det har betydet at sproget er blevet mindre gennem mange år :-)

Jeg overvejede at foreslå følgende feature til INTERCAL newsgroup:

DO  
  ...kode...  
UNLESS ...betingelse...

hvor det ville være pænt rollback hvis betingelsen viste sig at ikke blive opfyldt. Man kan så overveje hvor fantastisk mere letlæselige programmer bliver med den konstruktion. Men så kom jeg i tanke om at progress-4gl faktisk har den feature (ja, transaktioner på lokale og globale variabler).

Det er nyttigt at studere tåbelige, farlige og forældede features i andre sprog (INTERCALs ABSTAIN og COMESFROM statements, COBOLs "ALTER" statement, Smalltalks mulighed for at omdefinere hvordan addition virker på heltal, osv.), fordi man så i sit daglige arbejde indser faren når man er ved at skrive ævivalenten til ALTER i f.eks. C++

Jesper Louis Andersen

Og lidt ironisk, at jeg for tiden er interesseret i SMLs modulsystem netop fordi det ikke er det samme - det garanterer nemlig at funktorer og funktorapplikation kan oversættes væk, hvilket har nogle interessante konsekvenser hvis man gerne vil generere hurtig kode.

Stratification er virkeligt kraftfuldt.

Det er lykkedes Rossberg at phase-splitte 1ML, hvilket i sig selv er ganske imponerende. Men jeg ved ikke om det er lykkedes ham at lave endnu et phase-split så du kan isolere functors der kan håndteres på oversættelsestidspunktet via expansion. Det ville være dejligt hvis du kunne kode functors som man plejer og så få hastigheden ud af dem.

Troels Henriksen

Det ville være dejligt hvis du kunne kode functors som man plejer og så få hastigheden ud af dem.

Det ville være særligt rart hvis det var en del af typesystemet. Der er intet galt med at have et enormt udtryksfuldt sprog, men omvendt kan det være belejeligt at kunne lave en 'map', og være sikker på at dette omdannes til en stram løkke med funktionskroppen inlinet. Visse oversættere kan det nogle gange, måske, men der er ingen garanti som sådan (eller nogen måde at hjælpe oversætteren med dens arbejde).

HW Jensen

Har hørt at compileren er langsom, men som et skridt videre fra java lyder det godt. Jeg har aldrig synes at java var ideelt, men det gør hvad det skal, og når man så begynder at kode javascript går det pludseligt op for mig at det kunne være meget værre, og man kommer til at værdsætte at der er en rigtig compiler som understøtter syntaksen.

Baldur Norddahl

Vi er helt sikkert et par stykker der koder Scala, men overskriften er "programmeringssprog jeg gerne ville lære" - så man skal vel ikke skrive om det man allerede kan?

Hvis det skal være en slags anbefaling, så vil jeg opfordre til at se på Scala-JS. Det er den nye måde at kode web applikationer på. 100% integration med JavaScript miljøet og samme sprog på server og klient. Automatisk klient/server kommunikation og type tjek på tværs af klient og server. Og ja, der er også andre sprog end Scala der er med på den vogn, men jeg synes nu Scala-JS er noget særligt. En god introduktion her: http://www.lihaoyi.com/hands-on-scala-js/

Tak til ham der nævnte F*. Den står nu på min liste over ting jeg skal lære en dag :-). Ikke at jeg tror jeg kommer til at kode i det, men jeg er lidt fascineret af konceptet med at kunne bevise egenskaber i programmet. Vil godt udforske hvor tæt man kan komme på programmer der er garanteret til at virke korrekt.

Søren Koch

Jeg vil dog mene at man bør holde sig til Perl 5.

Pel 6 er stadig over 100 gange langsommere end perl 5 selv for et simpelt 'hello world' program.

Det gør i min optik perl 6 mindre egnet som 'glue language' hvis det skal bruge 300 ms på bare at starte fortolkeren op.
En af perl5's store styrker er jo at den er så god til oneliners og som filterprogram i pipe-sekvenser mm.

Jesper Louis Andersen

Tak til ham der nævnte F*. Den står nu på min liste over ting jeg skal lære en dag :-). Ikke at jeg tror jeg kommer til at kode i det, men jeg er lidt fascineret af konceptet med at kunne bevise egenskaber i programmet. Vil godt udforske hvor tæt man kan komme på programmer der er garanteret til at virke korrekt.

Det er den samme ide i Idris.

I princippet kan problemet anskues ved at du som programmør i dag skriver et program og nogen typer ned. Maskinen laver så noget "skjult" kode i form af maskinkode og sletter alle typerne.

Robin Milner viste[0] at man kunne dreje den lidt: Man kunne i visse tilfælde nøjes med at skrive et program, og så regnede maskinen typerne ud for en. Men i den forbindelse sker der desværre nogengange det at maskinen er nødt til at generalisere voldsomt, og det gør at man får nogen icky situationer der ikke helt lader sig type pænt.

Man kunne også prøve at gå den anden vej: skriv nogen typer ned og lad maskinen regne programmet ud. Det er et langt mindre gennemsøgt område. Finten er så, at hvis dine typer er præcise nok, så er programmet den kan genereres eller hjælpes på vej det program man søger.

I praksis sker der det vidunderlige at du ikke længere har en term-verden og en type-verden. Du koder i begge på samme tid. Og de levede lykkeligt til deres dages ende.

[0] I fucking 1973. Når vi har så mange problemer i IT, så skyldes det i høj grad at industrien overhovedet ikke har overvejet hvad der er forsket i.

Torben Mogensen Blogger

Swift føler mere som skrive code i ruby, Python, javascript, men performance er ikke lange fra C++, og der er ingen garbage collector

Det er en sandhed med modifikationer. Swift har en garbage collector, men den bruger reference-counts. Fordelen er, at der kun i få tilfælde er lange pauser i programudførslen, og det er relativt enkelt at distribuere over flere processorer med delt lager. Ulemperne er, at man skal bruge eksplicitte "soft pointers", hvis man har cyklisk data (som f.eks. dobbelthægtede lister) og at der er et meget stort overhead. Personligt foretrækker jeg en concurrent tracing collector, som også undgår pauser, men som tillader cyklisk data på en transparent måde, og som har betragteligt mindre overhead end reference counting.

Ironisk nok har jeg for nylig skrevet en artikel, der foreslår reference counting kombineret med hash-consing til garbage collection i reversible funktionssprog, men det skyldes de constraints, reversibiliteten giver, så selv garbage collection skal være reversibel. Hvis nogen kan lave en reversibel tracing collector, hører jeg gerne om det. :-)

Hvilket bringer mig til andre sprog, interesserede kan prøve at lære: Janus (http://topps.diku.dk/pirc/?id=janus) er et reversibelt imperativt sprog, og rFun (http://topps.diku.dk/pirc/?id=rfun) er et reversibelt funktionssprog.

Erlo Haugen

Om Rust:
"Det er lige nu det bedste bud på et programmeringssprog, der både ser ud til at kunne holde, hvad det lover, når det gælder sikkerhed, og være brugbart til applikationer. Specielt for sikkerheden er det spændende, at sproget hjælper med at gøre det rigtigt, men uden bare at rydde op efter dine fejl som med garbage collection."

Ligner meget godt en kort beskrivelse af Ada. Det er et omfangsrigt sprog, men er absolute værd at stifte bekendtskab med.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen