Erfahrungen mit Racket

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.
Aber das ist doch in anderen Sprachen genauso. Ich glaube kaum, dass jemand mit einem nicht eingerückten Java-Quelltext glücklich werden würde. Also rückt man ein.
Genauso wie man es auch bei Lisp macht.
Und als zusätzliche visuelle Hilfe nutzen viele Syntaxhighlighting. Auch das geht mit Lisp.

Andererseits hast Du aber auch handfeste Vorteile. Ein zusammengehöriges Klammerpaar ergibt insgesamt halt immer einen gültigen Lisp-Ausdruck. Das macht das editieren von Lisp-Programmen sehr angenehm.

Ich kenne auch kaum einen Lisp-Programmierer (mich inbegriffen) der die Syntax als schlecht empfindet, wenn man sich erstmal eingearbeitet hat. Im Gegenteil.

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).
Eben. Bei Rust stand übrigens auch im Raum, ob man dem nicht ne Lisp-Syntax gibt. Man hat es nur deshalb verworfen, weil ne C-artige Syntax eben eher den Gewohnheiten der Leute entgegenkommt.
 
Aber das ist doch in anderen Sprachen genauso.

In Assembler und COBOL finde ich mich momentan auch ohne Einrückung ganz gut zurecht (wobei COBOL das ja noch nicht so lange überhaupt erlaubt). Bei Java, (ausreichend kompliziertem) PHP und C# hätte ich da schon größere Probleme.

Bei Rust stand übrigens auch im Raum, ob man dem nicht ne Lisp-Syntax gibt. Man hat es nur deshalb verworfen, weil ne C-artige Syntax eben eher den Gewohnheiten der Leute entgegenkommt.

Und warum hat Rust dann stattdessen eine haskellartige Syntax bekommen? Um alle gleichermaßen abzuschrecken?
 
Für bedenklich halte ich die Einstellung, die Entwicklung von Software zur Lösung realer Probleme - mit all den Kompromissen, die das erfordert - sei eine verwerfliche und verachtenswerte Angelegenheit. Nur wer in reinen Sprachen nicht existente Probleme beackert, ist der Huldigung würdig. :ugly:
Das Problem ist ein Anderes. Ich nehm mal exemplarisch Javascript (gilt aber im Prinzip für jede andere Einsteigersprache). Die Sprache ist so, dass auch jemand der nicht wirklich begabt ist damit ein Programm entwickeln kann. Die Lernkurve ist (scheinbar) flach und so kommt man auch schnell zu Ergebnissen und kann dementsprechend auch schnell Applikationen bauen.

Das Problem daran ist, dass die Applikation nicht wirklich robust und/oder sicher ist. Der Javascript-Programmierer musste sich ja nie gedanken um Sachen wie was ist der Unterschied zwischen Integer und String machen. Hat ihm ja die Sprache abgenommen. Und in den rudimentären Tests funktioniert auch alles wunderbar. Gut. Es hakt mal ein bissl. Muss man neustarten. Keine Ahnung worans liegt aber schlimm kann es ja nicht sein. usw.

Und genau da liegt der Hase im Pfeffer. Solange alles nur im kleinen Rahmen abläuft ist alles ganz nett. Aber sobald professionelle Anforderungen kommtn, kracht es. Dann ist Javascript nämlich plötzlich nicht mehr einfach, sondern hoch komplex.
Javascript oder PHP-Programmierer werden ja immer etwas belächelt. Aber diese Sprachen wirklich zu beherrschen, um damit professionelle Lösungen zu bauen ist alles andere als einfach. Denn werden nämlich plötzlich wieder Sprachen interessant, die dem Programmierer abverlangen sich mit solchen Nichtigkeiten wie Variablendeklaration herumzuschlagen und der gleichen.

(Vermeintlich) einfache Sprachen sind nett, wenn jemand für sich seine Probleme lösen will. Sobald daraus mehr werden soll, muss man es auch anders angehen. Und das geschieht leider zu wenig. Das Ergebnis sehen wir heute mit der vielen kaputten Software die es gibt.

Ich kann mich noch an eine Zeit erinnern wo, wenn es ein Problem gab, man immer die Schuld bei sich selbst gesucht hat. Ganz einfach weil es auch meist so war. Auf die Software war i.d.R. Verlass.
Heute ist es genau umgekehrt. Wenns ein Problem gibt, gucke ich zuerst nach der Software. Und sehr häufig sieht man dann, dass genau hier das Problem liegt.

Wegen Einbindung von Bibliotheken:
Grundsätzlich hast Du recht. Aber auch hier ist das Problem wieder die Anwendung in der Praxis. Da wird halt irgendeien Bibliothek genommen über die man eigentlich auch nix genaues weiß. Aber es funktioniert irgendwie.
Dann gibts aber Probleme beim Deployment. Das man seine Software mit einer veralteten Bibliotheksversion ausliefert die bekannte Sicherheitslücken hat und solche Späße.

Es sollte eben genau nicht nur darum gehen, dass man am Ende des Tages irgendwie was Funktionierendes hat, was aber eigentlich am Rande des auseinanderfallens ist.
Unser Leben ist ja inzwischen auch sehr von der IT abhängig und die allgemeine Qualität in der Softwareentwicklung wird dem nicht gerecht (positive Beispiele gibts natürlich auch).

Und ich weiß nicht, ob ich über eine Reaktorsteuerung die mit nodeJS von nem Werksstudent zusammen geschraubt wurde wirklich ein gutes Gefühl hätte.
 
Und als zusätzliche visuelle Hilfe nutzen viele Syntaxhighlighting. Auch das geht mit Lisp.
Klar! Aber darum geht es nicht. Die ((...)) oder [[..]] haben in Lisp nur eine Bedeutung und nicht wie in Sprachen mit Syntax unterschiedliche. In der C-Welt {} begin/end block & Co, () functionsaufruf, [] Array & Co. Und die Kontrollstrukturen heben sich deutlich hervor, auch ohne hiliting. In smaltalk [] block (delayed execution). etc pp. In Forth spielt nur die Reihenfolge eine Rolle. Visuell ist das für uns Menschen schwierig. Aber klar, man kann sich an alles gewöhnen und findet auch geeignete Hilsmittel. Aber man sollte sich nichts vormachen wenn das von anderen nicht goutiert wird. Das sind nicht nur Ignoranten...

Jede Sprache/implementierung ist ein Kompromiss von konkurrierenden Zielsetzungen. In Lisp hat man sich eben für S-Expr entschieden, mit ihren Vorzügen und Nachteilen. Ist halt so.

Wir entfernen uns allzuweit vom Thema...

PS: Ich meine mich zu erinnern dass es in der Frühzeit von Lisp auch andere Formen gegeben hat, die sich aber nicht durchgesetzt haben. S-Expr waren dann so etwas wie eine Zwischensprache. Kann man natürlich noch heute machen, aber wer will das?
 
Da fällt mir ein: LINQ, dieses leider bisher nicht vernünftig woanders implementierte C#-Konstrukt, demzufolge alles, was nach Daten aussieht, eine durchsuch- und filterbare Liste ist, ist eigentlich ein integriertes Lisp.

Doch nicht so doof, die Leute...
 
Alte, gut abgehangene (und vermutlich schon deshalb nur noch schwer wartbare) Module einzubinden geht eben nur so lange gut, bis du an ihre Grenzen stößt und/oder jemand bemerkt, dass da seit zwanzig Jahren ein Bug drin ist. Das zu fixen ist nicht selten umständlicher als schnell eine Eigenbaulösung zu schreiben.
Das kann passieren, muss aber nicht. Man kann sich ja, wie schon gesagt, vorher informieren.

Wenn ich jetzt beispielsweise ein GUI-Toolkit wie GTK+ nutze, weiß ich halt das gibts schon seit 20 Jahren und das wird es vermutlich auch noch die nächsten 20 Jahre geben. Wenn ich mir vorstelle, ich müsste dazu ne eigene Lösung schreiben und das dann vielleicht auch noch für mehr als eine Plattform (weil ich ein plattformunabhängiges Programm haben möchte), dann sitze ich vermutlich allein daran schon so lange, dass mein eigentliches Problem was ich lösen wollte gar nicht mehr relevant ist.

Bei Lisp gibt es Paare (mit merkwürdiger Punktnotation), schwer erklärbare Standardmakros wie loop, nicht mal in C vorhandene, historisch bedingte Funktionen wie cdr
Gut. Bezeichnungen wie cdr sind vielleicht unglücklich, aber keine Syntaxangelegenheit. Lediglich ein evtl. schlecht gewählter Name für ein Schlüsselwort bzw. hier besser gesagt ne Funktion.
loop mag zwar ein kompliziert zu benutzendes Makro sein, folgt aber ansonsten brav den einfachen Regeln der Lisp-Syntax.
BLeibt noch die Paare mit Punkt was aber auch nur eine andere Schreibweise für cons ist. Also damit vergleichbar zur quote-Geschichte.

Bei C fängts ja schon an, dass Du Dich da mit nem Präprozessor rumschlagen muss der aber wiederum ne andere Syntax hat als eigentlicher C-Quelltext.

Für jeden Quatsch gibts ne Extra Syntax. Blöcke z.B. in geschweiften Klammern (ohne Schlüsselwort). Dann wie gesagt, die Unterschiede zwischen Operatoren, Funktionen und Statements. Apropos Operator. Selbst das ist ja schon ein Kapitel für sich.
Es gibt die normalen Operatoren mit 2 Argumenten. Dann gibts noch ternärer Operator. Und zusätzlich noch die Operatoren mit einem Argument wie ++ und die man dann auch noch vor oder hinter die Variable schreiben kann.

Solche Mätzchen das Du bei Arrays plötzlich auch noch irgendwie mit Eckigen Klammern rumfummeln musst. Dann bei den Zeigern Sternchen und Und-Zeichen.

Dann noch die ganzen Regeln Bezeichner betreffend. Das Du nicht alle Zeichen verwenden darfst. Das er nicht mit einer Ziffer beginnen darf.

Ist auch alles kein Problem. Ist aber nicht so homogen wie bei Lisp oder auch Smalltalk um mal ein anderes Beispiel zu bringen.

Es tut mir ein bisschen leid zu sehen, dass Nachwuchs-Pascaler kaum noch zu finden sind.
Ja. Das ist schon etwas tragisch, nachdem Pascal ja schon relativ erfolgreich war.
 
GTK+ ist ein mittelgutes Beispiel. Es ist immerhin eins von überschaubar wenigen "reinen" C-GUI-Toolkits, neben Motif natürlich. Der Rest (IUP...) ist eher Nische. Dass man da eher zu GTK+ greift, hat weniger technische als praktische Gründe. Aber ein GUI-Toolkit würde ich jetzt auch nicht selbst programmieren - ich meinte eher: selbst Dreizeiler werden in anderen Sprachen gern mal aus einer Bibliothek reinkopiert. Die Sache mit NPM und left-pad hast du ja sicher mitbekommen.

Bei C fängts ja schon an, dass Du Dich da mit nem Präprozessor rumschlagen muss der aber wiederum ne andere Syntax hat als eigentlicher C-Quelltext.

Dass sich ein Racketprogrammierer mal darüber aufregen würde, dass in C ein Programm meist mit einer Raute beginnt ... :D

Für jeden Quatsch gibts ne Extra Syntax. Blöcke z.B. in geschweiften Klammern (ohne Schlüsselwort).

Bleiben wir doch mal beim naheliegenden Vergleich: In Racket wird es gemeinhin als guter Stil bezeichnet, für switch-case u.a. andere Klammern zu nehmen als für den Rest des Codes (obwohl wohl auch normale Klammern gehen). Ab wie vielen Extrasyntaxen findest du es erwähnenswert? :)

Und zusätzlich noch die Operatoren mit einem Argument wie ++ und die man dann auch noch vor oder hinter die Variable schreiben kann.

Was logisch abbildet, was sie tun: Vor oder nach der Auswertung hochzählen. :)

Solche Mätzchen das Du bei Arrays plötzlich auch noch irgendwie mit Eckigen Klammern rumfummeln musst.

Siehe oben.

Dann bei den Zeigern Sternchen und Und-Zeichen.

In welcher Sprache, in der ich explizit Pointer nutzen kann, funktioniert das Addressieren und Deaddressieren von Pointern nicht über "besondere Zeichen"?

Dann noch die ganzen Regeln Bezeichner betreffend. Das Du nicht alle Zeichen verwenden darfst.

Das ist in Racket - anders als in Common Lisp - übrigens auch so. Naja, Leerzeichen mal allgemein ausgenommen.

Ja. Das ist schon etwas tragisch, nachdem Pascal ja schon relativ erfolgreich war.

Und immer noch ist - wenn auch nicht mehr so laut wie früher. Das hat Embarcadero zu verantworten.
 
Klar! Aber darum geht es nicht. Die (()) oder [[..]] haben in Lisp nur eine Bedeutung und nicht wie in Sprachen mit Syntax unterschiedliche.
Irgendwie lustig. Du versuchst mich davon zu überzeugen, dass Lisp zu homogen ist. CrimsonKing versucht mich davon zu überzeugen, dass es nicht so ist und das C viel einfacher ist.
Vielleicht solltet ihr beide direkt weiter diskutieren. :-)

In der C-Welt {} begin/end block & Co, () functionsaufruf, [] Array & Co.
Ich weiß ja was Du sagen willst. Sehe aber das Problem nicht ganz so dramatisch.

Und die Kontrollstrukturen heben sich deutlich hervor,
Das fängt ja schon allein damit an, dass in Lisp nicht zwischen Kontrollstrukturen und Funktionen unterschieden wird. Es gibt keine Anweisungen. Es gibt eigentlich nur Ausdrücke die auch immer einen Wert zurückliefern (bis auf ein paar Ausnahmen wie beispielsweise define).

Die Sprache prägt unser Denken und bei Programmiersprachen ist es im Prinzip nicht anders.
Wenn Du ein ganz bestimmtes Problem in C löst dann wird die selbe Lösung unter Scheme anders aussehen. Und damit meine ich jetzt nicht nur die Syntax, sondern um die Struktur des Programms. Du könntest es schon so hinbiegen, dass die Scheme-Lösung äquivalent zur C-Lösung aussieht (und umgekehrt). Aber keiner würde es halt so machen, weil es eben nicht der Scheme-Way ist.

Darum hast Du viele vermeintliche Probleme mit der Lisp-Syntax in Lisp gar nicht.

Aber man sollte sich nichts vormachen wenn das von anderen nicht goutiert wird. Das sind nicht nur Ignoranten
Ich möchte ja auch gar nicht mal grundsätzlich bestreiten, dass das ein Problem ist. Aber ich denke, dass dieses No-visual-distinction-Problem häufig größer gemacht wird, als es eigentlich ist.

Ich meine mich zu erinnern dass es in der Frühzeit von Lisp auch andere Formen gegeben hat, die sich aber nicht durchgesetzt haben. S-Expr waren dann so etwas wie eine Zwischensprache.
In der Tat hat McCarthy eigentlich eher M-Expressions im Sinn gehabt (also grob gesagt Funktionsaufrufe in eienr solchen Syntaxform, wie sie in der Mathematik oder auch in den C-Style-Sprachen üblich sind).
Die S-Expressions haben sich aber als so praktisch erwiesen, dass die M-Exps keiner mehr haben wollte.

Ich bin auch der Meinung die Syntax ist eine der wichtigen Sachen, die Lisp ausmachen (und auch in der Vergangenheit zu dessen Erfolg ganz wesentlich beigetragen hat).
Und wie gesagt, ich keine auch keinen Lisp-Anwender der die Syntax als Nachteil empfindet.

Und ich hab ja auch irgendwann mal mit Lisp angefangen und kenne daher alle Vorbehalte von mir selbst. So dramatisch wie man es am Anfang dachte, ist es aber dann bei Weitem nicht.

Wir entfernen uns allzuweit vom Thema
Finde ich gar nicht. Lisp a-ka Racket-Syntax trifft doch ziemlich genau das Thema
 
Die Sprache prägt unser Denken und bei Programmiersprachen ist es im Prinzip nicht anders.
Das sehe ich auch so! Wir differieren auch nur in der Gewichtung der Besonderheiten. Insofern EOT. Im übrigen bin ich geade dabei scheme ernsthaft auszuprobieren. Vielleicht kann auch ich mich an den Non-Syntax gewöhnen. Wir werden sehen...
 
Irgendwie lustig. Du versuchst mich davon zu überzeugen, dass Lisp zu homogen ist. CrimsonKing versucht mich davon zu überzeugen, dass es nicht so ist und das C viel einfacher ist.
Vielleicht solltet ihr beide direkt weiter diskutieren. :-)

Willst du mich loswerden? :D
 
Die Sache mit NPM und left-pad hast du ja sicher mitbekommen.
Ja. Gut. Wenn man von solchen Extremfällen ausgeht.

Dass sich ein Racketprogrammierer mal darüber aufregen würde, dass in C ein Programm meist mit einer Raute beginnt :D
Gut. Lassen wir allgemein Reader-Makros außen vor, dann bin ich auf der sicheren Seite. :-)

Bleiben wir doch mal beim naheliegenden Vergleich: In Racket wird es gemeinhin als guter Stil bezeichnet, für switch-case u.a. andere Klammern zu nehmen als für den Rest des Codes (obwohl wohl auch normale Klammern gehen). Ab wie vielen Extrasyntaxen findest du es erwähnenswert? :)
Ja. Aber Eckige Klammern und Runde Klammern sind semantisch identisch.

Was logisch abbildet, was sie tun: Vor oder nach der Auswertung hochzählen. :)
Das mag ja von der Logik her auch alles i.O. sein. Darum geht es aber nicht. Es geht um die Syntax.
Und das soll jetzt auch nicht primär als Kritik an der C-Syntax verstanden werden. Es geht nur darum, den Unterschied auszuzeigen.

In welcher Sprache, in der ich explizit Pointer nutzen kann, funktioniert das Addressieren und Deaddressieren von Pointern nicht über besondere Zeichen?
Man könnte das auch syntaktisch über ein Funktionsaufruf lösen.
Man hat sich aber für nen Operator entschieden.

Das ist in Racket - anders als in Common Lisp - übrigens auch so. Naja, Leerzeichen mal allgemein ausgenommen.
Ich bin bei Racket noch nicht direkt auf eine Grenze gestoßen, hab es aber auch noch nicht probiert zu provozieren.
Eigentlich geht so ziemlich alles, was der Unicode-Standard hergibt.
Ausgenommen sind nur das schon erwähnte Leerzeichen (oder Whitespaces im Allgemeinen), Klammern und noch ein paar andere Kleinigkeiten:
https://docs.racket-lang.org/guide/syntax-overview.html#(part._.Identifiers)

C dagegen meckert ja schon bei Umlauten. Oder wenn man ein Schlüsselwort als Bezeichner verwendet. Willst in Deinem Navi-Programm die Zielkoordinanten mit goto bezeichnen und der Dreck geht nicht :-)

Das hat Embarcadero zu verantworten.
Was haben die denn falsch gemach?
 
Man könnte das auch syntaktisch über ein Funktionsaufruf lösen.
Man hat sich aber für nen Operator entschieden.

In welcher Sprache - außer einigen Assemblern - geht das denn mit etwas anderem als einem Operator?

Ich bin bei Racket noch nicht direkt auf eine Grenze gestoßen, hab es aber auch noch nicht probiert zu provozieren.
Eigentlich geht so ziemlich alles, was der Unicode-Standard hergibt.
Ausgenommen sind nur das schon erwähnte Leerzeichen (oder Whitespaces im Allgemeinen), Klammern und noch ein paar andere Kleinigkeiten:
https://docs.racket-lang.org/guide/syntax-overview.html#(part._.Identifiers)
Eben! ;)

C dagegen meckert ja schon bei Umlauten.

Nein, siehe Annex D. Emojis gehen (noch?) nicht, Nicht-ASCII-Zeichen stören aber höchstens einige Compiler.

Oder wenn man ein Schlüsselwort als Bezeichner verwendet.

Da ist C aber besser dran als C++, C# und Java... :)

Mein Lieblingsbeispiel:

C:
int class = 0;

Das klappt in C auch nur, weil C so kompakt ist.

Was haben die denn falsch gemach?

Sie haben kurz nach der Übernahme von CodeGear (und damit effektiv der mittelfristigen Einschläferung des Unternehmens Borland - was haben die denn jetzt noch?) Turbo Delphi eingestellt. De facto war es damit für Heim- und Privatanwender (und Hochschulen) nicht mehr erschwinglich, sich mit Delphi zu befassen, und Lazarus war noch weit von einer Version 1.0 entfernt (falls es überhaupt schon wer kannte - ich habe es selbst sehr lange ignoriert).
 
Willst du mich loswerden? :D
Nie im Leben. Mit wem soll ich sonst noch diskutieren? :-)

In welcher Sprache - außer einigen Assemblern - geht das denn mit etwas anderem als einem Operator?
Aus dem Stand keine Ahnung, aber das ist ja auch gar nicht der Punkt. Es geht um Syntax.

Nicht-ASCII-Zeichen stören aber höchstens einige Compiler.
Genau das ist aber, was mich in der Praxis interessiert.

Da ist C aber besser dran als C++, C# und Java :)
lol Aber ja. Ist es.

Turbo Delphi eingestellt. De facto war es damit für Heim- und Privatanwender (und Hochschulen) nicht mehr erschwinglich,
Das hab ich gar nicht mehr mitgekriegt.

Ich muss mich korrigieren: Es gibt wieder ein Gratis-Delphi.
Ich glaube der Kostenfaktor war auch mit entscheidend. Kostenfrei nutzbare Programmiersprachen wurden in den 90er Jahren sehr viel mehr zur Selbstverständlichkeit.

Klar. Die Fans hielten Delphi die Stange. Die waren aber inzwischen auch in einem Alter, wo sie sich das leisten konnten. Aber das junger Mensch sind ja selbst 100€ ne Menge Geld. Und da kam Delphi erst gar nicht mehr in Betracht.
So was wie ne kostenlose Community Edition hätte viel viel früher kommen müssen.

Ich glaube, da hing man noch zu sehr in früherer Zeit, wo man ja allein mit dem Verkauf von Software sehr gut gelebt hat.
 
Während unsere Experten noch die einzelnen Vor- oder Nachteile diverser Sprachen diskutieren, bin ich weiter in Racket eingetaucht und bin dabei, mich mit der GUI Programmierung zu beschäftigen.;) Um auch Ein- oder Umsteigern zu zeigen, wie einfach GUI Programmierung ist und es Ihnen ein wenig schmackhaft zu machen, habe ich gestern ein kleines GUI Programm mit Racket geschrieben, was die Erstellung eines Button mit Callback Funktion verdeutlicht. Du kannst Musik per Klick ein- oder ausschalten. Gewöhnungsbedürftig war für mich, das auch bei mehreren Button bei der Declaration immer button% genommen wird. Dann wird er das intern wohl durch button1, button2 unterscheiden, denn es muß ja auseinander gehalten werden. Zum Ausschalten benutze ich

Code:
killall mpg123

bei FreeBSD oder

Code:
pkill mpg123

bei OpenBSD, weil OpenBSD killall nicht kennt, was es auf den verschiedenen Plattformen zu berücksichtigen gilt. Wer es ausprobieren möchte, ich habe den Sourcecode musik.rkt als Datei angehangen, um Euch das Tippen zu ersparen.:)

Sourcecode musik.rkt:

Code:
#lang racket/gui

(require racket/system)

; Erstellt einen Frame, indem die Frame% -Klasse instanziiert wird

(define frame (new frame% [label "Musikbox"]))

; Erstellt eine statische Textnachricht im Frame

(define msg (new message% [parent frame]
                          [label "Flower Power Radio"]))

; Erstell einen Button im Frame

(new button% [parent frame]
             [label "Musik  an"]

; Callback-Verfahren für einen Klick auf die Schaltfläche button (Musik an)

             [callback (lambda (button event)
                         (system "mpg123 http://50.7.129.122:8433/ &"))])

(new button% [parent frame]
             [label "Musik aus"]

; Callback-Verfahren für einen Klick auf die Schaltfläche button (Musik aus)

             [callback (lambda (button event)
                         (system "pkill mpg123"))])

; Zeigt den Frame, indem seine show-Methode aufgerufen wird

(send frame show #t)

gui.png


Bitte nach dem Download umbenennen von musik.txt in musik.rkt. Andere Dateinamenerweiterungen als txt dürfen hier als Dateianhang ja nicht benutzt werden.

have fun:)

PS: Natürlich muß auch mpg123 installiert sein.
 

Anhänge

  • musik.txt
    928 Bytes · Aufrufe: 245
Zuletzt bearbeitet von einem Moderator:
Gewöhnungsbedürftig war für mich, das auch bei mehreren Button bei der Declaration immer button% genommen wird.
button% ist der Klassenname. Analog zu frame% oder message%.
Genauso kannst Du natürlich mit define Deinen Buttons Bezeichner zuordnen und die dann darüber konfigurieren. Da Du das aber bereits bei der Init (new) gemacht hast, ist es nicht notwendig.

Verbesserungsvorschläge:
  • mach den Button als Toggle-Button, damit man entweder an oder ausschalten kann. Selten will man mehrmals einschalten :-)
  • mach die Kind-Prozess-Verwaltung über Racket
    nimm process
    http://docs.racket-lang.org/referen...s#(def._((lib._racket/system..rkt)._process))
    damit hast Du nicht nur das Problem gelöst, dass Du Prozesse asynchron aufrufen kannst, sondern erhältst auch gleich noch die Möglichkeit den erzeugten Kind-Prozess zu killen ohne auf Systemkommandos zurückgreifen zu müssen
 
Hallo Andy, danke für die Tipps, die ich alle zukünftig berücksichtigen werde.:) Ich hab erst Mal angefangen, denn auch ein anfängliches Erfolgserlebnis ist für die weitere Motivation wichtig. Dann werde ich mich mal an eine verbesserte Version machen. Ich stell mir immer Aufgaben. Ich werde ein Progamm OcrMaker entwickeln, einen Texteditor, mit dem ich Texte einscannen kann und dann mit tesseract zur Weiterbearbeitung erkennen und nutzen kann. Hab ich schon mal mit Qt und auch mit Lazarus verwirklicht. Dann kommt auch die Klasse Process zum Einsatz.

Andy, hast Du mit Racket auch schon einige nutzbringende größere Projekte verwirklicht? Denn nur eine Sprache zu lernen, finde ich ziemlich langweilig, wenn ich keinen möglichen Nutzen daraus ziehen kann. So kleine Helferlein sind ja schnell erstellt wie mit einem Toggle-Button mounten/unmounten oder ein kleines Brennprogramm, um unter OpenBSD mal schnell eine CD zu brennen.

Wenn dann auch ein größeres Interesse besteht, könnte ich mir auch einen Workshop GUI Programmierung mit Racket vorstellen. Das würde ich dann mit LaTeX machen.
 
Ich hab erst Mal angefangen, denn auch ein anfängliches Erfolgserlebnis ist für die weitere Motivation wichtig.
Ja. So hatte ich es auch verstanden.
Deshalb war es auch nicht als Kritik gemeint, sondern als Hinweis, wie man das möglicherweise weiter entwickeln könnte.
Da man mit process auch das stdout vom Kind-Prozess bekommt, könnte man z.B. auch überlegen, ob man etwaige Ausgaben von "mpg123" in einem Textfeld anzeigt oder solche Scherze.

Andy, hast Du mit Racket auch schon einige nutzbringende größere Projekte verwirklicht?
Durchaus. Und eigentlich wollte ich den ganzen Krempel auch mal open-sourcen. Was fehlt sind hier und da ein paar Refactorings von vor allem Dokumentationen.

Wenn dann auch ein größeres Interesse besteht, könnte ich mir auch einen Workshop GUI Programmierung mit Racket vorstellen. Das würde ich dann mit LaTeX machen.
So etwas macht man optimalerweise mit Scribble:
http://docs.racket-lang.org/scribble/index.html

Funktioniert im Grunde ziemlich ähnlich zu LaTeX (Du kannst Dir auch ein LaTeX-Dokument rendern lassen), hast aber viele Racket-typische Sachen schon drin wie automatisch gesyntaxhighlighted Quelltexte mit Verlinkungen etc.
Alles so wie man es aus den offiziellen Dokumentationen zu Racket kennt. Die sind nämlich alle mit Scribble erstellt.

Code:
#lang scribble/manual

@(require
   scribble/extract
   scribble/examples
   scriblib/footnote
   racket/sandbox
)
@(require (for-label racket))

@title{Tolles GUI Tutorial}

@section{Erste Schritte}

Ein einfaches GUI-Programm in @hyperlink["https://www.racket-lang.org/" "Racket"]:

@codeblock{
#lang racket/gui

(require racket/system)

(define frame (new frame% [label "Hello World!"]))

(send frame show #t)
}

@margin-note{Und vergesst nicht mir auf Twitter zu folgen ;-)
}

Sieht dann im Browser so aus:
tut.png
 
Nie im Leben. Mit wem soll ich sonst noch diskutieren? :-)

Mit ralli!

Dafür muß aber wieder Windows auf die Platte. Mittlerweile ist Lazarus doch sehr ausgereift, und das läuft auf beiden Plattformen.:)

Und kann mit zu vielen großen Delphi-Bibliotheken nicht besonders gut umgehen, und gerade auch auf eine Alternative zu FireMonkey warte ich vergeblich (und da kommt so schnell auch keine, so weit ich weiß).

Wenn dann auch ein größeres Interesse besteht, könnte ich mir auch einen Workshop GUI Programmierung mit Racket vorstellen.

Wenn ich einen unverbindlichen Tipp geben darf:
https://github.com/Metaxal/MrEd-Designer

Der hat zwar bedienmäßig seine Eigenheiten, aber ist durchaus ein guter Anfang - komplizierte GUIs kann man damit anscheinend ganz gut prototypisieren. (Oder gibt es da noch einen besseren? @Andy_m4)

Code:
@margin-note{Und vergesst nicht mir auf Twitter zu folgen ;-)

Nickname? Gleich mal blockieren. :D
 
So etwas macht man optimalerweise mit Scribble:
http://docs.racket-lang.org/scribble/index.html

Funktioniert im Grunde ziemlich ähnlich zu LaTeX (Du kannst Dir auch ein LaTeX-Dokument rendern lassen), hast aber viele Racket-typische Sachen schon drin wie automatisch gesyntaxhighlighted Quelltexte mit Verlinkungen etc.
Alles so wie man es aus den offiziellen Dokumentationen zu Racket kennt. Die sind nämlich alle mit Scribble erstellt.
Danke, das ist sehr interessant und werde ich mir näher anschauen. Die Nähe zu LaTeX ist syntaktisch nicht zu verleugnen.
 
ansonsten vertraue ich der Aussage, MrEd erzeugte sauberen Code.
Ja. Da hab ich jetzt auch nicht unbedingt Zweifel.
Ich hab auch nix generell gegen GUI-Designer. Allerdings kommt es bei mir auch nicht so häufig vor, dass ich komplexe GUIs designen muss.
Von daher besteht von meiner Seite auch kein gesteigerter Bedarf danach.
 
Hab mal auf die Schnelle den MrEd-Designer installiert und ausprobiert. Gut, er funktioniert, ich werde aber auf jeden Fall händisch den Code erstellen, weil ich es lernen will und weil ich dann auch verstehe, was genau passiert. Der automatisch erzeugte Code von MrEd mag zwar sauber sein, bei mir ist er aber manuell übersichtlicher. Schön fände ich, wenn es eine GUI für den Dokumentationsmanager scribble geben würde, gefunden habe ich noch nichts. Aber das wäre dann ja auch eine schöne Aufgabe, ein solches Projekt selbst zu erstellen.
 
Zurück
Oben