Springer ud som sprogudvikler

Det er ikke altid de store aha-oplevelser der kommer til at fylde mest i hvad man tager hjem fra en konference. Fra årets GOTO-konferencer kommer jeg nok primært til at tage en ny hobby: Jeg skal være sprogudvikler. Det bliver ikke det nye Go jeg stiler efter, men jeg har en række tanker om programmeringssprog jeg må prøve af i praksis. Det startede egentligt på JavaScript-tracket...

Først fortalte Douglas Crockford om syntax. Det bestod dels af et historisk overblik og dels af en gennemgang af en parser for et lille sprog.

Dernæst fortalte Phil Calçado om funktionel programmering i JavaScript. Objekter er bare så meget sidste årtusinde og højereordens funktioner er det nye sort.

For 15 år siden var jeg helt med på den funktionelle bølge og jeg skrev mange ting i Standard ML og et par ting i Haskell. Egentligt burde det være et glædeligt gensyn, endelig har alle andre fået øjnene op for de ting jeg så i funktionelle sprog for 15 år siden. Men der mangler et eller andet.

Efter konferencemiddagen endte jeg i hotelbaren og klokken blev omkring halv fire inden jeg kom op på værelset efter flere runder af diskussione om NSA vs. Den Frie Verden. Det har intet med sprogudvikling at gøre, men det betyder at min hjerne er tilpas udbrændt til at jeg sidder mere og hacker på et mindre projekt end følger med i dagens foredrag.

Der var dog et foredrag der helt uplanlagt fangede min opmærksomhed. Marcus Lagergren fortalte om JavaScript på JVM og kampen med at få dynamiske sprog til at virke på JVM.

Det er ikke enkelte aha-oplevelser jeg tager med fra de forskellige foredrag, men samlet har de lagt kimen til at jeg endelig skal til at designe og udvikle mit eget programmeringssprog.

Detaljer skal I ikke forvente de første par måneder. Jeg vil gerne have en mere klar ide før jeg lader mig påvirke af andres bike-shedding.

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Uanset om nogen (inklusive dig selv) nogensinde kommer til at bruge det sprog, du designer og måske implementerer, så er det en meget lærerig proces.

Ligesom enhver god humanist har en "skufferoman", som de af og til skriver lidt på, men som sandsynligvis ingen andre nogensinde ser, så bør enhver god programmør have et "skuffesprog".

  • 6
  • 0
#3 Deleted User

Også herfra.

Mine egne skuffesprog findes indtil videre kun i hovedet, men det er altid spændende at tænke over hvorledes de kan gøres bedre.

  • Kan man få feature X med uden at den bliver en klods om benet på oversætteren?
  • Kunne man samle nogle af de tiltænkte funktioner i færre funktioner med lidt bredere anvendelse?
  • Hvis de fleste brugere alligevel bruger en "intelligent" editor, er der så nogle ting som burde designes anderledes end traditionelt?
  • 1
  • 0
#5 Lars Tørnes Hansen

Jeg er ikke datalog og har haft god gavn af de 2 her bøger:

Egentlig fik jeg i sin tid fat i ANTLR 3 Reference bogen, men i mellemtiden er ANTLR 4 udgivet, så det er den bog jeg referer til nu. Jeg har ANTLR 4 bogen i PDF format: Der er flere gode eksempler i den bog end der var i ANTLR 3 bogen.

"Language Implemtation Patterns" bogen har været meget nyttig, synes jeg.

  • 0
  • 0
#6 Peter Makholm Blogger

Det glæder vi os til at høre mere om :-)

Det skal I nok komme til.

Jeg har et par kort på hånden, men skal lige tænke et par træk frem inden jeg spiller dem åbent ud. Ikke for at være hemmelig, men primært for at være sikker på at jeg ikke bliver distraheret af kommentare. Indtil videre har sproget fået et navn (Wulfenite), en todo-liste på Questhub.io og et git-repository på GitHub.

Der er lidt en historie bag navnet, men det er et af de kort jeg lige holder lidt på...

Jeg har ikke leget nok med Go til at jeg rigtigt vil kommentere på det. At jeg nævnte Go var mest bare som eksempel på et af de moderne hypede sprog.

  • 1
  • 0
#7 Jimmy Krag

Hvis det var noget, har jeg lidt en drøm om at lave et databasesprog der bryder med klassisk SQL. Indtil videre har jeg følgende overslag til designmål:

  • Sproget skal kunne kompilere til flere forskellige dialekter af SQL, så det er muligt at skrive databasekode til flere forskellige platforme på én gang. Dermed bliver det også muligt at lave biblioteker af genbrugelig kode.

  • Sproget skal være simpelt men kraftfuldt. Det skal så vidt som muligt ikke være et stort sprog med meget indbygget funktionalitet, men blot indeholde features der gør at almindelige handlinger (f.eks. foreach over nogle rækker og erklæring af variable) bliver nemmere at udtrykke, og koden generelt bliver mere overskuelig. Det skal samtidig gøre sproget tidsbesparende i forhold til at skrive SQL.

  • Sproget skal være nemt at parse og analysere. Både så det er nemt at debugge, men også for at undgå tvetydighed og gøre det nemt at implementere kodningshjælp i et IDE.

  • Det skal være nemt at udvide sproget med flere måldialekter af SQL.

  • Resultatet af en kompilering af koden skal være forudsigeligt og pænt så det er nemt at læse.

  • Den genererede SQL skal være hurtig, og udnytte optimeringer i målsprogene.

  • 0
  • 0
#8 Deleted User

Umiddelbart tror jeg at det vil være en ret stor hæmsko for et sprog som skal bryde med klassisk SQL at det skal kompileres til SQL.

  • Simple dialekter af SQL er ikke Turing komplette.
  • SQL er svært at kompilere, i modsætning til alle andre sprog jeg kender er heuristisk optimering en forudsætning for acceptabel performance. Dette gør det svært at forudsige performance.
  • SQL er et ekstremt højniveau sprog, hvor man ikke engang kan skrive kode på et mellemlavt niveau.

Alt i alt gør dette SQL til et meget dårligt kompilermål. Man kunne nok bygge et sprog med SQL-lignende funktionalitet og kompilere det til SQL, men et sprog som bryder med SQL principperne bliver du nødt til at kompilere til noget mere jordnært.

  • 2
  • 0
#9 Peter Makholm Blogger

Hvis det var noget, har jeg lidt en drøm om at lave et databasesprog der bryder med klassisk SQL. Indtil videre har jeg følgende overslag til designmål:

Det lyder meget ambitiøst og jeg vil tro at en del af dine mål strider imod hinanden på en måde det vil være svært at få et godt resultat ud af.

Først og fremmest at du vil generere læsbar SQL ud fra et kildesprog der er principielt anderledes end SQL. Selv med et fleksibelt målsprog kan det være svært, men med SQL som i forvejet er er besværligt målsprog , tror jeg det bliver noget nær umuligt.

Jeg tror aldrig jeg har debugget SQL. Jeg har stirret dybt og længe på SQL-kode og til tider fundet problemet. Men egentlig debugging tror jeg aldrig jeg har set værktøjer til. Så det designmål kræver formodentlig et form for Münchchausen-trick.

Jeg ville nok skære opgaven helt ind til benet: Definer et velegnet forspørgselssprog og lave en oversætter til den interne bytekode for et enkelt databaseprodukt. For eksempel SQLites virtuelle maskine.

  • 0
  • 0
#10 Peter Stricker

Jeg tror aldrig jeg har debugget SQL. Jeg har stirret dybt og længe på SQL-kode og til tider fundet problemet. Men egentlig debugging tror jeg aldrig jeg har set værktøjer til. Så det designmål kræver formodentlig et form for Münchchausen-trick.

Der findes masser af værktøjer til at debugge SQL. Både med mulighed for at singlesteppe og sætte breakpoints. Eclipse har Data Tools Platform, som er et værktøj der kan bruges til at debugge SQL rettet mod mange forskellige DBMS. Visual Studio har også en T-SQL debugger.

Ud over SQL, er der også masser af debuggere til XSLT, så blot fordi et sprog er deklarativt frem for imperativt, betyder det altså ikke at man skal undvære gode debugging værktøjer.

  • 0
  • 0
Log ind eller Opret konto for at kommentere