Gå til innhold

Anbefalte innlegg

En annen ting med Common Lisp som man ikke ser nevt så ofte er det interaktive miljøet. Det er en av tingene som gjør programmeringen så effektiv.

 

Selv om jeg kan enkelte andre språk bedre enn Common Lisp så blir programmet fortere ferdig (og debugget!) når jeg programmerer i Common Lisp. Jeg tror det i tillegg til det høye abstraksjonsnivået har mye med det interaktive miljøet å gjøre.

 

Man designer ofte top down men koder en del bottom up samtidig som man tester funksjonene på data man har i miljøet. Dette er i motsetning til compile, link & crash i f.eks. C hvorpå man kaster seg over gdb og/eller legger inn masse printf statement. Jeg tror mange Matlab brukere vil kjenne seg litt igjen i måten å skrive Common Lisp kode på.

 

Eller hvordan skrivere dere andre CL kode? Hva mener dere om det interaktive miljøet og produktivitet?

Lenke til kommentar
Videoannonse
Annonse

Common Lisp er _vel_ gammelt og hårete for min del. Har satt meg ned med CL flere ganger, men det er alltid et eller annet som lukter litt rart. Hvis du skal lære deg en Lisp (som jeg absolutt anbefaler) foreslår jeg at du ser på Clojure i stedet.

 

Clojure er en moderne lisp som kjører på Java-plattformen. Språket har mer fokus på funksjonell programmering med sine persistente(immutable) datastrukturer, og har gått helt bort fra oo-paradigmen. -- Du får det beste fra Scheme og CL, sammen med Java-økosystemet som er overlegent alt annet for de fleste oppgaver.

Endret av Frank2004
Lenke til kommentar

Fordelen med alderen er at språket er modent og har "satt seg". Jeg kan kjøre flere tiår gammel kode uten problemer, og om ti år vil koden jeg skriver nå ha samme semantikk som idag. Om dette vil gjelde clojure vil vise seg, men jeg håper det dog.

 

I motsetning har vi f.eks Python for ting endrer seg omtrent på dagsbasis, IMHO det største ankepunktet ved språket.

Lenke til kommentar

Hvis du bruker paredit.el, blir parenteser autopairet slik at du slipper å tenke på dette.

Takk for tipset. Jeg har ikke brukt paredit tidligere så jeg skal teste den og se hvordan jeg liker den.

Igjen takk for tipset. Det er litt uvant, spesielt når jeg skriver en defun osv. som går over flere linjer. Men jeg tror jeg kommer til å fortsette a bruke denne.

Før jeg brukte paredit.el, hadde jeg ofte problemer med manglende parenteser og brukte så mye tid på å rydde opp i koden at det tok lengre tid å skrive Lisp enn andre språk. Dette var en god tid etter at jeg hadde bestemt meg for at jeg faktisk likte Lisp.

 

Men nå er alt snudd på hodet. Jeg skriver og håndterer Lisp raskere enn noe annet språk fordi paredit.el behandler koden på et høyere nivå – som et tre, istedenfor som en haug med parenteser eller annen vilkårlig syntaks. Syntaksen blir abstrahert vekk. Ulempen er at jeg føler meg fryktelig treg i alle andre språk enn Lisp, og jo mer syntaks-tungt språket er (C++, gode gamle Perl), jo verre er det. :(

Endret av ....
Lenke til kommentar

Common Lisp er _vel_ gammelt og hårete for min del.

 

Kan du utdype litt? Riktig nok gammelt, men jeg har til gode å se noe særlig nytt i andre språk. Hva du mener med hårete er jeg litt usikker på.

 

Jeg har sett på clojure. Det kan ha noe for seg for de som skal integrere det i mot Java plattformen. Men at CL kompilerer til effektiv maskinkode ser jeg på en fordel.

 

En ulempe med Cl er det ikke er tråder innebygget i språket, men det finnes biblioteker som f.eks. Bordeaux threads som er blitt veldig vanlig å bruke. I clojure har man en standard trådmodell, noe som er bra.

Lenke til kommentar

Før jeg brukte paredit.el, hadde jeg ofte problemer med manglende parenteser og brukte så mye tid på å rydde opp i koden at det tok lengre tid å skrive Lisp enn andre språk.

 

Selv om jeg ikke har testet paredit før nå takket være tips fra deg så brukte jeg ikke mye tid på parenteser tidligere. Emacs matacher parenteser for deg og C-cC-] slenger på det man måtte trenge av parentester for å lukke f.eks. en defun.

Lenke til kommentar

Oioi, Common Lisp på diskuson.no/hw.no? Er vel ikke lenge før vi blir bannet for å være eksentriske eller "smug"'e .. :)

 

Ser Google har kjøpt ITA nå; kanskje muligheter for at hjulet går ennå fortere? F.eks. sliter jeg med et par bugs. E.g., https://bugs.launchpad.net/sbcl/+bug/492851 ( http://blog.nostdal.org/2009/12/eql-specialization-and-leaks.html ). Naivt forsøk; http://paste.lisp.org/display/112346 .. men ser ut til at noe i eller rundt sb-pcl::*effective-method-cache* lekker, også.

 

edit: PS: Utfordring; noen som greier å finne løsningen på dette problemet? O_o

 

Sikkert ikke et problem i sammenheng med "normal bruk", men irriterende i visse sammenhenger.

 

Common Lisp, SBCL og Emacs+Slime er forøvrig helt rått tross bugs her&der. For en som egentlig ikke kan fordra programmering er dette _nesten_ på kanten til å være morro i blant. :)

Endret av worseisworser
Lenke til kommentar

Ser at du har sjekket inn kode i SymbolicWeb-repoet. Synes å huske å ha lest at du sluttet? (kanskje jeg husker feil...)

 

Hei,

Ja, ble/er noe lei -- egentlig. :}

 

 

Ser jo ut som et spennende prosjekt (selv om jeg aldri har drevet med web-ting).

 

:)

 

 

Hva skjer med at du hele tiden lager nye brukere?

 

Jeg blir stort sett bannet på alle ikke-åpne forum, og/eller husker aldri passord og/eller aner ikke hvilke mailkontoer jeg har "koblet" til de forskjellige brukerne! ...hehe.

 

 

PS: Forøvrig ser det ut til at ECL og CLISP ikke har samme problem som SBCL påpekt over.

Lenke til kommentar

g/eller husker aldri passord og/eller aner ikke hvilke mailkontoer jeg har "koblet" til de forskjellige brukerne!

 

Jeg bruker forskjellige e-post adresser når jeg melder meg på en ny tjeneste for å se hvem som søler med e-post adressene når det kommer spam. Ulempen er at man ikke husker hva man registrerte seg som når man skal be om å få nytt passord etter å ha rensket opp .mozilla o.l.

 

OpenID skulle jo løse dette, men det hjelper lite når det ikke er så mange som støtter OpenID.

Lenke til kommentar

edit: PS: Utfordring; noen som greier å finne løsningen på dette problemet? O_o

 

Urg, SBCL internals har jeg ikke bedrevet så jeg vet desverre ikke. La oss håpe at du får en respons på SBCL mailing lista. Har du forresten testet det i plain CMUCL?

 

Har ikke testet dette med CMUCL, men hverken ECL (fra git) eller CLISP (2.44) har samme problem.

 

edit: err .. ser jeg allerede har nevnt dette i posten min over. Kan kanskje teste CMUCL, men vet ikke om det har noe for seg(?) da dette skal være lovlig CL kode -- tror jeg da.

Endret av worseisworser
Lenke til kommentar

 

Har ikke testet dette med CMUCL, men hverken ECL (fra git) eller CLISP (2.44) har samme problem.

 

 

Hvis jeg ikke husker feil så er SBCL en fork av CMUCL (selv om det er lenge siden). Jeg tenkte det kunne gi utviklerene en clue om denne feilen er med i CMUCL eller ikke. Er feilen i CMUCL så kan kanskje maintainerene der være til hjelp.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...