ProgrammeringsBaren! Småprat, om det du elsker!

[GeirGrusom]

Ok, men dette går ikke på dynamisk typing vs. statisk typing.

 

Python må ikke nødvendigvis ha dynamisk typing, eller spesifikk dynamisk typing, men det er et valg de har tatt, som jeg synes er ganske teit.

 

Dersom python hadde hatt valget med statisk typing, og eksplisitt deklarering av variabler i Python; hadde dere brukt dette, eller gått tilbake til dynamisk typing?

I VB6 hade en valget, og jeg vet ikke om én som brukte det.

 

edit: når det gjelder raskt enkelt bytte kode i biblioteker, kalles dette generisk programmering i C# og Java, som stort sett gir samme mulighet i denne sammenhengen.

Endret 5. juni 2008 av GeirGrusom

[teflonpanne]

Jo, mye av det går på dynamisk typing. Og python hadde sett helt annerledes ut hvis de hadde hatt statisk typing. Se bare på templates i C++ og generics i C#, det er det jeg mener med at dynamisk typing tillater mer clean syntax. C++-templates er forferdelig hårete, lett å gjøre feil, kryptiske feilmeldinger osv osv. Menmen, nå har jeg sagt mitt. Hvis du ikke ser noen fordeler så er det jo greit, du trenger jo ikke å bruke språket, men mange andre syns altså at dynamiske språk er fint og mer effektive å utvikle i.

 

Forresten, så hadde jeg valgt eksplisitt deklarering av variablene og dynamisk typing. I Common lisp har man eksplisitt deklarering av variablene og dynamisk typing, men du kan også deklarere typer i deler av koden der du trenger hastighet, så du kan f.eks deklarere en variabel integer så kompilatoren kan optimalisere der. Veldig greit.

[DeadManWalking]

Så langt er det ikke krangling, det er en saklig diskusjon om et gitt emne og det er lov! Hva med å fikse C++ koden min for den EP oppgaven

[GeirGrusom]

Forresten, så hadde jeg valgt eksplisitt deklarering av variablene og dynamisk typing. I Common lisp har man eksplisitt deklarering av variablene og dynamisk typing, men du kan også deklarere typer i deler av koden der du trenger hastighet, så du kan f.eks deklarere en variabel integer så kompilatoren kan optimalisere der. Veldig greit.

 

Jeg hadde valgt eksplisitt deklarering, og statisk typing, med mulighet for dynamisk typing dersom oppgaven løses enklere på den måten.

 

Så jeg er egentlig enig.

 

Jeg bare misliker at en ikke har noe valg i Python, at det ikke er nødvendig med eksplisitt deklarering, og at alle variabler er dynamiske.

 

Men men, jeg får bare holde meg til mitt språk, så får dere holde til deres.

[Giddion]

Så langt er det ikke krangling, det er en saklig diskusjon om et gitt emne og det er lov!

 

hehe så lenge det blir med det så,mulig jeg var litt kjapp der

[x871kx6167ss7]

Yay, har laget mitt første clisp-program. Gjorde oppgave 12 på projecteuler.

 

Neppe det peneste, men det funker ihvertfall.

Klikk for å se/fjerne innholdet nedenfor

#!/usr/bin/clisp
;;; Find all those imba numbers

;; Generate tri-numbers and puts them in *tri*
(defparameter *tri* 1)
(defparameter *next* 1)
(defun next-tri ()
 (setf *next* (1+ *next*))
 (setf *tri* (+ *tri* *next*)))

(defun is-prime (n)
 (if (equal (mod n 2) 0) (return-from is-prime nil))
 (loop for x from 3 to (sqrt n) by 2
	do (if (equal (mod n x) 0) (return-from is-prime nil)))
 (return-from is-prime T))

;; Finds the first divider of a number and returns it
(defun find-first-div (n)
 (loop for x from 2 to n do
	(if (equal (mod n x) 0) (return-from find-first-div x))))

;; Hashmap containing primtallfaktoriseringen
(defparameter *fac* (make-hash-table))
(defun clear () (setf *fac* (make-hash-table)))
(defun add (n)
 (if (not (gethash n *fac*))
(setf (gethash n *fac*) 1)
(setf (gethash n *fac*) (+ (gethash n *fac*) 1))))

(defun factorize (n)
 (let (x)
(loop
  (if (is-prime n) (return-from factorize (add n)))
  (setf x (find-first-div n))
  (add x)
  (setf n (/ n x)))))

(defun number-of-div (n)
 (clear)				  ;Empty *fac*
 (factorize n)
 (let ((num 1))
(maphash #'(lambda (k v) (setf num (* num (+ v 1)))) *fac*)
num))

(loop
 (next-tri)
 (if (> (number-of-div *tri*) 500) (return)))

(format t "Answer: ~d~%" *tri*)

 

[dewszaq@blackslash problem012]$ time ./prob12.lsp

Answer: 76576500

 

real 0m10.958s

user 0m10.863s

sys 0m0.050s

 

Tror det er riktig ihvertfall, projecteuler er nede for meg, men husker at det var rundt der.

[steingrim]

Om man blir redd av å se Python så bæsjer man vel i buksa av å se litt Lisp

[x871kx6167ss7]

Driver å leser et toturial nå, og hode går i surr når jeg leser. Har programmert i c++ og python, og prøvde litt java for noen dager siden, men dette er jo heeeelt annerledes.

 

Leste at «mottoet» var «the programmable programming language», og tenkte at det var det teiteste mottoet som fantest, men macroer virker jo helt genialt. Tror nok at jeg skal prøve å legge litt arbeid i å lære meg lisp.

 

Edit: kompilert:

[dewszaq@blackslash problem012]$ time clisp prob12.fas

Answer: 76576500

 

real 0m1.571s

user 0m1.503s

sys 0m0.063s

Endret 5. juni 2008 av Blackslash

[teflonpanne]

Hehe, lisp er et jævlig kult språk, du kommer nok til å like det Og makroer er jo omtrent det kuleste man finner i programmering.

 

Her er forøvrig en utrolig god bok om common lisp: http://gigamonkeys.com/book/

 

Kan også anbefale deg å bruke SBCL som Common Lisp-kompilator sammen med Emacs og SLIME. Veldig bra utviklingsmiljø. Her er en liten video også: http://www.cl-user.net/asp/web-sites/slime-video

[Johan]

Støttes. Lisp er utrolig deilig når man først kommer over de første kneikene.

 

SLIME er også så utrolig deilig, og interpreter-støtten gjør at man lett kan teste små snutter kode, noe som øker produktiviteten betraktelig, særlig når en ikke helt vet hvordan man skal angripe et problem. Da kan man lett teste ut forskjellige måter uten å måtte rekompilere og lage masse pretty-print og boilerplate.

[GeirGrusom]

Lisp har en smart grunnidé

 

Jeg derimot er forelsket i D

 

D mest fordi det rett og slett er et genialt språk med bøtter og spann med features.

Metaprogramming som er helt ufattelig for et native code språk

nested functions

D intefaces er direkte kompatibelt med COM interfaces

D støtter inline assembly

Recursive functions med egen syntaks for det

 

Skulle ønske D var mer utbredt

[x871kx6167ss7]

Hehe, lisp er et jævlig kult språk, du kommer nok til å like det Og makroer er jo omtrent det kuleste man finner i programmering.

 

Her er forøvrig en utrolig god bok om common lisp: http://gigamonkeys.com/book/

 

Kan også anbefale deg å bruke SBCL som Common Lisp-kompilator sammen med Emacs og SLIME. Veldig bra utviklingsmiljø. Her er en liten video også: http://www.cl-user.net/asp/web-sites/slime-video

Den boken jeg leser, helt enig at den er god, går veldig grundig til verks.

 

Støttes. Lisp er utrolig deilig når man først kommer over de første kneikene.

 

SLIME er også så utrolig deilig, og interpreter-støtten gjør at man lett kan teste små snutter kode, noe som øker produktiviteten betraktelig, særlig når en ikke helt vet hvordan man skal angripe et problem. Da kan man lett teste ut forskjellige måter uten å måtte rekompilere og lage masse pretty-print og boilerplate.

 

Hmm, kanskje jeg må prøve emacs og slime, da. >.< Jeg bruker vim og interpreteren til clisp for øyeblikket. Får vel prøve meg på emacs, da. Virker jo som et veldig fint os.

Endret 6. juni 2008 av Blackslash

[Manfred]

Hadde jeg bare hatt tid, så skulle jeg gjerne satt meg ned og sett på heeelt andre språk enn de jeg er vant til, som python, lisp, osv... Jeg er opplært i c-syntaktiske språk, og dette er det eneste jeg har brukt. Når det i tillegg er jobben min blir det liten tid til andre ting. Og jeg ville hatt liten praktisk nytte av de også. Satser heller på å bli jævlig god på det jeg driver med jeg da Hehe

[Cucum(r)]

Poster denne her, sidan det var lite respons i Webkafeen:

 

Folket her som har studert Java/andre-statiske-språk på høgare institusjonar: Korleis blei det anbefalt å utvikle message brokers/processors? Asynkront/synkront? Emnebasert eller innholdsbasert?

 

Driv med eit lite system i Python som ser ut til å fungere ganske så bra. Minnebruken ligg på mellom 2 og 25 mb, avhengig av størrelsen på prosessane som køyrer på den (500mb map/reduce-jobb førte til 30mb minnebruk på køserveren). Ein jobb har prioritet 1-4, kor 1 er høgaste prioritet utan moglegheit for å miste data. Her har vi dobbellagring (både minne og database), slik at jobben blir utført sjølv om memcached-serveren går ned. Dei andre prioritetane ligg kun i minnet, og køene blir sjeldnare sjekka til lavare prioritet.

 

Prosessen fungerer no slik:

• Prosess blir sendt til ein `descriptor´, som avgjer prioritet på jobben, og legg ved metadata som fortel kva for ein ´worker´ som skal ta seg av jobben. Jobben blir lagt i kø
  
• Serveren køyrer som ein daemon, og sjekker dei forskjellige prioritetskøene. Om den finn ein jobb prøver den å dekode key/value-paret slik at den finn ut kva for ein ´worker´som skal ta seg av dataene
  
• Serveren sender jobben til den korrekte map/reduce-funksjonen asynkront, og går vidare
  

Heile systemet køyrer på memcached, så det er lynkjapt i tillegg.

 

Ser dette OK ut? Er det noko vesentleg som manglar? Kva hadde dykk gjort annaleis?

[Manfred]

Hadde det ikke vært bedre å startet dette som en egen tråd??

[Jaffe]

Hehe, lisp er et jævlig kult språk, du kommer nok til å like det Og makroer er jo omtrent det kuleste man finner i programmering.

 

Her er forøvrig en utrolig god bok om common lisp: http://gigamonkeys.com/book/

 

Kan også anbefale deg å bruke SBCL som Common Lisp-kompilator sammen med Emacs og SLIME. Veldig bra utviklingsmiljø. Her er en liten video også: http://www.cl-user.net/asp/web-sites/slime-video

 

Slenger meg på her, Lisp er rett og slett genialt (først og fremst på grunn av den suverene makrostøtta). Har lært meg ein del no, i alle fall nok til å lage enkle småprogram (tre på rad (med GUI), telnet-chat, dynamisk nettside), og må seie at det går forbausande lett å komme i gong med eit nytt program, mykje på grunn av det interaktive programmeringsmiljøet. Det einaste problemet eg har med Common Lisp er den noko lause og mangelfulle stanadrden (rotete navn og mangel på grunnleggande ting som sockets og tråding), og mangelen på robuste bibliotek. Dei fleste implementasjonane lappar over socket- og trådstøttemangelen, men det er ingen felles standard, noko som gjer kode lite portabel mellom forskjellige implementasjonar.

[x871kx6167ss7]

Dersom jeg får litt skills i lisp må jeg nesten kjøpe meg en symbolics-maskin. Har sett litt videoer og sånt om dem, virker jo sykt kule. Desktop-versjonene, ikke kjøleskapene, da...

Endret 6. juni 2008 av Blackslash

[teflonpanne]

Jaffe: jepp, det er veldig synd. Common Lisp burde egentlig bli redesignet med standarder for tråder, sockets osv og så burde de kutte drastisk ned på antall funksjoner i standardbiblioteket. Liksom 10 forskjellige map-funksjoner eller noe. Ikke rart ingen implementasjoner av CL klarer å støtte hele språket, det er jo så jævlig stort og hårete. Der burde de lære litt av Haskell, det har et veldig rent og pent lite bibliotek. Menmen, CL er fult brukbart selvom da.

 

Blackslash: hehe, de som er 30 år gamle mener du?

[x871kx6167ss7]

Blackslash: hehe, de som er 30 år gamle mener du?

Riktig, riktig.

http://lispm.dyndns.org/mov/lispm-4.mov

[DeadManWalking]

Før jeg begir meg ut på et nytt eventyr, vil jeg bare få bekreftet at det lar seg gjøre. Det går an å skrive en msn-klient i dette sant? Det er støtte for SSL, så det burde la seg gjøre.

Endret 8. juni 2008 av data_jepp