Üblicherweise Shell-Skript ziehe jedoch Python vor. Mittlerweile verstärkter Fokus auf Ruby, durch neuere Werkzeuge wie chef und puppet bekommt diese mittlerweile eine stärkere Bedeutung.
Je nach Anforderung/Projekt: PHP (auch auf der Konsole), Perl, Shell, Python, Sonstige ...
Zur Zeit tendiere ich zu Python, aber nur falls ich genügend Zeit habe etwas komplett neu zu machen, da ich da nicht soviel selber geschriebene Libs in Python habe.
Und angefangen hat alles auf meinem Schneider CPC 464: https://de.wikipedia.org/wiki/Amstrad_CPC mit "Locomotive BASIC" : https://de.wikipedia.org/wiki/Locomotive_BASIC
;)
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 27. Feb 2015 um 15:02.
Da ich nur Bash (und eingeschränkt zsh), Perl und Tcl beherrsche, ist die Auswahl natürlich eingeschränkt Ich versuche zunächst das Problem mit Bash zu lösen, wenn es aber etwas komplizierter wird oder wenn sich Perl-Module anbieten, nehme ich Perl. So ist in den letzten Jahren die eine oder andere Mini-Applikation entstanden.
Liebe PL Redaktion, es gibt in der IT kaum ein Wort, welches mit mehr Bedeutungen bedacht ist als das Wort "Scriptsprache". Ich persönlich benutze es gar nicht mehr, weil damit zu wenig eindeutig ausgesagt werden kann. Wenn Ihr es schon benutzt, könntet ihr dann nicht klarer abgrenzen, *was* genau damit im dem Kontext gemeint ist?
Automatisierte Abläufe sind die Domäne von Skriptsprache
Die im Sinne von die einzige oder im Sinne von die Hauptdomäne? Und egal was von beidem, wieso eigentlich? Oder soll das Eure Definition sein? Wieso nicht schreiben "Welche Sprache zur Automatisierung von Abläufen"? Dann braucht man das unsägliche Wort nicht verwenden und der Kontext ist sofort klar!
(Typo Hinweis: Im Text fehlt ein "n" bei "Scriptsprache" - es muss der Plural sein)
Ich schreibe häufig kleine Programme zur Visualisierung von physikalischen Vorgängen mit Perl/Tk. Ich habe schon oft versucht auf Python umzusteigen, aber irgendwie kann ich mich nicht trennen. Der Mensch ist ein Gewohnheitstier.
Muss man ja auch nicht. Zum Glück kann man aus vielen Sprachen wählen, und es ist letztlich eine Geschmacksfrage. Es ist lange her, dass ich Perl benutzt habe, aber ich wurde damit nicht warm. Python ist mir von alles Sprachen generell die liebste. Manche mögen das erzwungene Einrüclen nicht, bevorzugen die Klammern von C, mir gefällt es dagegen sehr gut. Meiner Meinung nach ist es deutlich leichter lesbar und bearbeitbar als Perl. Wer Perl mag, sollte es vielleicht eher mal mit Ruby versuchen
Shell Scripte kommen natürlich manchmal vor aber eigentlich programmiere ich in C oder C++.
Wenn es um Script Sprachen geht, dann ist Lua mein Favorit, weil ich das in meine eigenen C/C++ Programme einbauen kann, um diese scriptingfähig zu machen. Bibliotheken kann man mit http://swig.org mit einer Sprachenanbindung versehen.
Perl: Wenn es ne GUI braucht (Tk, Gtk+) aber immer weniger. Es ist wirlklich unlesbar nach einer gewissen Zeit, man muss es täglich nutzen sonst vergisst man die obskure Synthax sehr schnell. Man hockt da wie ein Ägytologe und vesucht die Zeichen zu entziffern. Äh was macht dieses seltsame Konstrukt jetzt noch mal, da gab es doch wieder ein Sonderfall wenn .... Irgendwie cool aber wenig praktikabel.
PHP: Wenn es etwas 'komplexer' wird und Netzsupport gebraucht wird, manchmal nehme ich hier auch Perl, je nachdem was es da schon an fertigen Modulen gibt nehme ich die eine oder andere Sprache. Ansonst auch für Webentwicklung (läuft alles lokal), wobei ich da immer wenige PHP verwende und so viel wie es geht in den Client stopfe (JavaScript). Habe PHP eine Zeit lang auch beruflich nutzen 'müssen', für "richtige" Webentwicklung ist es ein krampf, obwohl es sich 'professionalisiert' hat, es gibt ganz nette Frameworks aber unter der Haube stinkt es immer noch, die Sicherheitsmägel sind immer noch extrem und hahnebüchen. Erst letzten wieder auf Heise eine entspr. Meldung wo man sich einfach nur an den Kopf fasst.
bash: Wenn es Systemscripte sind die hauptsächlich nur andere Programme aufrufen und ein bischen Ablauflogik gebraucht wird und das Ganze automatisch regelmässig aufgerufen wird. Also sowas wie Backupscript, brenn- bildbearbeitung, ocr-script, ... Manchmal wächst so ein Programm auch und macht es dann doch in bash, wo man dann denkt, mist, hätte ich doch gleich eine neuere Scriptsprache genommen. bash ist ähnlich kryptisch wie Perl allerdings noch überschaubar auch wenn man es nur gelegentlich nutzt. Für so simples Zeug wie oben ist es ideal.
Python: Finde ich persönlich einfach scheisse, tut mir leid ich verstehe die Begeisterung einfach nicht. Versionschaos mit 2.x/3x, lahm, Whitspace als Synthaxelement ist der grössete Murks schlechthin. Für grössere Programme taugt es auch nicht, das OO-System ist nur auf den ersten Blick toll, hat einige grobe Mängel mit dem man böse auf die Fresse fallen kann. Das Ding ist nur gehypt weil es Ubuntu, google (für ein paar Projektchen) nutzt und einige US-Unis ihre Anfängerkurse darauf umgestellt haben (vorher so ein Lispdialekt), da werden automatisch viele Pythonfanboys herangezüchtet die eh noch nie was anderes gesehen haben und für die das Beste ist. Die ganzen angeblichen Vorteile sind reine Werbeaussagen die genauso auf andere Scriptsprachen zutreffen.
Ruby: Habe ich auch mal eine Zeit lang getestet war extram lahm, aber die Sprache selbst ist sehr schick. Wie das heute aussieht keine Ahnung, angeblich immer noch sehr lahm, ist auch nicht so populär, hat eigentlich nur wegen Rails grössere Bedeutung erlangt aber Rails selbst ist auch auf dem absteigenden Ast seit jede andere Sprache ähnliche Frameworks bietet, bin da allerdings auch nicht mehr so firm darin wie da der aktuelle Stand ist.
Ein Backupskript wird man wohl kaum in c++ schreiben, das geht meist via Shell+externe Werkzeuge gut von der Hand. Die externen Werkzeuge allerdings wird man dann wohl eher in c++ oder besser rust schreiben.
Von kamome umidori am Sa, 28. Februar 2015 um 09:52 #
> wobei ich da immer wenige PHP verwende und so viel wie es geht in den Client stopfe (JavaScript).
Ist ja sehr in - empfinde ich als totale Fehlentwicklung, denn ordentlich geschriebenes PHP finde ich besser als jemandem zu erlauben seinen JS-Code unbesehen auf meinem Rechner auszuführen (halte ich für viel unsicherer). Ich bin froh über NoScript - aber ärgere mich über die vielen Websites, bei denen nicht mal mehr das Menü funktioniert ohne JS.
Klammern auf C-Art finde ich nicht wirklich schlimm, hat Vorteile wie Nachteile. Ich finde sie in jedem Fall angenehmer als begin/end oder das Geklammer über das man sich bei Scheme/Lisp freuen darf.
Python: [...] Versionschaos mit 2.x/3x, lahm, Whitspace als Synthaxelement ist der grössete Murks schlechthin.
In wie fern ist Python langsamer als Perl? Das Versionschaos hast du bei Bash schon innerhalb einer Version (Bash vs Sh). Whitespaces als Syntaxelement hast du bei Bash ebenfalls. Dürftest dich ja schon auf Perl6 freuen, dann hast du das Versionschaos in noch einer Sprache mehr.
Verstehe nicht warum du das nur Python ankreidest. Du musst Python natürlich nicht mögen, andere tun es halt und ich gehöre dazu.
Das wirklich schlimme ist ja, dass CRuby und CPython von den zuerst genannten nichts gelernt haben, was die Implementierung angeht. Die direkte Community ist auch sehr schmerzbefreit.
Ein Beispiel: Die C-API ist dermaßen schlecht, dass sie es nicht erlaubt, mehr als eine Instanz des Interpreters (nützlich für Debugging, Sandboxing usw.) zu erstellen. Stattdessen wird es sich auf so ein C Antipattern verlassen, wo irgendwo im Pythonheader durch eine Funktion eine Instanz erstellt und verwaltet wird.
Selbst Perl kann das besser. Selbst TCC - eigentlich ein C-Compiler, den man zufällig auch einbetten kann- kann das besser. Selbst bei SQLite hat man die Notwendigkeit erkannt und deshalb wird Version 4 mehrere Umgebungen erlauben.
So isses. Drum bin ich auch auf node.js rueber. Seit die Leute anfangen zu kapieren, was das tolle an funktionaler Programmierung ist, beginnen sie auch endlich, JavaScript zu verstehen.
JavaScript hat schon eine bemerkenswerte Karriere hingelegt in den letzten Jahren: JavaScript auf dem Client, JavaScript auf dem Server, JavaScript auf der Datenbank... - fehlt nur noch auf dem Linuxsystem. Als Pendant für die Powershell sozusagen. Und mit JIT ist das *richtig* schnell geworden.
Sysadmins sind halt sehr konservativ und können eher selten "richtig" programmieren bzw. Man kann froh sein, wenn sie in 1 Sprache einen Dreiteiler hin bekommen. Von wegen die geeignetste Sprache aussuchen - *lol*
Zu C++ (hier im Thread): Viel zu komplex und fehleranfällig. Eine Ansammlung von Fehlgriffen und Deprecates aus 3 Jahrzehnten. Steinzeit der Software Entwicklung und zurecht auf dem absteigenden Ast. Entweder gleich C wenns um die letzten 5 % Performance geht oder halt gleich was modernes...
> Zu C++ (hier im Thread): Viel zu komplex und > fehleranfällig. Eine Ansammlung von Fehlgriffen und > Deprecates aus 3 Jahrzehnten. Steinzeit der Software > Entwicklung und zurecht auf dem absteigenden Ast. > Entweder gleich C wenns um die letzten 5 % > Performance > geht oder halt gleich was modernes...
Vorteilhaft ist aber, daß es einen herstellerunabhängigen Standard gibt. http://www.open-std.org/jtc1/sc22/wg14/www/standards http://www.open-std.org/jtc1/sc22/wg21/docs/standards Jedenfalls besser als so manche kurzlebige Sau, die schon mal hier durch das Dorf getrieben wurde.
Und "unmodern" würde ich C auch nicht nennen, wenn ich z.B. an die IoT denke (Programmierung von Microcontrollern / SoC).
Und Qt, besonders wenn ich an Linux denke, ist eines der wichtigsten Frameworks.
Was nützt mir ein "Standard" wenn die Sprache defekt ist? Was nützt mir ein Standard wenn aktuelle Compiler immer auf den Stand des letzten oder vorletzten Standards sind? Was die letzten Jahre in C++ in den Standard eingeflossen ist hat doch noch mehr Leute von diesem verkorksten Müllhaufen weggetrieben. C++ ist ein barocker Zombie, mit 5 Armen, 2 Köpfen jedes Teil von woanders übernommen und schlecht rangeflickt und das wird dann als grossartiges Feature verkauft.
C++ macht nur noch in wenigen Ausnahmen Sinn und dann auch nur wenn man sich auf abgespecktes Featureset beschränkt. Qt versteckt die meisten Grausamkeiten, wer mit Qt seine Programme strickt hat von den Untiefen von C++ nicht wirklich Ahnung, das ist eher C++ mit Stützrädern. Das geht ja schon beim eigenen Makesystem los....
Da hast du (leider) sehr recht... Heftig aber absolut hinreichend beschrieben. Ein wildes Sammelsurium aller guten und saublöden Ideen der letzten 30 Jahre. Niemand hat offenbar den Mut, da mal aufzuräumen und den uebelsten Unsinn raus zunehmen... Bzw. Ja, doch. Nur heißt das dann nicht mehr C++ sondern C# oder Java oder Swift ;-) Die hätten imho eh lieber bei "C mit Klassen" bleiben sollen. Oder "C mit allem". Heute dies morgen das und so kommts zu dem Monster mit 2 Köpfen und 5 Armen... - barock in der Tat - gut beschrieben. Aber wie gesagt, nicht mehr lange. Absteigender Ast. Was für Oldies die nichts neues mehr lernen können und gerne über alte Zeiten schwelgen - weist du noch, 14-18, da hats unter Wasser noch gestaubt. Und der Karl hatte ne Methode die konnte schneller RAM besorgen als alloc. Ja das war noch ein Hund...
> Was für Oldies die nichts neues mehr lernen können > und gerne über alte Zeiten schwelgen - > weist du noch, 14-18, > da hats unter Wasser noch gestaubt. Und der Karl > hatte ne Methode die konnte schneller RAM > besorgen als > alloc. Ja das war noch ein Hund...
Ich bekenne, dass ich so ein Oldie bin und vor über 30 Jahren zu der Erkenntnis gekommen bin, dass C die Vorteile von Assembler und einer Hochsprache wie Fortran miteinander vereint. In diesen 30 Jahren habe ich und meine Kollegen nur Murks gebaut und die neue Generation wird alles besser machen.
C != C++ Und Murks zu programmieren hat nichts oder nur wenig mit der Sprache zu tun. Hab nie behauptet, dass ein Programm schlecht ist, nur weil es in dieser oder jener Sprache geschrieben ist. So what?!
Ggfls. anfälliger als notwendig (PHP), das ja. Ggfls. schwieriger als notwendig (Kampf mit Technik), das ja. Und genau darum geht es ja in dem ganzen Thread: Warum wählt man diese oder jene (Skript-) Sprache. Wenn du vor 30 Jahren eine für damals vielleicht richtige Entscheidung getroffen hast, weil es nix anderes / besseres gab, wäre dieselbe Entscheidung mit den heutigen Umständen dann auch noch richtig? Wohl kaum. So what?!
Danke fuer die nette Antwort - hier meine Anmerkungen: Standard schön und gut. Hat aber jede Sprache in meist besserer Form; wozu bräuchte es sonst z.B. Qt? Und viel von dem "Standard" ist mehr als suboptimal. Hersteller unabhängig. Naja also da sag ich jetzt mal lieber nix zu... Zu C und "modern": Damit ist bei einer Sprache was anderes gemeint, ist schon klar, oder?
Die Sprache C und C++ mit Qt beweisen aber real (nicht nur in der Theorie), daß Portabilität möglich ist.
C ist ein Prozessor-unabhängiger Assembler mit Eigenschaften einer Hochsprache. Es läuft auf quasi jedem Prozessor und jedem Betriebssystem. Vom kleinsten Mikrocontroller über PCs und Mobilgeräte bis zum Supercomputer. Mir ist aus dem Stand kein Betriebssystem bekannt wo C nicht verfügbar wäre. Mir ist aus dem Stand kein GUI System bekannt, das auf so vielen Plattformen zuhause ist wie Qt.
Nach deiner Logik sind 3raeder auch besser wie Fahrräder ohne solche hilfsraeder für Kleinkinder.
Sicher bei sehr grossen Projekten mit viel teamwork mag z.b. Stativ typeing besser sein aber das kann man auch nachrüsten Google hilft.
Zum speed versteht nicht warum das immer das primäre Gegenargument ist für 99 % aller desktop apps und consolenscripts sollte es schnell genug sein der Vorteil ist einfach bei Skriptsprachen das man Entwicklungszeit zumindest bei kleinen Sachen spart und die Optimierung auf weniger CPU Zeit lohnt oft einfach nicht bzw hab ein karaoke game mit Python geschrieben. Klar die engine lief über pyrex aber wo ist da das Problem gibt ja kein Grund nicht zu mischen wenn an der stelle ne andere Sprache besser geeignet ist
Meine ist C++, und ich meine tatsächlich Skriptsprache! Mit dem passenden Interpreter ist das null problemo: http://root.cern.ch/ Das ist auf den ersten Blick eine wissenschaftliche Spezialsoftware, auf den zweiten aber ein C++-Interpreter und Entwicklungstool. Die wissenschaftliche Auslegung besteht nur aus einer mitgelieferten Sammlung von Bibliotheken, die man nicht benutzen muß. Das Ding ist wie eine Shell, man kann am Prompt C++-Befehle eingeben, und die werden sofort ausgeführt. Man kann Skripte verfassen und sie wahlweise kompilieren oder interpretieren lassen, der Interpreter kann nahtlos kompilierte Libraries einbinden und bietet viele nützliche Funktionen für Debugging usw. Man kann Objekte vom Interpreter komplett in spezielle Dateien hinausschreiben mit der momentanen Belegung ihrer Datenfelder und Subklassen, samt Typ-Informationen usw., und sie anderswo wieder einlesen, so daß sie wieder im Speicher des Interpreters sind. Das Ganze ist ein riesengroßer Spielplatz von C++-Aufbauten mit ausgiebig Dokumentation, Tutorials, Foren usw., nützlich für wenig Bewanderte wie auch für Anspruchsvolle, aber keineswegs exklusiv für Physiker gemacht.
Mag ja sein, dass das wie mit einem Interpreter funktioniert. Für "Skripte" benutze ich aber eher eine höhere Sprache in der ich weniger schreiben muss und das Skript lesbar bleibt. Dieser Ansatz vereint aber doch die schlechten Eigenschaften beider Welten (Langsamkeit + Verbosität / schlechter überschaubarer Quelltext).
Ich würde ja gerne zu einem Shell-Script greifen aber da sich jeder Shell-Interpreter anders verhält und es somit verdammt aufwendig ist das eigene Script auf allen zum laufen zu bringen schreckt mich das ziemlich ab.
Dadurch wird das Problem lediglich local umgangen und ein weiteres geschaffen, eine gute Scriptsprache sollte Interpreterunabhängig sein was die Shell nicht ist.
Genau so ist es und weil bei den Shell-Scripts genau dieses Kriterium nicht erfüllt wird ist es meiner Meinung nach auch unverantwortlich überhaupt noch darauf aufzubauen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 01. Mär 2015 um 12:58.
Man kann versuchen sich auf Posix-Shell zu beschränken. In wie fern man damit allerdings Glück mit den verschiedenen Interpretern hat, vermag ich auch nicht zu sagen.
Wenn man Shell Skripte möglichst portierbar halten will, dann einfach die KORN-SHELL nehmen. Ich habe mit Linux(RedHat), Solaris und AIX Maschinen zu tun. Auf allen ist die KSH die Standard-Shell und alles ist gut. Die Korn Shell ist zwar vom Sprachumfang hinter der Bash, aber was bringen mir schöne, neue Möglichkeiten, wenn ich sie nur eingeschränkt nutzen kann? Von daher ist auf allen Maschinen der kleinste gemeinsame Nenner installiert und schon klappt das mit der Portierbarkeit
Ich möchte ein C-Programm auch mit dem Cobol-Compiler übersetzen können, und Cobol Programme mit dem von Modula , usw. - Unfaßbar wieder, was hier für "Experten" aufschlagen.
Mein Senf dazu: Shell: Wenn es klein ist und lediglich ein automatisierter 'Überbau' ist. Perl: Wenn man darin geübt ist und das gewünschte schnell umsetzen kann oder wenn es eine passende Lib servierfertig gibt. Python: Wenn es ein bisschen komplexer wird und es noch keine Vorarbeiten dazu gibt Ruby: Wenn man Python doof findet und nicht speziell auf Libs aus Perl oder Python angewiesen ist.
Nachtrag: Grundsätzlich keine größeren evtl. komplexeren Dinge mehr mit Perl anfangen .... es sei denn es gibt einen technischen Zwang dazu und es wird 'sauber' geschrieben und gut dokumentiert(Bruuuhahahahaha )
Shell-Script, wenn's unbedingt mal sein muss.
Dito.
Wenn es Richtung komplexerer Abläufe geht, würde ich aber zu Python greifen.
Üblicherweise Shell-Skript ziehe jedoch Python vor. Mittlerweile verstärkter Fokus auf Ruby, durch neuere Werkzeuge wie chef und puppet bekommt diese mittlerweile eine stärkere Bedeutung.
Je nach Anforderung/Projekt: PHP (auch auf der Konsole), Perl, Shell, Python, Sonstige ...
Zur Zeit tendiere ich zu Python, aber nur falls ich genügend Zeit habe etwas komplett neu zu machen, da ich da nicht soviel selber geschriebene Libs in Python habe.
Und angefangen hat alles auf meinem Schneider CPC 464: https://de.wikipedia.org/wiki/Amstrad_CPC
mit "Locomotive BASIC" : https://de.wikipedia.org/wiki/Locomotive_BASIC
;)
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 27. Feb 2015 um 15:02.ich verwende fast immer shell skripte.
Da ich nur Bash (und eingeschränkt zsh), Perl und Tcl beherrsche, ist die Auswahl natürlich eingeschränkt
Ich versuche zunächst das Problem mit Bash zu lösen, wenn es aber etwas komplizierter wird oder wenn sich Perl-Module anbieten, nehme ich Perl. So ist in den letzten Jahren die eine oder andere Mini-Applikation entstanden.
Liebe PL Redaktion, es gibt in der IT kaum ein Wort, welches mit mehr Bedeutungen bedacht ist als das Wort "Scriptsprache". Ich persönlich benutze es gar nicht mehr, weil damit zu wenig eindeutig ausgesagt werden kann. Wenn Ihr es schon benutzt, könntet ihr dann nicht klarer abgrenzen, *was* genau damit im dem Kontext gemeint ist?
Die im Sinne von die einzige oder im Sinne von die Hauptdomäne? Und egal was von beidem, wieso eigentlich? Oder soll das Eure Definition sein? Wieso nicht schreiben "Welche Sprache zur Automatisierung von Abläufen"? Dann braucht man das unsägliche Wort nicht verwenden und der Kontext ist sofort klar!(Typo Hinweis: Im Text fehlt ein "n" bei "Scriptsprache" - es muss der Plural sein)
Alle Config-Dateien in json und als Interpreter JavaScript in Form der ultraschnellen neuen Engines mit JIT.
Das wärs :-)
*träum*
Mit nodejs + shelljs kein Traum
Ich schreibe häufig kleine Programme zur Visualisierung von physikalischen Vorgängen mit Perl/Tk.
Ich habe schon oft versucht auf Python umzusteigen, aber irgendwie kann ich mich nicht trennen.
Der Mensch ist ein Gewohnheitstier.
Muss man ja auch nicht. Zum Glück kann man aus vielen Sprachen wählen, und es ist letztlich eine Geschmacksfrage.
Es ist lange her, dass ich Perl benutzt habe, aber ich wurde damit nicht warm. Python ist mir von alles Sprachen generell die liebste. Manche mögen das erzwungene Einrüclen nicht, bevorzugen die Klammern von C, mir gefällt es dagegen sehr gut. Meiner Meinung nach ist es deutlich leichter lesbar und bearbeitbar als Perl. Wer Perl mag, sollte es vielleicht eher mal mit Ruby versuchen
Mittlerweile nicht nur als Webscriptsprache sondern auch als Shellscript zur Steuerung von Serveraufgaben
Mittlerweile nicht nur als Webscriptsprache sondern auch als Shellscript zur Steuerung von Serveraufgaben
Shell Scripte kommen natürlich manchmal vor aber
eigentlich programmiere ich in C oder C++.
Wenn es um Script Sprachen geht,
dann ist Lua mein Favorit,
weil ich das in meine eigenen C/C++ Programme einbauen kann, um diese scriptingfähig zu machen.
Bibliotheken kann man mit
http://swig.org
mit einer Sprachenanbindung versehen.
Perl: Wenn es ne GUI braucht (Tk, Gtk+) aber immer weniger. Es ist wirlklich unlesbar nach einer gewissen Zeit, man muss es täglich nutzen sonst vergisst man die obskure Synthax sehr schnell. Man hockt da wie ein Ägytologe und vesucht die Zeichen zu entziffern.
Äh was macht dieses seltsame Konstrukt jetzt noch mal, da gab es doch wieder ein Sonderfall wenn .... Irgendwie cool aber wenig praktikabel.
PHP: Wenn es etwas 'komplexer' wird und Netzsupport gebraucht wird, manchmal nehme ich hier auch Perl, je nachdem was es da schon an fertigen Modulen gibt nehme ich die eine oder andere Sprache. Ansonst auch für Webentwicklung (läuft alles lokal), wobei ich da immer wenige PHP verwende und so viel wie es geht in den Client stopfe (JavaScript).
Habe PHP eine Zeit lang auch beruflich nutzen 'müssen',
für "richtige" Webentwicklung ist es ein krampf, obwohl es sich 'professionalisiert' hat, es gibt ganz nette Frameworks aber unter der Haube stinkt es immer noch, die Sicherheitsmägel sind immer noch extrem und hahnebüchen. Erst letzten wieder auf Heise eine entspr. Meldung wo man sich einfach nur an den Kopf fasst.
bash: Wenn es Systemscripte sind die hauptsächlich nur andere Programme aufrufen und ein bischen Ablauflogik gebraucht wird und das Ganze automatisch regelmässig aufgerufen wird. Also sowas wie Backupscript, brenn- bildbearbeitung, ocr-script, ... Manchmal wächst so ein Programm auch und macht es dann doch in bash, wo man dann denkt, mist, hätte ich doch gleich eine neuere Scriptsprache genommen. bash ist ähnlich kryptisch wie Perl allerdings noch überschaubar auch wenn man es nur gelegentlich nutzt. Für so simples Zeug wie oben ist es ideal.
Python: Finde ich persönlich einfach scheisse, tut mir leid ich verstehe die Begeisterung einfach nicht. Versionschaos mit 2.x/3x, lahm, Whitspace als Synthaxelement ist der grössete Murks schlechthin.
Für grössere Programme taugt es auch nicht, das OO-System ist nur auf den ersten Blick toll, hat einige grobe Mängel mit dem man böse auf die Fresse fallen kann. Das Ding ist nur gehypt weil es Ubuntu, google (für ein paar Projektchen) nutzt und einige US-Unis ihre Anfängerkurse darauf umgestellt haben (vorher so ein Lispdialekt), da werden automatisch viele Pythonfanboys herangezüchtet die eh noch nie was anderes gesehen haben und für die das Beste ist.
Die ganzen angeblichen Vorteile sind reine Werbeaussagen die genauso auf andere Scriptsprachen zutreffen.
Ruby: Habe ich auch mal eine Zeit lang getestet war extram lahm, aber die Sprache selbst ist sehr schick. Wie das heute aussieht keine Ahnung, angeblich immer noch sehr lahm, ist auch nicht so populär, hat eigentlich nur wegen Rails grössere Bedeutung erlangt aber Rails selbst ist auch auf dem absteigenden Ast seit jede andere Sprache ähnliche Frameworks bietet, bin da allerdings auch nicht mehr so firm darin wie da der aktuelle Stand ist.
Warum nehmen die Leute nicht gleich C++ ,
wenn auf Linux der g++ doch bei jeder Distribution dabei ist?
Und für GUI dann Qt.
Man will ja auch jeden Mist erst mal kompilieren müssen.
make
Als wenn das ein Thema wäre.
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
http://qt-project.org/doc/qt-4.8/qmake-tutorial.html
Weil ich keinen Presslufthammer brauche wenn ich einen Nagel reinschlagen will.
Was ist daran "Presslufthammer"?
g++ hello.cpp -o hello
Für kleine Sachen kann man sich Makefile sparen.
Ist dann aber nicht eingeschränkt, wenn das "tool" doch wachsen sollte.
PS: Man muss das ja nicht ewig eintippen, da es eine Commandline History gibt
Ein Backupskript wird man wohl kaum in c++ schreiben, das geht meist via Shell+externe Werkzeuge gut von der Hand. Die externen Werkzeuge allerdings wird man dann wohl eher in c++ oder besser rust schreiben.
> wobei ich da immer wenige PHP verwende und so viel wie es geht in den Client stopfe (JavaScript).
Ist ja sehr in - empfinde ich als totale Fehlentwicklung, denn ordentlich geschriebenes PHP finde ich besser als jemandem zu erlauben seinen JS-Code unbesehen auf meinem Rechner auszuführen (halte ich für viel unsicherer). Ich bin froh über NoScript - aber ärgere mich über die vielen Websites, bei denen nicht mal mehr das Menü funktioniert ohne JS.
Das sind Webanwendungen die nur im internen Netz laufen, das sieht keiner der es nicht soll.
PHP dient nur als Ajaxgegenstelle und Schnittstelle zur DB.
Für intern ist das natürlich prima - wäre schön, wenn das alle so machten.
Whitespace als Syntaxelement ist hervorragend!. Code in Python ist für mich der leserlichste und wartbarste.
{
Ich verstehe um Himmels Willen nicht, warum so viele Sprachen die unsägliche C-Syntax mit den umherflatternden Blockklammern "{" kopieren.
}
Könntest ja mal Lua / LuaJIT probieren. Lesbar und schnell aber leider viel schwächere Batterien als Python.
Klammern auf C-Art finde ich nicht wirklich schlimm, hat Vorteile wie Nachteile. Ich finde sie in jedem Fall angenehmer als begin/end oder das Geklammer über das man sich bei Scheme/Lisp freuen darf.
In wie fern ist Python langsamer als Perl? Das Versionschaos hast du bei Bash schon innerhalb einer Version (Bash vs Sh). Whitespaces als Syntaxelement hast du bei Bash ebenfalls. Dürftest dich ja schon auf Perl6 freuen, dann hast du das Versionschaos in noch einer Sprache mehr.
Verstehe nicht warum du das nur Python ankreidest. Du musst Python natürlich nicht mögen, andere tun es halt und ich gehöre dazu.
Das wirklich schlimme ist ja, dass CRuby und CPython von den zuerst genannten nichts gelernt haben, was die Implementierung angeht. Die direkte Community ist auch sehr schmerzbefreit.
Ein Beispiel: Die C-API ist dermaßen schlecht, dass sie es nicht erlaubt, mehr als eine Instanz des Interpreters (nützlich für Debugging, Sandboxing usw.) zu erstellen.
Stattdessen wird es sich auf so ein C Antipattern verlassen, wo irgendwo im Pythonheader durch eine Funktion eine Instanz erstellt und verwaltet wird.
Selbst Perl kann das besser. Selbst TCC - eigentlich ein C-Compiler, den man zufällig auch einbetten kann- kann das besser. Selbst bei SQLite hat man die Notwendigkeit erkannt und deshalb wird Version 4 mehrere Umgebungen erlauben.
So isses.
Drum bin ich auch auf node.js rueber. Seit die Leute anfangen zu kapieren, was das tolle an funktionaler Programmierung ist, beginnen sie auch endlich, JavaScript zu verstehen.
JavaScript hat schon eine bemerkenswerte Karriere hingelegt in den letzten Jahren: JavaScript auf dem Client, JavaScript auf dem Server, JavaScript auf der Datenbank... - fehlt nur noch auf dem Linuxsystem. Als Pendant für die Powershell sozusagen.
Und mit JIT ist das *richtig* schnell geworden.
Sysadmins sind halt sehr konservativ und können eher selten "richtig" programmieren bzw. Man kann froh sein, wenn sie in 1 Sprache einen Dreiteiler hin bekommen. Von wegen die geeignetste Sprache aussuchen - *lol*
Zu C++ (hier im Thread): Viel zu komplex und fehleranfällig. Eine Ansammlung von Fehlgriffen und Deprecates aus 3 Jahrzehnten. Steinzeit der Software Entwicklung und zurecht auf dem absteigenden Ast. Entweder gleich C wenns um die letzten 5 % Performance geht oder halt gleich was modernes...
> Zu C++ (hier im Thread): Viel zu komplex und
> fehleranfällig. Eine Ansammlung von Fehlgriffen und
> Deprecates aus 3 Jahrzehnten. Steinzeit der Software
> Entwicklung und zurecht auf dem absteigenden Ast.
> Entweder gleich C wenns um die letzten 5 %
> Performance
> geht oder halt gleich was modernes...
Vorteilhaft ist aber, daß es einen herstellerunabhängigen Standard gibt.
http://www.open-std.org/jtc1/sc22/wg14/www/standards
http://www.open-std.org/jtc1/sc22/wg21/docs/standards
Jedenfalls besser als so manche kurzlebige Sau, die schon mal hier durch das Dorf getrieben wurde.
Und "unmodern" würde ich C auch nicht nennen,
wenn ich z.B. an die IoT denke (Programmierung von Microcontrollern / SoC).
Und Qt, besonders wenn ich an Linux denke, ist eines der wichtigsten Frameworks.
Was haben C/C++ mit Skripten (im Sinne von interpretierten Programmen) zu tun?
Lies bitte den kompletten Thread.
Man kann mit C/C++ auch in Scriptform ala bash programmieren.
Ich habe jetzt adhoc nichts gefunden, aber irgendwann 'mal ein
Artikel dazu gelesen.
Siehe dazu meinen Beitrag oben! Der Sinn ist hier sicherlich *nicht* gemeint - und dann wären auch viele aufgeführte Sprachen falsch platziert!
Also Obacht mit diesem doofen Begriff "Scriptsprache"!
Was nützt mir ein "Standard" wenn die Sprache defekt ist? Was nützt mir ein Standard wenn aktuelle Compiler immer auf den Stand des letzten oder vorletzten Standards sind?
Was die letzten Jahre in C++ in den Standard eingeflossen ist hat doch noch mehr Leute von diesem verkorksten Müllhaufen weggetrieben. C++ ist ein barocker Zombie, mit 5 Armen, 2 Köpfen jedes Teil von woanders übernommen und schlecht rangeflickt und das wird dann als grossartiges Feature verkauft.
C++ macht nur noch in wenigen Ausnahmen Sinn und dann auch nur wenn man sich auf abgespecktes Featureset beschränkt. Qt versteckt die meisten Grausamkeiten, wer mit Qt seine Programme strickt hat von den Untiefen von C++ nicht wirklich Ahnung, das ist eher C++ mit Stützrädern. Das geht ja schon beim eigenen Makesystem los....
Da hast du (leider) sehr recht...
Heftig aber absolut hinreichend beschrieben.
Ein wildes Sammelsurium aller guten und saublöden Ideen der letzten 30 Jahre.
Niemand hat offenbar den Mut, da mal aufzuräumen und den uebelsten Unsinn raus zunehmen...
Bzw. Ja, doch. Nur heißt das dann nicht mehr C++ sondern C# oder Java oder Swift ;-)
Die hätten imho eh lieber bei "C mit Klassen" bleiben sollen. Oder "C mit allem". Heute dies morgen das und so kommts zu dem Monster mit 2 Köpfen und 5 Armen... - barock in der Tat - gut beschrieben.
Aber wie gesagt, nicht mehr lange. Absteigender Ast. Was für Oldies die nichts neues mehr lernen können und gerne über alte Zeiten schwelgen - weist du noch, 14-18, da hats unter Wasser noch gestaubt. Und der Karl hatte ne Methode die konnte schneller RAM besorgen als alloc. Ja das war noch ein Hund...
> Was für Oldies die nichts neues mehr lernen können
> und gerne über alte Zeiten schwelgen -
> weist du noch, 14-18,
> da hats unter Wasser noch gestaubt. Und der Karl
> hatte ne Methode die konnte schneller RAM
> besorgen als
> alloc. Ja das war noch ein Hund...
Ich bekenne, dass ich so ein Oldie bin und vor über 30 Jahren zu der Erkenntnis gekommen bin, dass C die Vorteile von Assembler und einer Hochsprache wie Fortran miteinander vereint.
In diesen 30 Jahren habe ich und meine Kollegen nur Murks gebaut und die neue Generation wird alles besser machen.
C != C++
Und Murks zu programmieren hat nichts oder nur wenig mit der Sprache zu tun.
Hab nie behauptet, dass ein Programm schlecht ist, nur weil es in dieser oder jener Sprache geschrieben ist. So what?!
Ggfls. anfälliger als notwendig (PHP), das ja.
Ggfls. schwieriger als notwendig (Kampf mit Technik), das ja. Und genau darum geht es ja in dem ganzen Thread: Warum wählt man diese oder jene (Skript-) Sprache. Wenn du vor 30 Jahren eine für damals vielleicht richtige Entscheidung getroffen hast, weil es nix anderes / besseres gab, wäre dieselbe Entscheidung mit den heutigen Umständen dann auch noch richtig? Wohl kaum. So what?!
Danke fuer die nette Antwort - hier meine Anmerkungen:
Standard schön und gut. Hat aber jede Sprache in meist besserer Form; wozu bräuchte es sonst z.B. Qt? Und viel von dem "Standard" ist mehr als suboptimal.
Hersteller unabhängig. Naja also da sag ich jetzt mal lieber nix zu...
Zu C und "modern": Damit ist bei einer Sprache was anderes gemeint, ist schon klar, oder?
Greets!
Die Sprache C und C++ mit Qt beweisen aber real (nicht nur in der Theorie),
daß Portabilität möglich ist.
C ist ein Prozessor-unabhängiger Assembler mit Eigenschaften einer Hochsprache.
Es läuft auf quasi jedem Prozessor und jedem Betriebssystem.
Vom kleinsten Mikrocontroller über PCs und Mobilgeräte bis zum Supercomputer.
Mir ist aus dem Stand kein Betriebssystem bekannt wo C nicht verfügbar wäre.
Mir ist aus dem Stand kein GUI System bekannt, das auf so vielen Plattformen zuhause ist wie Qt.
Das hängt aber von der Verfügbarkeit eines entsprechenden Compilers ab. "C an sich" läuft da nicht.
danke, so isses.
Und noch in Ergänzung: "Es läuft" != "Es ist super, das so zu machen"
Nach deiner Logik sind 3raeder auch besser wie Fahrräder ohne solche hilfsraeder für Kleinkinder.
Sicher bei sehr grossen Projekten mit viel teamwork mag z.b. Stativ typeing besser sein aber das kann man auch nachrüsten Google hilft.
Zum speed versteht nicht warum das immer das primäre Gegenargument ist für 99 % aller desktop apps und consolenscripts sollte es schnell genug sein der Vorteil ist einfach bei Skriptsprachen das man Entwicklungszeit zumindest bei kleinen Sachen spart und die Optimierung auf weniger CPU Zeit lohnt oft einfach nicht bzw hab ein karaoke game mit Python geschrieben. Klar die engine lief über pyrex aber wo ist da das Problem gibt ja kein Grund nicht zu mischen wenn an der stelle ne andere Sprache besser geeignet ist
Meine ist C++, und ich meine tatsächlich Skriptsprache! Mit dem passenden Interpreter ist das null problemo: http://root.cern.ch/
Das ist auf den ersten Blick eine wissenschaftliche Spezialsoftware, auf den zweiten aber ein C++-Interpreter und Entwicklungstool. Die wissenschaftliche Auslegung besteht nur aus einer mitgelieferten Sammlung von Bibliotheken, die man nicht benutzen muß.
Das Ding ist wie eine Shell, man kann am Prompt C++-Befehle eingeben, und die werden sofort ausgeführt. Man kann Skripte verfassen und sie wahlweise kompilieren oder interpretieren lassen, der Interpreter kann nahtlos kompilierte Libraries einbinden und bietet viele nützliche Funktionen für Debugging usw.
Man kann Objekte vom Interpreter komplett in spezielle Dateien hinausschreiben mit der momentanen Belegung ihrer Datenfelder und Subklassen, samt Typ-Informationen usw., und sie anderswo wieder einlesen, so daß sie wieder im Speicher des Interpreters sind.
Das Ganze ist ein riesengroßer Spielplatz von C++-Aufbauten mit ausgiebig Dokumentation, Tutorials, Foren usw., nützlich für wenig Bewanderte wie auch für Anspruchsvolle, aber keineswegs exklusiv für Physiker gemacht.
Ist das ähnlich wie Matlab Simulink?
http://de.mathworks.com/
Oder Octave?
https://www.gnu.org/software/octave/
Oder Scilab?
http://www.scilab.org/
Wo ist der Zusammenhang zwischen einen C/C++-Interpreter und Simulink?
Mag ja sein, dass das wie mit einem Interpreter funktioniert. Für "Skripte" benutze ich aber eher eine höhere Sprache in der ich weniger schreiben muss und das Skript lesbar bleibt.
Dieser Ansatz vereint aber doch die schlechten Eigenschaften beider Welten (Langsamkeit + Verbosität / schlechter überschaubarer Quelltext).
Ich würde ja gerne zu einem Shell-Script greifen aber da sich jeder Shell-Interpreter anders verhält und es somit verdammt aufwendig ist das eigene Script auf allen zum laufen zu bringen schreckt mich das ziemlich ab.
Es gibt kein Shell-Problem. Schon mal was von #! (gesprochen shebang) gelesen?
#!/bin/bash
am Anfang des Skripts, und es wird die Bash verwendet. Damit ist das Verhalten überall genau gleich.
Dadurch wird das Problem lediglich local umgangen und ein weiteres geschaffen, eine gute Scriptsprache sollte Interpreterunabhängig sein was die Shell nicht ist.
Fazit: Nicht wirklich massen tauglich.
Sag mal: Wie willst du denn eine interpretierte Skriptsprache ohne ihren Interpreter verwenden?
Richtig! Gar nicht!
Nein. Er möchte eine interpretierte Sprache benutzen ohne von einer speziellen Implementierung eines Interpreter abhängig zu sein.
Genau so ist es und weil bei den Shell-Scripts genau dieses Kriterium nicht erfüllt wird ist es meiner Meinung nach auch unverantwortlich überhaupt noch darauf aufzubauen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 01. Mär 2015 um 12:58.Man kann versuchen sich auf Posix-Shell zu beschränken. In wie fern man damit allerdings Glück mit den verschiedenen Interpretern hat, vermag ich auch nicht zu sagen.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_01
Wenn man Shell Skripte möglichst portierbar halten will, dann einfach die KORN-SHELL nehmen. Ich habe mit Linux(RedHat), Solaris und AIX Maschinen zu tun. Auf allen ist die KSH die Standard-Shell und alles ist gut. Die Korn Shell ist zwar vom Sprachumfang hinter der Bash, aber was bringen mir schöne, neue Möglichkeiten, wenn ich sie nur eingeschränkt nutzen kann? Von daher ist auf allen Maschinen der kleinste gemeinsame Nenner installiert und schon klappt das mit der Portierbarkeit
Gott, was für ein Schwachsinn!
Ich möchte ein C-Programm auch mit dem Cobol-Compiler übersetzen können, und Cobol Programme mit dem von Modula , usw. - Unfaßbar wieder, was hier für "Experten" aufschlagen.
Mahlzeit Leute!
Mein Senf dazu:
Shell: Wenn es klein ist und lediglich ein automatisierter 'Überbau' ist.
Perl: Wenn man darin geübt ist und das gewünschte schnell umsetzen kann oder wenn es eine passende Lib servierfertig gibt.
Python: Wenn es ein bisschen komplexer wird und es noch keine Vorarbeiten dazu gibt
Ruby: Wenn man Python doof findet und nicht speziell auf Libs aus Perl oder Python angewiesen ist.
Nachtrag:
)
Grundsätzlich keine größeren evtl. komplexeren Dinge mehr mit Perl anfangen .... es sei denn es gibt einen technischen Zwang dazu und es wird 'sauber' geschrieben und gut dokumentiert(Bruuuhahahahaha
Bash oder für komplexere Dinge PHP (auf der Shell)