asicman Skrevet 8. juli 2010 Forfatter Del Skrevet 8. juli 2010 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
cyclo Skrevet 8. juli 2010 Del Skrevet 8. juli 2010 Asci: Jeg er ingen stor bruker av Lisp, og bruker det stort sett til to ting: elisp i emacs og cl i stumpwm via slime. Det er fantastisk å kunne interaktivt "hacke" windowmanageren man bruker på det viset. Lenke til kommentar
x871kx6167ss7 Skrevet 8. juli 2010 Del Skrevet 8. juli 2010 Føler jeg burde kommer meg over på Emacs når jeg driver med lisp. Bruker for det meste vi(m) og drscheme. Lenke til kommentar
Frank2004 Skrevet 9. juli 2010 Del Skrevet 9. juli 2010 (endret) 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 9. juli 2010 av Frank2004 Lenke til kommentar
Johan Skrevet 9. juli 2010 Del Skrevet 9. juli 2010 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
.... Skrevet 9. juli 2010 Del Skrevet 9. juli 2010 (endret) 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 3. januar 2012 av .... Lenke til kommentar
asicman Skrevet 9. juli 2010 Forfatter Del Skrevet 9. juli 2010 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
asicman Skrevet 9. juli 2010 Forfatter Del Skrevet 9. juli 2010 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
worseisworser Skrevet 10. juli 2010 Del Skrevet 10. juli 2010 (endret) 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 10. juli 2010 av worseisworser Lenke til kommentar
x871kx6167ss7 Skrevet 10. juli 2010 Del Skrevet 10. juli 2010 Ser at du har sjekket inn kode i SymbolicWeb-repoet. Synes å huske å ha lest at du sluttet? (kanskje jeg husker feil...) 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? Lenke til kommentar
worseisworser Skrevet 10. juli 2010 Del Skrevet 10. juli 2010 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
asicman Skrevet 11. juli 2010 Forfatter Del Skrevet 11. juli 2010 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? Lenke til kommentar
asicman Skrevet 11. juli 2010 Forfatter Del Skrevet 11. juli 2010 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
worseisworser Skrevet 11. juli 2010 Del Skrevet 11. juli 2010 (endret) 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 11. juli 2010 av worseisworser Lenke til kommentar
asicman Skrevet 12. juli 2010 Forfatter Del Skrevet 12. juli 2010 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
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå