Torben Mogensen header

RIP John McCarthy

Som man kan læse på blandt andet The Register, er LISPs fader John McCarthy død i en alder af 84.

John McCarthy er, som nævnt, mest kendt for at have designet sproget LISP, som er en forkortelse for "LISt Processing", et sprog McCarthy lavede fordi han mente, at der var brug for at regne på andet end blot tal -- altså beregninger på symboler, lister og træer. Den parentesrige notation, som LISP er kendt for, var i starten kun tænkt som et skridt på vejen til en mere traditionel matematisk notation, men McCarthy indså hurtigt fordelen ved at have programmer i en form, der nemt lod sig manipulere af andre programmer. Og netop metaprogrammering er en af de ting, som kom til at kendetegne brugen af LISP fremover.

McCarthy arbejdede med designet af LISP mellem 1956 og 1958, hvilket gør det til en af verdens første højniveausprog. Kun FORTRAN har overlevet længere end LISP, som stadig bruges dels i form af Common LISP men også i form af Scheme og Clojure, som er direkte efterkommere til LISP. LISP er også forfader til funktionelle sprog såsom ML, Haskell og F# på samme måde som Algol 60 er forfader til Pascal, C og Java.

Fordi LISP var så anderledes end FORTRAN, skulle der udvikles nye implementeringsmetoder. Blandt andet er garbage collection udviklet af McCarthy for at implementere LISP. Designet indeholdt også nogle spøjse detaljer, såsom operatorerne CAR og CDR, som hentede hhv. første og andet element af et par (eller hovedet og halen af en liste). Operatorerne tog navn efter opdelingen af registre på den IBM 704 computer, som McCarthy brugte: CAR står for "Contents of the Address part of Register" og CDR for "Contents of the Decrement part of Register". På trods af, at navnene var maskinspecifikke og ikke sagde meget om, hvad de egentlig gjorde, holdt navnene ved, mestendels fordi de blev generaliserede til f.eks. CADAR, som tager hovedet af halen af hovedet af en liste. De alternative navne FIRST og REST kunne ikke ligeså let og kompakt sammensættes.

McCarthy var også en tidlig fortaler for kunstig intelligens, men skældte samtidig ud på folk, som forvekslede computerintelligens med menneskelig intelligens. Han forudså endvidere allerede i 1961 levering af regnekraft på samme måde som levering af strøm og vand, hvilket vi i dag kender som Internettet og skyen.

Jeg har mødt John McCarthy et par gange. Første gang i 1987, hvor han besøgte Danmark til workshoppen "Partial Evaluation and Mixed Computation", hvor også hans kone Carolyn Talcott deltog, og senere på Stanford University, som jeg besøgte et par år senere.

Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Palle Simonsen

LISP er blevet karakteriseret som værende "More advanced than any programming language before and any programming languages after". Som en, der har programmeret professionelt i Interlisp-D, Common Lisp og C (og Java og PHP og ...) kan jeg kun være 100% enig i den karakteristik. Den meget korte vej fra tanke til handling er en klar styrke i sproget, ligesom de gode abstraktionsmuligheder, håndtering af kode som data og vice versa sparer en hel del omveje, som man har i senere og mere primitive sprog/frameworks.

Efter AI vinteren har det desværre været småt med gode gennemførte implementeringer af sproget og der er altså ret langt i ’coolness’ og produktivitet fra f.eks. CLISP + CLX + Emacs og til et fuldt integeret grafisk programmeringsmiljø, som det fandtes på Xerox, Symbolics etc. Man kan kun håbe for sproget, at der vil være interesse i at lave en god integreret ’toolchain’. Man kan så mene, at Clojure er fremtiden for LISP, men det er en helt anden diskussion.

RIP John McCarthy

  • 3
  • 0
Lars Tørnes Hansen

LISP gruppen af sprog er meget anderledes, men også meget brugbare.

Jeg lavede engang en eksperiment i produktivitet - ikke helt fair måske.

Samme opgave blev løst i C hhv i Common LISP. Med Common LISP var opgaven løst på kun 1/2 time og ca 6x længere tid for C udgaven. :)

RIP John McCarthy

  • 2
  • 1
Lars Bengtsson

Arh, Poul Henning. Kan du virkelig ikke indrømme at du tager fejl? Bare en enkelt gang, i offentlighed. Hvorfor i al verden kræver du at Torben skal nævne andre højniveausprog, når artiklen handler om John McCarthy? Jeg synes det er upassende, fordi det ikke var forkert hvad Torben skrev.

Men tilbage til emnet. Mit eget bekendtskab til LISP begrænser sig til konfigurationsfilen til Emacs og nogle ret sjove videoer fra Computer Science undervisning på MIT, hvor LISP blev brugt. http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

RIP John McCarthy

  • 5
  • 0
Søren Pilgård

"Samme opgave blev løst i C hhv i Common LISP. Med Common LISP var opgaven løst på kun 1/2 time og ca 6x længere tid for C udgaven. :)"

Det siger desværre ikke særligt meget som en kvantitativ måling af sprogene. Når man løser et problem en gang til (godt nok i et andet sprog) vil ens hjerne kunne benytte de tekniker den tidligere kom frem til og det vil som oftest gå klart hurtigere.

Som Datalog studerende har jeg ihvertfald lært at det først og fremmest handler om at nedbryde og løse problemer, derefter (og som oftest delvist samtidigt) kan man formulere sin løsning i et programmeringssprog. Forskelle i sprog handler derfor mere om hvor let det er at formullere en løsning end de problemnedbrydnings proccesser som jo kan genbruge på tværs af sprog og paradigmer.

At sige at et sprog er bedre end et andet er derfor ofte meningsløst da det mere handler om hvor nemt det er for programmøren at udtrykke sin løsning i sproget. Forskellige sprog understøtter forskellige former for tankeprocceser og problemområder. Det er derfor at det er noget hø at ville lave webprogrammering i c, maskinprogrammering i javascript osv. Og det er derfor folk har forskellige prefferencer.

Personligt er jeg selv stor fan af Lisp famillien. Jeg har dagligt lispfiler åbne, i form af min .emacs fil der glædeligt hilser på mig hver gang jeg starter Emacs.

  • 1
  • 0
Lars Tørnes Hansen

"Samme opgave blev løst i C hhv i Common LISP. Med Common LISP var opgaven løst på kun 1/2 time og ca 6x længere tid for C udgaven. :)"

Det siger desværre ikke særligt meget som en kvantitativ måling af sprogene.

Det er helt rigtigt - det siger kun noget om det specifikke problem jeg løste i 2 sprog.

Du har muligvis ret i at da man kender problemet kan løse det hurtigere 2. gang, men nu var det så kun implementeringstiden jeg målte på, og ikke design delen som jeg lavede først lavede på papir på et højt abstraktionsniveau (specielt hvis man sammenligner med C). Jeg kan derfor hævde at jeg allerede fra design delen havde en så god forståelse af problemet at jeg nemt kunne løse opgaven i de 2. sprog.

Så med:

Som Datalog studerende har jeg ihvertfald lært at det først og fremmest handler om at nedbryde og løse problemer

altså (software) dekomposition - ja vi er enige.

Vi er også enig om at forskellige sprog giver forskellige abstraktionsniveauer, og at det af den grund er sandt at et sprog ikke er lige så godt som et andet til en given opgave. http://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#Blub ,Paul Grahams "Beating the averanges" artikel finder man på: http://www.paulgraham.com/avg.html Jeg skriver af den grund også "at det ikke er helt fair" i mit forrige indlæg.

I øvrigt så er jeg ikke datalog, eller datalogi studerende, men er uddannet IT ingeniør, og før det Datamatiker. Min tilgang til tingene er så måske en del mere praktisk orienteret. Kan jeg frit vælge værktøj, så bruger jeg gerne det sprog som for mig løser opgaven nemmest.

Det inkluderer udover objekt-orienterede programmeringssprog, og imperative programmeringssprog, også de funktionelle og deklarative programmeringssprog.

En sidste mulighed jeg har brugt med stor success er at lave imellem 1 til flere DSLer, som jeg så bruger til at løse et problem på et højt abstraktionsniveau. Det kaldes "language-oriented programming": Kig på http://www.onboard.jetbrains.com/articles/04/10/lop/2.html og Wikipedia artiklen[*] om emnet, hvis du synes at det lyder interessant.

[*] Kig i External Link sektionen, de 3 første links: http://en.wikipedia.org/wiki/Language-oriented_programming#External_links

  • 1
  • 0
Palle Simonsen

@Tørnes Helt enig!

Som en forskel på måden at programmerer på, som måske forklarer lidt af den faktor 4-6, der typisk måles. Prøv at sammenligne det simple swing eksempel i wikiepedia (http://en.wikipedia.org/wiki/Swing_(Java)) med noget tilsvarende i et typisk Common Lisp GUI:

;; Alt dette kan gøres som en one-liner med eller uden assignment af w1:

;; Mellemrummene skyldes, at V2 ikke kan formaterer LISP

(setf w1 (make-instance 'window :label "Hello World"))

(setf (content w1) (list (make-instance 'button :label "Press me")))

(show w1)

  • 1
  • 0
Søren Pilgård

"Kan jeg frit vælge værktøj, så bruger jeg gerne det sprog som for mig løser opgaven nemmest."

Det er lige præcis det jeg argumenterer for.

Det er en dårlig koder der bare går i gang med at kode uden at tænke på om der kunne være bedre værktøjer. Men som man siger, hvis ens eneste værktøj er en hammer, så ligner alle problemer et søm.

  • 4
  • 0
Palle Simonsen

@Søren Problemet er bare, at man sjældent kan vælge frit. Der kan være branche'standarder', projektstandarder, firmastandarder etc. der gør, at man bare må bruge en hammer til at slå skruer i med. Men hvis man har en god grundlæggende forståelse for programmering (opnået gennem studier og/eller praktisk erfaring) skal det være et meget ringe værktøj, før man ikke klare sig igennem alligevel - hvis man er rigtig god, er man start set ligeglad med værktøjet.

  • 4
  • 0
Lars Tørnes Hansen

@Søren Problemet er bare, at man sjældent kan vælge frit. Der kan være branche'standarder', projektstandarder, firmastandarder etc. der gør, at man bare må bruge en hammer til at slå skruer i med. Men hvis man har en god grundlæggende forståelse for programmering (opnået gennem studier og/eller praktisk erfaring) skal det være et meget ringe værktøj, før man ikke klare sig igennem alligevel - hvis man er rigtig god, er man start set ligeglad med værktøjet.

Jeg er nu ikke Søren, men jeg tager nu alligevel bolden op:

Jeg er enig i at der er firmastandarder, og jeg mener også at det er en fejl at man i den grad låser sig fast til kun en hammer for nu at bruge Sørens udtryk.

Iøvrigt kommer jeg sådan til at tænke på den her: (Det bliver lige i 1 quote per afsnit fordi v2s formattering går fløjten.

In the software business there is an ongoing struggle between the pointy-headed academics, and another equally formidable force, the pointy-haired bosses. Everyone knows who the pointy-haired boss is, right? I think most people in the technology world not only recognize this cartoon character, but know the actual person in their company that he is modelled upon.

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

Suppose, for example, you need to write a piece of software. The pointy-haired boss has no idea how this software has to work, and can't tell one programming language from another, and yet he knows what language you should write it in. Exactly. He thinks you should write it in Java.

Why does he think this? Let's take a look inside the brain of the pointy-haired boss. What he's thinking is something like this. Java is a standard. I know it must be, because I read about it in the press all the time. Since it is a standard, I won't get in trouble for using it. And that also means there will always be lots of Java programmers, so if the programmers working for me now quit, as programmers working for me mysteriously always do, I can easily replace them.

...

fra "Revenge of the Nerds" af Paul Graham. Den kan læses i sin fulde længe på http://www.paulgraham.com/icad.html

  • 1
  • 0
Torben Mogensen Blogger

fra "Revenge of the Nerds" af Paul Graham. Den kan læses i sin fulde længe på http://www.paulgraham.com/icad.

Jeg synes at en senere del af teksten er mere relevant for det egentlige enme:

If you look at these languages in order, Java, Perl, Python, you notice an interesting pattern. At least, you notice this pattern if you are a Lisp hacker. Each one is progressively more like Lisp. Python copies even features that many Lisp hackers consider to be mistakes. You could translate simple Lisp programs into Python line for line. It's 2002, and programming languages have almost caught up with 1958.

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