Erfahrungen mit alternativen Script- oder Programmiersprachen

R

ralli

Guest
Es gibt auch Programmiersprachen abseits des Mainstreams, die durchaus interessant sind. Ich werfe mal hier scheme ins Rennen, eine vereinfachte Form der zweitältesten Programmersprache Lisp. Selbst kann ich noch über keine eigenen Erfahrungen berichten, das soll sich aber ändern. Unter OpenBSD habe ich scheme48 gefunden. Auch bin ich noch auf der Suche nach einem geeigneten Tutorial für scheme. Dann gibt es noch guil. Ob guil einen eigenen lisp oder scheme Interpreter an Bord hat, habe ich noch nicht rausgefunden. Wer abseits vom gängigen Mainstream auch mal was exotisches ausprobieren möchte, der kann ja hier über seine Erfahrungen berichten.
 
Der erste Lisp-Compiler wurde 1962 veröffentlicht. Das macht Lisp an sich zumindest in der Praxis zur, je nach Zählung, höchstens drittältesten heute noch genutzten Sprache (wobei das damalige Lisp mit den heutigen auch kaum noch etwas zu tun hat). :belehren:

Wer abseits vom gängigen Mainstream auch mal was exotisches ausprobieren möchte, der kann ja hier über seine Erfahrungen berichten.

Der "gängige Mainstream" ist natürlich immer definiert von dem, den du fragst. ;) Abseits von den üblichen Mehrheitssprachen Perl, Python, C (einschl. C++ und C#), Delphi[*] "und so" habe ich 2018 bislang folgende Sprachen ausprobiert oder gar rege genutzt:
  • Lisp: Bei der Entscheidung zwischen Lisp-1 (Scheme-Modell) und Lisp-2 (Common-Lisp-Modell) habe ich mich vor einigen Jahren auf zweiteres festgelegt. Scheme finde ich irgendwie merkwürdig, seine Syntax schwerer zu verstehen als Common Lisp und es ist gleichzeitig viel "kleiner", was den Sprachumfang angeht. Ich halte Common Lisp für die syntaktisch bessere Alternative zu Python und verwende es auch als eine solche.
  • Kotlin: Die Zukunft der Androidentwicklung - sofern Android nicht vorher von Fuchsia abgelöst wird, dessen Heimatsprache ja Googles Dart ist (ist doch noch Dart, oder?) - scheint funktional zu sein. Ich habe noch nicht besonders rege damit gearbeitet, aber gegenüber Java mache ich bereits jetzt eine wesentlich weniger geschwätzige Syntax aus. Gefällt mir sehr gut!
  • COBOL: Ja. Nein. Also vielleicht. Pro: Man versteht auch, was der Code macht, wenn man noch nie COBOL benutzt hat. Kontra: TCP und GUIs machen mit COBOL wirklich keinen Spaß. - Andererseits ist genau das die Herausforderung. Programmieren ohne Herausforderung ist langweilig. Und dieser Thread im GnuCOBOL-Forum reizt mich schon ziemlich, das noch ein bisschen weiter zu vertiefen. Und sei's nur, damit ich hinterher sagen kann: war lustig, mache ich aber nie wieder.
  • Rust: Die angeblich "bessere" Alternative zu C++ geht mir eigentlich nur furchtbar auf die Nerven. Nichts halbes, nichts ganzes. Viel Haskell, viele weggelassene Features (u.a. globale statische Variablen), kaum C. Das ist mir die "Sicherheit" nicht wert. Der Paketmanager Cargo ist aber super, so was hätte ich für C auch gerne: Einfach Abhängigkeiten in eine Art INI-Datei schreiben und der Rest passiert fast von allein.
  • Go: Man scheint in Go ziemlich gut Webanwendungen schreiben zu können, es ist merklich von C und Python inspiriert. Von letzterer Sprache hat es leider auch die Unsitte übernommen, dass es genau eine einzige gültige Codeformatierung gibt. Jede andere ist ein Syntaxfehler. Muss echt nicht sein. - Ansonsten gilt: Go ist C für Leute, die kein C können. Man kann mit ihm aber nur statisch linken, d.h. jedes Go-Programm ist vergleichsweise groß. Das war der wesentliche Grund für mich, ymarks in C statt Go zu schreiben. Dass Go außerdem schnell kompiliert: Sei's drum. Das tut Pascal auch seit Jahrzehnten.
  • x86 ASM: Wenn ich eines nicht leiden kann, dann ist es Software, die fett und lahm ist. Der Texteditor Visual Studio Code belegt im Leerlauf ein halbes Gigabyte RAM... :rolleyes: ich habe mir jedenfalls vorgenommen, dieses Jahr ein bisschen mit dem Windows-API herumzuspielen, und weil das in C zu wenig schmerzhaft ist, mache ich es stattdessen in Assembler. Seitdem sehe ich zwanzig Jahre älter aus und es dauert viel zu lange, aber das Ergebnis kann sich hinsichtlich der Geschwindigkeit und der Dateigröße sehen lassen. Und ich verstehe sogar etwas besser als in C, was das Windows-API eigentlich macht. :)
[*] Nein, Delphi halte ich nicht für exotisch.
 
@CrimsonKing warum hälst du Delphi für noch nicht für einen Exoten? Mir kommt da immer so vor wie wenn ich im Stadtpark über nen Dodo stolpere ... so selten ist Delphi in den letzten 10-15 Jahren geworden.
 
Das könnte daran liegen, dass die wenigsten Delphientwickler ihren Quellcode rausrücken. Gerade schon länger bestehende Windowssoftware wird selten mal in einer anderen Sprache neu entwickelt.
 
Ich verwende seit ewigkeiten Lua: einfacher Syntax, vergleichsweise schnell und kompakt. Entweder embedded in C oder standalone als Skriptsprache (als schlanke Alternative zu Python & Co). Ich habe immer wieder mit verschiedenen Lisp-Dialekten versucht warm zu werden, habe das aber inzwischen aufgegeben. Ich denke ich brauche einfach mehr visuelle Struktur. Früher habe ich gerne Forth benutzt aber das ist irgendwie auf der Strecke geblieben. Wunderbar zum basteln! Eine Weiterentwicklung davon ist Faktor. Aber dazu - wie für mach andere interessante Sprache - reicht einfach meine Zeit nicht.

Nach einer steilen Lernkurve und anfänglichen Schwierigkeiten verwende ich vor allem Rust obwohl ich mit dessen Lifetime Features immer noch auf dem Kriegsfuß stehe. Aber man kann das ggf. (durch unsafe) leicht umgehen was ich auch mache (shame on me!). Die Infrastruktur der Sprache ist einfach klasse: rustup zum einrichten und updates (einschließlich libs), cargo als Paketmanager mit automatischer Versionsverwaltung. Wer das kennen gelernt hat wird zu Makefiles & Co nur mit Bauchschmerzen zurückkehren. Ich jedenfalls nicht!

Es ist immer gut eine weiter Sprache zu erlernen da die jeweilige Sprache unser Denken vorstrukturiert. Ich verwende z.B. kein Lisp, habe aber mit der Beschäftigung damit einiges gelernt. Und vermutlich eine Menge davon wieder vergessen ... :-)
 
Die größten Projekte und Erfolge insbesondere in der Datenbankprogrammierung hatte ich mit Delphi. Habe hier noch ein Datenbankfrontend für Sqlite, Firebird und Postgresql mit Formulareditor für die Datenbanken . Auch für dBase hatte ich ein Datenbankfronend erstellt. Leider habe ich Lazarus unter FreeBSD nie ans Laufen gebracht. Im übrigen ist Delphi nur der Name der IDE, dahinter verbirgt sich ja Objektpascal, die eigentliche Programmiersprache. Zu Borlands Zeiten war das garantiert kein Exot und mit Lazarus gibt es ja eine Opensource IDE mit Freepascal.
 
Unter OpenBSD habe ich scheme48 gefunden.
Wenn dich Scheme interessiert wäre chicken-scheme eine portable, performante und ausgereifte alternative (RS-5/7) das zu C übersetzt wird. Schme48 ist m.W. nicht mehr aktuell, kann mich da aber irren. Das ist eines der Scheme-Probleme dass es einge ganze Reihe von durchaus unterschiedliche Implementationen und Standarts gibt die auch unterschiedlich gut gepflegt werden. Racket ist wohl auch weit verbreitet, hat eine IDE und ist gut zum lernen. Guile ist eine GNU-Impementation und ist als allgemeine Scripsprache für GNU-Projekte konzipiert. Hat wohl einige Eigenheiten und ich weiß nicht wie weit sie sich an Standarts halte. Eigentlich sollten (nahezu) alle Scheme Dialekte auch unter OpenBSD laufen da sie meist in C implementiert sind, nur dass du sie nicht im Packet Manger findest sondern selbst installieren mußt. Scheme ist nett, aber man muss sich umschauen und ausprobieren was zu einem paßt.
 
Fast hätte ich Erlang bzw. Elixier vergessen, die ich einige Jahre benutzt habe und womit ich viel Spass hatte. Elexier ist ein Dialekt der auf der Erlang-VM läuft und der den etwa antiquierten Erlang Syntax aufgebrezelt und erweitert hat was a.G. des Erlang Makrosystems möglich geworden ist.

Die Erlang-VM ist ausgereift und es stehen Features zur Verfügung die man so nirgendwo finded: "Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance. "

Damit ist aber auch beschrieben weshalb ich selbst es nicht mehr benutze: Die Erlang VM ist hinsichtlich Resourcenverbrauch und Runtime-Verhalten wohl mit der Java-VM zu vergleichbar. Was man dafür aber bekommt ist m.E. Java - und nicht nur dem! - haushoch überlegen. Anders gesagt: Das ist etwas für Profis die ein großes, sicheres, möglicherweise verteiltes und zur Laufzeit modifizierbarer Projekt angehen wollen, - oder eben für Liebhaber vom Computer-Sprachen wie mich. Dann weiß man nämlich was alles möglich ist! :-)

Mal ein schmackerl: In Smalltalk gibt es eine "become" Message mit der man der Typ eines Objektes zu Laufzeit ändern kann was auch in Erlang möglich ist. Das ist natürlich gefährlich und hat in einer Release-Version nichts zu suchen, ist aber für Prototyping und zum experementiern toll.
 
Elixir u.dgl. hatte ich ebenso wie Forth aufgrund bloßen Mangels an Einsatzzwecken bisher noch nicht auf dem Rechner, obwohl ich mich auch für einen Sprachnerd halte und Forthcode durchaus schon ein paarmal wenigstens gelesen habe, aber das hier sei noch kommentiert:

In Smalltalk gibt es eine "become" Message mit der man der Typ eines Objektes zu Laufzeit ändern kann was auch in Erlang möglich ist.

In Common Lisp kannst du das ganze Programm zur Laufzeit neu schreiben. :)
 
Ich persönlich finde es schade, dass Forth so nach und nach in der Versenkung verschwindet.

Wer früher mal nen HP Taschenrechner mit UPN schätzen und lieben gelernt hat ... dürfte Forth vermissen.

Für alle die es nicht mehr kennenlernten:
UPN steht für umgekehrte polnische Notation. D.h. der taschenrechner kommt ohne Klammern und ohne Gleichheitszeichen aus! Im Prinzip hat man einen Stack mit mehreren Registern und verknüpft mit der entertaste immer 2 dieser Register nach Eingabe eines operstionszeichens ... klingt kompliziert - ist aber absolut genial und vorallem schnell - auf jeden Fall hab ich auf dem HP41 immer schneller die ergebnisse gehabt - als Kommilitonen auf ihren Texas Instruments ;-)

... und es ist ein hervorragendes algebraisches Training;-)
 
Elixir u.dgl. hatte ich ebenso wie Forth aufgrund bloßen Mangels an Einsatzzwecken bisher noch nicht auf dem Rechner, ...
Schon klar, ich habe mir auch eine ganze Reihe Sprachen kurz angeschaut und dann nicht weiter verfolgt. Man muss ja jeweils einen besonderen Grund haben um sich eine Sprache näher anzuschauen denn es dauert doch eine ganze Weile bis man sich in Sprache, Libs und Tools eingearbeitet und zumindest 1-2 kleinerer Projekte realisiert hat um die Sprache halbwegs beurteilen zu können. Und mit universellen Sprachen wie C/C++/Rust (meinetwegen auch ein Lisp) sowie einer Scriptsprache kommt man vermutlich bei 98% aller Projekte gut zurecht. Der Rest ist entweder ein besonderes Interesse oder eben ein recht spezieller Einsatzzweck. Und so bleibt man halt bei dem Bekannten...

Was ich bei Erlang gelernt habe ist wie robuste und fehlertolerante Applikationen strukturiert sein müssen. Da muss man in universellen Sprachen schon einige Klimmzüge machen um das hinzubekommen, - wenn überhaupt ! Und wenn man derartiges z.B. in C++/Rust realisieren will verschwindet der Laufzeitvorteil recht schnell...
 
Ich persönlich finde es schade, dass Forth so nach und nach in der Versenkung verschwindet.
Yep, aber man sollte auch die Nachteile nicht übersehen: Das ist weniger die UPN, daran gewöhnt man sich schnell, sondern die extreme Modularisierung da Funktionsaufrufe ja nahezu nichts kosten. Hinzu kommt eine z.T. abenteuerliche Namensgebung und fehlende Standartisierung. Ich glaube im embedded Bereich wird es noch benutzt.

Nett ist es auch einen Forth-Interpreter zu schreiben. Ich habe das früher mal in C gemacht und weiß von einem der das in Lua gemacht hat. Na ja, - just fun! :-)
 
Wenn dich Scheme interessiert wäre chicken-scheme eine portable, performante und ausgereifte alternative (RS-5/7) das zu C übersetzt wird. Schme48 ist m.W. nicht mehr aktuell, kann mich da aber irren. Das ist eines der Scheme-Probleme dass es einge ganze Reihe von durchaus unterschiedliche Implementationen und Standarts gibt die auch unterschiedlich gut gepflegt werden.
Danke, das werde ich mir mal anschauen. Scheme48 ist in der Tat nicht mehr aktuell, die Homepage sieht verwaist aus und die Dokumentation mit Beispielen für den Einstieg meineserachtens spärlich.
 
  • Go: Man scheint in Go ziemlich gut Webanwendungen schreiben zu können, es ist merklich von C und Python inspiriert. Von letzterer Sprache hat es leider auch die Unsitte übernommen, dass es genau eine einzige gültige Codeformatierung gibt. Jede andere ist ein Syntaxfehler. Muss echt nicht sein. - Ansonsten gilt: Go ist C für Leute, die kein C können. Man kann mit ihm aber nur statisch linken, d.h. jedes Go-Programm ist vergleichsweise groß. Das war der wesentliche Grund für mich, ymarks in C statt Go zu schreiben. Dass Go außerdem schnell kompiliert: Sei's drum. Das tut Pascal auch seit Jahrzehnten.
Webanwendungen? Sowas wie Ruby on Rails ist eher verpönt in der Community, wg. Magie und so. Heißt nicht, dass es nicht trotzdem gemacht wird. Oder meintest du eher Backend/"API" Server. Dann stimmt's. Ich nehme an das meintest du? Oder hast du generell Netzwerkanwendungen gemeint?

Das mit der Codeformatierung stimmt so nicht. Es gibt go fmt, aber das zu nutzen ist nicht Pflicht. Bin mir aber nicht sicher, was du meinst, weil die Python erwähnt hast. Übrigens werden Python und Go finde ich etwas zu oft verglichen. Den einzigen gemeinsamen Nenner, denn ich da sehe (außer der Verwendung von Arrays) ist dass man die Sprache möglichst simpel halten will, wobei Python finde ich vielleicht simpel im Vergleich zu Perl, Ruby und JavaScript ist, aber Python glaube ich selbst nicht gerade eine simple Sprache ist. Oder anders gesagt, bei den Vergleichen mit Python müsste fast nahezu alles was nicht wie Python ist wie C oder LISP sein. Ist kein Weltuntergang, aber ein paar syntaktische Ähnlichkeiten und dass man den Weg einer simplen Sprache geht macht das nicht zu sonderlich ähnlichen Sprachen. In anderen Bereichen (Concurrency, OO, Type System, Umgang mit Fehlern, etc.) gibt es teils recht große Unterschiede.

C für Leute, die kein C können trifft's wohl eher. Ist ja auch von den selben Entwicklern.

Go hat ein wenig den Vorteil, dass es schwierig ist zu groben Unfug zu machen, ohne dabei vielleicht so viel zu bremsen wie sagen wir Java.

Eine Sprache, die wie ich finde immer zu kurz kommt ist D. Als jemand der D gelernt, damit eine Weile experimentiert hat, aber selbst nicht verwendet würde ich sagen, dass das vielleicht die Sprache ist um die es wirklich schade ist, dass da nicht Google oder andere dahinter stehen. Wobei die ja bei Facebook (oder war's Netflix?) angeblich ein wenig Beliebtheit erfahren hat.

Wie dem auch sei. D hat viele von den guten Eigenschaften von Rust was wohl damit zusammen hängt, dass beide C++ ersetzen wollten. Was für viele Leute sicher sehr nett ist, ist dass man mit D deutlich weniger Verwirrung abbekommt. Rust hat ein paar neue Konzepte und sich sehr viel von funktionalen Sprachen abgeschaut. Es ist sehr strikt und hat eine hohe Lernkurve. D ist etwas flexibler und geht mehr in eine Richtung, wo du dir aussuchen kannst wie wichtig dir bestimmte Garantien im Einzelfall sind. Du kannst Funktionen entsprechend dieser Eigenschaften mittels Keyword "markieren".

Was ich an D als ich damit ein wenig experimentiert habe waren diese kleinen "Nettigkeiten", die Dinge einfacher machen, ohne jetzt gleich in Richtung Skriptsprache zu gehen. Das sind so Dinge, die bei vielen anderen Sprachen, aber vor allem bei sowas wo man C++ oder Java nutzen würde nervend sind. Die Sprache hat ironischerweise gerade wegen Rust, welche in die selbe Richtung geht gerade ein wenig Aufwind. Das ist vielleicht die Sprache, die man wirklich mit Rust vergleichen sollte, nicht Go, welches sehr anders ist und nur zu einer ähnlichen Zeit populär wurde. Jedenfalls schauen sich die beiden Communities vieles voneinander ab.

Die Community ist nicht groß, aber größer als man meist annimmt. Ein großer Vorteil gegenüber anderen neuen Sprachen ist, dass sie schon etwas mehr Zeit zum heranreifen hatte. Am Anfang hatte sie außerdem einen schweren Start, weil da ein Unternehmen mit eigenen Interessen dahinter steht (eigentlich nichts schlimmes, aber Leute haben halt ein gesundes Maß an Skepsis wenn eine Sprache stark an ein Unternehmen gebunden ist - vor allem wenn die Sprache ein Produkt und nicht einfach ein (Seiten-)Projekt ist). Diverse Entwicklungen haben allerdings dafür gesorgt, dass es diese starke Bindung nicht mehr gibt.

Ich möchte jetzt keine einzelnen Features herausgreifen, aber wenn man mit Anwendungsfällen konfrontiert ist wo man vielleicht Java oder C++ nutzen würde, man damit nicht glücklich ist und einem auch Rust nicht bekommt, oder wenn einem Rust und Co. einfach zu neumodisch oder jung sind, dann ist D sicherlich einen Blick wert.
 
Oder meintest du eher Backend/"API" Server. Dann stimmt's. Ich nehme an das meintest du? Oder hast du generell Netzwerkanwendungen gemeint?

Ein bisschen von beidem. Frontendentwicklung scheint damit auch "ganz gut" zu funktionieren, aber bei mir scheitert es da immer noch an der Sympathie für die Syntax, fürchte ich.

Das mit der Codeformatierung stimmt so nicht.

Doch, natürlich stimmt das. Go hat diese Unsitte eines "impliziten Semikolons". Geschweifte Klammern in einer neuen Zeile machen also exakt nicht das, was du glaubst:

Code:
if (true)
{
    // Syntaxfehler! Aaaaargh!
}

Das halte ich für bevormundend und ziemlich pythonesque. Python neigt ja auch dazu, dem Benutzer Formatierung aufzuzwingen. Ich bin da C-verwöhnt.

Oder anders gesagt, bei den Vergleichen mit Python müsste fast nahezu alles was nicht wie Python ist wie C oder LISP sein.

Python ist angeblich von Lisp inspiriert, die meisten anderen Sprachen hängen aber am großen ALGOL-Zweig, Go eingeschlossen. Go macht - anders als C - auch das mit dem Unterschied zwischen ":=" und "=" richtig... das ist tatsächlich etwas, was ich Go positiv anrechnen kann.

C für Leute, die kein C können trifft's wohl eher. Ist ja auch von den selben Entwicklern.

C wurde von Dennis Ritchie "entworfen". (Also so lange "optimiert", bis die ressourcenmäßig beschränkte PDP-7 es kompilieren konnte.)

Go wurde von Robert Griesemer, Rob Pike und Ken Thompson entworfen. Robert Griesemer hatte man vorher überhaupt nicht wahrgenommen, er war wohl eher im JavaScript-Umfeld (Googles V8-Engine) aktiv; Rob Pike ist für manches (darunter auch diverse Sprachen) verantwortlich, aber C gehört nicht dazu; Ken Thompson war unter den ersten C-Entwicklern, aber erfunden hat er "nur" dessen Vorgänger B.

Go hat ein wenig den Vorteil, dass es schwierig ist zu groben Unfug zu machen, ohne dabei vielleicht so viel zu bremsen wie sagen wir Java.

In Java kann man eine Menge groben Unfug machen. :D

Eine Sprache, die wie ich finde immer zu kurz kommt ist D.

Das liegt aber auch daran, dass es gegenüber C++ (in dessen aktuellen Standards) nicht übermäßig viele Vorteile aufweist. Zudem ist seine Community eher klein. Da steckt halt kein riesiges Marketingbudget mit einem alltäglichen Anwendungsfall (Rust: Mozilla mit Firefox) drin. D schwirrt dieser Tage auch ab und zu wieder an mir vorbei, aber immer, wenn ich es mir eine Weile ansehe, fällt mir auf, dass ich alles, was es anzubieten hat, auch anderswo bekomme. Andererseits gefällt es mir persönlich immer noch um Längen besser als das erfolgreichere Äquivalent...

Vielleicht nächstes Jahr. ;) Dieses Jahr kriege ich beim besten Willen in meinen TODOs kein völlig neues Projekt mehr unter.

aber Leute haben halt ein gesundes Maß an Skepsis wenn eine Sprache stark an ein Unternehmen gebunden ist

Zu viele Leute benutzen Go (Google), Rust (Mozilla Corporation), C# (Microsoft) und Java ('orrible) ohne jede Skepsis.
 
Es gibt auch Programmiersprachen abseits des Mainstreams, die durchaus interessant sind. Ich werfe mal hier scheme ins Rennen, eine vereinfachte Form der zweitältesten Programmersprache Lisp. Selbst kann ich noch über keine eigenen Erfahrungen berichten, das soll sich aber ändern. Unter OpenBSD habe ich scheme48 gefunden. Auch bin ich noch auf der Suche nach einem geeigneten Tutorial für scheme. Dann gibt es noch guil. Ob guil einen eigenen lisp oder scheme Interpreter an Bord hat, habe ich noch nicht rausgefunden. Wer abseits vom gängigen Mainstream auch mal was exotisches ausprobieren möchte, der kann ja hier über seine Erfahrungen berichten.

Ich nutze unter OpenBSD "Common Lisp" (mit emacs, slime und sbcl) _und_ Racket.

Unter OpenBSD kannst Du Racket wie folgt installieren:

Code:
$ doas pkg_add racket-minimal
$ raco pkg install --jobs $(sysctl -n hw.ncpu) --auto main-distribution
$ $HOME/.racket/VERSION/bin/drracket

Mehr Infos findest Du auch in der entsprechenden racket-minimal pkg_readme:

https://cvsweb.openbsd.org/cgi-bin/...ME?rev=1.11&content-type=text/x-cvsweb-markup

Dann wuerde ich als naechstes mit SICP unter Racket anfangen:

Das komplette MIT-Standardwerk gibt es inzwischen kostenlos im Internet:

https://mitpress.mit.edu/sites/default/files/sicp/index.html

Weitere Infos, um die SICP collections ueber den Racket package manager zu installieren:

https://docs.racket-lang.org/sicp-manual/index.html
 
Zuletzt bearbeitet:
Racket ist mit auf jeden Fall ein guter Tipp, wenn es in Richtung Lisp/Scheme gehen soll. Wobei man sagen muss, Racket weist einige Unterschiede zu Scheme auf (in Racket sind Listen z.B. standardmäßig unveränderbar).

Dennoch dürfte Racket das Scheme sein, welches den einfachsten Einstieg ermöglicht. Denn es ist eine recht brauchbare IDE dabei und es gibt zu vielen Sachen schon Bibliotheken (batteries included, wie man es bei Python nennt g) sowie umfangreiche Dokumentationen.

Racket ist aber auch ein Framework zum erstellen neuer Sprachen und davon wird durchaus rege Gebrauch gemacht. Zum Beispiel durch die Dokumentationssprache Scribble.
Das ermöglicht aber auch Standard-Scheme-Programme direkt laufen zu lassen oder einzubinden.

Derzeit wird auch aktiv daran gearbeitet als Laufzeitumgebung Chez-Scheme anzubieten, was dann evtl. auch noch mal einen Geschwindigkeitsvorteil bringt, wenngleich auch schon jetzt Racket dank JIT und der Möglichkeit typed-code zu erstellen relativ schnell ist.

Ich selbst nutze Racket jetzt schon mehrere Jahre für alles Mögliche. Angefangen von Skripts bishin zu GUI-Programme und Web-Programmierung. Es deckt all diese Bereiche für mich hinreichend gut ab, so dass ich keine Notwendigkeit habe dafür auf eine besser geeignete Sprache zurückgreifen zu müssen. Gerade im Web hast Du ne relativ natürliche Art, HTML auszudrücken. Nämlich via normaler S-Expressions.
Statt: <p class="abschnitt">Hello</p>
eben: (p ((class abschnitt)) Hello)

Chicken Scheme ist aber auch ein sehr interessanter Vertreter (wurde ja hier im Thread ebenfalls genannt. Ist, soweit ich weiß, sogar in deutscher Hand. :-)
Du hast auch eine aktive Community. Und das es nach C kompiliert macht natürlich auch die Interaktion mit C sehr einfach, was gut ist, wenn man Drittbiliotheken die nicht in Scheme geschrieben sind benutzen will.
Kurzum: Chicken ist gut in Projekten in denen nicht ausschließlich Scheme benutzt wird.

Common Lisp ist mit Sicherheit das ausgereifteste Lisp. Das gibt es halt auch schon sehr lange und es gibt auch etliche Compiler dazu (sowohl frei als auch kommerziell). Common Lisp hat auch einen sehr dynamischen Charakter. Man arbeitet in einem lebenden System (vergleichbar zu Smalltalk ).
Es dürfte auch mit CLOS und MOP die von den Möglichkeiten her umfangreichste Implementierung von OOP haben.

Allerdings merkt man das Common Lisp das Alter an vielen Stellen auch an. Während Scheme deutlich in die funktionale Richtung geht ist Common Lisp eher imparativ gefärbt.
 
Ich nutze unter OpenBSD "Common Lisp" (mit emacs, slime und sbcl) _und_ Racket.

Unter OpenBSD kannst Du Racket wie folgt installieren:
Danke @midnight , hab mich für Racket entschieden, sieht gut aus. Für DrRacket habe ich einen Starter auf dem Mate Desktop angelegt. Dann habe ich mit Hilfe des Paketmanagers SICP installiert, die Sprache läßt sich aber nicht auswählen als Standard. Offensichtlich kann man auch GUI Progs mit Racket erstellen, oder irre ich mich?. Bei mir wurde racet ins Homeverzeichnis isnstallert:

Code:
.racket/6.12

Jetzt werde ich es mal weiter erforschen, zur Zeit ist als Sprache Racket eingestellt, SICP findet er nicht.
 
Scheme ist älter als Common Lisp. :)
Hat auch keiner das Gegenteil behauptet. Aber zugegebenermaßen etwas missverständlich ausgedrückt.

Denn man muss auch mal gucken, wo Common Lisp her kommt. Es ist ja quasi die Standardisierung der bis dahin verfügbaren Lisp-Dialekte. Daher auch common. Während Scheme mehr oder weniger auf der grünen Wiese entstand.
Zudem ist der Common Lisp Standard auch schon ein paar Jahre alt, während der aktuelle Revisited-Report noch gar nicht sooo alt ist.

Aber die Aussage stimmt so auch nicht - Common Lisp ist eine Multiparadigmensprache.
Ich sprach auf von imperativ gefärbt und nicht das es eine solche Sprache ist.

Denn wenn Du so willst ist Scheme auch eine Multiparadigmen-Sprache. Allerdings gibt es schon einen gewissen Schwerpunkt auf funktionale Programmierung.
 
zur Zeit ist als Sprache Racket eingestellt, SICP findet er nicht.
Du musst das SICP-Package mit dem Package-Manager installieren (also entweder via DrRacket oder über die Kommandozeile mit raco pkg install sicp).
Danach kannst Du Dein Quelltext mit
Code:
#lang sicp
beginnen und den Code aus dem Buch schreiben.
 
Als Ergänzung:
  • Fortran: älteste Hochsprache; sehr einfach zu erlernen. Hat dieses Jahr wieder ein Update bekommen (Fortran 2018). Eignet sich nicht nur für HPC und numerische Berechnung. Dank ISO C Binding lässt sich C-Code problemlos einbinden.
  • KornShell 93: nicht nur Shell, sondern auch tolle Programmiersprache (Assoziative Arrays! Float! OOP!).
 
Etwas OT: Jetzt habe ich mir Racket aufgrund dieser Diskussion doch mal wieder angesehen und der vorhandene Sprachstandard löst ein Problem, das ich in einem (allerdings zum Glück noch sehr wenig implementierten) Projekt in Common Lisp seit Monaten vor mir herschiebe. Ich werde es neu schreiben. :) Insofern danke!
 
Du musst das SICP-Package mit dem Package-Manager installieren (also entweder via DrRacket oder über die Kommandozeile mit raco pkg install sicp).
Danach kannst Du Dein Quelltext mit
Code:
#lang sicp
beginnen und den Code aus dem Buch schreiben.
Danke @Andy_m4, nachdem ich es mit raco aus der Konsole installieren wollte, sagte er mir, das das Paket sicp bereits installiert ist. Das wunderte mich insofern, weil ich dachte, das ich das in DrRacket - Sprache ändern müsse, es aber nicht angezeigt wurde. Mittlerweile funktioniert es, danke für die Unterstützung.:)
 
Zurück
Oben