ProgrammeringsBaren! Småprat, om det du elsker!

[snippsat]

Skal man ha det virkelig gøy programmerer man i Common Lisp

Ja Commom lisp er er et bra språk,men mangel på bibliotek synse jeg kan være et problem.

 

Python har bibliotek for hva enn man måtte ønske og gjør og ønske

og gjøre.

web(Django,Pylons,TurboGears,web2py...) Gui(Wxpythnon,PyQt,PyGTK...) Scientific Computing(NumPy,SciPy,Matplotlib...) og en økning i på Python Package Index er veldig stor.

 

Nå er selfølgelig ikke bibliotek støtten alt,men det kan gjøre livet mye letter for en programmer på hoppybasis.

 

Commen lips er nok mye mindere kjent,derfor vanskligere med support/dokumentasjon og forum.

Ser man på stackoverflow er commen lips delen rimlig død.

 

Jeg er aktiv i forum om python nesten hver dag daniweb og python-forum.org,synes det er grei måte og hele tiden holde seg oppdatert og dele idèer om løsninger av problemer og språkets utvikling.

 

Pycon øker også mye som viser at python har en stor tilhengerskare og et sterkt språk nå og for fremtiden.

Endret 4. juli 2010 av SNIPPSAT

[asicman]

Ja Commom lisp er er et bra språk,men mangel på bibliotek synse jeg kan være et problem.

Det er mange bibliotek for Common Lisp, men ikke så mange som i Python. Men kvaliteten på CL bibliotekene er som regel meget bra. Når det gjelder Python er det stor kvantitet med veldig stor variasjon i kvalitet.

 

 

web(Django,Pylons,TurboGears,web2py...) Gui(Wxpythnon,PyQt,PyGTK...)

Scientific Computing(NumPy,SciPy,Matplotlib...) og en økning i på

Python Package Index er veldig stor.

 

Når det gjelder web så finnes det noen etter min mening mange ekstremt bra Common Lisp bibliotek. De har ikke så mange brukere og så mye dokumentasjon og fancy eksempler som f.eks. Django, Ruby on Rails, osv.

 

Jeg ser mange her på forumet som drømmer om hvordan et slik system kunne være, og det er faktisk ganske likt Widgets i Weblocks. Et annet Webtoolkit er Webactions.

 

Felles for disse er at de kjører på en Common Lisp webserver (Hunchentooth og Allegroserve) som gjør at koden blir kompilert og man får dynamikken til Common Lisp. Man kan f.eks. endre en klassedefinisjon, beskrive hvordan ekstererende instanser av objektene skal oppgraderes og deretter koble seg til processen og kompilere dette inn i programmet som kjører uten å måtte stoppe programmet.

 

Det finnes også masse bibliotek for forskjellige GUI toolkits. Mange av disse er bare FFI (foreign function interface) wrappere til de aktuelle bibliotekene. FFI wrappers kan genereres direkte fra C header filer.

 

Det som ikke er bra er støtten for Windows GUI bibliotek (jeg bruker stort sett Linux). Det er også flere frie Common Lisp implementasjoner som kjører på Linux siden noen av dem har sitt opphav fra tiden før Windows. Men det finnes gratis implementasjoner for Windows som f.eks. Franz og LispWorks

 

Common Lisp kompilatorer har utviklet seg over lang tid og mange av dem lager meget effektiv kode som gjør at de egner seg bra til Scientific Computing som gjør at man ikke trenger bibliotek som NumPy. Komplekse og rasjonale tall er en del av språket.

 

I Python så blir 1/3 + 2/3 0:

 

>>> 1/3 + 2/3
0

 

I Common Lisp så blir det faktisk 1:

CL-USER> (+ 1/3 2/3)
1

 

En av de klassiske algebra systemene er Macsyma som er skrevet i Lisp. Dette lever lever videre i en re-inkarnasjon som open source Maxima.

 

Cliki og commonlisp.net er bra steder å lete etter Common Lisp bibliotek.

 

Commen lips er nok mye mindere kjent,derfor vanskligere med support/dokumentasjon og forum.

Ser man på stackoverflow er commen lips delen rimlig død.

 

Det er snart 52 år siden Lisp så dagens lys. Diskusjoner foregår ofte i andre litt mer etablerte forum som f.eks. comp.lang.lisp. For 20-30 år siden var det mer aktivitet da det var mange Lisp dialekter som ble samlet inn i en ANSI standard nå ANSI INCITS 226-1994 (tidligere X3.226-1994). Common Lisp Hyperspec brukes av mange som online referanse.

 

Python fortsetter og endre seg og det er mye diskusjoner om uklarheter og om utviklingen. For Common Lisp så finnes det en standard spesifikasjon og forskjellige implementasjoner fra forskjellige leverandører. Det gjør at det blir mindre uklarheter rundt dette.

 

 

Python er et bevegelig mål. Kode jeg skrev for mindre enn to år siden kommer med warning om at funksjonalitet vil forsvinne. Jeg har sett Python programmer som oppdaterer Python kildekode for at de skal være kompatible med nyere versjoner av Python og hva annet Guido måtte finne på. Common Lisp har en ANSI standard spesifikasjon og flere implementasjoner som følger denne i større og mindre grad.

[snippsat]

Takk for fin info Common Lisp asciman

 

>>> 1/3 + 2/3
0

Det er noe som er fikset opp i python 3.x

Eller det har alltid virket,men må bruke float i python 2.x

#Python 3.x
>>> 1/3 + 2/3
1.0

#Python 2.x
>>> 1/3 + 2/3
0
#Bruke float
>>> 1/3.0 + 2/3.0
1.0
>>> 
#Ellers kan alle ny python funskjoner importeres fra fremtiden.
>>> from __future__ import division
>>> 1/3 + 2/3
1.0
>>> 

 

Kode jeg skrev for mindre enn to år siden kommer med warning om at funksjonalitet vil forsvinne.

Det kommer "deprecated" advarsel ja når moduler er på vei ut.

Det skjer en utvikling og det blir som regel byttet ut til noe bedere.

Blir som regel ikke fjernet før i python 3.x,for da rydder man opp og bryter som kjent med bakoverkompatibelt med python 2.x.

 

Jeg er enig i grepene som er tatt med python 3.x.

Kommer nok til og bruke python 2.x et par år til p.g.a 3 parts bibliotek jeg bruker må bli skrevet om,men ser ikke på dette som noe problem.

 

Peter Norvig Python for Lisp Programmerser også greit lesestoff.

Endret 5. juli 2010 av SNIPPSAT

[zotbar1234]

Common Lisp kompilatorer har utviklet seg over lang tid og mange av dem lager meget effektiv kode som gjør at de egner seg bra til Scientific Computing som gjør at man ikke trenger bibliotek som NumPy.

 

Spiller det noen rolle om man bruker et bibliotek fra en 3. part eller fra språkdistribusjonen for å få utført en oppgave? Enhver applikasjon med kompleksitet utover "hello world" vil kreve 3-partsbiblioteker uansett.

 

Komplekse og rasjonale tall er en del av språket.

 

I Python så blir 1/3 + 2/3 0:

 

For det første -- nei, det blir ikke det (noe som er problematisk i seg selv). For det andre, hvis man først trenger å jobbe med rasjonale tall, er heller ikke det problematisk. Kanskje velge et bedre eksempel?

 

Python er et bevegelig mål.

 

Dette, derimot, er et veldig bra eksempel. Og dessverre 100% korrekt.

[asicman]

Det er noe som er fikset opp i python 3.x

Eller det har alltid virket,men må bruke float i python 2.x

 

Nok et eksempel på versjonsproblematikk. Tradisjonelt så er man litt skeptisk til å bruke float for eksakte rasjonelle tall, hvis det blir brukt float under kalkuleringen så vil man få unøyaktigheter, som er grunnen til at man bruker rasjonale tall i utgangspunktet.

 

I andre tilfeller av omregningene som blir gjort i Python så ser det ut som det kan bli unøyaktige avrundinger som f.eks.

 

>>> math.log(pow(10,100000),10)
99999.999999999985
>>> 0 == 100000 - math.log(pow(10,100000),10)
False

 

i forhold til:

 

CL-USER> (log (expt 10 100000) 10)
100000.0
CL-USER> (zerop (- 100000 (log (expt 10 100000) 10)))
t

 

Jeg har sett eksempler på større Python systemer som sliter litt med alle de forskjellige versjonenene.

 

Norvig gir en bra oversikt over Lisp og Python funksjoner. Jeg vet om enkelte som har lært seg Lisp ut i fra den. Den var kanskje var ment som det motsatte, men det er ikke noe nytt i Python for en Lisp programmerer.

[Inaktivbruker_101125]

Har noen av dere lest denne boken? Driver å utvikler et lite OS og tenkte å implementere et enkelt scriptingspråk eller lignende for moro skyld. Har noen av dere utviklet et stand-alone programmerings/scriptingspråk? Hvordan er det?

[asicman]

Har noen av dere lest denne boken?

 

Jeg har ikke lest den, men jeg har brukt programmene til forfatteren (PCCTS og ANTLR) så jeg vil tippe det dreier seg litt om parsing med ANTLR. Personlig så foretrekker jeg ANTLR fremfor f.eks. lex/yacc/bison da det er mye mer oversiktlig.

 

Men et DSL er mye enklere å skrive vha. macroer i Common Lisp så for meg er det ofte det enkleste hvis det ikke er gitt noe krav til syntax på forhånd.

[Niinja47]

Hva med Java da? La oss diskutere litt Java

[asicman]

Spiller det noen rolle om man bruker et bibliotek fra en 3. part eller fra språkdistribusjonen for å få utført en oppgave?

 

Nei, men det var et eksempel på hvorfor man ikke trenger en så stor mengde med biblioteker i CL.

 

 

For det første -- nei, det blir ikke det

 

Skrevet uten floatingpoint notasjon og i Python 2.6.4 blir det 0 hos meg i alle fall.

Endret 5. juli 2010 av asicman

[x871kx6167ss7]

Har noen av dere lest denne boken?

 

Jeg har ikke lest den, men jeg har brukt programmene til forfatteren (PCCTS og ANTLR) så jeg vil tippe det dreier seg litt om parsing med ANTLR. Personlig så foretrekker jeg ANTLR fremfor f.eks. lex/yacc/bison da det er mye mer oversiktlig.

 

Men et DSL er mye enklere å skrive vha. macroer i Common Lisp så for meg er det ofte det enkleste hvis det ikke er gitt noe krav til syntax på forhånd.

 

Liker s-expressions, siden jeg slipper jeg å sette meg inn i alle de forskjellige parserene. Er vel LR(1) som er nok.

[zotbar1234]

Spiller det noen rolle om man bruker et bibliotek fra en 3. part eller fra språkdistribusjonen for å få utført en oppgave?

 

Nei, men det var et eksempel på hvorfor man ikke trenger en så stor mengde med biblioteker i CL.

 

Igjen, ethvert program med kompleksitetsnivå over "hello world" vil kreve ekstra biblioteker. Om man sier "import collections" eller "import psycopg2" er således lite vesentlig.

 

For det første -- nei, det blir ikke det

 

Skrevet uten floatingpoint notasjon og i Python 2.6.4 blir det 0 hos meg i alle fall.

 

Det tviler jeg ikke på.

[snippsat]

disjonelt så er man litt skeptisk til å bruke float for eksakte rasjonelle tall, hvis det blir brukt float under kalkuleringen så vil man få unøyaktigheter, som er grunnen til at man bruker rasjonale tall i utgangspunktet.

Ja det er derfor man har decimal modulen i standar biblioteket,for eksakte kalkuleringer.

 

Hva med Java da? La oss diskutere litt Java

Diskutere hva?,du må jo nesten komme med noe.

Kansje hvorfor java er så verbose,for og mobbe java litt.

Neida java er greit det,men synes at det kan bli for verbose i mange tilfeller.

 

Et eksempel legge en bowling score inn i et dictionary/hashmap.

#Python
my_dict = {}
my_dict["my bowling scores"] = [120, 140, 165]

#Java
Map<String, List<Integer>> my_dict = new HashMap<String, List<Integer>>();
List<Integer> lst = new LinkedList<Integer>();
lst.add(120);
lst.add(140);
lst.add(165);
my_dict.put("my bowling scores", lst);

 

En sammenliging Python vs java

 

Python is not java

Getter og setter som blir sett på som som dårlig programmering i python.

Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the ‘property’ built-in is for.

getters-setters-fuxors

Endret 6. juli 2010 av SNIPPSAT

[asicman]

disjonelt så er man litt skeptisk til å bruke float for eksakte rasjonelle tall, hvis det blir brukt float under kalkuleringen så vil man få unøyaktigheter, som er grunnen til at man bruker rasjonale tall i utgangspunktet.

Ja det er derfor man har decimal modulen i standar biblioteket,for eksakte kalkuleringer.

 

 

Men det gir ikke eksakte rasjonale tall.

 

>>> Decimal(1) / Decimal(3)
Decimal('0.3333333333333333333333333333')

 

Python 2.6.4 readeren aksepterer rasjonale tall, men gir feil resultat etter hva som ville være naturlig å forvente:

 

>>> 1/3 + 2/3
0

 

Men man kan skrive:

>>> 1/3.0 + 2/3.0
1.0

 

Som gir noe som kan se ut til å være et floating point resultat.

 

Det som er riktig er å bruke til rasjonale tall er Fraction:

 

>>> from fractions import Fraction
>>> Fraction(1,3) + Fraction(2,3)
Fraction(1, 1)

 

I Python 3 kan man skrive 1/3 + 2/3.

 

Dette er ikke etter min mening så veldig elegant og det er noen fallgruver å gå i.

Endret 6. juli 2010 av asicman

[snippsat]

Dette er ikke etter min mening så veldig elegant og det er noen fallgruver å gå i.

Ja dette er kjent teama i python,jeg er enig at python 2.x sin integer division løsning kunne ha vært bedere.

Historien skrevet av Guido.

http://python-history.blogspot.com/2009/03/problem-with-integer-division.html

 

Den enkleste løsningen nå for python 2.x er og ha med denne linjen,viss man skal gjøre integer division.

Da fungere integer division som i python 3.x

from __future__ import division

Endret 8. juli 2010 av SNIPPSAT

[NevroMance]

Vil nå påstå at Python ikke akkurat er alene om denne fallgruven, og det er en problemstilling alle programmerere må ha kjennskap til. Siden det er noe en må ha kjennskap til, ser jeg heller ikke helt problemet med det. Ser fordelen med å kunne skrive det som 1/3 + 2/3, men ser det ikke som noe stort problem å måtte presisere at det er flyttall.

[asicman]

Ja dette er kjent teama i python,jeg er enig at python 2.x sin integer division løsning kunne ha vært bedere.

Historien skrevet av Guido.

http://python-history.blogspot.com/2009/03/problem-with-integer-division.html

 

Hovedpoenget med meldingen min er at dette har endret seg over tid som mange andre ting i Python. Det kan skape problemer med vedlikehold av Ptyhon kode.

 

 

 

Den enkleste løsningen nå for python 2.x er og ha med denne linjen,viss man skal gjøre integer division.

Da fungere integer division som i python 3.x

from __future__ import division

 

Jeg vil anta (korriger meg om jeg tar feil) at tidslinjen ser slik ut:

 

(A) 2.0 release

(B) 3.0 utviklingen starter (eller pågår)

© Man innser at man kan få problemer med kompabilitetet og innfører from __future__

(D) 3.0 release

 

For kode som er skrevet før C og som har basert seg på en gitt semantikk med divisjon kan få problemer når den integreres i kode skrevet etter D (også C, men jeg vil tro ingen bare slenger på en from __future__ import division og tror det skal løse problemet)

[Johan]

Integerdivisjon er noe herk. Fornuftige programmeringsspråk har støtte for rasjonale tall. Også automatisk konvertering til flyttall er no dritt, taper man informasjon burde det helt klart være warn.

Endret 8. juli 2010 av Johan

[asicman]

Vil nå påstå at Python ikke akkurat er alene om denne fallgruven, og det er en problemstilling alle programmerere må ha kjennskap til. Siden det er noe en må ha kjennskap til, ser jeg heller ikke helt problemet med det. Ser fordelen med å kunne skrive det som 1/3 + 2/3, men ser det ikke som noe stort problem å måtte presisere at det er flyttall.

 

Det er mange fallgruver med forskjellige språk. Problemet her er at det endrer seg over tid. Hvordan kan man ha kjennskap til hva Guido måtte finne på i framtiden når man skrev koden før tidspunkt C (se forrige melding).

 

Man kan selvsagt lage et bakoverkompabilitetsmodus, men det blir fort integrasjonsproblemer.

 

 

Ser fordelen med å kunne skrive det som 1/3 + 2/3, men ser det ikke som noe stort problem å måtte presisere at det er flyttall.

 

Det ser ut som om Guido og andre har sett denne fordelen siden er introdusert i Python 3.0. Men flyttal er akkurat det man ikke vil ha når man skal gjøre eksakte beregnringer med rasjonale tall. Fraction som jeg viste tidligere vil virke for å jobbe med rasjonale tall.

[TheMaister]

Integerdivisjon er noe herk. Fornuftige programmeringsspråk har støtte for rasjonale tall. Også automatisk konvertering til flyttall er no dritt, taper man informasjon burde det helt klart være warn.

 

Kommer veldig an på språket. Integerdivisjon (at 1/3 == 0, etc) har helt klart sine bruksområder.

 

I C++ kan man f.eks lage en rational-klasse som overloader alt av aritmetiske operasjoner.

Endret 8. juli 2010 av TheMaister

[asicman]

Kommer veldig an på språket. Integerdivisjon (at 1/3 == 0, etc) har helt klart sine bruksområder.

 

Ja, og hvis man skrev kode som benyttet seg av den egenskapen i Python 2.x så vil det ikke virke i Python 3 (hvor man bruker //).

 

Personlig så foretrekker jeg heller språk som er definsert av en standard framfor dikatorspråk som ender seg over tid som f.eks. Python, Perl og PHP. Jeg ser for meg PHP utvilerene: "closures må vi ha det? ja, det er nyttig for å implementere continuations og noen sier det fantes i lisp for snart 40 år siden, ja da må vi finne på en kludge for å få det med,"

 

Standarder endrer seg også, men prossessen er litt mer demokratisk og ofte mer gjennomtenkt. Diktatorspråk kan selvsagt bli standardisert på et tidspunkt.

 

 

I C++ kan man f.eks lage en rational-klasse som overloader alt av aritmetiske operasjoner.

 

Det blir som Fraction jeg nevnte tidligere i Python. Parseren forstår fortsatt ikke at 1/3, men man kan skrive Fraction(1,3) for å lage en instans av en fraction.

 

I Common Lisp kan man bruke rasjonale tall siden readeren forstår disse (hvis den ikke hadde det kunne man laget en reader macro for å endre syntax) og det finnes en egen funksjon for integerdivision (truncate)