Infoseite // Coden für Filmer - welche Sprachen, welche Anwendungen?

Frage von Drushba:


Hi, mir ist coronabedingt langweilig und ich möchte programmieren lernen. Warum? Derzeit werde ich wie wir alle bombardiert mit Werbung zum Codenlernen und langsam fruchtet das bei mir. )) Da stellt sich für mich die Frage, was wohl für Filmer die beste Sprache wäre. Im Auge habe ich für das erste, eigene Projekt zwar eine browserbasierte Drehplan- und Produktionssoftware, die an meine Bedürfnisse angepasst ist und die ich derzeit so nicht auf dem Markt finde. Klar ist aber auch, dass das viel zu umfangreich für mich alleine ist und ich bei der Umsetzung deshalb ohnehin mit Programmierern zusammenarbeiten werden muss. Trotzdem will ich was davon verstehen.)) Beim ersten Umschauen hab ich Javascript ausmachen können, aber vielleicht fällt Euch ja was ein, was für Filmer noch interessanter sein könnte, egal auf welchem Gebiet oder für welche Anwendung. Und: Ich hab - bis auf meine verschollenen Basic-Kenntnisse aus C64 Zeiten - überhaupt keinen Plan. Gar keinen. Merci schonmal für Input, gerne auch für lohnenswerte bzw. fehlende Softwarelösungen.))

PS: Bin auf Mac only



Antwort von Alex:

Ich bin jetzt Keiner, der einen guten Überblick über alle Programmiersprachen hat, allerdings war ich damals (C-64/Amiga/erster PC) auch sehr früh mit Basic zugange, weiterhin Turbo Pascal, DBAse und Clipper. Dann 2 Jahrzehnte gar nichts mehr programmiert. Als es mich dann wieder gepackt hat, bin ich in Visual Basic (.NET) eingestiegen. Das ging für mich ganz gut und nach 2 Wochen hatte ich einen für meine Verhältnisse recht komplexen Code geschrieben. Soweit ich weiß kannst du kostenlos loslegen mit Visual Studio.

P.S.: Und Tipp gegen Werbung - Falls die aus dem Browser kommt, empfehle ich folgende Plugins/Erweiterungen/Addons:

UBlock Origin

Track me not (TMN)

Canvas Fingerprint Defender

Cookie Quick Manager

HTTPS everywhere

Redirector

Privacy Badger

Facebook Container

Die meisten sollten für Chrome und Mozilla verfügbar sein, MAC/Safari kenn ich mich nicht aus...



Antwort von roki100:

Die frage ist, was willst Du genau machen? Auch GUI oder Webbasierte Programmierung? Unix oder Windows...?

Das andere ist, willst Du dir schwieriger machen oder leichter haben? ;)
Statt Visual Studio, würde ich immer noch eher AutoIT empfehlen. AutoIT ist unterschätzt aber mächtig....und da meistens von Virenmacher "missbraucht", werden AutoIT Programme von Virenscanner meistens auch als Viren erkannt. ;)

Unix&Scripting: da würde ich dir klar #!/bin/bash empfehlen und auf jeden Fall, Perl oder TCL.

Einfach mal testen. Es ist unterschiedlich, was einer als "logischer" für sich selbst kapiert. In den meisten Fällen macht man sich auch schwieriger, indem man meint (weil man das so irgendwo gelesen hat, jedoch nicht klar und eindeutig rübergebracht), dass objektorientierte Programmierung (kurz OOP), besser sei, was totaler quatsch ist. Das merkt man aber mit der Erfahrung und kennst dann die Möglichkeiten und wunderst dich darüber, wie schwer Du dir damals mit OOP das leben gemacht hast. ;)
OOP macht also nicht immer Sinn, nur bei Großprojekten und Gruppen-Programmierung, wo auch bestimmte Standards beachtet werden, weil die anderen sich auch daran halten müssen.
Wenn Du aber als ein-Mann-Kopf etwas programmierst, dann scheiß auf die Standards bzw. irgendwelche Regeln die von dritte als feste regeln eingeführt wurden. An diese musst Du dich nicht wirklich halten. Wichtig ist, Ziel zu erreichen, wie Du dahin kommst, ist erstmal egal. Mit der Zeit lernst Du dann, wie Du das eigene Programm "Modular" aufbauen kannst bzw. soll etwas neues dazu kommen? Dann lernst Du, wie Du von beginn daran denkst, so das Programm zu schreiben, um neue Funktionen etc. zukünftig einbauen zu können...

Ansonsten, egal mit was Du beginnst, wenn Du das eine kannst, dann ist es leicht etwas neues zu erlernen....



Antwort von mash_gh4:

naja -- für einfach dinge ist es ausgesprochen nützlich, wenn man python gut vertraut ist. das ist auch im filmgeschehen mittlerweile die wichtigste scripting-sprache, um irgendwelche ablauf mit möglichst wenig aufwand zu automatisieren.
im übrigen ist python wirklich sehr leicht zu lernen und in der nutzung ausgesprochen entgegenkommend, um vorhaben schenll zu skizziern und irgendwie zum laufen zu bekommen.

für ernsthaftere projekte bzw. software, die dann wirklich möglichst fehlerfrei und schnell laufen soll, greift man aber trotzdem besser zu anderen werkzeugen. ich würde dir in diesem zusammenhang heute unbedingit rust ans herz legen. das ist zwar am anfang eine wirkliche herausforderung, weil der compiler äußerst streng urteilt, und dir kaum einen programmierfehler durchgehen lässt, aber dafür sind dann auch die resulate unvergleichlich sauberer und oft noch schnell als C/C++ programme.

gerade wenn man kein vollprofi ist, und all die fallstricke, feinheiten und probleme, wie sie sich etwa im zusammenhang mit feinheiten der speicherverwaltung und parallelisierten abläufen stellen, noch nicht völlig verinnerlicht hat, kann diese streng erzieherische und kontrollierende wirkung von rust wunder bewirken und einen großteil der häufigsten programmierfehlern verhindern. das ist auch der grund, warum selbst große firmen, dieser sprache, die eigentlich aus der freien szene kommt bzw. ursprünglich bei mozilla entwickelt wurde, immer mehr beachtung schenken. microsoft hat bspw. analysiert, dass sich 70% ihrer groben softwarefehler und sicherheitslücken der letzten jahre verhindern hätten lassen, wenn rust für die programmierung benutzt worden wäre.

da man mit hilfe dieser sprache ohnehin praktisch alles bewerkstelligen kann, was sonst mit C oder C++ abgewickelt wird, ist es oft einfach vernünftig, neuere software von grund auf damit zu schreiben. so wird im augenblick sehr viel wirklich herausragender und innovativer code eben tatsächlich in dieser sprache entwickelt. es gibt dafür auch bspw. ganz wunderbare unterstützung im gstreamer, so dass es auch für ernsthaftere vorhaben des videoprocessings eine höchst effiziente basis darstellt.



Antwort von mash_gh4:

roki100 hat geschrieben:
...auf jeden Fall, Perl oder TCL. bitte nicht! -- das sind zwar alles dinge, die ich irgendwann auch gelernt und benutzt habe, aber von denen ich heute wirklich jedem ganz dringend abraten würde!

wie gesagt -- von mir aus python, typescript od. auch go, wenn es einfach sein soll, aber doch bitte nicht irgendwas deutlich schlechteres aus dem vorigen jahrhundert!
roki100 hat geschrieben:
In den meisten Fällen macht man sich auch schwieriger, indem man z.B. meint das objektorientierte Programmierung (kurz OOP) besser sei, was totaler quatsch ist. Das merkt man aber mit der Erfahrung und kennst dann die Möglichkeiten und wunderst dich darüber, wie schwer Du dir damals mit OOP das leben gemacht hast. naja -- rust hat auch mit vielen dogmen der bekannten objektorientierten sprachen gebrochen, um noch effizienter zu sein bzw. "zero-cost abstractions" umzusetzen, aber deswegen ist die sache nicht unbedingt gleich einfacher geworden, weil eben die entsprechenden sprachlichen möglichkeiten durchaus auch ihren sinn haben bzw. unglaubliche möglichkeiten bieten, wenn man einmal den umgang damit erlernt hat. das gilt auch in hohem maße für die einflüsse und möglichkeiten funktionaler programmiersprachen bzw. sprachkonstrukte, wie sie heute ohnehein in allen ernstzunehmenden programmierungebungen geboten werden.



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
...auf jeden Fall, Perl oder TCL. bitte nicht! jeder wie es mag :) Wenn es um komplexe Aufgaben geht (wie z.B. Datenbanken analysieren&auswerten usw.), nutze ich viel lieber das. :)
Erwähnt habe ich ja schon: Es ist unterschiedlich, was einer als "logischer" für sich selbst kapiert. Natürlich ist Python auch gut. Es geht auch nicht darum "was besser ist". Der Anfang ist ja sowieso etwas, wo man sagen kann, fang an mit egal was...und wenn Anfänger weiter macht und andere Programmiersprachen kennenlernt, Erfahrung sammelt, dann weißt er mit der zeit, was für welche zwecke besser geeignet ist. Das beste gibt es nicht, alt oder neu zählt nicht, sondern was ist für X/Y besser geeignet, um das Ergebnis zu perfektionieren.... ;)

Es gibt so Sachen, da muss man nicht übertreiben und tausende Zeilen und Kopfzerbrechen betreiben ;)
Beispiel: Unix Systeme steuern, Protokolle analysieren&auswerten, Ergebnisse liefern (am besten mit Filter und E-Mail an die Zuständige senden). Was wirst Du dafür einsetzen? Python? Ja, mach mal... ;)
Ich würde eher ssh in Verbindung mit (tcl) "expect" empfehlen, womit eben auch die #!/bin/bash Werkzeuge (wie sendmail, cat, grep usw) bedient werden.... ;)



Antwort von prime:

Probier Python :-) roki100 hat geschrieben:
Beispiel: Unix Systeme steuern. Was wirst Du dafür einsetzen? Python? Ja, mach mal... ;)
Ich würde eher ssh in Verbindung mit (tcl) "expect" empfehlen. ;) Warum soll man mit Python kein Unix System (oder auch Linux) steuern können? Dann ist wohl das was ich hier jeden Tag mache schwarze Magie oder was?

Ne lange Zeit hab ich auch bash Skripte verwendet um allerlei Zeugs zu automatisieren, irgendwann hab ich ein Teil der Skripte auf Python umgestellt. Hätte ich viel früher machen sollen. Warum? Viel portabler, viel leichter zu lesen und zu verstehen (vor allem nach langer Zeit), kein Raten zwischen verschiedenen Implementation von cp oder was auch immer, Zugriff auf eine Riesensammlung an zusätzlichen Bibliotheken (Python-Module). Simples Beispiel, Standard-Mac Installation hat kein 'watch' oder 'wget' (ja ja es gibt curl bla bla). Wenn man mal hier mal da unterwegs ist dann kann das schon ganz schön nerven.



Antwort von roki100:

prime hat geschrieben:
Probier Python :-) roki100 hat geschrieben:
Beispiel: Unix Systeme steuern. Was wirst Du dafür einsetzen? Python? Ja, mach mal... ;)
Ich würde eher ssh in Verbindung mit (tcl) "expect" empfehlen. ;) Warum soll man mit Python kein Unix System (oder auch Linux) steuern können? Dann ist wohl das was ich hier jeden Tag mache schwarze Magie oder was? Wo steht, man soll es nicht? Ich schreibe nur, was ich eher empfehlen würde. Mir ist ein freier Tag wertvoller als es unnötig in Zeilen und für gleiches Ergebnis, zu investieren... ;)
Standard-Mac Installation hat kein 'watch' oder 'wget' (ja ja es gibt curl bla bla). Wenn man mal hier mal da unterwegs ist dann kann das schon ganz schön nerven. Das muss ja wirklich(?) einfacher sein, Python Script zu schreiben, statt die fehlenden Werkzeuge zu installieren oder auf andere auszuweichen? ;)
Für mich gilt: #!/bin/* ist eine riesige Programmierumgebung (IDE). ;)



Antwort von prime:

roki100 hat geschrieben:
Das muss ja wirklich(?) einfacher sein, Python Script zu schreiben, statt die fehlenden Werkzeuge zu installieren oder auf andere auszuweichen? ;)
Für mich gilt: #!/bin/* ist eine riesige Programmierumgebung (IDE). Genau und wenn ich auf dem Gerät keine Admin/Root Rechte hab dann installiere ich erstmal neue Sachen statt einfach mein bestehendes Python Skript zu nutzen?

*Bitte jetzt nicht anfangen mit, kopier es doch in ~/bin und erweitere PATH.. alles schon gemacht ;-P






Antwort von roki100:

prime hat geschrieben:
roki100 hat geschrieben:
Das muss ja wirklich(?) einfacher sein, Python Script zu schreiben, statt die fehlenden Werkzeuge zu installieren oder auf andere auszuweichen? ;)
Für mich gilt: #!/bin/* ist eine riesige Programmierumgebung (IDE). Genau und wenn ich auf dem Gerät keine Admin/Root Rechte hab dann installiere ich erstmal neue Sachen statt einfach mein bestehendes Python Skript zu nutzen?

*Bitte jetzt nicht anfangen mit, kopier es doch in ~/bin und erweitere PATH.. alles schon gemacht ;-P Verstehe ich nicht warum Du kein Admin Rechte hast? Das war aber so nicht gemeint. Was ich meinte ist folgender Beispiel: Ziel, Änderungsdatum aller Dateien in Ordner xy auslesen, die in den letzten 100 Tagen geändert wurden. Nun zeigt mal bitte Drushba ein Beispiel Python Script, damit er auch versteht was gemeint ist ;)

Und ich zeige Drushba meine Empfehlung: find /xy -mtime -100 ;)

Da war jetzt eine einfache Aufgabe. Nun soll aber das Ergebnis am besten in einer Datei gespeichert werden und am besten Ergebnis von Dateien, die mit SlashCam* beginnen.... Uff, jetzt gibt es in Python Script etwas mehr Zeilen, nicht wahr? ;) Zeigt bitte Drushba wie das dann aussieht....

Und ich zeige Drushba meine Empfehlung: find /xy -mtime -100 | grep -i "SlashCam" > ergebnis.txt

Weiter machen? z.B. das Ergebnis per E-Mail senden? Ja, zeigt mal Drushba wie das Python Script aussieht, um das Ergebnis dann noch per E-Mail zu versendet... und ich liefere dann meine Empfehlung? ;)

Und nochmal:
Für mich gilt: #!/bin/* ist eine riesige Programmierumgebung (IDE). ;)
Python ist NUR ein Bestandteil von "*"



Antwort von prime:

roki100 hat geschrieben:
Verstehe ich nicht warum Du kein Admin Rechte hast? Soll es geben wenn man auf unterschiedlichen Geräten unterwegs ist die einen nicht gehören etc.
roki100 hat geschrieben:
Das war aber so nicht gemeint. Was ich meinte ist folgender Beispiel: Ziel, Änderungsdatum aller Dateien in Ordner xy auslesen, die in den letzten 100 Tagen geändert wurden. Nun zigmal Druschba ein Beispiel Python Script, damit er auch versteht was gemeint ist ;)

Und ich zeige Drushba meine Empfehlung: find /xy -mtime -100 ;) Das ist ja schön und gut aber du verwechselst Einzeiler mit (ganzen) Skripten.



Antwort von roki100:

prime hat geschrieben:
roki100 hat geschrieben:
Das war aber so nicht gemeint. Was ich meinte ist folgender Beispiel: Ziel, Änderungsdatum aller Dateien in Ordner xy auslesen, die in den letzten 100 Tagen geändert wurden. Nun zigmal Druschba ein Beispiel Python Script, damit er auch versteht was gemeint ist ;)

Und ich zeige Drushba meine Empfehlung: find /xy -mtime -100 ;) Das ist ja schön und gut aber du verwechselst Einzeiler mit (ganzen) Skripten. Nein :) Die Missverständnisse kommen daher, weil einige nicht begriffen haben, dass die Konsole (#!/bin/*) eine riesige Programmierumgebung (IDE) ist. Betrachtet man das als IDE, dann wird einem mit der Zeit einiges klarer.
Das Beispiel mit find, ist also etwas, wie in Python Script:
import os.path
print os.path.getmtime(<datei>)
...

Zeigt bitte Drushba wie das aussieht (noch Ergebnis speichern und per E-Mail senden)... es ist ja nur ein kleines Beispiel. Danach kann sich Drushba ungefähr vorstellen, was ich hiermit gemeint habe: Es gibt so Sachen, da muss man nicht übertreiben und tausende Zeilen und Kopfzerbrechen betreiben ;)

Natürlich sind das nur ein paar Zeilen, bei komplexere Aufgaben, ändert sich das aber nicht... ;)

Und bitte nicht missverstehen, jeder wie es mag.... ;)



Antwort von prime:

roki100 hat geschrieben:
Nein :) Die Missverständnisse kommen daher, weil einige nicht begriffen haben, dass die Konsole (#!/bin/*) eine riesige Programmierumgebung (IDE) ist. Die Konsole (Terminal) ist kein IDE. Du bist der erste von den ich sowas höre.

Komm mal runter, es geht hier nicht um UNIX/Linux Admin Wissen. Er fragt welche Programmiersprache, nicht nach Verwendung von den Standard-Werkzeugen etc.



Antwort von roki100:

prime hat geschrieben:
roki100 hat geschrieben:
Nein :) Die Missverständnisse kommen daher, weil einige nicht begriffen haben, dass die Konsole (#!/bin/*) eine riesige Programmierumgebung (IDE) ist. Die Konsole (Terminal) ist kein IDE. Du bist der erste von den ich sowas höre. ja ist bekannt, deswegen erwähne ich es... ;)
Komm mal runter, es geht hier nicht um UNIX/Linux Admin Wissen. Er fragt welche Programmiersprache, nicht nach Verwendung von den Standard-Werkzeugen etc. Hä? Sorry, Du hast immer noch nicht kapiert. Nochmal:
import os.path
print os.path.getmtime(<datei>)

ist nichts weiter als "find" bzw. das Werkzeug bedienen.



Antwort von mash_gh4:

lieber roki!

der schwachsinn, den du hier gerade verzapfst, kommt mir ungefähr so lächerlich vor, als würden selbstbewusste männer sich als erfahrene handwerker darzustellen versuchen, nur weil sie in der lage sind, irgendwelche IKEA reagale zusammenzuschauben...

und übrigens, wenn ich irgendwas zu rechnen hab, starte ich nicht die taschenrecherapplikation od. versuch das umständlich in der shell zu bewerkstelligen, sondern tipp einfach ein "python3" ein und geb mich glücklich und unbelastet der tatsächlichen aufgabe im dortigen REPL mode hin... :)

aber, wie gesagt, richtiges programmieren ist ohnehin etwas anderes...



Antwort von roki100:

Das war bloß nur eine simple Aufgabe um zu zeigen wie mächtig die (Unix) Konsole/Terminal ist und das das eben in Wirklichkeit, eine Programmierumgebung ist.



Antwort von prime:

roki100 hat geschrieben:
Hä? Sorry, Du hast immer noch nicht kapiert. Oh doch ich hab schon verstanden das du nicht den Unterschied zwischen Verwendung von Standard Werkzeugen und einer Programmiersprache kennst (mit der man z.B. die Werkzeuge 're-implementieren' kann wenn man will).
um zu zeigen wie mächtig die (Unix) Konsole/Terminal ist Und danach hat hier niemand gefragt.



Antwort von cantsin:

Kann nur mash_gh4's Empfehlungen für Python als Scripting-Sprache (inkl. Web-Applikationen) und Rust als Softwareentwicklungssprache (=moderne, sichere Alternative zu C, C++ und Objective C) unterstützen.

Auf unserer Hochschule ist in den Mediendesignstudiengängen Python schon seit 15 Jahren die Standard-Programmiersprache. Sie ist die einzige, die leicht zu erlernen und dabei gut strukturiert, lesbar und mit unzähligen Bibliotheken und Modulen hervorragend ausgebaut ist (und auch im Gegensatz zur Shell-Programmierung betriebssystemübergreifend).

Ich bin selbst ein Shell-Nerd (zsh rules!), aber komplexere Dinge würde ich darin niemals schreiben, nicht nur wegen ggü. Python viel schlechter lesbaren C-Shell-Syntax, sondern vor allem, wegen der Abhängigkeiten und Inkompatiblitäten zur jeweiligen Shell und Unix-kompatiblen Tools (wo z.B. die Syntax des find-Kommandos zwischen den BSD-Tools in MacOS und den GNU-Tools in Linux und Cygwin signifkant voneinander abweicht und Skripte daher nicht übergreifend kompatibel sind, und sich die Syntax bestehender Skripte zerschiesst, sobald eins der verwendeten Tools seine Kommandosyntax ändert. Gerade heute wieder saß ich beinahe eine halbe Stunde lang fest an einem nicht mehr funktionierenden, selbstgeschriebenen ffmpeg-Wrapper-Skript, bis mir auffiel, dass die POSIX-Substitution nicht von der ash-Systemshell unter Debian unterstützt wird, und ich "#!/bin/sh" durch "#!/bin/zsh" ersetzen musste...)






Antwort von roki100:

@prime
Das ist ja das Problem, nicht begreifen wollen, dass die (Unix)Werkzeuge auch in #!/bin/* Script genau so funktionieren (wie das Beispiel mit os.path.getmtime(<datei>) in *.py ) und das #!/bin/* zu einem riesigen Programm (zu einem Werkzeug) gemacht werden kann, der die selbe Ergebnisse erfüllen kann...wie ein riesiger Python Script... ;)

Der Unterschied besteht darin, das einige z.B. find nur als Unix-Werkzeug (und nicht als ein teil der Programmierumgebung) verstehen , sondern nur das andere (os.path.getmtime(<datei>)) als teil einer Programmiersprache. ;)



Antwort von prime:

Niemand hat hier nach der Verwendung von Unix-Werkzeugen gefragt... weiß echt nicht warum du da noch jetzt weiter drauf rumreitest. Es ist deiner Argumentation nicht sehr förderlich wenn du grundlegende Dinge (Programmiersprache vs ausführbares Programm) neu-definieren willst. Du kannst es gerne noch 100 mal schreiben, ändert nix, es bleibt lächerlich.



Antwort von roki100:

Das liest sich so in etwa:
Niemand hat hier nach der Verwendung von Python-Werkzeugen gefragt... ;)

Aber so ist das wenn man ls, cp, cat usw. nur als Unix-Werkzeuge in der Konsole kennt und #!/bin/* völlig außer acht lässt...



Antwort von prime:

Roki ich werde dich nicht daran hindern dich weiter hier lächerlich zu machen.



Antwort von mash_gh4:

roki100 hat geschrieben:
Der Unterschied besteht darin, das einige z.B. find nur als Unix-Werkzeug (und nicht als ein teil der Programmierumgebung) verstehen, ... du solltest dir einmal die performance und ergonomie von befehlen wie fd oder ripgrep ansehen, wenn dich die frage der beziehung zur tatsächlich benutzen programmierumgebung im hinblick auf solche qualitäten interessiert.



Antwort von roki100:

@prime
Warum lächerlich? Das Du das nicht verstehen willst oder kannst, macht sich nicht der dritte lächerlich, sondern Du tust das, indem Du eine Sache nicht verstehen willst oder kannst, weil Du Konsole nur als Werkzeug für Befehle ausführen oder ähnliches verstehst.

Also nochmal für dich. Ein Python "Programm" beginnt in der Linux Konsole so (Beispiel): #!/usr/bin/env python3 import os.path print os.path.getmtime(xy) ... ... Das nennst Du dann: eine echte Script/Programmiersprache und nicht lächerlich! ;)

Doch das hier #!/usr/bash find xy -mtime -100 ;) ... ... Ist für dich keine Script/Programmiersprache und sogar lächerlich.
;)

Vielleicht wird es Zeit mal umzudenken? Denn #!/bin/*** ist eine mächtige Programmierumgebung. Es ist auch mit Editoren (nano, vi etc.) ausgestattet, womit Du deine Programme schreiben kannst... ;) Es ist einiges aber zu beachten, für #!/usr/bin/env python3 musst Du import x.y anwenden, und für bash musst Du nichts importieren, es ist alles inklusive dabei ... ;)))



Antwort von Drushba:

Leute , ich häng Euch an den Lippen, danke für all die Infos, aber bitte nicht streiten.))



Antwort von prime:

Reise nach Absurdistan. Roki, schreib gerne noch weitere 20 Beispiele, vielleicht kommst du selber noch drauf, wenn nicht auch nicht weiter schlimm. Hauptsache du bist glücklich mit deiner IDE.



Antwort von mash_gh4:

ah ja -- as IDE würde ich übrigens VSCode verweden, wobei natürlich das ganz freie Che fast noch toller ist.






Antwort von roki100:

prime hat geschrieben:
Reise nach Absurdistan. Na dann wünsche ich Dir viel spaß da. ;)

Übrigens, hier etwas für dich: https://cdn.oreillystatic.com/en/assets ... on1.ppt Wenn dir irgendwann mal langweilig ist, einfach lesen. ;)



Antwort von roki100:

mash_gh4 hat geschrieben:
ah ja -- as IDE würde ich übrigens VSCode verweden, wobei natürlich das ganz freie Che fast noch toller ist. Ja nicht schlecht. Zu empfehlen ist auch "Sublime Text"



Antwort von Onkel Danny:

Also auch ich kann mash_gh4 nur voll zustimmen.
Python zum reinschnuppern und Rust als gute Alternative zu C/C++/Java.
Wobei letztere natürlich auch zu empfehlen sind, wenn es um Anwendungsentwicklung geht.

Es sei vielleicht noch erwähnt, das die Programmiersprachen für gewöhnlich Betriebssystem unabhängig sind.
Auch wenn die Anwendung für jedes OS neu compiliert werden muss. Ausnahme Java, da geht ein Code für alle.
Und man sich als Anfänger auf eine lange Einarbeitungszeit einstellen kann.

Also mal eben ein Große Anwendung erstellen, ist leider nicht drin. Dran bleiben, ist hier das A und O.
Genau wie beim Schnitt oder Grading etc. regelmäßig daran arbeiten, dann wird das auch was.

Und das was rooki100 von sich gegeben hat, vergessen wir mal lieber ganz schnell wieder!

greetz



Antwort von roki100:

"Onkel Danny" hat geschrieben:
Und das was rooki100 von sich gegeben hat, vergessen wir mal lieber ganz schnell wieder! Bis auf cantsin, habt ihr keine eindeutige Erklärung geliefert. ;) Man kann doch auch bash/sh/zsh, perl, tcl etc. auch empfehlen. :) Die frage ist nun, warum soll "only UNIX/apple" Nutzer das schnell vergessen? :) Wenn ihr das eine bevorzugt, ist doch schön, jedoch sollte das kein Hindernis sein, auch etwas anderes empfehlen zu dürfen. Schadet ja nicht.... :)

Übrigens: http://vschart.de/vergleich/python-prog ... rl/vs/rust



Antwort von mash_gh4:

"Onkel Danny" hat geschrieben:
Es sei vielleicht noch erwähnt, das die Programmiersprachen für gewöhnlich Betriebssystem unabhängig sind.
Auch wenn die Anwendung für jedes OS neu compiliert werden muss. Ausnahme Java, da geht ein Code für alle. naja -- leider war das auch bei java mehr ein großartiges versprechen, dass all beflügelt hat, aber in der praxis hat es mit der kompatibilität und langzeitpflege immer gewaltige probleme gegeben, und im übrigen war das zeug halt auch immer ausgesprochen ressourcengefräßig, so dass es mittlerweile wohl wirklich nur mehr in trägen bereichen wirtschaft größerer beliebtheit erfreut.

aber natürlich ist dieser wunsch nach möglichst großer plattformunabhängigkeit und der sicheren ausführung von fremdem code in sandboxes nicht verschwunden. mit webassembly (WASM u. WASI) ist hier in den letzten jahren eine wundere lösung herangereift, die diesen traum in erneuerter form zum leben erweckt. prinzipiell kann man zwar mittlerweile code aus ganz verschieden programmiersprachen nach WASM übersetzen und dann bspw. einfach im webbrowser ausführen, aber auch hier ist rust den meisten anderen lösungen deutlich überlegen, weil es keinen garbage collector benötigt und sich damit viel besser in die WASM-vorgaben fügt bzw. deutlich schlankere und effizienteren resultate in diesem format generiert.

das ist jetzt natürlich nicht unbedingt ein feature, mit dem man gleich am anfang loslegen sollte, aber doch ein bereich, den ich für ausgesprochen spannend und bedeutsam für das zukünftitge geschehen halte.

auch wenn man natürlich code oft relativ leicht in native ausführbare executables für die bekannten plattformen cross-compilieren kann (nur in richtung mac ist das immer sehr mühsam, weil man dafür um die entsprechenden werkzeuge von apple nicht herumkommt bzw. es in der praxis aus linzenzrechtlichen gründen kaum auf anderen maschinen abwickeln kann), bleibt doch das problem, dass man mit einem unheimlichen aufwand verbunden ist, software wirklich auf allen systemen zu testen, die kleinen unterschiede auszubügelen und befriedigende GUI-lösungen anzubieten, die den erwartungen der jeweiligen benutzerschaft tatsächlich gerecht werden. das vermag man in irgendwelchen engagierten und von neugierde und schaffensdrang beseelten freizeitprojekten einfach nicht zu leisten. ich mach meine sachen deshalb in der regel lieber als docker-images zugänglich, die dann auch relativ einfach auf allen drei betriebssystemen genutzt werden können. im übrigen ist das ja mittlerweile auch die wichtigste art der bereitstellung, um irgendwas im server-umfeld bzw. auf kubernetes-clustern irgendwo in der cloud nutzen zu können.

auch im entwicklungsalltag bzw. den hilfsmitteln, deren man sich dazu bedient, haben diese containerbasierten lösungen in den letzten jahren ein völliges umdenken mit sich gebracht. heute ist es ganz selbstverständlich, dass man auch bei lächerlichen amateurprojekten bspw. auf GitLab ganz wunderbare continous integration (CI) lösungen nutzt, wo code beim einpflegen von änderungen automatisch überprüft und in einem ganz sauberen und eindeutig reproduzierbarem umfeld automatisch übersetzt und zur auslieferung bereitstellt wird. derartiges möchte ich mittlerweile wirklich nicht mehr missen.
"Onkel Danny" hat geschrieben:
Und man sich als Anfänger auf eine lange Einarbeitungszeit einstellen kann. leider betrifft das ja nicht nur die anfänger! auch wenn man einmal mitten drinnen ist, kommt man mit dem lernen und aneignen all der ständig hinzukommenden neuerungen und weiterentwicklungen kaum nach. ;)

trotzdem muss man einfach ins kalte wasser springen. wirklich lernen kann man vieler dieser sachen nur im praktischen tun -- ...und all den unvermeidlichen fehlern und langsam dämmernden einsichten, die man dabei im laufe der zeit durchmacht... ;)



Antwort von mash_gh4:

roki100 hat geschrieben:
Wenn ihr das eine bevorzugt, ist doch schön, jedoch sollte das kein Hindernis sein, auch etwas anderes empfehlen zu dürfen. Schadet ja nicht.... :) ja -- natürlich sollte man ein größeres instrumentarium an werkzeugen beherrschen, weil sich nicht alles für jeden zweck in gleicher weise eignet, aber wenn man es sich aussuchen kann -- was ja z.b. bei beruflicher tätigkeit in diesem umfeld leider nur eher selten der fall ist --, ist in den letzten paar jahren bei umfragen immer weitrestgehend das selbe ergebnis herausgekommen:

https://insights.stackoverflow.com/surv ... -languages



Antwort von roki100:

rust ist auf jeden Fall interessant. Ich habe mal beim Kollegen gesehen der einige GTK Apps mit rust programmiert hat.



Antwort von prime:

roki100 hat geschrieben:
Bis auf cantsin, habt ihr keine eindeutige Erklärung geliefert. ;) Wirklich? Liest du überhaupt was andere hier schreiben? Lies doch nochmal mein Post der enthält mehr oder wenige die gleichen Argumente wie cantsin auch aufgeführt hat.

Hier gerne für dich nochmal: prime hat geschrieben:
... Warum? Viel portabler, viel leichter zu lesen und zu verstehen (vor allem nach langer Zeit), kein Raten zwischen verschiedenen Implementation von cp oder was auch immer, Zugriff auf eine Riesensammlung an zusätzlichen Bibliotheken (Python-Module). Simples Beispiel, Standard-Mac Installation hat kein 'watch' oder 'wget' (ja ja es gibt curl bla bla). Wenn man mal hier mal da unterwegs ist dann kann das schon ganz schön nerven.



Antwort von roki100:

@prime
ich bezog mich auf bash/sh/zsh Teil von cantsin und zwar nur das: "Ich bin selbst ein Shell-Nerd (zsh rules!), aber komplexere Dinge würde ich darin niemals schreiben....vor allem, wegen der Abhängigkeiten und Inkompatiblitäten zur jeweiligen Shell und Unix-kompatiblen Tools (wo z.B. die Syntax des find-Kommandos zwischen den BSD-Tools in MacOS und den GNU-Tools in Linux und Cygwin signifkant voneinander abweicht und Skripte daher nicht übergreifend kompatibel sind, und sich die Syntax bestehender Skripte zerschiesst, sobald eins der verwendeten Tools seine Kommandosyntax ändert. " ...Zugriff auf eine Riesensammlung an zusätzlichen Bibliotheken (Python-Module).... Die Riesensammlung z.B. für bash, wäre all das, was auch Du als Unix-Werkzeuge bereits genannt hast...

Aber gut, ich habe ja nichts gegen wenn jemand Python empfiehlt. Es ging nur darum, dass einige Sachen viel einfacher zu lösen sind... deswegen das Beispiel mit Einzeiler.






Antwort von mash_gh4:

roki100 hat geschrieben:
Die Riesensammlung z.B. für bash, wäre all das, was auch Du als Unix-Werkzeuge bereits genannt hast... die stehen dir ja auch in fast jeder anderen programmiersprache immer noch zur verfügung, wo es sinn macht.

ich hab zum beipiel die letzten paar wochen wieder damit zugebracht ein tool zu basteln, um die DASH/HLS aufbereitung von video files und befriedigenderes ein bisserl praktischer abzuwickeln und ein paar wichtige features (SRT-upstreams, VP9 und AV1 support, r128-loudness korrektur) einzubeziehen, die mir in diesem zusammenhang in den meisten bekannten lösungen fehlen.

letztlich ist das ganze in diesem fall aber tatsächlich nur ein ziemlich aufwendiger wrapper um das ffmpeg command line tool geblieben. das hat damit zu tun, dass einerseits jene libraries auf denen ffmpeg basiert, derart problematisch zu benutzen sind bzw. so unglaublich schlecht dokumentiert sind, dass es wirklich keinen spass macht, sich damit herumzuärgern, und anderseits gstreramer, dass zwar ohnehin den größten teil der ffmpeg funktionalität in deutlich schöner handhabbarer weise bereitstellt, genau in jenen punkten, die in meinem fall besonders wichtig waren (CMAF support und dash-sink), leider augenblicklich noch immer bekannte schwächen aufweist, wo ich sehr viel zeit darauf verwenden hätte müssen, komplizierten low-level code zu debuggen, bevor das tatsächlich brauchbar funktioniert hätte.

stellt sich also die frage, ob ich das nicht tatsächlich auch einfach mit bash-scripts od. python abwickeln hätte können, so wie du das empfiehlst?

in genau dieser weise hab ich das die letzten jahre über ohnehin ständig für denen eigenen hausgebrauch gemacht. zuerst mit ganz einfachen shell-scripts, die halt nur die einfachsten abläufe bzw. kommandoaufrufsequenzen quasi als batch job festgehalten und einfacher wiederholbar machen, und später dann mit immer weiter ausufernden python scripts, die das ganze bereits deutlich schöner und nachvollziehbarer zu lösen versuchten. aber auch diese scripts, von denen sich im laufe der zeit umengen angesammelt haben, waren irgendwann keine lösung mehr. obwohl sie natürlich den vorzug haben, dass man sie sehr schnell abändern und korrigieren kann, ist es ab einer gewissen größe einfach nicht mehr möglich, die enthaltenen anweisungen auf den ersten blick zu erfassen, nachzuvollziehen und ggf. zu korrigieren, statt dessen schleichen sich immer mehr probleme ein, die erst bei der ausführung als runtime-error in erscheinung treten.

so hab ich also eine ganze menge an zeit darauf verschwendet, einiges von den erfahrungen, die sich im laufe der zeit rund um diese aufgabe bei mir angesammelt haben, zu einem neuen werkzeug zu verdichten. das ist zwar momentan wirklich nur ein ganz primitiver wrapper um das ffmpeg CLI-tool , aber in der umsetztung benutzt es doch möglichkeiten, die mit shell-scripts od. auch python kaum befriedigend einzulösen wären.

die nötige konfiguration für die DASH/HLS ausgabe wird bspw. mittels serde aus einer YAML od. Json konfigurationsdatei eingelesen und in eine streng typisierte interne repräsentation des setups übersetzt. das hat unter anderem den vorzug, dass man aus der definition der betreffenden datenstruktur im code auch gleich völlig automatisiert ein json-schema ableiten und exportieren kann, an hand dessen man im editor beim eintippen der konfigurationsangaben dann syntax-highliting, eingabevorschläge und dokumentation der eingabefeolder eingeblendet bekommt. man kann damit aber auch eine automatische validierung von konfigurationsanweisungen beim einsatz des tools auf serverless platformen wie OpenFaaS umsetzen, oder webformulare für benutzerinterface automatisch daraus generieren usw.

letztendlich wird in der gegenwärtiger form daraus dann aber trotzdem nur ein ganz simpler ffmpeg-aufruf generiert, der allerdings in der praxis meist in einem normalen terminal-fenster keinen platz mehr findet und gespickt ist, mit lauter kleinen feinheiten und notwendigen zaubertricks, über die jeder von uns lange rätseln muss, wenn er derartiges selber hinzubekommen versucht (ganz konkret müssen ja die unzähligen konvertierungen in diesem fall alle mit "-map" anweisungen voneinader getrennt werden und jede transcoding- und filter-option mit expliziten stream-angaben versehen werden etc.).

wie gesagt, prinzipiell geht so etwas schon auch mit shell-scripts, aber ich hab im laufe der zeit irgendwann einfach gelernt, warum man es in der praxis doch besser mit anderer mitteln abwickelt, wenn etwas einigermaßen zufriedenstellendes dabei herauskommen soll.



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
Die Riesensammlung z.B. für bash, wäre all das, was auch Du als Unix-Werkzeuge bereits genannt hast... die stehen dir ja auch in fast jeder anderen programmiersprache immer noch zur verfügung, wo es sinn macht.
So ist es.
Ich kann nur aus meiner Erfahrung sprechen: Natürlich macht das nur für Leute Sinn, wenn sie mit Unix (BSD/Linux) Systeme zu tun haben und egal ob Python oder Perl, wird man mit (z.B. bei Python) os-Modul/os.system() öfter gebrauchen... und das bedeutet nicht nur: weniger Aufwand...
Mit der Zeit erkennt man, warum es mehr Sinn macht, das eine mit dem andere kommunizieren zu lassen...



Antwort von mash_gh4:

roki100 hat geschrieben:
...(egal ob in Python oder Perl) wird man mit (z.B. bei Python) os-Modul/os.system() öfter zu tun haben... nein! -- das ist eines der ersten dinge, die man man unbedingt lernen bzw. berherzigen sollte, dass man in solchen fällen möglichst nicht 'os.system()' bzw. eine ausführung über eine sub-shell, sondern unbedingt die befehle im 'subprocess' modul an dessen stelle nutzen sollte, weil die verwendung von ersterem ganz ungute seiteneffekte und sicherheitsprobleme nach sich zieht und auch ineffizienter ist!

steht aber ohnehin in der betreffenden dokumentation und jedem besseren tutorial od. python lehrbuch.



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
...(egal ob in Python oder Perl) wird man mit (z.B. bei Python) os-Modul/os.system() öfter zu tun haben... nein! -- das ist eines der ersten dinge die man man unbedingt lernen sollte, dass man in solchen fällen möglichst nicht 'os.system()', sondern unbedingt die befehle im 'subprocess' modul an dessen stelle nutzen sollte, weil die verwendung von ersterem ganz ungute seiteneffekte und sicherheitsprobleme nach sich zieht!

steht aber ohnehin in der betreffenden dokumentation und jedem besseren tutorial od. python lehrbuch. Ja das ist klar! Gilt aber für mich nur dann, wenn es z.B. um WebBasierte Programmierung geht... Das os-Modul ist ja nicht Sinnlos / oder als Sicherheitslücke was man vermeiden sollte, auch für Python vorhanden. ;)



Antwort von mash_gh4:

roki100 hat geschrieben:
Ja das ist klar! Gilt aber für mich nur dann, wenn es um WebBasierte Programmierung geht. Das os-Modul ist ja nicht Sinnlos / oder als Sicherheitslücke was man vermeiden sollte, auch für Python vorhanden. ;) in C gibt's auch einen 'goto' befehl, und trotzdem ist das in 99.9% der fälle nicht unbedingt die empfehleswerteste lösung, wie man sauber in dieser sprache programmieren sollte.

aber ich glaub, wenn wir in dem stil hier weiter diskutieren, haben wir spätestens in zwei tagen wenigstens die allergrößten anfängerfehler alle durch und der thread hier hat wirklich seinen sinn erfüllt.



Antwort von roki100:

Ein Anfänger wird sowieso jede menge Fehler machen...Alles Menschlich, aus Fehlern zu lernen.
Mit der Zeit wird der Anfänger leider auch erkennen, wie unfreundlich die "Programmier-Kultur" (vor allem hier zu lande) ist, und wie da kommuniziert wird (natürlich nicht alle, aber viele...) ;) Hat er leider jetzt schon teilweise, NUR weil einer etwas empfohlen hat, was dem anderem nicht schmeckt... ;)

Nochmal für Drushba (denn es geht nur um Drushba hier, nicht darum, was der eine bevorzugt und der andere nicht): Egal mit was Du beginnst, wenn Du das eine kannst, dann ist es leicht etwas neues zu erlernen.... Es ist unterschiedlich, was einer als "logischer" für sich selbst kapiert. Der eine mag auch keine Äpfel, dafür aber Bananen... ;)