Erfahrungen mit Racket

Fair oder nicht - es zählt auch, was am Ende beim Anwender rauskommt. Ich meine, viele Anwender sind 2018 ja durchaus damit zufrieden, dass eine poplige Bananenanwendung ein Gigabyte Plattenplatz für zwei, drei bunte Knöpfe braucht, aber ich bin's nicht. Meine Common-Lisp-Scripts kompiliere ich in der Regel gar nicht, sondern nehme lieber den Umweg über den Interpreter in Kauf, weil ich es überhaupt nicht einsehe, dass ich so viel Extraplatz dafür hergeben soll. :rolleyes:

Racket ist eine relativ statische Sprache. Das heißt, Du kannst viel genauer analysieren und Annahmen darüber treffen, was gebraucht wird und entsprechend den Rest weglassen.

Das heißt, Racketprogramme kann man nicht zur Laufzeit umprogrammieren?

(Arbeitest du eigentlich für PLT o.vglb.? Ich wundere mich gerade über dein Auftauchen im Forum kurz nach der Eröffnung des "Scriptsprachen"-Threads und deine sehr themenfokussierten Beiträge.)
 
Wo liegt das Binary genau? Eventuell liegt es an dem Schutz w^x.
In meinem Homeverzeichnis im Ordner racket/arbeit.

Schau mal nach, ob du eine Partition mit wxallowed gemountet hast und kopiere das Binary mal dorthin, dann ausführen.

Ja es ist folgende Partition:

Code:
6b98cc1eebbd98f1.h /usr/local ffs rw,wxallowed,nodev 1 2

habe das Binary dort hin kopiert und aus der Konsole gestartet:

Code:
No protocol specified
Gtk initialization failed for display ":0"
  context...:
   #%embedded:g3116:queue: [running body]
   #%embedded:g3019:init: [traversing imports]
   #%embedded:g2998:platform: [traversing imports]
   #%embedded:g2993:platform: [running body]
   #%embedded:g2972:kernel: [traversing imports]
   #%embedded:g2196:mred: [traversing imports]
   #%embedded:g2175:mred: [traversing imports]
   #%embedded:g2154:main: [traversing imports]
   #%embedded:g2133:base: [traversing imports]
   #%embedded:g125:gui: [traversing imports]
   #%mzc:probeform: [traversing imports]
   loop

Gtk2 und gtk3 sind installiert, gdk-pixbuf ebenfalls. Jetzt weiß ich auch nicht mehr weiter.
Mit einem einfachen Konsolenprogramm dasselbe Theater, es läuft nicht, obwohl es keine GUI ist und deshalb auch keine gtk Bibliotheken benötigt. Danke @KobRheTilla für Deine Unterstützung, aber es ist halt OpenBSD und interpretiert laufen die Progs/Scripte ja.
 
Fair oder nicht - es zählt auch, was am Ende beim Anwender rauskommt. Ich meine, viele Anwender sind 2018 ja durchaus damit zufrieden, dass eine poplige Bananenanwendung ein Gigabyte Plattenplatz für zwei, drei bunte Knöpfe braucht, aber ich bin's nicht. Meine Common-Lisp-Scripts kompiliere ich in der Regel gar nicht, sondern nehme lieber den Umweg über den Interpreter in Kauf, weil ich es überhaupt nicht einsehe, dass ich so viel Extraplatz dafür hergeben soll. :rolleyes:

Ganz genau so sehe ich das auch. Auch wenn Speicherplatz relativ billig geworden ist zu früher, muß damit nicht geaast werden.
 
Meine Common-Lisp-Scripts kompiliere ich in der Regel gar nicht, sondern nehme lieber den Umweg über den Interpreter in Kauf, weil ich es überhaupt nicht einsehe, dass ich so viel Extraplatz dafür hergeben soll. :rolleyes:
Kann ich verstehen. Ich erstelle auch nur eher selten Standalone-Executables. Also wirklich nur für Fälle, wo es halt kein passendes Laufzeitsystem auf der Zielmaschine gibt.

Fair oder nicht - es zählt auch, was am Ende beim Anwender rauskommt.
Ja. Wobei ich jetzt adhoc nicht weiß, ob sich da SBCL noch optimieren lässt. Wie gesagt. Ich erzeuge nur selten Standalone-Executables. Zumindest beim erzeugten Code kann man ja durchaus optimieren for space oder for speed.
Möglicherweise bieten andere Common Lisp Compiler auch da bessere Möglichkeiten an.

Das heißt, Racketprogramme kann man nicht zur Laufzeit umprogrammieren?
Doch. Kann man.

Dennoch ist unter Common Lisp eine andere Arbeitsweise üblich. Da bist Du in Deiner interaktiven Lisp-Umgebung und erstellst darin das Programm. Kannst Veränderungen vornehmen während das Programm läuft usw.
Das kannst Du in Racket auch machen. Aber üblich ist es, dass man wie in anderen Sprachen (C, Java, Whatever) sein Programm schreibt, kompiliert und ausführt. Dann wird halt ne Änderung vorgenommen. Wieder läuft der Compiler und man startet wieder das Programm von Neuem.

Das Verhalten von Common Lisp kann man aber auch auf Racket anwenden. Zwar nicht exakt, aber vergleichbar. Davon mache ich in einigen Programmen auch mehr oder weniger intensiven Gebrauch.

Arbeitest du eigentlich für PLT
Nein. Allerdings bin ich jetzt schon einige Zeit dabei.

Ich wundere mich gerade über dein Auftauchen im Forum kurz nach der Eröffnung des Scriptsprachen-Threads und deine sehr themenfokussierten Beiträge
Ja. Bisher war ich auch nur Beobachter in meiner Eigenschaft als FreeBSD-Nutzer und OpenBSD und NetBSD Interessierter.

Das Racket dann hier im Forum auftauchte, gab mir dann den nötigen Ruck mich doch mal anzumelden. :-)

Vor allem, weil ich bisher immer davon ausgegangen war außerhalb des universitären Bereichs der einzige Racket-Programmierer in Deutschland zu sein (überspitzt gesagt).

Und war dann doch einigermaßen überrascht im Forum eines Randgruppen-Systems dann auch noch auf eine Randgruppen-Programmiersprache zu treffen. :-)
 
Wobei ich jetzt adhoc nicht weiß, ob sich da SBCL noch optimieren lässt.

Bedingt. Wie schon angemerkt: Es ist möglich (unter Windows aber standardmäßig nicht der Fall), SBCL mit der zlib zu linken und die Images entsprechend zu komprimieren (siehe Handbuch). So weit ich das begriffen habe, wird das aber auch keine Wunder wirken, mehr als ein paar Prozent kommen da nicht raus.

Bei Common Lisp haben, so weit ich mich erinnere, ausschließlich die für uns, die wir kein Geld damit verdienen, viel zu wenig preiswerten LispWorks und Allegro CL einen Tree-Shaker eingebaut, der alles aus dem Image wirft, was nicht gebraucht wird. Eine Alternative in SBCL war mal aus der Community in Planung, hat aber nie so recht funktioniert und wurde schlussendlich auch nicht integriert.

Doch. Kann man. (...) Aber üblich ist es, dass man wie in anderen Sprachen (C, Java, Whatever) sein Programm schreibt, kompiliert und ausführt. Dann wird halt ne Änderung vorgenommen. Wieder läuft der Compiler und man startet wieder das Programm von Neuem.

Ah, danke für die Erklärung. Ich dachte, da geht nur "entweder - oder". :)

Das Racket dann hier im Forum auftauchte, gab mir dann den nötigen Ruck mich doch mal anzumelden. :-) (...) Und war dann doch einigermaßen überrascht im Forum eines Randgruppen-Systems dann auch noch auf eine Randgruppen-Programmiersprache zu treffen. :-)

Du wirst überrascht sein, was hier manchmal für Software im Einsatz ist... :ugly:
Dann mal willkommen.
 
Drei, sobald ich zu Hause bin ... :D
Ich bin wirklich ziemlich angetan von dem, was ich da so sehe.
 
Und war dann doch einigermaßen überrascht im Forum eines Randgruppen-Systems dann auch noch auf eine Randgruppen-Programmiersprache zu treffen.
Diese Randgruppen-Programmiersprache gefällt mir außerordentlich gut. Und so richtig verstehe ich nicht, warum Racket als solche gehandelt wird. Die klare Syntax und gute Dokumentation finde ich schon erwähnenswert.
 
Ich habe inzwischen aufgegeben, Menschen fuer Racket begeistern zu wollen. Wer mit seiner gelernten und genutzten Programmiersprache zufrieden ist, wird nicht wechseln. Da ist leider jede Diskussion sinnlos. Wer auf der Suche ist, stolpert frueher oder spaeter von selbst ueber Lisp und seine Dialekte. Nur die wenigsten Menschen werden ``erleuchtet'' und erkennen bzw. erfahren die Schoenheit und Eleganz von Lisp. Fuer alle anderen sieht Lisp nur komisch aus mit den ganzen Klammern. Ich habe ausserdem selten eine so freundliche und hilfsbereite community wie die Lisp community getroffen.
 
So weit ich das begriffen habe, wird das aber auch keine Wunder wirken, mehr als ein paar Prozent kommen da nicht raus.
Ja. Ich wird spontan vermuten, dass da auch kein wirklich großer Vorteil bei rausspringt, auch wenn es sicherlich von Anwendung zu Anwendung durchaus variieren kann.

Tree-Shaker eingebaut
Das klingt interessant. Stimmt.

Eine Alternative in SBCL war mal aus der Community in Planung, hat aber nie so recht funktioniert und wurde schlussendlich auch nicht integriert.
Bei solchen Features muss man eben auch immer gucken, ob man die wirklich braucht. Und wenn die eben nicht wichtig genug sind, dann bleiben solche Sachen halt liegen. Gibt ja genug Projekte denen da sicherlich ne höhere Priorität beigemessen wird.

Ah, danke für die Erklärung. Ich dachte, da geht nur entweder - oder. :)
Irgendwie geht immer alles. Der IBM-Java-Compiler der bei der Java-IDE Eclipse zum Einsatz kam (noch kommt?) beherrscht ja auch Hot-Code-Replacement, was ja ebenfalls in die Richtung am laufenden Programm Änderungen vornehm ging.
Inzwischen hat sowas auch wohl Einzug in die offizielle Java-VM gefunden.
Dennoch ist auch hier der bevorzugte Weg Edit-Compile-Run.

Ich bin wirklich ziemlich angetan von dem, was ich da so sehe.
Oh-ha. Das jemand von Common Lisp zu Scheme bzw. Racket wechselt (vor allem in so kurzer Zeit) kommt auch nicht so häufig vor. :-)

Theoretisch könnte man sich ja auch ein Frontend für Common Lisp basteln um Common-Lisp-Programme unter Racket direkt laufen zu lassen. Die Idee ist naheliegend, allerdings ist mir bisher noch kein solches Projekt begegnet.
Das Einzige, was einer mal gemacht hat ist das Loop-Makro nach Racket portiert.

Dann mal willkommen.
Danke.
Gibts da noch irgendwelche abstrusen Rituale die Neulinge durchleben müssen? :zitter:
 
Bei solchen Features muss man eben auch immer gucken, ob man die wirklich braucht.

Gerade die großen "Business-Lisps" (eben LispWorks und Allegro CL) werden ja vor allem von Unternehmen genutzt, die die entwickelte Software gern verscherbeln würden. Und wenn ich Software kaufe, dann kaufe ich doch lieber die, für die ich nur ein Zehntel der Größe runterladen muss... :)

Ich würde da doch schon eine gewisse Notwendigkeit sehen.

Der IBM-Java-Compiler der bei der Java-IDE Eclipse zum Einsatz kam (noch kommt?) beherrscht ja auch Hot-Code-Replacement

Der Vergleich zwischen Lisp und Java ist ein Vergleich voller Missverständnisse. ;)

Oh-ha. Das jemand von Common Lisp zu Scheme bzw. Racket wechselt (vor allem in so kurzer Zeit) kommt auch nicht so häufig vor. :-)

"Wechseln" ist das falsche Wort. Ich gucke mir Racket für ein bestimmtes Projekt mal etwas genauer an und wenn es nichts wird, dann wird es halt nichts. Was ich an Common Lisp habe, ist mir schon bewusst (die Syntax von LOOP zählt übrigens nicht dazu :D), und selbst, wenn ich irgendwann Racket halbwegs so "gut" schreiben und lesen kann wie Common Lisp, bezweifle ich, dass ich meine vorhandenen Anwendungen noch mal neu schreibe. Und für manches ist das CL-"Ökosystem" einfach hervorragend.

Gibts da noch irgendwelche abstrusen Rituale die Neulinge durchleben müssen? :zitter:

Also meine Kontodaten sind ...
 
Diese Randgruppen-Programmiersprache gefällt mir außerordentlich gut. Und so richtig verstehe ich nicht, warum Racket als solche gehandelt wird.
Naja. Speziell hier in Europa hatte Lisp eh nie den Stand den es jenseits des großen Teiches hatte.
Wenn Du heute mit einer neuen Sprache anfängst oder eine Alte wiederbeleben willst, dann muss die signifikante Vorteile gegenüber dem haben, was bereits da ist.
Vieles was Lisp einstmals auszeichnet ist aber inzwischen in den Mainstream gewandert.
Weiterhin steht auch keine Marketing-Maschinerie hinter Racket oder Lisp im Allgemeinen.
Und auch keine Firma die da ordentlich investiert. Solche Sprachen wie Go sind deshalb erfolgreich, weil eben Google dahinter steht und die Entwicklung vorantreibt. Hast Du sowas nicht, brauchst Du zumindest eine einigermaßen große Community.
Ohne kritische Masse wirds für eine Sprache schwer. Ein gutes Beispiel ist das hier schon diskutierte D.

Was Du dann brauchst ist ein Ökosystem. Eine Sprache allein nützt Dir nicht viel. Was heute verlangt wird, sind Tools, Bibliotheken/Frameworks. Dokus.
Man kann sagen, dass Racket da gar nicht so schlecht aufgestellt ist.
Man muss aber auch zugeben, dass andere Sprachen da deutlich besser sind, um hier mal exemplarisch Python zu nennen.

Von der Sprache her ist Python
Common Lisp oder Racket unterlegen. Aber es gibt halt für jeden Sch**ß eine Bibliothek, wo Du Dir dann mit wenig Aufwand Deine Lösung bauen kannst. Und solche Sachen sind halt Dinge, die heutzutage zählen.
Das Du ne elegante Lösung gefunden hast interessiert dagegen (außerhalb gewisser Programmiererkreise) keine Sau.
Das muss man einfach zur Kenntnis nehmen und so akzeptieren.
Und letztlich für sich gucken, was man denn selbst denn will.

Ich mach ja nu schon ein paar Jährchen Racket und mir ist auch bewusst, dass ich mir damit Nachteile einhandle. Aber ich nehme das in Kauf, weil es mich immer sehr genervt hat, wenn die Sprache mir irgendwelche Grenzen gesetzt hat.

Die klare Syntax und gute Dokumentation finde ich schon erwähnenswert.
Die meisten würden sagen, die Syntax ist gerade das, was abschreckt. :-)
Natürlich hast Du recht. Die Syntax ist super einfach und hat auch viele Vorteile. Ist auch alles sehr homogen.

Die meisten "wollen" aber offenbar eine komplizierte Syntax. Oder sagen wir besser: Sie sind es so gewohnt. Und auch das ist sehr wichtig bei einer Sprache. Darum findest Du ja auch in vielen Sprachen diesen C-Stil. Den kennen die Leute. Der wird eher akzeptiert als irgendwas "Exotisches".

Das ist ein ganz wichtiger Erfolgsfaktor. Also das man durchaus sich auch mal für etwas Schlechtes entscheiden müsste, wo man aber weiß, das das die Leute kennen.

Dann sind wir jetzt schon zwei.
Ja. Ganz so dramatisch ist es nicht. Ich weiß, dass Racket in der Universität Tübingen in der Lehre eingesetzt wird. Dann noch in Hamburg, glaube ich. Und dann gibt es noch eine Uni. Habs nicht mehr genau im Kopf.

Finde ich als Lehrsprache auch ganz prima (gut, wurde ja auch dafür gemacht).

Ich weiß auch nicht, wer auf die glorreiche Idee gekommen ist, dass Java Lehrsprache an Hochschulen sein sollte. Java ist als Lehrsprache in meinen Augen völlig ungeeignet.
Gut. War sicherlich auf dem Zeitgeist der 90er Jahre geschuldet, als es ja nicht nur einen gewissen Hype um Java gab, sondern auch die Bestrebungen anfingen, dass so ein Studium praxisnäher sein müsse.

Andererseits ist es vielleicht gar nicht so verkehrt, wenn Racket nicht in der Ausbildung verwendet wird. Stellt euch mal vor, das wäre so und dann in der Praxis müssen sich die Leute dann plötzlich mit Java, Javascript und PHP umherschlagen. Die würden ja ihres Lebens nicht mehr froh. ;)
 
Gerade die großen Business-Lisps (eben LispWorks und Allegro CL) werden ja vor allem von Unternehmen genutzt, die die entwickelte Software gern verscherbeln würden. Und wenn ich Software kaufe, dann kaufe ich doch lieber die, für die ich nur ein Zehntel der Größe runterladen muss :)

Ich würde da doch schon eine gewisse Notwendigkeit sehen.
Würde ich auch sagen. Aber offenbar nicht wichtig genug, als dass man sich bei den kostenlosen Lisp-Umgebungen dafür ein Bein ausreißen würde.
Und wenn Du für Geld Programme erstellst, dann bist Du ja auch eher bereit die Apothekenpreise von LispWorks oder Allegro zu bezahlen.
Das egalisiert sich ja dann auch ganz schnell, weil diese Umgebungen halt auch viel bieten.

Der Vergleich zwischen Lisp und Java ist ein Vergleich voller Missverständnisse. ;)
lol

Wechseln ist das falsche Wort. Ich gucke mir Racket für ein bestimmtes Projekt mal etwas genauer an und wenn es nichts wird, dann wird es halt nichts.
Ok. Ich erkenne aber Deinen guten Willen an. :-)

Und für manches ist das CL-Ökosystem einfach hervorragend.
Das stimmt. Ich würde mich auch nicht unbedingt entscheiden wollen zwischen entweder Racket oder Common Lisp, auch wenn ich zur Zeit mehr bei Racket hänge.

Also meine Kontodaten sind
Aber nur so lange einzahlen, bis Dein Kontostand auf Null ist. :-)
 
Hier noch einmal das Programm von CrimsonKing, einmal statisch, einmal dynamisch gelinkt.
Code:
#lang racket/base

 (writeln "hallo bsdforen!")
statisch 6. 54 MB
dynamisch 1.23 MB

Dein compiliertes Racket Programm nur 1 MB. Da geht Windows 10 aber verschwenderisch mit dem Plattenplatz um.
Das hat offenbar nichts mit Win10 zu tun, sondern mit dem linken.
 
Vieles was Lisp einstmals auszeichnet ist aber inzwischen in den Mainstream gewandert.

Leider gehören vernünftige Stacktraces selten dazu. :(

Weiterhin steht auch keine Marketing-Maschinerie hinter Racket oder Lisp im Allgemeinen.
Und auch keine Firma die da ordentlich investiert.

Zählt Y Combinator?

Aber es gibt halt für jeden Sch**ß eine Bibliothek, wo Du Dir dann mit wenig Aufwand Deine Lösung bauen kannst. Und solche Sachen sind halt Dinge, die heutzutage zählen.

Das erklärt m.E. auch den Erfolg von JavaScript - aber Python auch: Die Leute wollen nicht programmieren, die wollen so lange fertige Snippets aneinanderreihen, bis das Gesamtding irgendwie lauffähig ist. Mit einer lesbaren Sprache muss man denen da nicht kommen.

Dass wenigstens Common Lisp mit Alexandria u.a. inzwischen auch so was zu bieten hat: Sei's drum. Ich gehöre auch zu den Leuten, die lieber ein schlechteres Rad selbst bauen als ein fremdes Rad mit integriertem Außenspiegel, Scheibenwischer, Waschbecken und Abenteuerspielplatz an ihre Software zu schrauben. Ich bin Entwickler, kein Verfuger.

Die meisten "wollen" aber offenbar eine komplizierte Syntax.

Vielleicht sollte man viel mehr Menschen APL zeigen ... :D

Die C-Syntax ist nicht kompliziert, die C-Syntax ist nur gelegentlich sehr kompakt. Lisper/Schemer sollten sich darüber aber nicht allzu lustig machen, auch "wir" - wohl dem, der beides kennt und schätzt - schreiben (quote ...) ja selten aus, weil wir manchmal ein bisschen schreibfaul sind.

Ich weiß auch nicht, wer auf die glorreiche Idee gekommen ist, dass Java Lehrsprache an Hochschulen sein sollte.

Schlipsträger, die möglichst schnell billigen Nachwuchs für ihren Java-EE-Kack haben wollten.
Zum Glück wächst sich das allmählich raus. Heute wollen sie möglichst schnell billigen Nachwuchs für ihren Python-Kack...

Zu meiner Schulzeit waren Pascal und u.U. BASIC ja noch die Lehrsprachen der Wahl. Ob man davon nun unbedingt mehr hatte, ist offen.
 
Die meisten "wollen" aber offenbar eine komplizierte Syntax. Oder sagen wir besser: Sie sind es so gewohnt. Und auch das ist sehr wichtig bei einer Sprache. Darum findest Du ja auch in vielen Sprachen diesen C-Stil. Den kennen die Leute. Der wird eher akzeptiert als irgendwas "Exotisches".

Ich denke die Argumentation die ich immer wieder von Lispern lese ist zu einfach. Sprachen wie Lisp oder auch Forth bieten einfach sehr wenig visuelle Struktur die das lesen und verstehen wesentlich erleichtert. Das wird dann durch entsprechende Koventionen und Formatierung ein wenig (!) gemildert. Der Vorzug von Päfix/Postfix Sprachen ist eben dass der ohne AST direkt interpretiert werden kann und u.A. deshalb sehr flexibel sind was u.A. auch einfachere Compiler ermöglicht. Makros in Infix-Notation sind wesentlich komplizierter (s.u.A. Rust oder Erlang). Alles hat eben seinen Preis...

NB: Interessant finde ich in diesem Zusammenhang Smalltalk denn das ist im Prinzip eine vereinfachte Postfix-Notation.
 
Das erklärt m.E. auch den Erfolg von JavaScript

Contra: JavaScript war jahrelang die einzige Möglichkeit, clientseitig im Browser was auf die Beine zu stellen. Die Frage nach Alternativen hat sich mangels verfügbarer Alternativen gar nicht gestellt. Man konnte entweder eine Runde Mimimi anstimmen oder trotz JavaScript mit JavaScript was Cooles bauen. :cool:

Die Leute wollen nicht programmieren, die wollen so lange fertige Snippets aneinanderreihen, bis das Gesamtding irgendwie lauffähig ist.

Während der Python-Entwickler schon produktive Software auf die Beine gestellt hat, diskutiert der ${EXOTIC_LANGUAGE}-Entwickler noch über die Frage, ob vi oder emacs der einzig wahre Editor ist. :rolleyes:

Mit einer lesbaren Sprache muss man denen da nicht kommen.

Es gibt ja bekanntlich nur zwei Arten von Programmiersprachen:
  • Die, über die jeder schimpft
  • Die, die keiner benutzt
;)

Ich gehöre auch zu den Leuten, die lieber ein schlechteres Rad selbst bauen als ein fremdes Rad mit integriertem Außenspiegel, Scheibenwischer, Waschbecken und Abenteuerspielplatz an ihre Software zu schrauben.

Dito. Ich kann mich auch stundenlang mit Spielereien beschäftigen. Im Grunde meines Herzens will ich aber reale Probleme lösen und nicht noch ein weiteres Logging-, Web- oder ORM-Framework bauen, das mangels Ressourcen niemals die Qualität existierender Lösungen erreicht und das keine Sau braucht.

Ich bin Entwickler, kein Verfuger.

Entwickler stellen ihr Ego hinten an und verfallen nicht in das Not-invented-here-Syndrom. :belehren:

Wenn der "Verfuger" mit weniger Aufwand in kürzerer Zeit eine leichter wartbare Software mit besser unterstützem Ökosystem in höherer Qualität als der "Entwickler" in ${EXOTIC_LANGUAGE} auf die Beine stellt - wer von beiden leistet den wertvolleren Beitrag?

Heute wollen sie möglichst schnell billigen Nachwuchs für ihren Python-Kack...

Solange die Liebhaber von ${EXOTIC_LANGUAGE} lieber jammern und sich mit Trockenübungen beschäftigen, als die Killerapplikation in ${EXOTIC_LANGUAGE} tatsächlich zu entwickeln, solange wird ernstzunehmende Software nicht in ${EXOTIC_LANGUAGE} entwickelt.
 
Contra: JavaScript war jahrelang die einzige Möglichkeit, clientseitig im Browser was auf die Beine zu stellen.

Das ist heute auch noch so. Mit dem Unterschied, dass irgendeiner von diesen Kloppis sich mal gedacht hat: Hmm, was passiert, wenn wir JavaScript auch auf einem Server benutzen? Seitdem geht es steil bergab.
JavaScript ist was für Leute, die nicht programmieren können. Sie sollten es insgesamt lieber lassen.

Während der Python-Entwickler schon produktive Software auf die Beine gestellt hat, diskutiert der ${EXOTIC_LANGUAGE}-Entwickler noch über die Frage, ob vi oder emacs der einzig wahre Editor ist. :rolleyes:

ed(1) natürlich. :belehren: - Ich stelle übrigens lieber gut als schnell Software "auf die Beine", aber ich bin auch kein Silicon-Valley-Vollpfosten mit schlecht sitzendem Anzug.

Es gibt ja bekanntlich nur zwei Arten von Programmiersprachen:
  • Die, über die jeder schimpft
  • Die, die keiner benutzt

Es gibt vor allem eins: Zu viele Leute, die glauben, sie müssten jetzt auch was programmieren. :rolleyes:
Wir haben zu viele Köche für zu wenig Brei.

Entwickler stellen ihr Ego hinten an und verfallen nicht in das Not-invented-here-Syndrom. :belehren:

Ich würfle mein Pseudonym für meine Software jedes Mal neu aus, sofern ich sie veröffentliche. Mein Ego hat davon überhaupt nichts.

Wenn der "Verfuger" mit weniger Aufwand in kürzerer Zeit eine leichter wartbare Software mit besser unterstützem Ökosystem in höherer Qualität als der "Entwickler" in ${EXOTIC_LANGUAGE} auf die Beine stellt - wer von beiden leistet den wertvolleren Beitrag?

Der Entwickler der verfugten Bibliotheken natürlich - und damit eher Letzterer. ;)

Solange die Liebhaber von ${EXOTIC_LANGUAGE} lieber jammern und sich mit Trockenübungen beschäftigen, als die Killerapplikation in ${EXOTIC_LANGUAGE} tatsächlich zu entwickeln

Wird eine Sprache dadurch besser, dass irgendeine sonstwie miese, aber beliebte Software in ihr geschrieben ist?
Ernstzunehmende Software, die dein Geld verwaltet, ist übrigens in COBOL geschrieben.
 
Ich habe mal Rallis GUI Beispiel unter Win10 kompiliert:
Code:
#lang racket/gui

(define frame (new frame%
                   [label "Probeform"]
                   [width 600]
                   [height 400]
                   [x 650]
                   [y 340] ))
(send frame show #t)

Größe:
dynamisch 12.7 mb
statisch 31.6 mb

Ich denke die dyn version wird nur laufen wenn racket im system installiert ist. Immerhin angenehm während der Entwicklung.

Man kann auch eine Programmdatei für die Installation auf einer anderen Maschine generieren. Ich hatte vermutet dass die dann Platform unabhängig wäre. Aber das ist nicht so. Es entsteht einfach eine zip-datei in der die win-exe sowie die notwendigen dlls gepackt sind. Ist also nur zur Verteilung unter Windows. Man kommt also wie es scheint nicht um eine Kompilation auf anderen Platformen herum. Wäre interessant zu erfahren wie das unter verschiedenen *nix ist. Ich vermute dass da die statisch gelingte Version (meist) ausreicht.

zip 10.3 mb
entpacked 26,6 mb

Kleine Ärgerlichkeit am Rande: Wenn DrRacket startet wird es immer oben links 0,0 geöffnet. Da ich den Taskbar wie beim Mac oben verwende wird das Menu durch den Taskbar verdeckt. Mist!
 
Zurück
Oben