Att Lisp är gammalt är inget att vara orolig för. Lisp var först med t.ex. garbage collection, interaktiv programmering (d.v.s. man behöver inte kompilera i ett separat steg, det finns en tolk man kan skriva i), dynamiska typer, o.s.v., jag vet inte exakt men, det var väldigt mycket före sin tid. Lisp-folk brukar säga att moderna språk först nu börjar komma ikapp.

Dessutom så är funktionell programmering mycket bättre än objektorienterad programmering. Fast när du ska tänka på avsaknaden av objekt så kan du inte tänka på Java eller C++. I Lisp finns higher-order/first-class functions, closures och macros.

First-class functions betyder att man kan skapa funktioner och stoppa dem i variabler och ge dem som argument till andra funktioner o.s.v., d.v.s. de är bara en annan typ av värde som man kan bolla runt. Det finns i Python, Ruby, JavaScript o.s.v. också. Higher-order functions är funktioner som tar andra funktioner som argument.

Exempel (I Python, för att det kan nog fler läsa):
lst = [1, 2, 3, 4]
map(lambda x: x + 2, lst)
>> (svar): [3, 4, 5, 6]
filter(lambda x: x % 2 == 0, lst)
>> [2, 4]
reduce(lambda x, y: x + y, lst)
>> 10

lambda x: f(x) betyder "en funktion av ett argument (x) som returnerar f(x). Man kan ha fler argument också.

Det kanske inte ser fantastiskt ut, men man kan inte göra detta i Java eller C++.

map tar en funktion och en (eller flera) listor och applicerar funktionen på varje element av listan, och returnerar en lista av resultaten. När jag skriver Python så använder jag nästan aldrig loopar, utan så mycket map som möjligt.

filter filtrerar ut de element för vilka funktioner ger "sant".

reduce applicerar en funktion parvis till argumenten, d.v.s i fallet ovan är det samma sak som (om funktionen hette add) add(add(add(1, 2), 3), 4). Det är förstås inte bara såhär enkla fall då det är nyttigt med higer-order functions. Man skulle t.ex. kunna göra en funktion som ritar en graf av en annan funktion, och som alltså tar funktionen som ska ritas som argument.

Ett annat fall där det är bra är när man vill sortera nått men vill ange sin egen jämförelsefunktion. Man kan göra det i Java genom att ange en klass som implementerar Comparator eller nått sånt. Men det är enklare med first-class functions. Föregående två exempel borde visa att det finns många fall då det är narurligt att använda funktioner som argument.

Man kan också returnera funktioner från andra funktioner, som t.ex. (fortfarande Python):
def adder(x):
  return lambda y: x + y

a = adder(3)
a(2)
>> 5

Det kanske inte ser så mycket ut för världen i detta exempel men det är väldigt kraftfullt. Detta är också ett exempel på ett "closure": man "stänger över" x med funktionen man returnerar i "adder", och x liksom lever vidare i funktionen som returneras.

Lisp är också det enda språk som har macros: Kod som tar kod som indata och kod som utdata; kod som skriver kod. Det låter konstigt, och det är det också om man inte har sett det förut. Det är lite svårt att förklara för någon som inte kan Lisp redan, men låt oss ta ett litet exempel: Java fick för inte så länge sen en "foreach loop" d.v.s. "for(String s : strings) ...". Innan det fanns en foreach-loop kunde inte Javaprogrammerare göra foreach-loopar. Om det hade varit Lisp så hade du kunna skrivit foreach själv. Man kan göra nya specialkonstruktioner (som foreach-loopar, som inte är funktioner), inte bara skriva nya funktioner. Lisp är ett programmerbart programmeringsspråk. Du kan göra ett helt nytt programmeringsspråk som passar för att skriva just ditt program med Lisp. Det är därför Lisp har överlevt sen 60-talet. Varje ny bra idé som kommer kan Lisp bara suga upp. T.ex. så finns objektorientering i Lisp, och det är skrivet i Lisp själv, utan att språket behövde ändras när objektorientering kom. Fast, i Clojure, som är ett nytt Lisp (bara ca. 2 år gammalt) så finns inte objektorientering (fast du skulle kunna stoppa in det!) för att det är helt överflödigt när man har riktig funktionell programmering.

Funktionell programmering använder sig av higher-order functions mycket. Men det är egentligen inte det som är hela poängen. Poängen är också att funktioner ska vara funktionella i matematisk mening, d.v.s. bara bero av sin indata, vara deterministiska, och inte ha sidoeffekter. Om ni ser på mina exempel med map, filter, och reduce så returneras nya listor, de listorna man började med ändras inte på något sätt. Det är mycket, mycket enklare att skriva buggfri kod om man inte har massa sidoeffekter överallt. Om alla funktioner har sidoeffekter så är det svårt att hålla reda på vad som händer. Man brukar även försöka eliminera sidoeffekter innuti funktioner; alltså undvika tilldelningar helt. Det låter konstigt om man kommer från Java eller C++, men det går lätt i Lisp, och leder till många färre buggar. Som ett exempel: När man använder map, som ovan, behövs inga for(int i = 0...), d.v.s. vi har undvikit en tilldelning.

Man behöver såklart ha lite sidoeffekter, eftersom man behöver kunna skriva saker på skärmen o.s.v. men det är bra att undvika det i så stor utsträckning som möjligt. Ja, det går att skriva spel så. Python har nästan allt som Lisp har, förutom macros och Python har en lite sämre syntax. Men det är lättare att skriva spel till Python eftersom det finns bättre bibliotek för att göra det i Python än i Lisp.

Så varför är inte alla språk så bra, om Lisp har funnits sen 60-talet? Förvånansvärt få kan Lisp. Det ser konstigt ut och var, när det kom, ganska långsamt (inte längre!). De som inte lärde sig Lisp har under 50 år nu nästan kommit ikapp. Fast man kan inte komma hela vägen ikapp utan att språket blir Lisp. Låt tänka oss att en C++-programmerare tror att C++ är bäst (det finns många stackare som gör det). Det borde ändå vara ganska svårt att övertyga sig om det. Men när man har lärt sig Lisp så förstår man liksom, bara av att ha lärt sig Lisp, att det går inte att få ett mycket bättre språk (Ok, nu pratar jag om språket som språk, inte alla omständigheter. C är fortfarnde nog bäst på systemprogrammering t.ex. (notera, C, inte C++) eftersom man behöver ha ganska stor koll på resurser o.s.v.).

Senast redigerat av cancerman (2010-12-27 06:15)

För att skaffa Scheme: http://racket-lang.org/ (de har tydligen börjat kalla sig för "Racket" men det är Scheme)
För att skaffa Python: http://www.python.org/

Böcker:

Scheme: Om du är bra på matte och åtminståne typ 17-18 år, så (många av exemplen och övningarna är ganska matematiska, och man bör ha läst typ Ma D i alla fall för att hänga med kan jag tänka mig): http://mitpress.mit.edu/sicp/full-text/book/book.html
Annars: The Little Schemer http://www.amazon.com/Little-Schemer-Da … 0262560992

Python: http://www.amazon.com/Beginning-Python- … 1590599829 är rätt ok.
http://greenteapress.com/thinkpython/thinkCSpy/ (gratis)

Om du fastnar för Lisp så vill du nog läsa dessa böcker efter ett tag:
http://www.paulgraham.com/onlisp.html
http://letoverlambda.com/

Senast redigerat av cancerman (2010-12-04 03:44)

Satan skrev:

Någon som har en en guide eller ett schema över uppgifter som man kan göra dag för dag, några timmar i veckan över en längre tid, typ?

Jag har ganska svårt med disciplinen och klarar inte av att bara sätta mig ner och traggla python i flera timmar på en gång, iaf inte innan jag har fått upp intresset ordentligt. :yes:

Inte på rak arm. Men, är det bara Python du har det problemet med? Om du tycker programmering är tråkigt så kanske det inte är nått för dig, eller?

sneagel skrev:

Ska börja läsa en kurs i programmering i Scheme efter jul - hur svårt är det att sätta sig in i? Har läst programmering A (C++) på gymnasiet och tyckte väl varken det var lätt eller svårt.

Det finns väl de som tycker att det är lättare och de som tycker det är svårare. Det är lite annorlunda.

Jag kan ta ett enkelt exempel bara för att folk ska få se hur det ser ut. Följande kod räknar ut det n:te Fibonaccitalet, alltså ur talföljden 0, 1, 1, 2, 3, 5, 8, 13, 21...

Först kan jag skriva det i Python, för det förstår nog alla; det är ganska likt hur det skulle se ut i C++ eller Java.

def fib(n):
  if n < 2:
    return n
  else:
    return fib(n - 1) + fib(n - 2)

Och i Scheme:

(define (fib n)
  (if (< n 2)
      n
      (+ (fib (- n 1)) (fib (- n 2)))))

Några saker att notera angående Scheme

Alla operatorer (funktioner, macros, "special operators") står först, i s.k. prefix-notation. (+ 1 2 3) betyder 1 + 2 + 3. En nackdel med detta är att det krävs parenteser runt varje operator, d.v.s det går i andra språk att skriva 1 + 2 men i Scheme (och andra Lisps) så behöver man skriva (+ 1 2). Men det finns många fördelar:

* Man kan addera många termer utan att behöva fler plustecken, t.ex. (+ 1 2 3 4 5 6 7). För det andra så behöver man aldrig komma ihåg i vilket ordning operatorer appliceras, d.v.s. att 2*3 + 1 = 7 och inte 8. Det föregående skrivs såhär i Scheme: (+ (* 2 3) 1).

* Det är ingen skillnad på aritmetiska operatorer och funktioner. Om du hade en funktion som hetta "add" som adderade tal så hade du använt den på exakt samma sätt som +, d.v.s. (add 1 2 3 4 5 6 7). + är i Scheme en funktion, precis som add, om den hade funnits.

* Du kan använda alla möjliga tecken i namn, så som ! ? * - +. Exempel på namn som förekommer eller skulle kunna förekomma är zero? sort-by +*my-function*+. '-' i sort-by skulle aldrig kunna tolkas som ett minustecken för det skulle se ut såhär: (- 1 2 ...)

* Detta leder till att det som i Python skulle se ut reduce(lambda x, y: x + y, [1 2 3 4]) skulle i Scheme se ut (reduce + '(1 2 3 4)). Eftersom de aritmetiska operatorerna är funktioner så kan de ges direkt till funktioner som förväntar sig funktioner.

En annan sak att notera är att det finns inget return i Scheme. Det sista uttrycket i ett "form" returneras alltid som svaret på "formet". Ett form är i princip en parentes. T.ex. (if test svar-om-sant svar-om-falskt) "returnerar" svar-om-sant om test är sant, annars svar-om-falskt. "Retunerar" är inte riktigt rätt ord dock, istället pratar man om if-satsens värde. På samma sätt som (+ 1 2) har värdet 3 har (if true 1 2) värdet 1. Här ser vi åter prov på Schemes elegans. Det finns ingen anledning att hantera if och andra funktioner så olika som de görs i andra språk.

Ett annat kul exempel:

(define (abs n)
  ((if (< n 0) - +) n))

abs beräknar absolutbeloppet. if-"formet" returnerar funktionen - eller + beroende på om n är negativt eller inte. Sedan anropas (notera dubbla (( innan if) den valda funktionen på n, och det är abs svar.

Satan skrev:

Har inte testat på några andra programmeringsspråk, har varit sugen rätt länge på att börja med någonting men har inte tagit mig tiden att sätta mig ner och komma igång på riktigt. Python verkar bra att börja med och jag vill iaf ge programmeringen en chans innan jag lägger ner det, f.ö. är jag rätt bra på matematik.

Det är väl bara börja med en bok, sen kan du göra problem här: www.projecteuler.net De är inte för att just lära sig programmering men de kan vara kul ändå.

Senast redigerat av cancerman (2010-12-08 07:45)

cancerman vilket språk använder ni på Datateknik(KTH) ?

Senast redigerat av suraj (2010-12-26 07:16)

Mmm, Java. Fast på många andra program använder de Python. Men vad spelar det för roll egentligen?

Det är skillnad på C och C++ (om man använder de features i C++ som gör C++ till C++). Dessutom nämnde jag att C är antagligen det man vill använda om man verligen behöver pressa sin applikation till det yttersta. Men det är mycket sällan som "prestanda" är så viktigt. Python är t.ex. ganska populärt men inte alls bland de snabbaste språken.

Dessutom är inte C och C++ mycket snabbare än alla andra språk. Det finns många språk som är ungefär lika snabba, ibland snabbare. Java är ungefär lika snabbt som C++, bara för att ta ett exempel. (Python är lite långsamt, Lisp är rätt snabbt, men detta kan komma att förändras.)

Sen är det mest till nybörjare jag vänder mig. För dem så spelar det absolut igen roll hur "snabbt" språket är (ofta inte för andra heller).

Men även om C++ vore "snabbast" så är det fortfarande uselt som språk; så uselt att jag hellre skulle jobba på McDonalds än att jobba med C++. Att programmera i C++ är, kan jag tänka mig, som att vara en författare men bara få använda hälften av bokstäverna i alfabetet, och bara skriva för hand, med fel hand.

Mercurius skrev:

Men det finns alltså fler orsaker än dåliga vanor till att vissa fortsätter programmera i C++. Och nej, det förutspåddes att dö ut redan för 15 år sedan, och det är till högsta grad fortfarande levande.

Ja, men ingen av orsakerna är att C++ är ett bra språk.

Senast redigerat av cancerman (2011-01-14 18:39)

cancerman skrev:

Det är skillnad på C och C++ (om man använder de features i C++ som gör C++ till C++). Dessutom nämnde jag att C är antagligen det man vill använda om man verligen behöver pressa sin applikation till det yttersta. Men det är mycket sällan som "prestanda" är så viktigt. Python är t.ex. ganska populärt men inte alls bland de snabbaste språken.

Dessutom är inte C och C++ mycket snabbare än alla andra språk. Det finns många språk som är ungefär lika snabba, ibland snabbare. Java är ungefär lika snabbt som C++, bara för att ta ett exempel. (Python är lite långsamt, Lisp är rätt snabbt, men detta kan komma att förändras.)

Det är det mest till nybörjare jag vänder mig. För dem så spelar det absolut igen roll hur "snabbt" språket är (ofta inte för andra heller).

Men även om C++ vore "snabbast" så är det fortfarande uselt som språk; så uselt att jag hellre skulle jobba på McDonalds än att jobba med C++. Att programmera i C++ är, kan jag tänka mig, som att vara en författare men bara få använda hälften av bokstäverna i alfabetet, och bara skriva för hand, med fel hand.

Mercurius skrev:

Men det finns alltså fler orsaker än dåliga vanor till att vissa fortsätter programmera i C++. Och nej, det förutspåddes att dö ut redan för 15 år sedan, och det är till högsta grad fortfarande levande.

Ja, men ingen av orsakerna är att C++ är ett bra språk, på nått sätt.

"Att programmera i C++ är, kan jag tänka mig, som att vara en författare men bara få använda hälften av bokstäverna i alfabetet, och bara skriva för hand, med fel hand."
Jag hoppas verkligen inte att du nu menade att du aldrig har programmerat i C++ och ändå klankar ner på det?

Förövrigt, finns inget språk som är perfekt.
C++ - har säkert massa skit som att variabelnamn är casesensetive  och annat. Största anledningen att jag inte gillar C++ ibland är pga hur olika det är att sitta med en g++ jämfört med Visual C++-skit.
Folket har rätt, verktygen suger.
Men, anledningen att jag föredrar C++ framför t.ex Java(eller annat skit som har 50miljoner förinbyggda funktioner) är att man faktiskt får "återuppfinna hjulet", dock med sin egen tolkning.
Hur kul är det att få serverat framför sig exakt vad man ska göra i livet? Följa en plan väg, aldrig få utforska sidospåren som kan gå antingen åt helvete efter x antal månaders arbete eller tvärtom lyckan som uppstår när man väl löst ett problem man suttit med länge. Yin och Yang. Utan ett helvete finns inte heller en himmel, bara en gråzon.

Sen är det såklart att alla språk har sina egna områden inom programmeringen. Jag tycker att alla språk har sin egna charm.

Mercurius skrev:

Sedan finns det, hävdar jag, en pedagogisk poäng med lågnivå-språk, som du totalt missar med de andra språken. Visserligen minskar den successivt i betydelse, men oviktiga kommer de inte att bli. Språk som t.ex. Java lär säkert dö ut snabbare än C/C++.

Ja det är kanske sant. Men då kanske man till och med vill lära sig Assembly, och sen C och inte C++. Det finns ingen poäng med C++. Vill man ha "prestanda" så använd C. Vill man ha högnivåspråk så använd nått annat.

Mercurius skrev:

Jag är själv inte programmerare (men har en del bekanta som jobbar med det, och mina åsikter kommer från dem), men stöter regelbundet på de som spyr galla över både kurser och programspråk. Jag kan ha förståelse för det, har ju själv varit där. Det är väl bra att ha åsikter om vad som ska undervisas, och betoning på C/C++ kanske är för stor - inte så många kommer arbeta med det. Men den har en given plats bland programmerare med vissa special-inriktningar.

Nu för tiden så lär sig fler Java än C och C++, skulle jag tro. Jag vill mest varna för C++ eftersom så många nybörjare hör att t.ex. spel är för det mesta gjorda i C++. Men de inser inte hur mycket bättre det skulle gå om det började med nått annat, t.ex. Python. Jag vill också påpeka för de som lär sig C++ eller Java att alla programmeringspråk inte är likadana. Det finns stora skillnader; om man inte gillar programmering i Java eller C++ kanske man fortfarande gillar programmering.

Senast redigerat av cancerman (2010-12-27 06:19)

F0X skrev:

Hur mår t.ex brainfuck eller whitespace eller liknande språk för dej?

Jag tänkte inte på dem. Jag ser inte dem som seriösa språk.

F0X skrev:

Det är din åsikt, att C++ för dej suger måste inte betyda att det är dåligt? Kan du specificera själv om varför? Utan att använda 200+ länkar från quotes som folk har sagt om C++ där kod inte är inblandat?

Det handlar mest om s.k. "accidental complexity", alltså komplexitet som uppstår ifrån de verktyg (d.v.s. språket) man använder och inte härstammar från problemet i sig. Om du har ett problem, t.ex. bygg en databas eller vad som helst, så är minneshantering en typ av komplexitet som uppstår från språket C++. Den som vill ha databasen bryr sig antagligen inte om du har använt automatisk eller manuell minneshantering. Mer exempel på accidental komplexity i C++ är:
* Lås när man använder trådar
* Headerfiler, #ifndef o.s.v.
* Massa odefinierat beteende
* Det finns inga "first-class functions"
* Krånglig syntax
* Lätt att göra off-by-one-fel
* Datatypen int är ändligt stor, det finns ingen typ för rationella tal
* Pekare
* Listor, dictionaries (hash maps), mängder o.s.v. inte inbyggda, inga "literaler" till dem.
* Man kan inte blanda typer lätt i datastrukturer
* Komplicerat typsystem: pekare till funktion som returnerar en pekare till...

Finns säker saker jag glömt, eller inte ens vet om, för att jag har försökt undvika C++ som pesten sen jag lärde mig det.

F0X skrev:

Om jag känner för att ge mej in på något relativt omöjligt så gör jag det i C++, man blir lyckligare om det väl funkar då. ^^

Så du erkänner att det är jobbigt att programmera i C++? Asså, att man blir gladare när det väl går är det sämsta argumentet jag kan komma på. Det finns gott om svårigheter i programmering, man behöver verkligen inte göra det extra svårt för sig.

Senast redigerat av cancerman (2010-12-27 05:46)

F0X skrev:

Jag håller med dej inom allting där. ^^

Dock så tycker jag fortf. att C++ har sin charm på något sätt.. Det är någon form av hat-älska-relation. ^^

Aja, använd C++ då. Men lura inte ner fler personer i ditt träsk.