- memark
- Medlem ●
- Mölndal
Ett problemet är väl att "x function_foo y" bara funkar någorlunda när operationen tar två argument. Visst finns det flerställiga operatorer (t ex ?: i C), men de hör ju till undantagen.
En annan tendens (åtminstone i t ex jQuery och LINQ) är ju att kedja ihop fler och fler anrop, så här
x.Add(y).Multiply(z).SelectDistinct()
vilket snarare är en utveckling åt andra hållet...
Jag menar inte att diskussionen var ointressant, bara att Lisp väcker känslor.
Tror väl inte att jag kommer att bli någon stor Lisp-hackare, men jag tror absolut att jag kan bli bättre på att programmera, och att jag kommer att kunna skriva bättre Obj-C kod efter att ha löst ett gäng Euler-problem med Lisp!
Det finns ju ett problem med att lära sig programmering i att språkliga egenheter tenderar att stå i vägen för det rena problemlösandet (vilket väl märks i diskussionen i denna tråd). Och även om ett språk som Obj-C är ganska litet så har man hela skogen av API:er att traska igenom och man måste lära sig en massa om verktygen, i detta fall Xcode.
Det tog många rader kod innan jag skrev en kategori i Obj-C på riktigt, alltså inte som ett läroexempel, utan för att hantera min egen kod. Det tog ännu längre tid innan jag vidarebefordrade meddelanden från objekt av en klass till ett annat. Och dessa egenheter hos Obj-C är ju stora skäl till språkets framgång (kom in på Tiobes topp tio i maj). Apples framgångar är väl en större del, men folk har trots allt valt det som programmeringsspråk på Next och Apple.
Och nu rullar Emacs, SLIME och sbcl på min Macbook och jag läser Practical Common Lisp. Och om jag får tro en del lispfantaster kommer jag att möta min frälsning inom kort.
Vänligen, Ylan
Och nu rullar Emacs, SLIME och sbcl på min Macbook och jag läser Practical Common Lisp. Och om jag får tro en del lispfantaster kommer jag att möta min frälsning inom kort.
Eller också, och ur min synvinkel mer troligt, så kommer du fram till att det inte gör någon större nytta, men då har du testat det seriöst och vet i stället för bara gissar.
Jag har läst LISP och tyckte bara det var trögjobbat och svårläst. Man satt mest och försökte formulera om sina problem rekursivt, vilket kunde bli kompakt men inte snabbt och sällan lättläst. Dock har jag inte kört några större projekt så det är inte så djupa insikter.
Jag har däremot jobbat en hel del med Java, avskyr det, men jag beklagar inte att jag lärt mig det, för nu kan jag rakryggat säga att jag verkligen jämfört. Jag vet varför jag inte gillar det, varför jag väljer bort det.
Och samma sak med både Lisp och RPN: Är man inte nyfiken nog att i alla fall testa lite så vet man ju ingenting. De gamla verktygen är kanske bra men de måste tåla en jämförelse då och då. Men även där måste man välja hur djupt man skall gå, man hinner inte bli expert på allt.
Och om jag får tro en del lispfantaster kommer jag att möta min frälsning inom kort.
Haha, ja Lisp är fint. Jag blev helt klart frälst. Sen en gång till efter att ha läst JonesForth.
http://www.annexia.org/_file/jonesforth.s.txt
Det finns bara tre programspråk värd att nämna; Lisp, Forth och Prolog.
Just nu är det Forth på Arduino som är intressant för min del.
http://amforth.sourceforge.net
Haha, ja Lisp är fint. Jag blev helt klart frälst. Sen en gång till efter att ha läst JonesForth.
http://www.annexia.org/_file/jonesforth.s.txt
Det finns bara tre programspråk värd att nämna; Lisp, Forth och Prolog.
Just nu är det Forth på Arduino som är intressant för min del.
http://amforth.sourceforge.net
Försöker få min iPhone app ut på app store just nu. Och sedan är det 1.1. MEN SEN!
Vänligen, Ylan
Det där är väldigt sant. Jag har också provat en massa språk genom åren, det ger lite perspektiv på saker och ting, och gör att man med lite större trovärdighet kan uttala sig som om vad som är bra för olika ändamål.
Ni verkar ju vara ett funktionellt gäng här ändå, nån som har en åsikt om F#? (Som till stor del bygger på Scheme och OCaml.)
I knew it:
RPL (programming language) - Wikipedia, the free encyclopedia
"The RPL programming language (RPL meaning ROM-based procedural language following Hewlett-Packard or, alternatively, Reverse Polish LISP) is a handheld calculator system and application programming language used on Hewlett-Packard's engineering graphing RPN calculators of the HP-28, HP-48, HP-49 and HP-50 series, but it is also usable on non-RPN calculators, such as the HP-39 series.
RPL is a structured programming language based on RPN but equally capable of processing algebraic expressions and formulae, implemented as a threaded interpreter[1]. RPL has many similarities to Forth, both languages being stack-based, and of course the list-based LISP. Contrary to previous HP RPN calculators, which had a fixed four-level stack, the stack used by RPL is only limited by available calculator RAM.
RPL originated from HP's Corvallis, Oregon development facility in 1984 as a replacement for the previous practice of implementing the operating systems of calculators in assembly language.[2] According to a quote by Dr. William Wickes, one of the original RPL developers, "the development team never calls it anything but (the initials) RPL."[3]"
RPL har jag aldrig hört talas om. Liknar det FORTH?
RPL har jag aldrig hört talas om. Liknar det FORTH?
Det används ju i princip inte på annat änHP's räknare av senare snitt, du skall inte känna dig oupplyst om du inte hört talas om det. Få har.
Jag tycker det är grymt för matte, inget annat. Jag höll på med det när jag var i sena tonåren och man hade tid utforska allt.
Jag pillade en hel del med Forth också, men tyckte att det var plottrigt och förbaskat oelegant när det kom till annat än numeriska data.
Ibland var stacken ens vän, ibland svor man över den...
RPL gjorde det lättare hantera strängar, vektorer, variabler, listor etc.
Fortfarande stack, men det kändes modernare, och lite snyggare
i länken till Wikipedia finns lite kodexempel, mest på slingor, villkor osv.
Nedan är ett exempel ur "Advanced 49g+ Programming", Fibonnachi, Loop-variant (ej rekursiv). Gott om pilar, specialtecken etc att "götta ner sig i" ...
brevid det, den rekursiva varianten (snygg...)
Vad roligt att LISP språket fortfarande gillas av era entusiaster !
Jag har nämligen jobbat service av LISP Machine !
Det var början av 80 talet. Det var 16 bitar dator, långt före sin tid.
De kostade 800.000 kr per styck. Uppsala Universitet köpte in 2 st.
Umeå Universitetet köpte in 1 st. Det var för Lingvistik forskning, men även för
Artificial intelligence som LISP språket är lämpligt för det. Uppsala Universitet hade
en avdelning just för Artificial intelligence då.
Jag hade ansvaret att felsöka om CPU strejkade och byta ut TTL !
Processor var inte små CPU chips då. Det var TTL chips som byggdes så att det blir 16 bitar CPU, stor som en dörr ! Med massa wired kabeltrådar som kopplingar.
Se länken hur stor dörr det är! Lisp machine - Wikipedia, the free encyclopedia
Mannen som kom hit Uppsala Richard Greenblatt Richard Greenblatt (programmer) - Wikipedia, the free encyclopedia)
Han är mannen som jag fortfarande än idag är imponerat snabbaste tangenbordsskrivaren ! Ofattbar snabba händer och inte felstavelse ! Eftersom jag var där med honom när han arbetade igångsättning av dator. Mera länk Lisp Machines - Wikipedia, the free encyclopedia
Det används ju i princip inte på annat änHP's räknare av senare snitt, du skall inte känna dig oupplyst om du inte hört talas om det. Få har.
Jag tycker det är grymt för matte, inget annat. Jag höll på med det när jag var i sena tonåren och man hade tid utforska allt.
Rent miniräknarspråk? Det verkar ju kunna lite mer än bara räkna, så man kan köra iterativa saker. Formen gör att göra väldigt effektiv och kompakt, bra för små maskiner som en miniräknare. Jag hade definivt föredragit det framför det klumpiga systemet som Texasräknaren hade. Min Sharp var underbar på matten, men den lilla programmerbarhet den hade tillät inte loopar.
Vad roligt att LISP språket fortfarande gillas av era entusiaster !
Jag har nämligen jobbat service av LISP Machine !
Det var början av 80 talet. Det var 16 bitar dator, långt före sin tid.
De kostade 800.000 kr per styck. Uppsala Universitet köpte in 2 st.
Umeå Universitetet köpte in 1 st. Det var för Lingvistik forskning, men även för
Artificial intelligence som LISP språket är lämpligt för det. Uppsala Universitet hade
en avdelning just för Artificial intelligence då.
Jag hade ansvaret att felsöka om CPU strejkade och byta ut TTL !
Processor var inte små CPU chips då. Det var TTL chips som byggdes så att det blir 16 bitar CPU, stor som en dörr ! Med massa wired kabeltrådar som kopplingar.
Jag har ett vagt minne av Lispmaskiner på universitetet. Men menar du att de hade en CPU byggd av diskreta TTL-kretsar såpass sent?
Jag har ett vagt minne av Lispmaskiner på universitetet. Men menar du att de hade en CPU byggd av diskreta TTL-kretsar såpass sent?
Inte omöjligt. När jag praktiserade på Sperry Univac (senare Unisys) så hade man datorer med stora CPU-kort, sk. "löv", som hade CPU:n realiserad med hjälpa av TTL. Snygga kort med kretsarna i långa rader. Ingenjörskonst i den högre skolan.
Jag har ett vagt minne av Lispmaskiner på universitetet. Men menar du att de hade en CPU byggd av diskreta TTL-kretsar såpass sent?
ja CPU bestod av massor av TTL kretsar, sammankopplad av wired koppartrådar !
Ganska lätt att felsöka och byta ut TTL. Vips funkade CPU
Man felsökte med LISP språket ! Master - Slave funktion
Det var på gång första 16 bitar CPU chips på fabriken.
Men hann sälja många många LISP maskiner, mest till US militära
Snubblade över "Common Lisp Implementations: A Survey" idag. Kanske kan vara till hjälp.
There has been a new wave of interest in Common Lisp over the last few years. This paper is a November, 2007 (updated February, 2010) survey of Common Lisp implementations that are currently being actively maintained. It also provides references to writings about why Lisp is interesting and important, Lisp textbooks, and useful Lisp resources including repositories of available libraries. I hope it will help you find the right implementation for your project or product.
This paper also contains pointers to useful Web pages related to Lisp (including many dialects, not just Common Lisp).
Snubblade över "Common Lisp Implementations: A Survey" idag. Kanske kan vara till hjälp.
There has been a new wave of interest in Common Lisp over the last few years. This paper is a November, 2007 (updated February, 2010) survey of Common Lisp implementations that are currently being actively maintained. It also provides references to writings about why Lisp is interesting and important, Lisp textbooks, and useful Lisp resources including repositories of available libraries. I hope it will help you find the right implementation for your project or product.
This paper also contains pointers to useful Web pages related to Lisp (including many dialects, not just Common Lisp).
LISP är en speciellt språk för djupare forskning inom Artificial intelligence och annat området (som jag inte vet). Idag när datorer har så mycket kraft då ligger LISP bra till med tiden ! När jag höll service av LISP Machine, var det i nivån 16 bitar CPU och utbytbara 300 MB hårddisk skivor ( man lyfter bort tunga 8 st magnetiska skivor som en block )
LISP är en speciellt språk för djupare forskning inom Artificial intelligence och annat området (som jag inte vet).
Jag har aldrig riktigt insett varför LISP skulle vara speciellt lämpat för AI, mer än på det sätt att vissa algoritmer kan vara väldigt kompakta och därmed verkar det mer rimligt att ett program skulle kunna skriva sig självt än att ett Fortran-program skulle kunna det. Men samma sak kan sägas om Forth, eller rentav en stram assembler. Och drömmen om självmodifierande program, är det mer än en galen dröm som är helt onyttig?
Rekursion var så klart häftigt, Lisp var först där och det är stort, men idag finns inga språk som inte stödjer rekursion, och dessutom är rekursion inte så överreklamerat längre ("to iterate is human, to recurse devine") utan har (lyckligtvis) fått en sund status som ett verktyg i mängden.
Rekursion var så klart häftigt, Lisp var först där och det är stort, men idag finns inga språk som inte stödjer rekursion
Det finns många språk som stödjer rekursion rent syntaktiskt idag, men på den smarta kompilatoroptimeringarnas nivå kan det vara både si och så med det - finns det något språk som inte växer på lisp-grenen som förmår att tillvarata de prestandamässiga fördelarna med svansrekursion, exempelvis?
Den stora fördelen med lisp, som jag ser det, är att det ger en helt annan infallsvinkel på algoritmiska problem än vad funktionella/oop:ade språk gör. Jag upplever ofta att jag förstår ett problem bättre efter att ha formulerat det i lisp, även om den faktiska implementationen blir i C# eller något annat.
Stöd för tail recursion har funnits i .NETs CLR ett antal år. Tidigare har det dock bara använts av funktionella språket F# och 64-bitarskompilatorn (!) för C#. Med framework 4.0 ska det enligt uppgift gälla alla språk och arkitekturer.