Exotische Prog.Sprachen
-
ich hab mal paar kleinere Sachen in Brainfuck geschrieben, das war sehr geil aber das hat wirklich mein brain gefuckt
-
Kennt jemand einen einfachen freien LISP-Interpreter/Compiler, mit dem man mit wenig Installationsaufwand und ohne großes Registry-Gepfriemele unter win32
mit LISP herumspielen kann ?
-
Cacheline schrieb:
Interessanter Link! Demzufolge scheint bei der Ausführungs-Effizienz kaum
ein Weg an C vorbeizugehen (abgesehen von Forth).nunja, interpretationsfrage. hier ist OCaml mal sehr schnell, da mal sehr langsam...
hier wird basierendn auf dem bench behauptet, es würde im schnitt den 2. schnellsten code generieren. aber keine ahnung, wie und wo das abgelesen wurde
naja, letztendlich halte ich so einen bench eh nur für minder aussagekräftig, zischen einem einzelnen kleinen algorithmus und einem komplexen programm ist auch wieder ein riesen unterschied, da kommen dann auch wieder andere faktoren zum tragen.
trotzdem interessant, dass eine sprache, die doch ein paar abstraktionsebenen über den maschinennahem wie C oder C++ steht trotzdem so gut mithalten kann.Cacheline schrieb:
Was von FP-Sprachen aber immer wieder behauptet wird, ist ja die höhere
Entwicklungs-Effizienz, man soll wohl x-mal so schnell zum ausführbaren
Programm kommen.da schaust du dir am besten mal den punkt codelänge bzw. gleich die implementationen der beispielprogramme an.
-
Cacheline schrieb:
Kennt jemand einen einfachen freien LISP-Interpreter/Compiler, mit dem man mit wenig Installationsaufwand und ohne großes Registry-Gepfriemele unter win32
mit LISP herumspielen kann ?Hallo!
Für Newbies am besten geeignet ist eigentlich SBCL. Doch leider läuft der nicht unter Windows.
clisp (den nutze ich auch die meiste Zeit) ist ebenfalls einfach zu benutzen.
Wichtig ist, dass du asdf zum Laufen bringst, damit du ohne großen Aufwand Bibliotheken nutzen kannst. Dafür gibt es auch ein Tutorial von Edi Weitz:http://www.weitz.de/asdf-install/
Wenn dir das zu schwierig ist (verständlich), installier dir eine kommerzielle Lisp-Umgebung wie LispWorks oder Allegro.
Die freien Personal-Editionen haben nur wenige Einschränkungen und sind zum Lernen der Sprache optimal.
-
@Doktor Prokt:
Danke für die Links. Ich will ja LISP erstmal zum Herumspielen und ausprobieren
verwenden, deshalb sind mir die Trial-Pakete zu gross oder zu restriktiv.
Ich probiere XLISP aus, das ist genau das, was ich gesucht habe.@maximAL:
Kann man mit Sprachen wie Haskell, *ML oder *LISP eigentlich auch Dinge
wie Systemprogramme oder eine Textverarbeitung ohne große Kompromisse
programmieren ?Und wenn ja, welche gängige Software ist denn z.B. in LISP programmiert ?
-
Cacheline schrieb:
@maximAL:
Kann man mit Sprachen wie Haskell, *ML oder *LISP eigentlich auch Dinge
wie Systemprogramme oder eine Textverarbeitung ohne große Kompromisse
programmieren ?nun...das kommt drauf an.
was verstehst du unter systemprogramme? wenns ganz hardware-nah sein muss, ist C(++) sicher besser geeignet.
und sowas wie ne textverarbeitung würd ich generell lieber mit etwas entwickeln, wo ich mir die GUI zusammenklicken kann
-
oder eine Textverarbeitung ohne große Kompromisse
programmieren ?Emacs ist doch der Editor und er ist komplett Lisp basiert. Hat zum Vorteil, dass du innerhalb von sekunden eigene Erweiterungen basteln kannst.
Lisp Software die ich einsätze ist
Sawfish (Lisp-Dialekt: rep (basiert auf elisp))
GNU/Emacs (Lisp-Dialekt: elisp)
Maxima (Lisp-Dialekt: ANSI Common Lisp)Eine weitere bekannte Software ist AutoCAD. Ansonsten ist Lisp eher in spezial Lösungen verbreitet und besonders im KI Bereich ist Lisp eine weit verbreitete (wenn nicht _die_) Sprache.
-
kingruedi schrieb:
Eine weitere bekannte Software ist AutoCAD.
Wobei das heutige AutoCAD soweit ich weiß zum größten Teil in C++ programmiert ist, aber unter anderem über einen Lisp-Dialekt aus Gründen der Abwärtskompatibilität noch Erweiterungen geschrieben werden können.
-
kingruedi:
interessant. Daß man den Emacs mit LISP programmieren kann, wußte ich, aber daß
Emacs komplett in LISP geschrieben ist, hätte ich nicht gedacht.
-
Cacheline schrieb:
kingruedi:
interessant. Daß man den Emacs mit LISP programmieren kann, wußte ich, aber daß
Emacs komplett in LISP geschrieben ist, hätte ich nicht gedacht.Naja, Emacs kann nicht komplett in Emacs-Lisp geschrieben sein. Es wurde erst ein Lisp-Interpreter in C geschrieben und darauf dann der Editor gebaut.
Also ein minimaler Kern in C ist schon noch vorhanden
-
Funktionale Sprachen funktionieren meiner Erfahrung nach nicht bei allen Problemstellungen gleichgut. Es gibt viele Programmier-Alltagsprobleme die ich nur umständlich funktional beschreiben kann.
Außerdem verstehen die meisten die imperative programmierung recht schnell, so dass man für kleine Aufgaben auch nicht so talentierte Menschen verwenden kann, wogegen funktionale Sprachen ein wenig mehr Einarbeitung und Verständis benötigen.Ich persönlich würde große Projekte nur ungern in Haskell, Clean, etc. Verwirklichen. Der entstehende Code wäre zwar mit Sicherheit deutlich kürzer, als der in den meisten Anderen Sprachen, aber die Arbeit deswegen nicht zwangsweise einfacher.
Die Lösung sind IMHO Mischsprachen, wie Scala, die zwar noch nicht hundertprozentig ausgereift ist, aber IMO nachwievor die Sprache mit dem meisten Potential ist und bereits jetzt an programmiereffizienz (für mich) alle anderen mir bekannten Sprachen in den Schatten stellt.
-
Kingruedi, kannst du mir das mal genauer erklären, wieso LISP für KI so gefragt ist? Ich meine, man kann mit Listen rumspielen bzw. sie sind _DIE_ basis, aber inwiefern ist das jetzt besser als brainfuck, haskell, c oder sonstwas?
Und wieso ist es gut - sehr gut geeignet für Textverarbeitung? (Ja, ich habe noch nicht viel mit LISP gemacht, mache gerade dieses Tutorial dieser uni Seite..)
-
Helium schrieb:
Die Lösung sind IMHO Mischsprachen, wie Scala, die zwar noch nicht hundertprozentig ausgereift ist
ich möchte nur nochmal anmerken, dass OCaml auch ein "mischsprache" ist. funktional und imperativ - auch objektorientiert .
keine ahnung, ob es ausgereifter als scala ist, das kenn ich nämlich nicht
-
Ich habe eine Zeit in Visual Basic 6 programmiert. Wer jetzt sagt, das sei nicht exotisch, der hat wohl noch nie die Syntax gesehen
Ausserdem gibt es in VB sehr abenteuerliche Auslegungen von Objektreferenzen:
Dim obj As New Object obj = Nothing 'Jetzt kommt es :-D if obj = Nothing 'Diese Zeile verursacht einen schönen Absturz ...
Für mich absolut unlogisch, stellt eine riesengrosse Einschränkung in der Sprache VB dar. In C/C++, C# und auch in JAVA kann man so wunderschön auf NULL-Referenzen prüfen, in VB geht das offenbar nicht...
Oder hat gleich jemand einen Tipp?
-
Ist Scala wirklich so extrem effizient hinsichtlich Software-Entwicklung ?
Das im "Scala by example" abgedruckte Quicksort braucht über 20 Zeilen
Quelltext, das ist auch etwa die Größe der C-Version.In Haskell oder auch LISP kann man Quicksort ja in zwei bis fünf Zeilen
programmieren.Da wir schon beim Thema sind: Was hältst Du eigentlich von Helium (die
Programmiersprache, nicht der Poster) ? Ist das
zum Lernen von Haskell brauchbar oder kann man Helium auch zur größeren
Anwendungsprogrammierung verwenden ?
Wieviel Aufwand erfordert ein späteres Umsetzen von Helium-Code in Haskell-Code?
-
Cacheline schrieb:
Ist Scala wirklich so extrem effizient hinsichtlich Software-Entwicklung ?
Das im "Scala by example" abgedruckte Quicksort braucht über 20 Zeilen
Quelltext, das ist auch etwa die Größe der C-Version.In Haskell oder auch LISP kann man Quicksort ja in zwei bis fünf Zeilen
programmieren.object sort1 { def sort(a: List[Int]): List[Int] = { if (a.length < 2) a else { val pivot = a(a.length / 2); sort(a.filter(x => x < pivot)) ::: a.filter(x => x == pivot) ::: sort(a.filter(x => x > pivot)) } } def main(args: Array[String]) = { val xs = List(6, 2, 8, 5, 1); Console.println(xs); Console.println(sort(xs)) } }
Das sind 10 Zeilen für den Algorithmus. Außerdem kommt es nicht ausschließlich auf die Zeilenzahl an.
Beispielsweise sind Comprehensions in Scala länger, als in Haskell, allein schon, weil man das Wort 'for' schreiben muss. Aber es geht vielmehr darum, dass man Sie überhaupt einsetzen kann. Außerdem funktionieren sie in Haskell nur mit Listen, in Scala kann man beinahe jede Collection entsprechend ausrüsten (solange es sinn macht).
-
Sorry, ich will Scala ja nicht disqualifizieren, kenne das auch gar nicht.
Aber in Haskell kann man Quicksort in 3 Zeilen programmieren, s. "a Gentle Introdutction to Haskell 98".Was mir an Haskell auf den ersten Blick gut gefällt, ist, daß endlich mal Dinge syntaktisch so dargestellt werden können wie sie
in der Mathematik dargestellt werden (Mengennotation, Abbildungsnotation usw...)
und daß Haskell eine Standard-Sprache für FP sein will.Ich habe aber immer noch keine Antwort auf meine eigentliche Frage erhalten:
Wieso behaupten FP-Vertreter immer wieder, man könne mit Sprachen wie
Haskell 10-mal so effizient entwickeln, da die Sourcen 10-mal kürzer und damit
10-mal fehlerfreier würden, aber alle Welt in C/C++ programmiert ?
Wenn die Behauptung stimmte, wieso verschenken fast alle Software-Hersteller
dann 90% ihrer Resourcen an Entwicklungs- und Testzeit anstatt auf FP
umzusteigen ?
-
Vielleicht, weil es nicht annähernd so einfach ist ein Programm in einer funktionalen Sprache zu entwickeln?
-
Cacheline schrieb:
Sorry, ich will Scala ja nicht disqualifizieren, kenne das auch gar nicht.
Aber in Haskell kann man Quicksort in 3 Zeilen programmieren, s. "a Gentle Introdutction to Haskell 98".Ich kenne Haskell und ich weiß, dass die Notation extrem kurz ist. Dennoch sage ich, dass sich viele Dinge in Haskell nicht so einfach programmieren lassen, wie in der objektorientierten Programmierung (, die Scala perfekt beherscht).
Was mir an Haskell auf den ersten Blick gut gefällt, ist, daß endlich mal Dinge syntaktisch so dargestellt werden können wie sie in der Mathematik dargestellt werden (Mengennotation, Abbildungsnotation usw...) und daß Haskell eine Standard-Sprache für FP sein will.
Ein Mathematiker könnte sich jetzt auch beschweren, dass die Symbole der Mengenlehre hier für andere Dinge missbraucht werden, nähmlich Listen. Außerdem ist die genaue Syntax nicht ganz so entscheident:
Haskell:
[x * x | x <- y, x > 0]
Python:
[x * x for x in y if x > 0]
Scala:
for (val x <- y; x > 0) yield x * xIch habe aber immer noch keine Antwort auf meine eigentliche Frage erhalten:
Wieso behaupten FP-Vertreter immer wieder, man könne mit Sprachen wie
Haskell 10-mal so effizient entwickeln, da die Sourcen 10-mal kürzer und damit
10-mal fehlerfreier würden, aber alle Welt in C/C++ programmiert ?
Wenn die Behauptung stimmte, wieso verschenken fast alle Software-Hersteller
dann 90% ihrer Resourcen an Entwicklungs- und Testzeit anstatt auf FP
umzusteigen ?Weil es zu vielen Dingen einfach nicht passt. Wenn ich eine Checkbox in meinem GUI habe, dann hätte ich im Code auch gerne ein entsprechendes Objekt, dass diese Checkbox repräsentiert. Ich möchte diese Objekt befragen können, ob die Checkbox gesetzt ist oder nicht. Das ist für mich die intuitive Variante. Dazu muss sie aber ihren Zustand speichern.
In einer rein funktionalen Sprache, wie Haskell gibt es aber keinen Zustand. Etwas so alltägliches, wie ein einfaches GUI-Element lässt sich nicht auf intuitive Weise in der Sprache realisieren (zumindest kenne ich keinen Weg). Man kann dann mit Monaden rumbasteln, aber es wird nie so einfach werden, wie in einer gewöhnlichen objektorientierten Sprache.
Oder zeig mir mal einen rein funktonalen Hash, der auch eine entsprechende Geschwindigkeit aufzeigen kann.Funktionale Programmierung ist kein allheilmittel. Im Gegenteil. Für viele altägliche Dinge ist sie ganz eifnach ungeeignet.
(Natürlich ist genauso die imperative Programmierung für viele Dinge ungeeignet und die funktionale Programmierung hätte deutliche Vorteile.)
-
paedubucher schrieb:
Ich habe eine Zeit in Visual Basic 6 programmiert. Wer jetzt sagt, das sei nicht exotisch, der hat wohl noch nie die Syntax gesehen
Ausserdem gibt es in VB sehr abenteuerliche Auslegungen von Objektreferenzen:
Dim obj As New Object obj = Nothing 'Jetzt kommt es :-D if obj = Nothing 'Diese Zeile verursacht einen schönen Absturz ...
Für mich absolut unlogisch, stellt eine riesengrosse Einschränkung in der Sprache VB dar. In C/C++, C# und auch in JAVA kann man so wunderschön auf NULL-Referenzen prüfen, in VB geht das offenbar nicht...
Oder hat gleich jemand einen Tipp?
Wow, sowas von peinlich. Ein Absturz kommt bei mir, VB6, nicht.
Geht auch garnicht, in drei 3 Zeilen Code, 3 dicke Fehler, zwei
davon 2 Syntaxfehler die nicht mal ein VB-Anfänger machen würde
und ausserdem verhindern das daraus ein ablauffähiges Programm
entstehen KANN.
Das überzeugt mich zumindest das du von VB6 NULL Ahnung hast.In diesem Sinne hast du dich mit diesem Beitrag gründlich
blamiert.