Erfahrungen mit alternativen Script- oder Programmiersprachen

  • Ersteller Ersteller ralli
  • Erstellt am Erstellt am
GUI Programmierung funktioniert auch mit Racket..... :) Jetzt muß ich lernen, lernen, lernen, aber es ist ja gut dokumentiert.
 
Andy_m4 schrieb:
Chicken Scheme ist aber auch ein sehr interessanter Vertreter (wurde ja hier im Thread ebenfalls genannt. Ist, soweit ich weiß, sogar in deutscher Hand. :-)
Zum Vergrößern anklicken....
Der Original-Author ist Felix Winkelmann, ein deutscher Programmierer der sich aber m.W. inzwischen weitgehend zurückgezogen hat. Ich denke es ist interessant für jeden der ein performantes und ausgereiftes Scheme haben will. Geht dann eher in Richtung
Applikation als Skripting. Als GUI wird IUP verwendet, aber natürlich ist via C auch anderes möglich.

In der Scheme Welt gibt es ja so etwas wie einen Grundsatzstreit: Mit R6RS wurde ein Standart angestrebt der sich an denen anderer, heute übliche Sprachen anlehnt. Das wird von Teilen der Community abgelehnt die meinen dass damit der Charakter von Scheme verloren gehen würde. Als Kompromiss wurde dann R7RS entwickelt, der soweit ich das übersehe ein Subset von R6RS oder auch eine Erweiterung von R5RS ist. Chicken implementiert R5RS und ist auf dem Weg zu R7RS.

Interessant ist die Implementation von chicken da hier CPS (continue-passing-style) verwendet wird womit kurzlebige Objekte auf dem Stack und nicht auf dem Heap gehalten werden. Wer sich für so etwas interessiert, hier eine detaillierte Beschreibung. Ähnliche Techniken werden wohl heute gelegentlich auch in anderen Sprachen verwendet (m.W. z.B. in Lua).

Dieser thread mach Lust mal wieder ein wenig mit Scheme herumzuspielen :-)
 
IUP ist schon klasse, auch unter C sehe ich normalerweise davon ab, etwas anderes zu verwenden. :)
 
Kleine Rückmeldung, Racket ist das, nachdem ich immer suchte. selbst GUI Programmierung ist ein Kinderspiel und macht wieder Spaß:

Ein einfaches Fenster (frame)

Code: 
#lang racket/gui

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

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

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

(send frame show #t)

Aufgerufen mit racket probeform.

probeform.webp


Hier die Widget Gallerie:

Widget Gallerie

Da ist alles an Widgets dabei.
 
@ralli: Ich würde vorschlagen einen neuen thread (racket/scheme oder so) zu eröffnen. Mich würde z.B. die Größe des Executables interessieren. Ich habe es mir nämlich gerade auch installiert, kämpfe aber noch ein wenig mit dem Environment (Win10) und habe z.Z. nicht so viel Zeit.
 
mogbo schrieb:
schonmal C# getestet :ugly:, da führt dich die GUI via Maus durchs Fenster + Knöpfchen bauen, bis hin zur Belegung?
Zum Vergrößern anklicken....
Nee hab ich nicht, ist ja interessant, ist das schon KI, die natürliche Dummheit kompensiert?:rolleyes: War ein kleiner Scherz, damit ich nicht mißverstanden werde. Die beste IDE ist und war die von Delphi. Der Schöpfer und Chefentwicker der Borland Entwicklungsumgebung hat ja später die Seiten gewechselt und ist nach Microsoft gegangen. Dort war er maßgeblich an der IDE von Visualbasic beteiligt, die ja, was die IDE angeht, sofort an Borland erinnert.

Jetzt werde ich aber nicht auf zig verschiedenen Hochzeiten tanzen, sondern erst Mal bei Racket bleiben.
 
rubricanis schrieb:
In der Scheme Welt gibt es ja so etwas wie einen Grundsatzstreit: Mit R6RS wurde ein Standart angestrebt der sich an denen anderer, heute übliche Sprachen anlehnt. Das wird von Teilen der Community abgelehnt die meinen dass damit der Charakter von Scheme verloren gehen würde.
Zum Vergrößern anklicken....
Ja. Grundsatzstreit ist durchaus richtig.
Es gibt halt die Leute die sagen, dass Scheme sich vor allem dadurch auszeichnet, dass es minimalistisch ist. Du hast also wirklich nicht viel (verglichen mit anderen Sprachen). Du hast nicht mal so was wie Objekte.
Aber was Du hast, ist halt so ausdrucksstark, dass Du Dir daraus bauen kannst, was Du willst (eben auch solche Sachen wie OOP).

Dieser Minimalansatz ist zwar recht elegant, aber für Praktiker ergeben sich damit auch Probleme. Denn viele Patterns die benutzt werden, braucht man halt immer wieder. Und verschiedene Scheme-Implementierung bieten neben dem Minimalstandard eben auch solche Funktionalitäten mit an.
Da diese aber nicht standardisiert sind, kocht jede Implementation so ein bisschen ihr eigenes Süppchen, was dann aber auch bedeutet, dass Du ein Programm für Scheme-Implementation A nicht so ohne Weiteres auf Implementation B laufen lassen kannst. Die Portabilität ist eingeschränkt.

Und genau dem versucht R6RS Rechnung zu tragen, indem man Scheme um bestimmte Dinge die man sowieso "immer" braucht zu erweitern. Zum Beispiel ein einheitlichen Weg zum Schreiben und Benutzen von Biliotheken (im Wesentlichen ein Beitrag von Matthew Flatt, einer der Hauptentwickler von Racket). Was ich auch als wichtig empfinde, denn wenn man schon damit konfrontiert ist, dass unterschiedliche Implementationen unterschiedliche Dinge anbieten, dann will ich die bei einem Wechsel auch sauber mitziehen können.

Natürlich rief das die Minimalisten auf den Plan, denen Scheme damit zu bloated wurde.
Da es zwei Gegensätze sind, die sich nicht miteinander vereinen lassen, entschloss man sich R7RS zu unterteilen.
In R7RS small für die Minimalisten und R7RS large für die Praktiker.

rubricanis schrieb:
Interessant ist die Implementation von chicken da hier CPS (continue-passing-style) verwendet wird womit kurzlebige Objekte auf dem Stack und nicht auf dem Heap gehalten werden.
Zum Vergrößern anklicken....
Ja. Wobei das jetzt nicht den continuation passing style ausmacht. Da geht es eher um das weiterreichen von Zuständen statt von Werten. Das ermöglicht dann ohne große Umwege sogar auch völlig ohne Stack auszukommen.
Der Gag bei Objekten auf dem Stack ist eher eine Memory-Management-Geschichte.

Grob gesagt, wenn Objekte eh nur innerhalb einer Funktion leben, dann brauch ich sie nicht unbedingt auf den Heap zu packen, sondern kann sie wie andere Funktionsbezogene Werte auch auf dem Stack tun. Das erleichtert dann das abräumen weil solche Objekte dann nicht auf dem Heap liegen, wo sie dann irgendwann mal vom Garbage-Collector rausgesucht und abgeräumt werden müssen.

Ist also eine Optimierugnsstrategie fürs Memory-Management.
 
tcberner schrieb:
Ich finde ruby sehr cool für kleine Skriptereien -- alles was mir in sh zu mühsam ist, mach ich damit.
Zum Vergrößern anklicken....
Ruby ist in der Tat ne nette Sprache. Ich persönlich finde ja auch, es ist das gelungenere Python.

Ein bisschen unhandlich wird es aber dann bei größeren Programmen, wo Du statische Typisierung haben willst und ein Compiler der die gröbsten Sachen schon vor Ausführung bemängelt.
Aber für kleine Sachen (Alternative zu Shell-Skripten) ist es auf jeden Fall sehr angenehm.
 
Andy_m4 schrieb:
Ist also eine Optimierugnsstrategie fürs Memory-Management.
Zum Vergrößern anklicken....
Klar: Der Punkt ist ja das in allen Lisp-Dialekten wie verrückt Objekte allokiert werden was zu Laufzeitprobleme führt wenn die nicht optimiert werden, - selbst mit einem generational GC. Aber das haben die heutigen Lisps wohl alle auf die eine oder andere Art gelöst.

Portabilität ist immer ein Problem, insbesondere System und GUI Wie mir scheint sind aber die meisten Implementierungen selbst ziemlich portabel, zwischen den Implementierungen knirscht es halt.
 
Gibt es denn eine aktuell empfehlenswerte Implementierung von "R7RS large" und wie unterscheidet sich die von Racket?
Oder gibt es gar ein #lang r7rs?
 
CrimsonKing schrieb:
Gibt es denn eine aktuell empfehlenswerte Implementierung von "R7RS large" und wie unterscheidet sich die von Racket?
Zum Vergrößern anklicken....
R7RS large ist noch in der Mache, soweit ich weiß.
Das Verhältnis zu Racket ist eher so, dass sich Racket zwar an Scheme angelehnt ist, sich aber trotzdem an einigen Stellen unterscheidet. Dem hat man vor einigen Jahren auch insofern Rechnung getragen als das der alte Name PLT-Scheme durch Racket abgelöst worden ist.
Es ist auch sinnvoll diese als getrennte Sprachen zu betrachten.

Wie schon gesagt, Racket ist nicht nur eine Sprache, sondern auch ein Framework zum erstellen von Sprachen. Und das beste ist, diese Sprachen können auch gut miteinander interagieren.
Das heißt, Du kannst in Dein Racket-Programm durchaus Scheme-Programme als Modul einbinden.

Die Portierung von Scheme nach Racket ist zwar auch nicht schwierig aufgrund der Ähnlichkeiten, aber wenn dem nix besonderes entgegen steht würde ich den eben beschriebenen Weg bevorzugen.

Ansonsten: Wenn man sich für Racket entscheidet, entscheidet man sich auch für die gleichnamige Racket-Implementierung.
Wobei natürlich grundsätzlich nix dagegen spricht Teile seines Programms in RnRS zu schreiben, damit später etwaiger Portierungsaufwand geringer ausfällt.
Außerdem unterstützt Racket auch viele SRFIs die auch andere Scheme-Implementierungen mitbringen.
Möglich ist es also durchaus mit Racket portable Programme (im Sinne man kann die Scheme-Implementation austauschen) zu schreiben.
Inwiefern das Sinn macht, muss dann jeder für sich selbst entscheiden.

CrimsonKing schrieb:
Oder gibt es gar ein #lang r7rs?
Zum Vergrößern anklicken....
Ja. Gibt es. Für die Small-Variante.
https://pkgs.racket-lang.org/package/r7rs
 
Etwas OT:

Vril schrieb:
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 ;-)
Zum Vergrößern anklicken....

Ich brauche nur alle 4787 Wochen mal einen Taschenrechner (und nehme dann zumeist den von Android), aber ich habe das mal zum Anlass genommen, RPN mal wieder auszuprobieren.

Kurz darauf eine RPN-App gekauft. :)
 
Dann musst du nun auch Reverse Polish LISP lernen: https://en.wikipedia.org/wiki/RPL_(programming_language) :) Ich habe damit vor Jahren mal auf einem HP 48G gespielt. War ganz lustig aber auf Dauer einfach zu schmerzhaft, außerdem gab's dann auch schon Laptops. Für die HP 48 Serie ist 'x48' ein guter Emulator. Für die späteren Modell, in denen HP selbst ihren Taschenrechner auf einer ARM CPU emuliert, 'x49g+'. Ein guter Einstieg in den größerem Themenbereich bis hin zu Assembler der Saturn CPU ist unter http://www.wiki4hp.com/doku.php?id=resources:start
 
Alternative Programmiersprachen:
  • M/Matlab: Eigentlich aus der Ecke Simulation kommend kann man damit trotzdem auch andere Sachen Programmieren....
  • C#: Eigentlich ganz nett und auch Visual Studio hat mir erstaunlich gut gefallen. Eigentlich eine ganz brauchbare IDE. C# muss man nicht unbedingt compilieren, es gibt auch einen C#-Interpreter (csi.exe), in dem man C#-"Skripte" ausführen kann. Das ist ganz praktisch wenn man eine dll experimentel erkunden muss.
  • Python: Nunja nicht wirklich alternativ. Das gute an Python ist, dass es für alles Bibliotheken ist, das schlechte, dass ich mit der Doku nicht zurechtkomme. Suche ich z.B. eine Funktionalität in openpyxl dann google ich, finde einen Hinweis auf Stackoverflow, probiere das interaktiv aus, bekomme den Hinweis, dass die Methode deprecated ist und welche Method ich stattdessen verwenden sollte. Mit diesem Methodennamen finde ich die Doku dann auch auf der (Docu)-Webseite von openpyxl. Gleich die richtige Methode auf der Dokuwebseite zu finden: Für mich sehe ich da keine Chance.
  • lua: Bin leider nur mit "italian" (Spaghetti) lua-Code in Berührung gekommen..... :(
 
Aktuell gibts wieder Delphi (10.2) in einer kostenlosen Version.
Da unsere Firma zu 80% alles mit Delphi macht und die meisten Anlagen in Betrieb sind & nachgefragt werden kann ich nur sagen:
Delphi ist noch lange nicht tot.
Was lässt sich sonst noch dazu sagen. Der Eigentümer wechselt ständig und IDE ist etwas verbuggt. Die API ist eine Mischung aus Oldschool und Teils zum am Kopf kratzen.
Der Compiler ist für Windows immer noch weitgehend eine alte, aufgebohrte Version, andere Plattformen nutzen LLVM, keine Ahnung ob da jemand draußen unterwegs ist.

C# ist ganz nett wenn nicht die Sprache sich nicht ständig ändern würde und das an VS-Versionen koppelt. Altprojekte profitieren davon nicht. Viele Apis für GUIs parallel und jedes hat andere Unzulänglichkeiten. Ich bin schon genug gestraft mit Silverlight und WPF.
Python setze ich noch massiv zum Auswerten von Diagnosen sprich Generierung von Statistiken ein, das geht recht gut. Zum Automatisieren in der Windows Welt kann ich das nicht gebrauchen.Der Aufwand um simpelste Windows-Dinge zu erledigen ist umständlicher als ein einfaches Batch-Skript.
Das was ich von Lua gesehen habe reicht mir, ziemlicher Murks selbst als Distribution für mich nicht zu gebrauchen. Zudem ist es langsamer als Python auch auf einem ESP32.

PS: Das soll nicht als Werbung für Delphi missverstanden werden.
 
darktrym schrieb:
kann ich nur sagen: Delphi ist noch lange nicht tot.
Zum Vergrößern anklicken....
Ich würd sagen, es hat seine Nische und der es sich auch behauptet. Die Frage ist aber, ob man in der jüngeren Vergangenheit auch genügend Nachwuchs generieren kann, damit das so bleibt. Und da hab ich so meine Zweifel.

darktrym schrieb:
Das soll nicht als Werbung für Delphi missverstanden werden.
Zum Vergrößern anklicken....
Wenn eine Sprache Werbung brauchen könnte, dann Delphi. :-)

darktrym schrieb:
C# ist ganz nett wenn nicht die Sprache sich nicht ständig ändern würde und das an VS-Versionen koppelt. Altprojekte profitieren davon nicht.
Zum Vergrößern anklicken....
Wie jetzt? Kann man Altprojekte nicht mehr in neuen Visual Studio Versionen öffnen und bearbeiten?
Würde mich ja sehr wundern.
Und das sich Sprachen ändern ist normal. Ist bei Delphi nicht anders.

darktrym schrieb:
Viele Apis für GUIs parallel und jedes hat andere Unzulänglichkeiten.
Zum Vergrößern anklicken....
Ja. Die Bibliotheken sind da manchmal etwas mühsam.

darktrym schrieb:
Ich bin schon genug gestraft mit Silverlight
Zum Vergrößern anklicken....
Auch so eine Microsoft-Krankheit. Kaum hat sich irgendwas etabliert, muss die nächste Sau durchs Dorf.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben