Hallo,
ich will ein Programm schreiben das auf WIN Linux MAC läuft.
Die Anforderung ist recht simpel:
- Grafische Anzeige (XY Plot)
- einige Tasten
- einige Wertefelder
- Serialschnittstelle
- Daten speichern und wieder einlesen
So nun gibt es aber QT, WxWidgets, JAVA, ...........
Was wäre euer Meinung nach das was man am besten nehmen sollte?
Auch bitte die IDE dazu mir sagen.
C, C++, Pascal, Basic, PHP und Java kann ich.
Python nur schlecht.
Grüsse, Klaus
Als Anwender benutze ich Java GUI nur wenn es absolut keine Alternative
gibt. Eigentlich benutze ich nur JDownloader und Mplab.
Wenn du dich mit C++ anfreunden kannst, sind Qt und QtCreater durchaus
brauchbar.
Wenn du ein Opensource Projekt starten willst - je verbreiteter die
Tools, desto eher findest du Mitstreiter.
Hat eigentlich jemand VisualStudio auf dem Radar? Unter Windows besser
als alles andere. Aber unter MAC und Linux hat es sich nicht
durchgesetzt. Warum eigentlich?
Klaus schrieb:> ich will ein Programm schreiben das auf WIN Linux MAC läuft.>> Die Anforderung ist recht simpel:> - Grafische Anzeige (XY Plot)> - einige Tasten> - einige Wertefelder> - Serialschnittstelle> - Daten speichern und wieder einlesen
Okay.
> Was wäre euer Meinung nach das was man am besten nehmen> sollte?
Das ist eine komische Frage. Woher soll ICH denn wissen,
was DIR liegt?
Wenn Du eine Scriptsprache bevorzugst, kann ich für das GUI
Tk empfehlen. Ich verwende Tcl/Tk; die gelehrten Bücher
berichten aber, dass es auch Perl/Tk und Python/Tk gibt.
Zu compiliertem Zeugs kann ich nichts sagen; meine Pascal-
programme verwenden noch Kommandozeile.
> Auch bitte die IDE dazu mir sagen.
mcedit
SCNR
Noch einer schrieb:> Hat eigentlich jemand VisualStudio auf dem Radar? Unter Windows besser> als alles andere. Aber unter MAC und Linux hat es sich nicht> durchgesetzt. Warum eigentlich?
Wenn du den Apple Macintosh meinst, dann schreibt man den "Mac". "MAC"
ist die Abkürzung für media access control, genau genommen eine
Erweiterung des OSI-Layers 2, landläufig auch einfach Netzwerkadapter.
Nachtrag: Ich verwende für meine Projekte "Xojo" (ehemals RealBasic).
Das enthält einen Cross-Compiler für Win, Mac und Linux (mit GTK2).
Wenn man keine spezifischen Systemaufrufe macht, einfach per Knopfdruck
aus dem gleichen Sourcecode compilieren und fertig.
Und das Tolle: Die GUI sieht auf jedem System genau so aus, wie man das
dort erwartet. ich hasse diese altbackenen "selbstgemalten" Oberflächen,
wie sie leider viele Java-Tools mitbringen ...
>> So nun gibt es aber QT, WxWidgets, JAVA, ...
Ich hatte seinerzeit ein ähnliches Problem. QT war da mir zu
umfangreich. Für mich blieben da nur WxWidgets und FLTK übrig. FLTK
hatte ich zuerst probiert und da ich damit bisher fast alle meine
Projekte realisieren konnte, bin ich dabei geblieben, gerade auch weil
ich die grafischen Ausgaben damit recht elegant hinbekommen hatte.
Allerdings ist FLTK nicht sehr weit verbreitet, weswegen die Suche nach
speziellen Problemen manchmal recht langwierig sein kann. Aber es lohnt
sich!
Lästige Probleme sind aber immer dann zu erwarten, wen es um BS
spezifische Dinge geht, also beispielsweise bei der Ausgebe von
Audiodaten. Da muss dann für alle BSn mittels Compilerswitch
spezifischer Code selektiert werden. Aber das scheint bei Deiner
Aufgabenstellung nicht der Fall zu sein.
Ich bin jetzt ein großer Fan von FLTK!
Übrigens, man sollte FLTK immer von den Quelltexten installieren. Nicht
nur um den Quelltext zu haben, sondern weil man damit auch eine große
Sammlung von Beispielen bekommt, die einem helfen, zu verstehen, wie
einzelne Funktionen anzuwenden sind. Das ist aus der Dokumentation nicht
immer sofort ersichtlich.
So ich war dann mal fleissig übers WE.
FLTK macht einen guten Eindruck, aber wie Du schon sagst Doku ist nicht
so gut.
WxWidgets ist auch recht gut, aber die Serialschnittstelle für Mac habe
ich noch nicht gefunden. Würde mich jetzt aber nicht hindern das zu
nutzen.
Mit Lazarus hatte ich vor einigen Jahre mal ein altes Pascal Program
überarbeitet. Die neue Version macht auch einen guten eindruck.
Xojo, ist auch gut, aber Basic kann ich zwar, ist dann nur nicht so
meine Wunschsprache.
QT mag ich nicht, hatte ich schon mit zu tun und nein!
So nun muss ich mich nur entscheiden.
>> FLTK macht einen guten Eindruck, aber wie Du schon sagst Doku ist nicht
>> so gut.
Die Doku ist schon gut und vollständig. Was fehlt sind Tutorials, die in
die Tiefe gehen.
Aber viele brauchbare Tips bekommt man auf
http://seriss.com/people/erco/fltk/
Noch einer schrieb:> Hat eigentlich jemand VisualStudio auf dem Radar? Unter Windows besser> als alles andere. Aber unter MAC und Linux hat es sich nicht> durchgesetzt. Warum eigentlich?
Vielleicht weil dort weder der Compiler noch die IDE überhaupt
funktionieren? :D
Klaus schrieb:> FLTK macht einen guten Eindruck, aber wie Du schon sagst Doku ist nicht> so gut.
Naja, sagen wir mal: gewöhnungsbedürftig, weil automatisch mit Doxygen
erstellt.
Wenn man aber erstmal den Anfang gefunden hat, findet man sich ganz gut
zurecht (ich zummindest). Erstmal die Tutorials durchgehen, um die
grundlegende Idee dahinter zu verstehen. Um die GUI zu bauen, gibt es
mit FLUID ein nützliches Tool, damit kann man sich die Oberfläche (fast
Microsoft-mäßig) zusammenklicken.
Habe bei mir festgestellt, das die Beschäftigung mit der Dokumentation
doch schon sehr den eigenen Programmierstil beeinflusst hat, hab die
Sache ja auch nie richtig gelernt.
Einige einfache Beispiele (wie man es nicht machen sollte ;-) ) findest
du z.B. auf meiner Userpage.
mfG
Sven B. schrieb:> Vielleicht weil dort weder der Compiler noch die IDE überhaupt> funktionieren?
Das ändert sich.
Es gibt mit "Visual Studio Code" mittlerweile eine Variante, die sowohl
unter macOS als auch unter Linux läuft.
https://code.visualstudio.com/download
Compiler lassen sich mit Plugins nachrüsten.
Rufus Τ. F. schrieb:> Es gibt mit "Visual Studio Code" mittlerweile eine Variante, die sowohl> unter macOS als auch unter Linux läuft.https://code.visualstudio.com/license
...
DATA. The software may collect information about you and your use of the
software, and send that to Microsoft. Microsoft may use this information
to provide services and improve our products and services.
...
UPDATES. The software may install automatic updates. By using the
software, you agree to receive automatic updates without any additional
notice, and permit Microsoft to download and install them for you. If
you do not want automatic updates, you may turn them off by following
the instructions in the documentation ...
Nicht jeder Linux User will das ...
Stephan G. schrieb:> proccessing
Processing ist ein gutes Lern-Tool, aber es steht mit der GUI auf
absolutem Kriegsfuß. Buttons sind z.B. lediglich Rechtecke, die auf
Mausklick reagieren ... System-Guidelines sind völlig fremd.
Oder kennt da jemand eine optisch korrekte GUI-Lib? Würde mich sehr
glücklich machen.
Klaus schrieb:> So ich war dann mal fleissig übers WE.> Xojo, ist auch gut, aber Basic kann ich zwar, ist dann nur nicht so> meine Wunschsprache.
Die Syntax eines modernen Basic unterscheidet sich heutzutage von C++
oder Java nur noch - grob vereinfacht - in der Handhabung von Klammern
(statt dessen "begin" & "end") und dass kein Semikolon am Zeilenende
steht ...
Frank E. schrieb:> Oder kennt da jemand eine optisch korrekte GUI-Lib? Würde mich sehr> glücklich machen.
Qt ist da momentan schon das Standard-Tool für
Crossplatform-Anwendungen.
Sven B. schrieb:> Qt ist da momentan schon das Standard-Tool für> Crossplatform-Anwendungen.
Es gibt in dieser Kategorie auch noch WxWidgets, das ist etwas
leichtgewichtiger als Qt.
Andreas B. schrieb:> Legacy is simple schrieb:>>>> DOSBox mit Turbopascal:>> http://www.angryflo.de/dosbox.htm>> Wir schreiben das Jahr 2017.>> Nur mal so .....
Früher war auch nicht alles schlecht ... nur mal so
oder
auch im Zeitalter der Computer lernt man Rechnen mit den 10 Fingern ...
nur mal so
oder
ein RasPi kostet keine 50€ ... nur mal so
Noch einer schrieb:> Wenn du dich mit C++ anfreunden kannst, sind Qt und QtCreater durchaus> brauchbar.
Mach das! Schau dir das echt mal an. Lohnt sich
Klaus schrieb:> So nun gibt es aber QT, WxWidgets, JAVA, ...........
Guck bei embarcadero nach, die Grundversion vom "RAD Studio 10.2 Tokyo"
gibt es derzeit kostenlos. Und da ist dabei: Windows, Apple, Android und
evtl. auch Linux.
Das sollte für deine Zwecke ausreichen - und das ganze teure Zeug, wo ne
Masse von Datenbank-Sachen dabei sind, wirst du wohl nicht brauchen.
W.S.
W.S. schrieb:> Guck bei embarcadero nach, die Grundversion vom "RAD Studio 10.2 Tokyo"> gibt es derzeit kostenlos. Und da ist dabei: Windows, Apple, Android und> evtl. auch Linux.
Ja, für nur €5,771.50 gibt es sogar Linux-Unterstützung.
> Das sollte für deine Zwecke ausreichen - und das ganze teure Zeug, wo ne> Masse von Datenbank-Sachen dabei sind, wirst du wohl nicht brauchen.
Offenbar sind aber die "Datenbank-Sachen" mehr oder weniger das Einzige,
was unter Linux überhaupt verfügbar ist:
"Linux compiler is for Delphi only, Linux does not include the FMX
framework"
Und wie entwickele ich mit diesem hoffnungslos überteuerten Zeug jetzt
eine GUI-Anwendung, die auch unter Linux läuft?
W.S. schrieb:> Guck bei embarcadero nach,
Nein, wenn er sich auf Object Pascal einlassen will dann sollte er
gleich zu Lazarus greifen statt erst den Umweg über diese sterbende
Firma zu gehen und sich dabei noch irgendwelches Vendor-Lock-In
einzufangen das er später nicht mehr los wird.
Für schnelle schlanke native cross platform GUI Apps ohne jegliche
Laufzeitabhängigkeiten gibts IMHO im Moment kaum was das Lazarus das
Wasser reichen könnte.
Kein Userspace-Programm hat Laufzeitabhängigkeiten wenn man alle
Laufzeitabhängigkeiten mit in's Archiv wirft. Das ganze "keine
Abhängigkeiten"-Konzept ist als Argument sehr komisch.
Sven B. schrieb:> Kein Userspace-Programm hat Laufzeitabhängigkeiten wenn man alle> Laufzeitabhängigkeiten mit in's Archiv wirft. Das ganze "keine> Abhängigkeiten"-Konzept ist als Argument sehr komisch.
Ja klar, man kann sich auch theoretisch einen Knopf an den Bauch nähen
und ein Klavier dranhängen und damit spielend durch die Stadt
marschieren.
Ich finde es komisch daß Du es komisch findest daß manche Leute auf ein
Klavier am Bauch lieber verzichten würden.
So nach weiteren Tests schwanke ich nur noch zwischen Wxwidgets mit
CodeBlocks als IDE und Lazarus.
Da ich aber dann doch mehr C++ bevorzugen würde, bräuchte ich noch eine
hübsche XY Dastellung.
http://plplot.sourceforge.net/http://wxmathplot.sourceforge.net/
Scheinen da die besten dafür zu sein.
VG, Klaus
Bernd K. schrieb:> Sven B. schrieb:>> Kein Userspace-Programm hat Laufzeitabhängigkeiten wenn man alle>> Laufzeitabhängigkeiten mit in's Archiv wirft. Das ganze "keine>> Abhängigkeiten"-Konzept ist als Argument sehr komisch.>> Ja klar, man kann sich auch theoretisch einen Knopf an den Bauch nähen> und ein Klavier dranhängen und damit spielend durch die Stadt> marschieren.
Das ist ein lustiger Spruch, aber es ist keinerlei Argument darin
enthalten warum meine Aussage irgendwie falsch sein sollte.
R hat einfach die besten freien Werkzeuge um fast alles Vorstellbare
darzustellen, und wenn eine Library die deine speziellen Anforderungen
erfüllt nicht verfügbar ist, kannst du deine eigene erstellen. Ich kann
keine kommerzielle Software finden die vergleichbar ist, außer du
erstellst einfache Graphen und willst keine 1-2 Tage damit verbringen zu
lernen wie das in R gemacht wird.
Hi,
wenn es um die graphische Darstellung geht, würde ich mir mal den Weg
über gnuplot überlegen.
Daten erstellen, auf Textdatei rausbringen und gnuplot aufrufen. Das
dürfte das einfachste sein und sieht auch ansprechend aus. (Wenn man
sich an den unterschiedlichen Design der Ausgabe von gnuplot nicht
stört)
Gruß
Andreas
Klaus schrieb:> ich will ein Programm schreiben das auf WIN Linux MAC läuft.>> Die Anforderung ist recht simpel:> - Grafische Anzeige (XY Plot)> - einige Tasten> - einige Wertefelder> - Serialschnittstelle> - Daten speichern und wieder einlesen>> So nun gibt es aber QT, WxWidgets, JAVA, ...
Neben diesen Toolkits gibt es auch noch eine Möglichkeit, die ich
persönlich für wesentlich flexibler und moderner halte: nämlich einen
kleinen Webserver, der sich um die serielle Kommunikation kümmert und
eine schicke Webseite mit dem oder den Plot(s) ausliefert. In Python
würde ich dazu ein Mikroframework wie Flask benutzen (Ähnliches gibt es
auch für andere Sprachen) und für die Darstellung auf der Website etwas
JavaScript-basiertes wie Flot, jqPlot oder jqWidgets. Neben der
Plattformunabhängigkeit kann man so auch Gerätegrenzen überwinden -- und
solange man nicht schon Erfahrung mit einem GUI-Toolkit hat, ist da im
Vergleich zu einer klassischen GUI-Applikation eher weniger Lern- und
Programmieraufwand zu bewältigen.
Spinnen wir mal die Idee mit dem Web Server weiter.
Ich habe einen kleinen AVR am Rechner dran der mir seriel Daten liefert.
Die empfange ich und will die Darstellen.
Es gibt einige Parameter die eingestellt werden sollen,
sowie einige Knöpfe die Funktionen auf dem AVR starten.
Ausserdem gibt es noch Status Informationen vom AVR.
So wo kommt nun der WEB Kram hin, damit es auf allen System läuft?
Und vorallendingen Wie & Was?
Ich bin da ganz offen für neues, was WEB gesteuertes wäre mir auch fast
lieber da ich mir dann über die Plattform keine grossen Gedanken machen
müsste.
Viele Grüsse
Klaus
Sorry aber um wenige AD Werte und IO Kram mit einem Raspi zu machen
halte ich für vollkommen daneben und ist für mich ein Zeichen von
totaler unkenntnis in dem aktuell beschriebenen Bereich.
Aber das man einen WEB Server auf einem ESP oder Raspi leicht zum laufen
bingen kann ist was anderes und da hast Du dann wohl wieder Erfahrung.
Ich übrigens auch aber das ist was anderes!
Klaus schrieb:> Spinnen wir mal die Idee mit dem Web Server weiter.>> Ich habe einen kleinen AVR am Rechner dran der mir seriel Daten liefert.> Die empfange ich und will die Darstellen.> Es gibt einige Parameter die eingestellt werden sollen,> sowie einige Knöpfe die Funktionen auf dem AVR starten.> Ausserdem gibt es noch Status Informationen vom AVR.>> So wo kommt nun der WEB Kram hin, damit es auf allen System läuft?
Der "Web-Kram" kommt dann auf den Rechner, an dem der AVR hängt.
> Und vorallendingen Wie & Was?
Entschuldige bitte, aber ich verstehe die Frage nicht.
Klaus schrieb:> Sorry aber um wenige AD Werte und IO Kram mit einem Raspi zu machen> halte ich für vollkommen daneben und ist für mich ein Zeichen von> totaler unkenntnis in dem aktuell beschriebenen Bereich
Wenn man sich den Preis von einem Pi Zero ansieht kann es manchmal
durchaus Sinn machen das anstelle eines uC zu verwenden. Man muss ja
kein Raspbian drauf machen es gibt z.B. BBC BASIC das ist ähnlich wie
BASCOM und echtzeitfähig.
Oliver S. schrieb:> Webserver mit html5 Ausgabe.> Sonst musst Du deine Software alle 2 Jahre für neue Betriebssysteme> kompilieren.
Für Windows mag das zutreffen...;-)
Aber prinzipiell sehe ich das genauso. Als pure Webanwendung ist das am
einfachsten Betriebsystemunabhängig zu realisieren.
Gruß
Andreas
Frank E. schrieb:> Processing ist ein gutes Lern-Tool, aber es steht mit der GUI auf> absolutem Kriegsfuß.
Kommt auf die konkrete Anwendung an. Ich persönlich benutze Processing
sehr gerne, insbesondere, wenn ich nicht nur buttons brauche, sondern
vielleicht auch noch grafische Ausgaben wie x/y-Koordinaten oder ein
Oszillogram oder ein 3D-Objekt oder was auch immer. Die normalen
Elemente per lib wie Knöpfe und Textfelder haben mir dabei immer völlig
gereicht.
Da ich mich nicht so mit solchen WEB Anwendungen auskenne.
Wie kann man einen einfachen WEB Server auf einem AVR über Serial (USB
SIO) bauen.
Gehen muss das ja, ein Akustikkoppler war ja nichts anders, aber nur
wie?
Was dann an HTML und JAVA Code zum PC gesendet wird ist dann der 2.
Schritt.
Wenn ich die Anbindung hätte und mal eine einfache HTML Seite Betreiben
könnte wäre mir schon geholfen.
Viele Grüsse,
Klaus
Hi,
der Webserver selbst läuft natürlich auf dem PC.
Aber am besten finde ich wenn Du jetzt mal genau erzählst was Du da
vorhast.
Soll die Anwendung 24/7 laufen und Du willst jederzeit mit einem
beliebigen PC drauf?
Wenn ja, dann macht man das am einfachsten mit einem Raspi oder einem
ESP. Da braucht es keinen AVR und auch keinen PC für den eigentlichen
Webserver.
Falls man eine Webserver auf den AVR laufen lassen will, binden man
diesen mit einem Adapter direkt an das Netz an.
Schau mal hier: www.ulrichradig.de/home/index.php/avr/webserver mit
einer Netzwerkkarte oder den Net-IO von Pollin mit einem ENC28J60.
Gruß
Andreas
Das mit dem WEB Server kommt ja nicht von mir, ich würde es aber gerne
umsetzen. Dann aber nur wenn ich keine Hardwareänderung machen müsste.
Sonnst kann ich auch gleich einen CORTEX M3,M4 oder M7 mit ETH nehmen
und ich könnte die Software fertig aus einem anderen Projekt kopieren.
So etwas habe ich erst vor einigen Monaten gebaut.
NEIN es bleibt bei einem AVR mit USB SIO dran!!!!!
WEB Interface wäre super, weil ich es auch sehe das ich damit am
zukunftssichersten wäre. Hätte ich auch richtig Lust drauf das zum
laufen zu bringen.
Aber ein normales Programm tut es letztlich auch, wenn der WEB Kram
nicht geht.
Das ist ein Hobby System und nichts womit man Geld macht, also gönne ich
mir den Spaß es so minimalistisch wie möglich zu machen.
Aber es soll trotzdem was sein wo ich auch noch was lerne.
VG, Klaus
Achso, das Teil wird möglicherweise nur Stundenweise laufen.
Aber ich kann ja niemanden verbieten es 24/7 laufen zu lassen.
WEB Server auf dem PC klingt nach Aufgabe verfehlt.
Entweder der läuft auf dem AVR oder WEB ist bei dem Projekt nicht drin.
Ich denke das ich niemanden dazu bringe einen WEB Server mit zig Paketen
zu installieren nur um einige Daten von einem AVR anzuzeigen.
Klaus schrieb:> WEB Server auf dem PC
Da Dein AVR an einem COM Port hängt brauchst Du keinen WEB Server. Du
kannst auch eine lokale HTML Seite machen und mit einem Javascript Timer
refreshen. Dann machst Du ein include auf eine weitere lokale HTML Datei
mit Platzhaltern für Deine Daten. Und dann machst Du noch ein C Programm
das diese HTML Datei im Hintergrund regelmäßig mit neuen Daten vom COM
Port bestückt.
Also zusammen wären das dann zwei HTML Dateien gleich für Win Linux Mac
und ein jeweils verschiedenes EXE
Abgesehen davon ist das aber Dein eigentliches Problem :-)
> NEIN es bleibt bei einem AVR mit USB SIO dran
Wenn ich für jedes System eine EXE brauche bin ich wieder bei meinem 1.
Eintrag. So wollte ich ja das ganze machen.
Die ganze WEB Idee war nicht von mir!
Ja mein Problem ist das ich an der Hardware nichts ändern will, aber
entweder es geht oder halt nicht!
Eine HTML Seite über die SIO raus zusenden ist ja nicht schwer, auch
wenn da genug CSS & JAVA drin ist. POST & GET an den AVR bekommt man
dann auch noch geregelt.
Aber die eigentliche Frage dabei ist doch wie teile ich WIN/ Linux mit
das die Ethernetschnittstelle eigentlich eine Serialschnittstelle ist
und was für ein Protokoll muss ich da fahren damit das dann läuft.
Und gibt es so was schon fertig zum abschreiben.
Viele Güße, Klaus
Du kannst dir sicherlich was bauen, was eine Bridge zwischen der
seriellen Schnittstelle und einem TCP-Socket baut. Auf Linux ist das
wahrscheinlich sogar relativ einfach, geht vermutlich mit 2 Zeilen
Shell. Ohne Software auf dem Rechner wird das aber nix.
Ich finde das ganze Thema hat sich in eine ziemlich komische Richtung
verrannt. Schreib' ein 20-Zeilen Python-Skript mit serial und PyQt5,
oder das äquivalente C++-Programm, oder was auch immer und gut ist.
Irgendwelche Bridges von USB auf Serial und dann auf TCP zu bauen und
dann irgendwelche Webserver drankleben um JS/HTML benutzen zu können
wird weder einfacher zu benutzen noch übersichtlicher werden. Das ist
wieder einer dieser Threads die versuchen ein wirr generalisiertes
Problem zu lösen und dabei den Pragmatismus völlig aus den Augen
verlieren. Überleg nochmal was du eigentlich real erreichen willst und
dann nimm die Technologie mit der das am einfachsten machbar ist.
Klaus schrieb:> Wie kann man einen einfachen WEB Server auf einem AVR über Serial (USB> SIO) bauen.
Für Arduinos gibt es spezielle Ethernet-Shields, für AVRs könnte man
etwas wie einen XPort benutzen.
> Was dann an HTML und JAVA Code zum PC gesendet wird ist dann der 2.> Schritt.
Nicht Java, sondern JavaScript. Obwohl es ähnlich klingt und in
mancherlei Hinsicht sogar ähnlich aussieht, ist das ein gewaltiger
Unterschied. Bitte versteh' mich nicht falsch, es geht hier nicht ums
Klugscheißen -- aber wenn Du Java in die Suchmaschine Deiner Wahl
eingibst, obwohl Du eigentlich nach JavaScript suchen willst, wirst Du
mit den Ergebnissen nicht glücklich. ;-)
Sven B. schrieb:> Ich finde das ganze Thema hat sich in eine ziemlich komische Richtung> verrannt. Schreib' ein 20-Zeilen Python-Skript mit serial und PyQt5,> oder das äquivalente C++-Programm, oder was auch immer und gut ist.> Irgendwelche Bridges von USB auf Serial und dann auf TCP zu bauen und> dann irgendwelche Webserver drankleben um JS/HTML benutzen zu können> wird weder einfacher zu benutzen noch übersichtlicher werden. Das ist> wieder einer dieser Threads die versuchen ein wirr generalisiertes> Problem zu lösen und dabei den Pragmatismus völlig aus den Augen> verlieren. Überleg nochmal was du eigentlich real erreichen willst und> dann nimm die Technologie mit der das am einfachsten machbar ist.
+1
Würde sagen die einfachste Lösung. Python läuft ja auf jeder Plattform
und hat und GUI ist kein Hexenwerk. Stimme meinem Vorredner zu, die
Diskussion geht in die falsche Richtung.
Have Fun
Gogo schrieb:> +1>> Würde sagen die einfachste Lösung. Python läuft ja auf jeder Plattform
-1
Was heißt es läuft auf jeder Plattform? Klar kann man es überall
installieren aber unter Windows läuft ist es kein Standard.
Java, Mono, Perl usw. läuft nach der Definition auch auf jeder
Plattform.
Abgesehen davon, finde ich Scriptsprachen nur für Quickie brauchbar. Ich
bin zumindest schneller mit Sprachen die übersetzt werden.
Peter II schrieb:> Abgesehen davon, finde ich Scriptsprachen nur für Quickie brauchbar. Ich> bin zumindest schneller mit Sprachen die übersetzt werden.
Soll ja einer werden, ist ja nix kommerzielles. Und Klaus geht es
ähnlich wie vielen HobbyBastlern.
Viele Ideen, wenig Zeit;-)
Sicher, viele Wege führen nach Rom. Schlussendlich kommt es auch darauf
an, welche Favoriten und Kenntnisse der TO hat. Python is imho der
einfachste Weg für MICH.Zufrieden? :-)
Klaus schrieb:> ich will ein Programm schreiben das auf WIN Linux MAC läuft.
Ich würde auch Purebasic empfehlen, schneller wird man nicht zu einem
brauchbaren Ergebnis kommen. Kostenlose Demo-Version ist u.a. auf 800
Code-Zeilen beschränkt, dass sollte aber kein Problem werden.
Klaus I. schrieb:> Klaus schrieb:>> ich will ein Programm schreiben das auf WIN Linux MAC läuft.>> Ich würde auch Purebasic empfehlen, schneller wird man nicht zu einem> brauchbaren Ergebnis kommen. Kostenlose Demo-Version ist u.a. auf 800> Code-Zeilen beschränkt, dass sollte aber kein Problem werden.
Ich würde empfehlen irgendwas zu benutzen, was es a) in fünf Jahren auch
noch gibt und keine Ein-Mann-Aktion, b) was nicht kommerziell ist, c)
was schonmal ein anderer Mensch auf der Welt benutzt hat und was d)
ordentlich getestet ist.
Nehmt doch gebräuchliche Tools für alltägliche Aufgaben. Die sind schon
okay. Jede Aufgabe mit einer anderen kommerziellen Hipster-Skriptsprache
zu erschlagen die noch nie jemand gehört hat hilft einfach nichts -- vor
allem nicht dem Lernenden, weil er kein Tool lernt, was er irgendwo
sonst realistisch benutzen kann.
Klar kann man PureBasic nehmen, aber ist das jetzt wirklich so viel
einfacher als Python, um statt der Sprache die halt jeder für alles
nimmt eine zu benutzen die noch nie irgendwer vorher dafür verwendet
hat?
Peter II schrieb:> Was heißt es läuft auf jeder Plattform? Klar kann man es überall> installieren aber unter Windows läuft ist es kein Standard.
Nichts läuft unter Windows als Standard. Selbst für C++ musst du die
typischerweise die aktuelle Standardbibliothek von MS nachinstallieren.
Dieses Argument hilft einfach nix. Wenn man alles in einen Installer
wirft läuft jedes Programm auf jeder unterstützten Plattform "direkt"™,
wenn man es nicht tut gibt es außer Konsolen-Programmen in C so gut wie
gar nix. Das ist kein Kriterium, anhand dessen man Optionen
gegeneinander abwägen kann -- zumindest kein binäres.
Sven B. schrieb:> Nichts läuft unter Windows als Standard
Möööp!
PowerShell, Visual Basic Script, Batch-Files und .NET Anwendungen laufen
unter Windows sehr wohl ohne weiteres Zutun.
Sven B. schrieb:> Nichts läuft unter Windows als Standard.
.net läuft auf jedem (aktuellen) Windows
> Selbst für C++ musst du die> typischerweise die aktuelle Standardbibliothek von MS nachinstallieren.
nur wenn man nicht statisch linkt. Es gibt mehr als genug "exen" die man
im Internet laden kann und die sofort laufen.
Borislav B. schrieb:> Sven B. schrieb:>> Nichts läuft unter Windows als Standard>> Möööp!>> PowerShell, Visual Basic Script, Batch-Files und .NET Anwendungen laufen> unter Windows sehr wohl ohne weiteres Zutun.
Ja toll, aber die laufen halt auf jeder anderen Plattform nicht! Darum
ging es doch.
Sven B. schrieb:> Ja toll, aber die laufen halt auf jeder anderen Plattform nicht! Darum> ging es doch.
hier ging es erst mal um dein Kommentar das unter Windows nichts als
Standard läuft. Was so nicht stimmt.
Peter II schrieb:> Sven B. schrieb:>> Ja toll, aber die laufen halt auf jeder anderen Plattform nicht! Darum>> ging es doch.>> hier ging es erst mal um dein Kommentar das unter Windows nichts als> Standard läuft. Was so nicht stimmt.
Ich wusste ja nicht, dass ich für jede Aussage nochmal alle im Thread
bisher gegebenen Vorbedingungen wiederholen muss ...
Das Statement find ich auch nicht so falsch, auf vielen anderen
Plattformen ist z.B. Python (was ja crossplatform ist) standardmäßig
verfügbar. Nur Windows hat nichts, was sich mit irgendeiner der anderen
Plattformen überschneiden würde.
>> Selbst für C++ musst du die>> typischerweise die aktuelle Standardbibliothek von MS nachinstallieren.> nur wenn man nicht statisch linkt. Es gibt mehr als genug "exen" die man> im Internet laden kann und die sofort laufen.
Ja. Weil das dann da drin ist. Ich kann aber genauso gut auch den
Python-Interpreter mit in die exe reinpacken. Dann läuft das auch
direkt. Das ist 100% genau dieselbe Situation. Trotzdem wird immer
Erbsen gezählt dass das irgendwie was fundamental anderes sei, weil
"aber dazu brauch ich ja Python". Stimmt, aber bei C++ brauche ich halt
die C++-Standardbibliothek. Beides ist einfach nur Bytecode den man in's
exe werfen oder sonstwie installieren kann bzw. muss ...
Borislav B. schrieb:> Sven B. schrieb:>> Nichts läuft unter Windows als Standard>> Möööp!>> PowerShell, Visual Basic Script, Batch-Files und .NET Anwendungen laufen> unter Windows sehr wohl ohne weiteres Zutun.
Und wieso will dann jedes Programm ein neues .NET Framework
installieren, wie z.B.
https://www.microsoft.com/en-us/download/details.aspx?id=22808 ?
Das einzige was unter Windows immer forhanden ist ist die WinAPI, und
damit GUIs zu erstellen ist wahnsinn.
Ich empfehle die Anwendung unter Linux in C++ zu entwickeln und QT zu
verwenden. Danach kann man es einfach für Windows mit MinGW
Cross-Kompilieren, und muss das Windows nichteinmahl mehr starten. Dabei
entfallen auch gleich noch diese "Redistributable" libraries die man
sich unter MSVC einfängt. Bei Mac kommt man dann vermutlich aber nicht
um XCode herum.
Daniel A. schrieb:> Und wieso will dann jedes Programm ein neues .NET Framework> installieren, wie z.B.> https://www.microsoft.com/en-us/download/details.aspx?id=22808 ?
schon mal auf den Link geklickt?
> Windows CE .NET, Windows Mobile 2003 software for Pocket PCs
Man sollte halt nicht auf die neuste Version immer setzen. Ein .net 3.5
muss nicht nachinstalliert werden.
> Ich empfehle die Anwendung unter Linux in C++ zu entwickeln und QT zu> verwenden. Danach kann man es einfach für Windows mit MinGW> Cross-Kompilieren, und muss das Windows nicht einmal mehr starten.
die Wahrscheinlichkeit das es ohne Probleme unter Windows stabil läuft
geht wohl gegen 0 - das schaffen ja nicht mal die Java-Programm die
angeblich Plattformunabhängig sind.
Ja ich muss auch sagen das hier läuft in eine falsche Richtung.
Ich mache es jetzt so wie ich es zu erst geplant hatte.
HTML & Javascript wäre zwar nett aber ist nicht so leicht umzusetzen.
An ncurses dachte ich auch schon mal kurz, aber da fehlt mir die Grafik.
Python mit den entsprechenden Erweiterungen schaue ich mir noch an und
dann wird das Teil gebaut.
Ich muss damit auch mal so langsam fertig werden und will nicht noch
Monate damit verbringen über die verteile von verschiedenen System zu
diskutieren.
VG, Klaus
Peter II schrieb:> Abgesehen davon, finde ich Scriptsprachen nur für Quickie brauchbar. Ich> bin zumindest schneller mit Sprachen die übersetzt werden.
Letztlich geht es um Entwicklungs- versus Laufzeitperformanz. Mit
modernen Skriptsprachen kann man etwa bis zu zehnmal (zB. Python vs.
Java) so schnell entwickeln, aber dafür sind Skriptsprachen meistens
nicht so performant wie kompilierter Code. Bei Programmen, die ohnehin
99% ihrer Laufzeit auf eine Benutzereingabe oder die auf Datenbank,
Netzwerk- oder Datei-I/O (oder hier Serial-I/O) warten und mit
überschaubaren Datenmengen arbeiten, reicht die Performanz von modernen
Skriptsprachen meist völlig aus.
Wobei Skriptsprachen mit kompilierten Erweiterungen wie Pythons numpy
oder mit einem verteilten Backend wie Apache Spark auch dort genutzt
werden, wo große Datenmengen dynamisch verarbeitet oder analysiert
werden müssen. Mit kompilierten Erweiterungen ist die Skriptsprache dann
in den kritischen Codeteilen ebenso schnell wie eine kompilierte, mit
Erweiterungen wie Spark wird die prinzipbedingt geringere Performanz der
Sprache durch entsprechend größer dimensionierte Hardware egalisiert.
Peter II schrieb:> hier ging es erst mal um dein Kommentar das unter Windows nichts als> Standard läuft. Was so nicht stimmt.
Ok: unter Windows läuft als Standard nichts plattformunabhängiges. (*)
Honi soit qui mal y pense.
(*) Obwohl MS ja langsam klüger wird und in den neuesten
Windows-Versionen sogar ELF-Binaries aus den Ubuntu-Repositories
ausführen kann.
Peter II schrieb:> Daniel A. schrieb:>> Ich empfehle die Anwendung unter Linux in C++ zu entwickeln und QT zu>> verwenden. Danach kann man es einfach für Windows mit MinGW>> Cross-Kompilieren, und muss das Windows nicht einmal mehr starten.>> die Wahrscheinlichkeit das es ohne Probleme unter Windows stabil läuft> geht wohl gegen 0 - das schaffen ja nicht mal die Java-Programm die> angeblich Plattformunabhängig sind.
Das stimmt nicht. Wenn man es richtig macht, laufen MingW- und
Java-Software vollkommen problemlos, auch unter Windows.
Sheeva P. schrieb:>> die Wahrscheinlichkeit das es ohne Probleme unter Windows stabil läuft>> geht wohl gegen 0 - das schaffen ja nicht mal die Java-Programm die>> angeblich Plattformunabhängig sind.>> Das stimmt nicht. Wenn man es richtig macht, laufen MingW- und> Java-Software vollkommen problemlos, auch unter Windows.
Wenn man es richtig macht läuft Software vollkommen problemlos überall.
Das ist die Definition von "richtig macht". Die Frage ist ja wie schwer
das ist.
Sheeva P. schrieb:> Letztlich geht es um Entwicklungs- versus Laufzeitperformanz. Mit> modernen Skriptsprachen kann man etwa bis zu zehnmal (zB. Python vs.> Java) so schnell entwickeln,
das ist Unsinn.
Wenn beide sprachen die gleichen Möglichkeiten bieten dann unterscheiden
es sich nur der Zeitdauern vom Compilieren und das macht niemals 90% der
Zeit aus.
Der Vorteil vom Compilieren ist sogar das Schreibfehler bei Variabel und
Funktionen sofort auffallen, bei Scripsprachen erst zur Laufzeit (wobei
ich Python nicht kenne)
Sven B. schrieb:> Sheeva P. schrieb:>>> die Wahrscheinlichkeit das es ohne Probleme unter Windows stabil läuft>>> geht wohl gegen 0 - das schaffen ja nicht mal die Java-Programm die>>> angeblich Plattformunabhängig sind.>>>> Das stimmt nicht. Wenn man es richtig macht, laufen MingW- und>> Java-Software vollkommen problemlos, auch unter Windows.>> Wenn man es richtig macht läuft Software vollkommen problemlos überall.> Das ist die Definition von "richtig macht". Die Frage ist ja wie schwer> das ist.
Das ist wirklich ganz einfach, man richtet sich die build Umgebung
einfach so ein, dass das Buildscript von anfang an immer gleich für
beide Platformen kompiliert. Bei jedem Kompiliervorgang sieht man dann,
ob man etwas bei einer oder beiden davon kaput gemacht hat, und kann es
korrigieren.
Peter II schrieb:> Sheeva P. schrieb:>> Letztlich geht es um Entwicklungs- versus Laufzeitperformanz. Mit>> modernen Skriptsprachen kann man etwa bis zu zehnmal (zB. Python vs.>> Java) so schnell entwickeln,>> das ist Unsinn.
Nein, Peter, das ist es erfreulicherweise nicht. Wenn das "Unsinn" wäre,
wie Du behauptest, dann würde niemand Skriptsprachen benutzen. Fakt ist
jedoch, daß Skriptsprachen heutzutage ganz weit vorne liegen: bei TIOBE
liegt Python auf Rang 4 hinter Java, C und C++ [1], bei PYPL auf Rang 2
hinter Java [2] und RedMonk [3] auf Rang 3 hinter JavaScript und Java.
> Wenn beide sprachen die gleichen Möglichkeiten bieten dann unterscheiden> es sich nur der Zeitdauern vom Compilieren und das macht niemals 90% der> Zeit aus.
Softwareentwicklung ist aber doch nicht nur Schreiben und Kompilieren,
sondern auch Testing, Debugging, Profiling, Qualitätssicherung und ein
paar anderen Aufgaben. In vielen dieser Bereiche haben Skriptsprachen
ein paar klare Performanzvorteile in der Entwicklung.
Hinzu kommt, daß es zum Beispiel für Perl und Python eine riesige
Vielzahl an fertigen Bibliotheken und Modulen gibt. Ja, die gibt es auch
für Java, C# und C++, aber die Skriptleute haben dafür zum Teil riesige
Repositories mit schlüssenfertigen, sofort benutzbaren, ausgetesteten,
stabilen Moduken und Bibliotheken, wie etwa in Perl das Comprehensive
Perl Archive Network (CPAN) mit seinem Modul zur Softwareinstallation
oder in Python den Python Package Index mit einem Programm namens pip.
Außerdem haben Skriptsprachen meistens bereits etliche Bibliotheken und
Module dabei, für die man sich in kompilierten Sprachen erst einmal
zeitaufwändig was zusammensuchen (und oft ausprobieren) muß -- alleine
Ubuntu-Linux führt aktuell 4474 Pythonmodule in seinen Repositories, die
nicht zur Standarddistribution von Python gehören.
> Der Vorteil vom Compilieren ist sogar das Schreibfehler bei Variabel und> Funktionen sofort auffallen, bei Scripsprachen erst zur Laufzeit (wobei> ich Python nicht kenne)
Ja, richtig. Dein Compiler warnt Dich sogar vor Typfehlern, wenn Du etwa
einer Funktion, die einen String erwartet, ein Integer übergibst. Vor
Schreibfehlern warnt mich schon mein Editor (GNU Emacs), wie trivial.
Das kann man in den aktuellen Versionen von Python3 mit sogenannten Type
Hints (ähnelt "Option Explicit" in VB) erzwingen, ist aber nicht Usus.
Üblicherweise wird der Typ einer Variablen in Python durch vom Typ ihres
Werts bestimmt. Damit kann sich ebenso böse in den Fuß schießen wie mit
Typecasts in kompilierten Sprachen... ;-)
Aber schau einfach mal in diese (unvollständige) Liste [4], um eine
grobe Vorstellung davon zu bekommen, was mit Python alles möglich ist.
[1] https://www.tiobe.com/tiobe-index/
[2] http://pypl.github.io/PYPL.html
[3] http://redmonk.com/sogrady/2017/03/17/language-rankings-1-17/
[4] https://en.wikipedia.org/wiki/List_of_Python_software
Sven B. schrieb:> Wenn man es richtig macht läuft Software vollkommen problemlos überall.> Das ist die Definition von "richtig macht". Die Frage ist ja wie schwer> das ist.
Nein, eben nicht. Man kann eine MFC-Anwendung in jedem Sinne von
"richtig" machen, und sie wird trotzdem nur unter Windows laufen. Man
kann eine WPF-Anwendung in jedem Sinne von "richtig" machen, und sie
wird trotzdem nur unter Windows laufen. Ähnliches gilt für WCF, ASP, und
XML.
Sheeva P. schrieb:> Softwareentwicklung ist aber doch nicht nur Schreiben und Kompilieren,> sondern auch Testing, Debugging, Profiling, Qualitätssicherung und ein> paar anderen Aufgaben. In vielen dieser Bereiche haben Skriptsprachen> ein paar klare Performanzvorteile in der Entwicklung.
welche Vorteile sollen das sein? Ich kann an den IDEs mit Debugging und
Profiling von C# und C++ nichts sehen was besser einer Scriptsprache
gehen würde?
> Hinzu kommt, daß es zum Beispiel für Perl und Python eine riesige> Vielzahl an fertigen Bibliotheken und Modulen gibt. Ja, die gibt es auch> für Java, C# und C++, aber die Skriptleute haben dafür zum Teil riesige> Repositories mit schlüssenfertigen, sofort benutzbaren, ausgetesteten,> stabilen Moduken und Bibliotheken, wie etwa in Perl das Comprehensive>Perl Archive Network (CPAN)
und hast du sie mal verwendet? Versuche mal mit Perl eine Excel zu
erzeugen. Ja es gibt viele Module - jedes hat andere Macken und die Doku
ist schrecklich. Die Qualität ist dabei nicht immer gegeben.
> Aber schau einfach mal in diese (unvollständige) Liste [4], um eine> grobe Vorstellung davon zu bekommen, was mit Python alles möglich ist.
es behauptet niemand das mit Python etwas nicht möglich ist. Aber das
man damit 10fach schneller ist als mit Java oder C# ist einfach
unrealistisch.
Peter II schrieb:> welche Vorteile sollen das sein? Ich kann an den IDEs mit Debugging und> Profiling von C# und C++ nichts sehen was besser einer Scriptsprache> gehen würde?
Ich glaube nicht das du jemals in einer Skriptsprache programmiert hast,
sonst würdest du so einen Unsinn hier nicht schreiben.
> es behauptet niemand das mit Python etwas nicht möglich ist. Aber das> man damit 10fach schneller ist als mit Java oder C# ist einfach> unrealistisch.
Ob das jetzt 10 mal sind weiß ich auch nicht. Auf jedenfall sehr, sehr
viel schneller.
Schon alleine eine Funktion aus einer Bib kurz testen um zu sehen ob sie
meinen Anforderungen genügt ist in Python wirklich kurz mit
Beispieldaten eingehackt.
Peter II schrieb:>> Aber schau einfach mal in diese (unvollständige) Liste [4], um eine>> grobe Vorstellung davon zu bekommen, was mit Python alles möglich ist.> es behauptet niemand das mit Python etwas nicht möglich ist. Aber das> man damit 10fach schneller ist als mit Java oder C# ist einfach> unrealistisch.
Für bestimmte Scopes ist Python wegen der Interpretierbarkeit, aber
insbesondere wegen den verbreiteten und gut verfügbaren Bibliotheken
viel besser geeignet als C++. In Python kann ich in weniger als zwei
Minuten aus dem interaktiven Interpreter eine CSV-Datei einlesen, die
enthaltenen Daten fouriertransformieren, und das Betragsquadrat in einem
beschrifteten Diagramm in ein PDF malen, das man so in jedem Paper
veröffentlichen könnte. In der Zeit hab ich in C++ noch nicht mal
angefangen zu fluchen wie unlesbar die fftw3-Doku ist ;)
Sven B. schrieb:>> Für bestimmte Scopes ist Python wegen der Interpretierbarkeit, aber> insbesondere wegen den verbreiteten und gut verfügbaren Bibliotheken> viel besser geeignet als C++. In Python kann ich in weniger als zwei> Minuten aus dem interaktiven Interpreter eine CSV-Datei einlesen, die> enthaltenen Daten fouriertransformieren, und das Betragsquadrat in einem> beschrifteten Diagramm in ein PDF malen, das man so in jedem Paper> veröffentlichen könnte. In der Zeit hab ich in C++ noch nicht mal> angefangen zu fluchen wie unlesbar die fftw3-Doku ist ;)
This
knallbär schrieb:> Peter II schrieb:>> welche Vorteile sollen das sein? Ich kann an den IDEs mit Debugging und>> Profiling von C# und C++ nichts sehen was besser einer Scriptsprache>> gehen würde?>> Ich glaube nicht das du jemals in einer Skriptsprache programmiert hast,> sonst würdest du so einen Unsinn hier nicht schreiben.
da irrst du dich, sind schon einige 1000 Zeilen Perl gewesen. Aus dem
Grund kann ich für mich aus Erfahrung sagen, das Perl nur für kleine
dinge gut ist, sobald es größer wird gehen ich lieber auf C# einsetze.
Sven B. schrieb:> Peter II schrieb:>>> Aber schau einfach mal in diese (unvollständige) Liste [4], um eine>>> grobe Vorstellung davon zu bekommen, was mit Python alles möglich ist.>> es behauptet niemand das mit Python etwas nicht möglich ist. Aber das>> man damit 10fach schneller ist als mit Java oder C# ist einfach>> unrealistisch.>> Für bestimmte Scopes ist Python wegen der Interpretierbarkeit, aber> insbesondere wegen den verbreiteten und gut verfügbaren Bibliotheken> viel besser geeignet als C++. In Python kann ich in weniger als zwei> Minuten aus dem interaktiven Interpreter eine CSV-Datei einlesen, die> enthaltenen Daten fouriertransformieren, und das Betragsquadrat in einem> beschrifteten Diagramm in ein PDF malen, das man so in jedem Paper> veröffentlichen könnte. In der Zeit hab ich in C++ noch nicht mal> angefangen zu fluchen wie unlesbar die fftw3-Doku ist ;)
hier wird aber wieder Sprache und Funktiosumfang vermischt. Wenn ich in
C# ein Klasse habe die genau das macht muss ich auch nur 1 Zeile code
schreiben.
Peter II schrieb:> hier wird aber wieder Sprache und Funktiosumfang vermischt. Wenn ich in> C# ein Klasse habe die genau das macht muss ich auch nur 1 Zeile code> schreiben.
Niemand hat behauptet, dass man auf Grund von Sprach-Features schneller
wäre... Es geht einzig und allein um den "Funktionsumfang" (in Form von
Bibliotheken). Und grad was Visualisierung und Datenbearbeitung angeht
ist Python schlichtweg konkurrenzlos.
Du behauptest ja selbst du kennst Python nicht. Vielleicht siehst du
jene Diskussion ja als Grund es dir mal anzusehen.
Peter II schrieb:> hier wird aber wieder Sprache und Funktiosumfang vermischt. Wenn ich in> C# ein Klasse habe die genau das macht muss ich auch nur 1 Zeile code> schreiben.
Ja, hast du aber nicht. Formal gesehen ist das natürlich völlig korrekt.
aber in der Praxis ist es halt einfach nicht so. Das macht halt den
Unterschied. In Python ist das Teil der, naja, nicht Standardbibliothek
aber Teil einer Bibliothek die so verbreitet ist dass sie immer überall
verfügbar ist und jeder sie benutzt, also quasi-Standard.
Vincent H. schrieb:> Niemand hat behauptet, dass man auf Grund von Sprach-Features schneller> wäre... Es geht einzig und allein um den "Funktionsumfang" (in Form von> Bibliotheken).
das habe ich hier aber anders gelesen
>> Wenn beide sprachen die gleichen Möglichkeiten bieten dann unterscheiden>> es sich nur der Zeitdauern vom Compilieren und das macht niemals 90% der>> Zeit aus.> Softwareentwicklung ist aber doch nicht nur Schreiben und Kompilieren,> sondern auch Testing, Debugging, Profiling, Qualitätssicherung und ein> paar anderen Aufgaben. In vielen dieser Bereiche haben Skriptsprachen> ein paar klare Performanzvorteile in der Entwicklung.
Schau Dir mal "TCP/IP Lean" von Jeremy Bentham an.
Zugriff vom PC aus über eine SLIP Verbindung, Darstellung Deiner Daten
im Web-Browser.
Das Buch gibt es gebraucht für wenig Knete und ne CD mit allen
Beispielen ist mit dabei. Und es ist gut zum Lernen geschrieben.
Gutt Lack, Tom.
Peter II schrieb:> Vincent H. schrieb:>> Niemand hat behauptet, dass man auf Grund von Sprach-Features schneller>> wäre... Es geht einzig und allein um den "Funktionsumfang" (in Form von>> Bibliotheken).>> das habe ich hier aber anders gelesen>>>> Wenn beide sprachen die gleichen Möglichkeiten bieten dann unterscheiden>>> es sich nur der Zeitdauern vom Compilieren und das macht niemals 90% der>>> Zeit aus.>> Softwareentwicklung ist aber doch nicht nur Schreiben und Kompilieren,>> sondern auch Testing, Debugging, Profiling, Qualitätssicherung und ein>> paar anderen Aufgaben. In vielen dieser Bereiche haben Skriptsprachen>> ein paar klare Performanzvorteile in der Entwicklung.
Hast du schonmal mit Matlab debugged? (Auch eine Skriptsprache, aber
properitär)
Vergleiche das mit debugging mit einer beliebigen C++ IDE.
Außerdem war der Diskussionspunkt eben folgender:
Sheeva P. schrieb:> Peter II schrieb:>> Sheeva P. schrieb:>>> Letztlich geht es um Entwicklungs- versus Laufzeitperformanz. Mit>>> modernen Skriptsprachen kann man etwa bis zu zehnmal (zB. Python vs.>>> Java) so schnell entwickeln,>>>> das ist Unsinn.>> Nein, Peter, das ist es erfreulicherweise nicht. [...]
Und für Entwicklungszeit spielt der Funktionsumfang eben die wesentlich
Rolle.
Peter II schrieb:> da irrst du dich, sind schon einige 1000 Zeilen Perl gewesen.
Dann solltest du wissen, dass nicht deklarierte Variablen in Perl schon
zur Compilezeit - ja, Perl hat eine Compilezeit! - abgefangen werden.
Man muss nur "use strict" oben hinschreiben, bevorzugt auch "use
warnings".
S. R. schrieb:> Dann solltest du wissen, dass nicht deklarierte Variablen in Perl schon> zur Compilezeit - ja, Perl hat eine Compilezeit! - abgefangen werden.>> Man muss nur "use strict" oben hinschreiben, bevorzugt auch "use> warnings".
das hilft nur nicht bei Schreibfehler von Funktionsname.
Man kann die Liste in Python sogar dynamisch erzeugen, ohne sie einer
Variablen zuzuweisen (das nutze ich ziemlich oft bei der Verarbeitung
von Daten in Dictionaries):
1
for i in ["a", "b", "c"]:
2
# do sth with i
Tatsächlich funktioniert letzteres sogar mit einem String, denn Strings
sind in Python einfache Iterables:
1
for i in "abc":
2
# do sth with i
Und dazu kommen dann noch Builtin-Funktionen wie map(), zip(), filter(),
List- und Dict-Comprehensions... Das sind alles Features aus dem Kern
der Sprache, die zur hohen Ausdrucksstärke von Python beitragen und bei
der Verarbeitung von Listen und Dictionaries zu einem Kinderspiel
machen.
knallbär schrieb:> Hast du schonmal mit Matlab debugged? (Auch eine Skriptsprache, aber> properitär)
Nein, habe ich nicht. Aber Ausnahmen bestätigen bekanntlich die Regel,
und eine proprietäre Sprache macht natürlich das was jede proprietäre
Software macht: ihre Geschäftsgeheimnisse schützen.
> Und für Entwicklungszeit spielt der Funktionsumfang eben die wesentlich> Rolle.
Was meinst Du mit "Funktionsumfang". Gehören Dynamic Typing, List- und
Dict-Comprehensions zum Funktionsumfang? Builtin-Funktionen? Lambdas?
Generatoren, Iteratoren? Gehört alles zum Sprachkern. Aber was ist mit
Standardmodulen wie csv oder argparse? ...Am Ende läuft das auf eine
kindisch-akademische Debatte hinaus wie die Frage, ob die
C-Standardbibliothek zum Sprachkern von C gehört oder ob das wie eine
externe Bibliothek anzusehen ist.
Fakt ist: es gibt eine Vielzahl an Features im Python-Interpreter
selbst, aber auch in den standardmäßig mitgelieferten Modulen, die die
Entwicklung von Software erheblich beschleunigen. Und die riesige
Vielzahl an fertigen externen Modulen beschleunigt die Sache nochmals
zusätzlich.
Sheeva P. schrieb:> Man kann die Liste in Python sogar dynamisch erzeugen, ohne sie einer> Variablen zuzuweisen (das nutze ich ziemlich oft bei der Verarbeitung> von Daten in Dictionaries):> for i in ["a", "b", "c"]:> # do sth with i
und was soll daran besonders sein, was nur in scriptsprachen geht?
C#
1
foreach (var x in new int[] { 1, 3, 5, 7, 9 } )
2
{
3
}
> Tatsächlich funktioniert letzteres sogar mit einem String, denn Strings> sind in Python einfache Iterables:
auch nichts besonders
1
foreach (var x in "abc") {
2
System.Diagnostics.Debug.Write(x);
3
}
also nichts was irgendwie nur ein Scripsprachen geht.
Peter II schrieb:> knallbär schrieb:>> Ich glaube nicht das du jemals in einer Skriptsprache programmiert hast,>> sonst würdest du so einen Unsinn hier nicht schreiben.>> da irrst du dich, sind schon einige 1000 Zeilen Perl gewesen. Aus dem> Grund kann ich für mich aus Erfahrung sagen, das Perl nur für kleine> dinge gut ist, sobald es größer wird gehen ich lieber auf C# einsetze.
Perl ist tatsächlich auch für größere Dinge gut, und das sagt Dir
jemand, der Perl über fünfzehn Jahre als Feld-, Wald- und Wiesensprache
für alles inkl. GUI-Software mit Qt benutzt und sicherlich einige 100
kLOC in Perl geschrieben hat. Für Python, das Perl in dieser Rolle bei
mir vor etwas über zehn Jahren abgelöst hat und das ein wesentlich
saubereres OO-Design besitzt, gilt das noch mehr.
Schau doch einfach mal auf die oben verlinkte Liste von
Python-Programmen, da sind viele riesige Projekte dabei: IDEs,
Videospiele, wissenschaftliche und mathematische Software, Instant
Messenger, Spreadsheet-Applikationen, Machine Learning, um nur ein paar
zu nennen.
Und dann stell' Dir doch bitte einfach mal selbst die Frage, warum
Python erfolgreicher und weiter verbreitet ist als C# -- übrigens nicht
zuletzt auch in der Wissenschaft, wo es oft um die Analyse und
Visualisierung von riesigen Datenmengen und -Strukturen geht. Sind die
Nutzer alle dumm, daß sie die Vorzüge von C# nicht sehen, wenn das doch
die perfekte und allein seligmachende Sprache ist?
> hier wird aber wieder Sprache und Funktiosumfang vermischt. Wenn ich in> C# ein Klasse habe die genau das macht muss ich auch nur 1 Zeile code> schreiben.
Wenn Du immer eine Klasse hast, die genau das macht was Du willst, dann
brauchst Du keine Entwickler mehr.
Nein, im Ernst: wir können gerne diskutieren, wenn Du mal mehr als nur
ein paar kLOC in einer Skriptsprache gehackt hast. Dann weißt Du nämlich
erst, wovon ich rede -- obwohl: dann wirst Du es wirklich wissen, und
die ganze Diskussion wird sich damit komplett erübrigt haben. ;-)
Am Ende noch ein Tipp: auch wenn man sich bereits in seiner persönlichen
Wohlfühlzone wähnt und glaubt, daß man für sich selbst die ideale
Sprache gefunden hat, lohnt es sich immer, über den eigenen Tellerrand
zu schauen. Ich persönlich habe mit jeder neuen Sprache, die ich gelernt
habe, einige neue Tricks und Kniffe kennengelernt, die ich dann auch in
meinen anderen Sprachen gewinnbringend einsetzen konnte. YMMV.
Peter II schrieb:> und was soll daran besonders sein, was nur in scriptsprachen geht?
Wir reden weiter, wenn Du es wirklich verstehen willst -- anstatt
ständig immer nur beweisen zu wollen, was mit Deinem geliebten C# alles
geht.
Sheeva P. schrieb:> Und dann stell' Dir doch bitte einfach mal selbst die Frage, warum> Python erfolgreicher und weiter verbreitet ist als C# -- übrigens nicht> zuletzt auch in der Wissenschaft, wo es oft um die Analyse und> Visualisierung von riesigen Datenmengen und -Strukturen geht. Sind die> Nutzer alle dumm, daß sie die Vorzüge von C# nicht sehen, wenn das doch> die perfekte und allein seligmachende Sprache ist?
dann lebst du auf einen anderen Teller als ich. Bei uns in der
Entwicklung können von 20 Leute nur einer Python die anderen C# oder
C++.
In meinen Umfeld habe ich kein Python script am laufen, dafür viele C#
und C++ Programme. Das es in andere Firmen anders ist kann durchaus
sein, ich würde zumindest nicht behaupten das C# deswegen
erfolgreicherer als Python ist.
Bis jetzt hast du immer noch kein Argument gebracht, warum man mit
Python 10mal schneller sein sollte also mit einer kompilierten Sprache.
Und für riesigen Datenmengen verwenden wir Datenbankserver und keine
Skripte.
Daniel A. schrieb:> [...C und C++-Code...]
Jungs, vielleicht habt Ihr meine Beiträge nicht so aufmerksam gelesen,
aber meine Vergleiche bezog ich eigentlich ausschließlich auf Java --
weil das nämlich eine automatische Speicherverwaltung hat und darum die
kompilierte Sprache ist, die ich am Ehesten mit Python vergleichen kann.
C und C++ haben keine automatische Speicherverwaltung (und bevor jetzt
wieder einer klugscheißt: ja, ich kenne Smartpointer und auch den
Boehm-GC), und C# kenne ich nicht gut genug für einen solchen Vergleich.
Deswegen rede ich bei so etwas lieber über Dinge, von denen ich was
verstehe -- und die sich auch halbwegs seriös und sinnvoll miteinander
vergleichen lassen.
Ansonsten kommt Ihr vielleicht auf die Idee, was gemeint ist, wenn Ihr
den kompakten, leicht und mit einem Blick erkennbaren Python-Code mit
den von Euch produzierten Sonderzeichenwüsten vergleicht. Natürlich
wirkt sich auch die Les- und Schreibbarkeit von Code auf die
Entwicklerperformance aus. Die beiden Python-Beispiele enthalten 15 bzw.
25 Zeichen, Peters C#-Beispiel kommt auf 47 Zeichen, Dein C++11-Beispiel
kommt auf 31 und Dein C-Beispiel sogar auf 75 Zeichen.
Geübte Zehn-Finger-Tipper kommen auf 200 bis 400 Anschläge pro Minute,
im Mittelwert also 5 Anschläge pro Sekunde. Umgerechnet auf Eure
Beispiele heißt das, daß der Python-Code in 3 bis 5 eingegeben werden
kann, während der C#-Code etwa 9,4, das C++11-Beispiel 6,2 und das
C-Beispiel sogar 15 Sekunden für die reine Eingabe des Code benötigt.
Und dabei habe ich noch kein Wort die Eingabe von Sonderzeichen wie "{"
und "[" gesagt, die ja zumindest auf deutschen Tastaturen nur mit
Tastenkombinationen erreicht werden können. Und ich habe, vor allem,
kein Wort über die Lesbarkeit verloren. Schon an diesem popeligen
Minimalstbeispiel könnt Ihr einen wichtigen Grund sehen, warum die
Entwicklerperformanz in Skriptsprachen deutlich höher ist: der Code ist
einfach viel kürzer, und dabei haben wir echte
Kompaktheits-Killerfeatures wie List- und Dict-Comprehensions noch gar
nicht angeschaut. Damit kann man Dinge in ein, zwei Zeilen machen,
welche in Java locker eine Bildschirmseite Code brauchen würden.
Außerdem haben wir dabei noch nicht einmal über Dynamic Typing geredet
-- in Python können Listen und Tupel nämlich Elemente unterschiedlicher
Datentypen enthalten:
1
for i in ["a", 10, 10.1, dict()]:
2
# do sth with i
Bildet das doch mal in C#, C oder C++ ab -- ohne Tricks und Libraries,
nur mit den Features im Sprachkern. ;-)
Sheeva P. schrieb:> Schon an diesem popeligen Minimalstbeispiel könnt> Ihr einen wichtigen Grund sehen, warum die> Entwicklerperformanz in Skriptsprachen deutlich höher> ist: der Code ist einfach viel kürzer, [...]
Naja, ich denke, Du machst einen wesentlichen Fehler: Du
betrachtest die Entwicklerperformanz völlig losgelöst
von der Projektgröße und von der Erfahrung des Entwicklers.
Das muss mMn schiefgehen.
Sheeva P. schrieb:> Die beiden Python-Beispiele enthalten 15 bzw.> 25 Zeichen, Peters C#-Beispiel kommt auf 47 Zeichen, Dein C++11-Beispiel> kommt auf 31
Das C++11 Beispiel entsprach nicht dem "15" Zeichen python ausschnit.
Ausserdem war der python ausschnitt syntaktisch unvolständig, und die
Abstände hätte man bei C auch nicht mitzählen müssen, da die anders als
in python meist optional sind.
Leere schleife über die Zeichen a, b und c, in C++11, 18 Zeichen:
1
for(autoi:"abc");
Leere schleife über die Zeichen a, b und c, in python 22 Zeichen:
1
foriin"abc":
2
pass
Jedes dieser Zeichen ist notwendig, bei python auch die 2 newlines und
dass pass, denn eine python schleife braucht einen inhalt. Das python
Beispiel ist also sogar 4 Zeichen länger!
Wo wir schon bei abständen sind, python ist wirklich Produktiv wenn man
mal ein paar abstände durcheinander bringt oder einen tab erwischt, und
von den typos, die erst zur laufzeit auffallen, will ich garnicht erst
anfangen...
Peter II schrieb:> Sheeva P. schrieb:>> Und dann stell' Dir doch bitte einfach mal selbst die Frage, warum>> Python erfolgreicher und weiter verbreitet ist als C# -- übrigens nicht>> zuletzt auch in der Wissenschaft, wo es oft um die Analyse und>> Visualisierung von riesigen Datenmengen und -Strukturen geht. Sind die>> Nutzer alle dumm, daß sie die Vorzüge von C# nicht sehen, wenn das doch>> die perfekte und allein seligmachende Sprache ist?>> dann lebst du auf einen anderen Teller als ich. Bei uns in der> Entwicklung können von 20 Leute nur einer Python die anderen C# oder> C++.
Natürlich, Du Genie, weil Ihr Euch die so ausgesucht habt.
> In meinen Umfeld habe ich kein Python script am laufen
Hatte ich nicht oben auf renommierte Indizes wie TIOBE, RedMonk und PYPL
verwiesen? Wenn Du die Links nicht liest, die ich Dir gebe, bestätigt
das meinen Verdacht, daß es Dir hier nicht um den Erkenntnisgewinn geht.
> Bis jetzt hast du immer noch kein Argument gebracht, warum man mit> Python 10mal schneller sein sollte also mit einer kompilierten Sprache.
Dann solltest Du meine Beiträge noch einmal lesen, diesmal vielleicht
der Abwechslung halber auch mal mit dem Ziel, sie zu verstehen.
> Und für riesigen Datenmengen verwenden wir Datenbankserver und keine> Skripte.
Tja, wer nur einen Hammer hat... Abgesehen davon fürchte ich, daß ich
unter "riesige Datenmengen" etwas ganz anderes verstehe als Du, nämlich
BigData.
Possetitjel schrieb:> Naja, ich denke, Du machst einen wesentlichen Fehler: Du> betrachtest die Entwicklerperformanz völlig losgelöst> von der Projektgröße und von der Erfahrung des Entwicklers.>> Das muss mMn schiefgehen.
Warum sollte das schiefgehen? Nichts davon hat mit den Eigenschaften
einer Programmiersprache zu tun, und die inhärenten Stärken von
Skriptsprachen kommen in jeder Projektgröße zum Tragen und sind gänzlich
unabhängig von der Erfahrung des Entwicklers.
Daniel A. schrieb:> Leere schleife über die Zeichen a, b und c, in python 22 Zeichen:>
1
>foriin"abc":
2
>pass
3
>
>> Jedes dieser Zeichen ist notwendig, bei python auch die 2 newlines und> dass pass, denn eine python schleife braucht einen inhalt. Das python> Beispiel ist also sogar 4 Zeichen länger!
Den Newline hinter dem ":" kannst Du weglassen und das "pass" einfach
durch einen Dummy ersetzen, schon sind's wieder 16 Zeichen -- also
wieder zwei Zeichen kürzer als Dein maximal eingedampfter C++-Code.
1
for i in "abc":1
> Wo wir schon bei abständen sind, python ist wirklich Produktiv wenn man> mal ein paar abstände durcheinander bringt oder einen tab erwischt, und> von den typos, die erst zur laufzeit auffallen, will ich garnicht erst> anfangen...
Hast Du praktische Erfahrung mit Python? In meiner Praxis habe ich
solche Probleme nämlich nicht und kenne solche Aussagen auch eigentlich
nur von Leuten, die keine bis wenig Erfahrung mit der Sprache haben.
Sheeva P. schrieb:> renommierte Indizes wie TIOBE
Dort wo BASIC (VB .net 3% und VB 2% zusammen) mit 5% deutlichst vor
Python mit 3.5% liegt was dazu jeden Monat immer weiter verliert :-)
Sheeva P. schrieb:> Die beiden Python-Beispiele enthalten 15 bzw. 25 Zeichen, Peters C#-> Beispiel kommt auf 47 Zeichen, Dein C++11-Beispiel kommt auf 31 und Dein> C-Beispiel sogar auf 75 Zeichen.>> Geübte Zehn-Finger-Tipper kommen auf 200 bis 400 Anschläge pro Minute,> im Mittelwert also 5 Anschläge pro Sekunde. Umgerechnet auf Eure> Beispiele heißt das, daß der Python-Code in 3 bis 5 eingegeben werden> kann, während der C#-Code etwa 9,4, das C++11-Beispiel 6,2 und das> C-Beispiel sogar 15 Sekunden für die reine Eingabe des Code benötigt.
Um ehrlich zu sein, lässt diese Aussage nicht unbedingt den Rückschluss
auf eine umfangreiche Erfahrung im Bereich der Software-Entwicklung zu.
Du solltest sonst eigentlich wissen, dass die reine Zahl der Zeichen und
die Sekunden, die man zum Eintippen braucht, recht unerheblich sind im
Vergleich zu der Zeit, die man für die anderen Teile der Entwicklung wie
Design, Kommunikation, Issue Tracking, Doku lesen, Testen, Debuggen, ...
braucht.
Man rechnet üblicherweise damit, dass ein durchschnittlicher Entwickler
pro Tag eine Codzeilenzahl im unteren zweistelligen Bereich produziert.
Da ist es völlig egal, ob der jetzt für eine davon 5 oder 15 Sekunden
zum hinschreiben braucht.
Das gilt natürlich nur für richtige Software-Entwicklung. Bei einem
Wegwerfskript für den einmaligen Gebrauch mag das etwas anders sein. Da
interessiert aber auch die Lesbarkeit keinen.
> Und ich habe, vor allem, kein Wort über die Lesbarkeit verloren. Schon an> diesem popeligen Minimalstbeispiel könnt Ihr einen wichtigen Grund sehen,> warum die Entwicklerperformanz in Skriptsprachen deutlich höher ist: der> Code ist einfach viel kürzer,
Code wird nicht automatisch lesbarer, nur weil er in ein paar Zeichen
weniger getippt werden kann.
> und dabei haben wir echte Kompaktheits-Killerfeatures wie List- und Dict-> Comprehensions noch gar nicht angeschaut. Damit kann man Dinge in ein,> zwei Zeilen machen, welche in Java locker eine Bildschirmseite Code> brauchen würden.
Da kommen wir schon eher in einen Bereich, wo es einen signifikanten
Unterschied machen kann. Ob ich einen Algorithmus in wenigen Zeilen
statt einer ganzen Seite formulieren kann, wäre für mich eher ein
Kriterium als die Zahl ein Zeichen, die man für eine for-Schleife
eingeben muss.
Sheeva P. schrieb:> Den Newline hinter dem ":" kannst Du weglassen und das "pass" einfach> durch einen Dummy ersetzen, schon sind's wieder 16 Zeichen -- also> wieder zwei Zeichen kürzer als Dein maximal eingedampfter C++-Code.> for i in "abc":1
Also hier wird's ja nun wirklich albern. Ob eine auf ein eher
unleserliches Minimum zusammengeschrumpfte nutzlose leere Schleife nun
in zwei Zeichen mehr oder weniger hingeschrieben werden kann, das ist
dein Kriterium für die Effizienz, mit der man in der Sprache entwickeln
kann? Ernsthaft?
Rolf M. schrieb:> Du solltest sonst eigentlich wissen, dass die reine Zahl der Zeichen und> die Sekunden, die man zum Eintippen braucht, recht unerheblich sind im> Vergleich zu der Zeit, die man für die anderen Teile der Entwicklung wie> Design, Kommunikation, Issue Tracking, Doku lesen, Testen, Debuggen, ...> braucht.
Natürlich weiß ich das, und in meinen vorherigen Beiträgen steht das
auch ziemlich genau so drin. Dabei ging es mir nur um ein möglichst
einfaches, nachvollziehbares und vergleichbares Beispiel. Andererseits
weiß ich aus meinen Erfahrungen mit Java und C++ aber auch, daß das
reine Eingeben des Code eben auch einen gewissen Anteil hat.
> Code wird nicht automatisch lesbarer, nur weil er in ein paar Zeichen> weniger getippt werden kann.
Nicht automatisch, natürlich. Aber kürzerer Code kann gemeinhin
schneller gelesen und erfaßt werden, und die vielfache Verwendung von
Sonderzeichen macht Code ebenfalls nicht besser lesbar, oder?
>> und dabei haben wir echte Kompaktheits-Killerfeatures wie List- und>> Dict-Comprehensions noch gar nicht angeschaut.>> Da kommen wir schon eher in einen Bereich, wo es einen signifikanten> Unterschied machen kann. Ob ich einen Algorithmus in wenigen Zeilen> statt einer ganzen Seite formulieren kann, wäre für mich eher ein> Kriterium als die Zahl ein Zeichen, die man für eine for-Schleife> eingeben muss.
Deswegen bezeichne ich diese Dinge ja auch als "Killerfeature". Nochmal:
die Zeichenanzahl war nur ein Beispiel, um zu zeigen, warum Python-Code
bereits bei so einfachen Beispielen kompakter und sowohl deswegen als
auch aufgrund der geringeren Anzahl an Sonderzeichen, mit denen er
auskommt, erheblich besser und schneller lesbar ist. Bei so einem
Vergleich kommt es ja immer auch auf Vergleichbarkeit an -- deswegen
habe ich erstens völlig bewußt ein möglichst einfaches Beispiel gewählt,
für das es zweitens auch in kompilierten Sprachen ein Äquivalent gibt.
Wir können stattdessen aber auch gerne eine List-Comprehension benutzen.
Etwa ein Fragment aus aktuellem Code, das Daten der NICB ([1]) in einen
Elasticsearch-Cluster füttert und Namen wie "SANCHEZ, JORGE" und "jorge
sanchez " in einheitliche Tupel wie ("Jorge", "Sanchez") normalisiert:
1
(m.capitalize() for m in (' '.join(
2
(n.strip() for n in reversed(name.split(','))) ).split()
3
) if m.strip() != '')
Ja, da muß man sich schon ein bisschen Zeit nehmen, um das zu verstehen,
aber ich bezweifle, daß entsprechender Code in C, C++, C# oder Java
(auch bei entsprechender Erfahrung) schneller gelesen und verstanden
werden kann.
> Sheeva P. schrieb:>> Den Newline hinter dem ":" kannst Du weglassen und das "pass" einfach>> durch einen Dummy ersetzen, schon sind's wieder 16 Zeichen -- also>> wieder zwei Zeichen kürzer als Dein maximal eingedampfter C++-Code.>> for i in "abc":1>> Also hier wird's ja nun wirklich albern. Ob eine auf ein eher> unleserliches Minimum zusammengeschrumpfte nutzlose leere Schleife nun> in zwei Zeichen mehr oder weniger hingeschrieben werden kann, das ist> dein Kriterium für die Effizienz, mit der man in der Sprache entwickeln> kann? Ernsthaft?
Entschuldige, aber das Beispiel mit der auf ein unleserliches Minimum
eingedampften, nutzlosen leeren Schleife war nicht von mir, sondern von
Daniel Albrecht. Darauf bin ich lediglich eingegangen und habe gezeigt,
warum sogar dieses sein Beispiel einen -- wenngleich winzigen -- Vorteil
für Python bietet, im Gegensatz zu seiner vorherigen Behauptung.
Insofern hast Du zwar vollkommen Recht, daß das albern ist, aber
diesbezüglich bin ich zum Glück nicht der richtige Adressat für Deine
Beschwerde.
[1] http://www.nicb.org/
Lothar schrieb:> Sheeva P. schrieb:>> renommierte Indizes wie TIOBE>> Dort wo BASIC (VB .net 3% und VB 2% zusammen) mit 5% deutlichst vor> Python mit 3.5% liegt was dazu jeden Monat immer weiter verliert :-)
Ehrlich gesagt verstehe ich leider nicht, was Du mir damit sagen
möchtest. Visual Basic wird gerne und oft benutzt, niemand bestreitet
das, aber hier ging und geht es doch gar nicht um Visual Basic?!
Zudem kommt Visual Basic in den Indizes von RedMonk nicht einmal unter
die ersten zwanzig, und liegt bei PyPL lediglich auf Platz 14.
Außerdem kannst Du bei TIOBE die betreffenden Sprachen anklicken und
bekommst dann einen hübschen Verlauf über die letzten Jahre angezeigt.
Dort kannst Du sehen, daß Python im Februar 2011 einen Höhepunkt von
guten 7%, im April 2014 einen Tiefpunkt von knapp 2% hatte und dann in
den letzten zwei Jahren stetig zwischen 3,3 und 4,5 % gelegen hat. Wie
Du angesichts dessen zu der Aussage kommst, daß Python "jeden Monat
immer weiter verlieren" würde, ist mir daher einigermaßen schleierhaft.
Ich lese aus den Daten von TIOBE eher, daß Python in den letzten beiden
Jahren bei ungefähr 3,9% stagniert.
Sheeva P. schrieb:> Wir können stattdessen aber auch gerne eine List-Comprehension benutzen.> Etwa ein Fragment aus aktuellem Code, das Daten der NICB ([1]) in einen> Elasticsearch-Cluster füttert und Namen wie "SANCHEZ, JORGE" und "jorge> sanchez " in einheitliche Tupel wie ("Jorge", "Sanchez") normalisiert:> (m.capitalize() for m in (' '.join(> (n.strip() for n in reversed(name.split(','))) ).split()> ) if m.strip() != '')>> Ja, da muß man sich schon ein bisschen Zeit nehmen, um das zu verstehen,
Damit sagst du es ja selber: Der Code ist schlecht lesbar. Und in dem
Fall ist das tatsächlich gerade deshalb so, weil er so kurz ist. Würde
man das alles auseinanderziehen, wäre sehr viel leichter zu erkennen,
was da passiert. Hier sind dazu viel zu viele Verschachtelungen und
Klammerungen vorhanden.
> aber ich bezweifle, daß entsprechender Code in C, C++, C# oder Java> (auch bei entsprechender Erfahrung) schneller gelesen und verstanden> werden kann.
Ich glaube, dass er auch in Python schneller gelesen und verstanden
werden könnte, wenn man nicht an jeder Stelle auf Biegen und Brechen
versucht hätte, es möglichst "pythonesque" zu machen.
> Entschuldige, aber das Beispiel mit der auf ein unleserliches Minimum> eingedampften, nutzlosen leeren Schleife war nicht von mir, sondern von> Daniel Albrecht.
Es ist eigentlich egal, wer damit nun angefangen hat. Du hast recht, das
er bei diesem "Wettrüsten" darüber, wer den kleinsten hat (also, Code
meine ich) genauso mitgemacht hat. Also geht meine Kritik an euch beide
gleichermaßen.
Sheeva P. schrieb:> die inhärenten Stärken von Skriptsprachen
Programmiersprachen sind ein Hilfmittel für MENSCHEN,
nicht für Computer. Der Computer ist mit Brainfuck
genauso zufrieden.
Die von Dir behaupteten inhärenten Stärken von Script-
sprachen gelten daher immer nur für bestimmte Klassen
von Menschen mit bestimmten Fähigkeiten und Vorkenntnissen.
Deine Argumentation läuft darauf hinaus, dass Englisch
"inhärent besser" als Russisch ist, weil die mittlere
Wortlänge im Englischen kleiner ist als im Russischen
(das ist tatsächlich so).
Du hast keine Vorstellung, warum das ein in Russland
aufgewachsener Dichter mit Muttersprache Russisch
anders sieht?
Possetitjel schrieb:> Sheeva P. schrieb:>> die inhärenten Stärken von Skriptsprachen>> Programmiersprachen sind ein Hilfmittel für MENSCHEN,> nicht für Computer.
Programmiersprachen sind ein Hilfsmittel für Menschen, um dem Computer
zu sagen, wie er bestimmte Probleme lösen soll. Einige davon sind
besonders gut für die Formulierung von bestimmten Problemlösungen
geeignet, andere sind eher Allrounder und zur Lösung verschiedener
Probleme geeignet.
Ganz allgemein sind Programmiersprachen aber stark formalisiert, damit
der Computer -- der ja nur eine blöde Rechenmaschine ohne Intuition,
Fantasie und Kreativität ist -- sie überhaupt verstehen kann. Und im
Prinzip sind die Mittel und Möglichkeiten der verbreitetsten
Programmiersprachen im Grunde ja dann auch ziemlich ähnlich -- weil sie
nämlich das, und nur das abbilden müssen und können, was der Computer
verstehen und umsetzen kann.
Insofern sind Programmiersprachen ein Hilfsmittel für beide, den
Menschen und den Computer. Für den Menschen, um seine Probleme
computerkompatibel zu formulieren, und für den Computer, um zur
Kompilier- oder Laufzeit daraus Maschinencode zu erzeugen und
auszuführen.
> Der Computer ist mit Brainfuck genauso zufrieden.
Das ist natürlich richtig, aber gerade dieses Beispiel zeigt, daß die
verschiedenen Sprachen jeweils ihre eigenen Vorzüge und eben auch ihre
eigenen Nachteile haben. Brainfuck, zum Beispiel, hat ein extrem simples
Sprachkonzept und ist gut geeignet, die Grundlagen der Computertechnik
zu erlernen. Andererseits ist es umständlich und ineffizient zu
benutzen, weswegen niemand diese Sprache ernsthaft in der Praxis
einsetzt.
Deswegen kann man generell sagen, daß Programmiersprachen, die in
nativen Maschinencode kompiliert werden, besonders gut für Probleme
geeignet sind, bei denen es auf eine besonders hohe Performanz und /
oder einen besonders geringen Ressourcenverbrauch ankommt.
Interpretierte Sprachen -- also: Skriptsprachen -- sind meistens weniger
performant und benötigen mehr Ressourcen für den Interpreter und dessen
zur Laufzeit stattfindende Übersetzung, vereinfachen und beschleunigen
aber die Programmierung und sind daher besonders gut geeignet, wenn der
Programmcode besonders schnell erstellt oder oft an neue Anforderungen
angepaßt werden muß.
Insofern geht es um eine Abwägung von Entwicklungszeit zu Laufzeit, und
wie immer sind die Hintergründe am Ende ökonomische. Mit entsprechendem
Aufwand an Hardwareressourcen kann ich auch eine Skriptsprache schnell
machen, und mit entsprechendem Aufwand an Entwicklerressourcen auch in
kompilierten Sprachen schnell entwickeln. Die Frage ist unterm Strich
immer, was preiswerter, was effizienter ist: große Hardware oder viele
Entwickler.
Erschwerend kommt da aber noch ein Aspekt hinzu: mit zunehmender Größe
des Entwicklungsteams oder der Hardwareressourcen steigen die Aufwände
für die Koordination und Kommunikation, dementsprechend sinkt die
Effizienz -- und zwar üblicherweise nicht linear, sondern exponentiell.
Sinkende Effizienz bedeutet aber wiederum steigende Kosten.
Deswegen werden bestimmte Problemfelder eindeutig die Domäne bestimmter
Sprachfamilien bleiben, jedenfalls auf absehbare Zeit. Webentwicklung
zum Beispiel wird auch weiterhin meist mit Skriptsprachen gemacht,
Embedded-Software überwiegend mit kompilierten Sprachen. In anderen
Bereichen wie Datenanalyse und -visualisierung und Machine Learning
werden allerdings heute schon beide Sprachfamilien eingesetzt. Zum Teil
verschwimmen die Grenzen auch, weil neue Tools verfügbar werden -- so
gibt es mittlerweile Embedded-Geräte, die in Micropython programmiert
werden können, und weil Compiler wie nuitka, der Python in C++
übersetzen und so zumindest einen Teil der Laufzeitnachteile egalisieren
kann.
> Die von Dir behaupteten inhärenten Stärken von Script-> sprachen gelten daher immer nur für bestimmte Klassen> von Menschen mit bestimmten Fähigkeiten und Vorkenntnissen.
Nein, eben nicht. Bestimmte Sprachen und Sprachfamilien haben bestimmte
Stärken und bestimmte Schwächen, genau wie andere Werkzeuge auch. Einen
etwas älteren Artikel aus Dr. Dobbs dazu findest Du hier: [1]. Ja, es
gibt Gründe, warum man mit klassischem ASP (das leider die einzige
halbwegs echte Skriptsprache in diesem Vergleich ist) und VB (das
ebenfalls einige Eigenschaften von Skriptsprachen hat) deutlich
schneller entwickeln kann, als mit Java, C++, C und C#. Wobei mich das
schlechte Abschneiden von C# ein wenig verwundert, aber ok, der Artikel
ist schon alt und seine wahren Stärken spielt C# wohl erst mit dem
.NET-Framework aus, das damals noch ziemlich in den Kinderschuhen
steckte.
All das hat zunächst nichts mit Menschen, ihren Fähigkeiten oder ihren
Kenntnissen zu tun. Zwar wird ein Entwickler, der eine Sprache besser
beherrscht als eine andere, in der besser beherrschten Sprache schneller
zum Ziel kommen als mit der anderen Sprache. Aber ein solcher Vergleich
würde nichts über die beiden Sprachen, sondern höchstens über die Skills
des Entwicklers in diesen Sprachen aussagen. Um die Vor- und Nachteile
bestimmter Sprachfamilien zu beleuchten, ist das ziemlich irrelevant.
> Deine Argumentation läuft darauf hinaus, dass Englisch> "inhärent besser" als Russisch ist, weil die mittlere> Wortlänge im Englischen kleiner ist als im Russischen> (das ist tatsächlich so).>> Du hast keine Vorstellung, warum das ein in Russland> aufgewachsener Dichter mit Muttersprache Russisch> anders sieht?
Englisch und Russisch sind Sprachen, die der Kommunikation unter
Menschen dienen. Im Gegensatz zu Programmiersprachen sind die
natürlichen Sprachen im Allgemeinen viel weniger formalisiert und sind
schon deswegen weniger gut für die Mensch-Maschine-Kommunikation
geeignet. Wenn es nicht so wäre, könnten wir unsere Computer nämlich per
Freitext in unserer Muttersprache programmieren.
Aber Menschen haben Intuition, Kreativität, und Fantasie, und sie sind
im Gegensatz zu Computern fehlertolerant. Wenn Du Dir alleine mal
anschauen magst, wie kompliziert phonetische Suchen mit Algorithmen wie
Soundex-, Metaphone- oder Beider-Morse-Algorithmen sind, oder wie
rechenaufwändig Wortabstände nach Levenshtein oder Damerau-Levenshtein
berechnet werden, und das einmal kurz damit vergleichst, wie
selbstverständlich wir beide über Tipp- und andere Fehler hinweglesen --
oft bemerken wir sie nicht einmal, weil unser Gehirn den Fehler schon
korrigiert hat, bevor er im Gehirn angekommen ist -- dann bekommst Du
eine grobe Idee, wie dämlich Computer im Vergleich zu einem menschlichen
Gehirn sind.
Man kann auch kaum sagen, daß eine natürliche Sprache in irgendeinem
Punkt "besser" oder "schlechter" wäre, sondern nur, daß man eine Sprache
besser und die andere schlechter beherrscht. Dasselbe kann man natürlich
auch über Programmiersprachen sagen, aber dann gibt es ja noch einen
Dritten, einen ziemlichen Dummbeutel, der die Sprache verstehen muß:
nämlich den Computer. Deswegen sind -- das hatte ich ja oben schon
angedeutet -- die meisten Programmiersprachen in ihren fundamentalen
Konzepten relativ ähnlich: Bedingungen und Schleifen in Java
unterscheiden sich nicht wesentlich von denen in Python, C++ oder C#.
Die Unterschiede von Programmiersprachen liegen daher insbesondere
darin, wann der Quellcode in Maschinencode übersetzt wird: in einem
separaten Kompilationsschritt wie in kompilierten Sprachen, bei welchem
dann auch Vorberechnungen ausgeführt, Typen überprüft und auch sehr
umfangreiche Optimierungen durchgeführt werden können, oder eben zur
Laufzeit, wo einige dieser Schritte nur mit großen Einschränkungen
gemacht werden können. All das sind aber rein technische Aspekte, haben
mit Menschen und ihren Fähigkeiten nichts zu tun, und können daher ohne
irgendeinen Bezug auf Menschen und ihre Fähigkeiten diskutiert werden.
[1]
http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881
Sheeva P. schrieb:> renommierte Indizes wie TIOBE, RedMonk und PYPL
BRUAHAHAHA!
Der aussagenlose Müll von Tiobe (die anderen sagen mir nix, vermutlich
noch schlimmer), solche Rankings und vor allem die Weissagungen die
daraus gezogen werden sind fast ausnahmslos für die Tonne. Mein
Morgenschissbild im Email ist vermutlich aussagekräftiger als diese
Indices. Die Wurst lag gekrümt in der Schüssel, also ist C der Favorit.
Sheeva P. schrieb:> knallbär schrieb:>> Hast du schonmal mit Matlab debugged? (Auch eine Skriptsprache, aber>> properitär)>> Nein, habe ich nicht. Aber Ausnahmen bestätigen bekanntlich die [...]
Nun du wirst es nicht bemerkt haben, aber ich bin in dieser Diskussion
ganz auf deiner Seite :)
Sheeva P. schrieb:> Possetitjel schrieb:>> Sheeva P. schrieb:>>> die inhärenten Stärken von Skriptsprachen>>>> Programmiersprachen sind ein Hilfmittel für MENSCHEN,>> nicht für Computer.>>> Deswegen kann man generell sagen, daß Programmiersprachen, die in> nativen Maschinencode kompiliert werden, [...]>> Interpretierte Sprachen -- also: Skriptsprachen -- sind [...]
Der Beitrag trifft es genau.
Danke für die Mühe.
Sheeva P. schrieb:>> Der Computer ist mit Brainfuck genauso zufrieden.>> Das ist natürlich richtig, aber gerade dieses Beispiel zeigt, daß die> verschiedenen Sprachen jeweils ihre eigenen Vorzüge und eben auch ihre> eigenen Nachteile haben. Brainfuck, zum Beispiel, hat ein extrem simples> Sprachkonzept und ist gut geeignet, die Grundlagen der Computertechnik> zu erlernen. Andererseits ist es umständlich und ineffizient zu> benutzen, weswegen niemand diese Sprache ernsthaft in der Praxis> einsetzt.
Oder (typisiertes) Lambda-Kalkül scnr ;)
> Die Unterschiede von Programmiersprachen liegen daher insbesondere> darin, wann der Quellcode in Maschinencode übersetzt wird: in einem> separaten Kompilationsschritt wie in kompilierten Sprachen, bei welchem> dann auch Vorberechnungen ausgeführt, Typen überprüft und auch sehr> umfangreiche Optimierungen durchgeführt werden können, oder eben zur> Laufzeit, wo einige dieser Schritte nur mit großen Einschränkungen> gemacht werden können.
Das ist eher der Unterschied zw. dynamisch und statisch typisierten
Sprachen. Letztlich eine Design-Entscheidung, die unabhängig davon ist,
ob das nachher interpretiert/JITed wird oder nicht.
Siehe bspw. die ganzen REPLs (Read-Evaluate-Print-Loops) für u.a. C++
1), C# 2), F# 3) mit denen die Code-Entwicklung wie bei Skriptsprachen
läuft.
Andersherum ging's auch mal vor langer Zeit: StrongTalk, ein Smalltalk
mit statischer Typisierung (irgendwann Ende der 1990er von Sun gekauft,
getötet und in Java/JVM verwurstet). Mypy wäre sowas für Python.
Die "Umständlichkeit" (viel zu Tippen, Lesbarkeit) einiger statisch
typisierter Sprachen liegt u.a. auch daran, dass sie keine Typinferenz
kennen (C z.B.) im Gegensatz zu C++ ab C++11, C# ab V3, F#, ML, Swift,
Scala, Haskell oder Rust.
1) Cling
https://cdn.rawgit.com/root-project/cling/master/www/index.html,
C++-Interpreter, der, wie der Name schon andeutet, auf Clang und LLVM
basiert
2) C# Interactive ab afair VS2015, gibt's auch in Mono
3) F# Interactive ab afair 2005, ebenso in Mono
Manchmal frage ich mich warum manche Fragen so eine lange Diskusion um
das falsche Thema nach sich ziehen.
Ich benutze nun WxWidgets also C++.
Bis auf die XY Darstellung geht auch schon alles.
VG, Klaus
Thread beobachten
Seitenaufteilung abschalten