Mal andersrum: Das sind die unbeliebtesten Programmiersprachen

Es gibt Programmiersprachen, die eigentlich zu Unrecht als "beliebt" ge­kenn­zeich­net werden. Den eigentlich sind sie nur besonders häufig aus irgendwelchen Gründen vorgegeben - und die Programmierer, die tag­täg­lich mit ihren Macken zu kämpfen ... mehr... Entwickler, Programmierung, Programmierer, Fail, Frust Bildquelle: Public Domain Entwickler, Programmierung, Programmierer, Fail, Frust Entwickler, Programmierung, Programmierer, Fail, Frust Public Domain

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Ähm... Diese Statistik würd ich nichtmal glauben wenn ich sie selbst gefälscht hätt. Javascript soll weniger unbeliebt sein als C, C#, Java???? Sorry, aber Javascript ist für Entwickler sowas wie Selbstgeißelung im Christentum. Es ist nichtmal sicher, ob Javascript überhaupt als Programmiersprache durchgeht....
 
@Tintifax: witzig was du schreibst...

nur schade, dass auf JavaScript so ziemlich alles basiert was im web existiert und sogar Serverseitig wird JavaScript eingesetzt...

jaja, die Sprüche mit Programmiersprache vs. Scriptsprache finde ich immer "witzig bis traurig" ... wo ist denn bitte der Unterschied? <- richtig, der Unterschied liegt in der Ausführung.. dann erklär mir mal was java ist... ne Kombination aus Scriptsprache und Programmiersprache?
ach komm...

PS. die beste Programmiersprache ist die, bei welchen sich der Programmierer mühe gibt, so habe ich schon edles VBA gesehen und abgekotztes Java oder objectiv C...
 
@bear7: Und weil es überall verwendet wird ist es eine gute Sprache? Und sorry, wenn Du wirklich den Unterschied nur auf "wie es ausggeführt" wird festlegen kannst, dann brauch ich leider wirklich nicht weiterdiskutieren.
 
@Tintifax: "Gut" ist immer relativ. Wenn eine Programmiersprache für den jeweiligen Einsatzzweck reicht, dann ist sie zumindest gut genug.
 
@Tintifax: Heute ist es nicht viel mehr Unterschied und der verschwimmt doch immer weiter. Turing-vollständig sind beide. JavaScript-Code wird inzwischen durch hochoptimierte Engines mit JIT-Kompilierung geschickt, als würde es bei den lustig aufspringenden Webseitenmenüs um automatisierten Optionshandel gehen und gleichzeitig hast du zum Teil native Software auf modernen System laufen, die mit einem Compiler aus dem letzten Jahrzehnt mit Debug-Einstellungen ohne Optimierung gebaut wurde und seitdem nicht mehr angefasst wird.
Das ist wirklich nicht mehr unbedingt eine Frage der Sprache. Bei Android kannst du die gleiche APK-Datei ausliefern und auf einem hinreichend alten Gerät läuft sie in der Dalvik-VM, bei einer ausreichend neuen Version, wird sie in native Anweisungen übersetzt.

Da sind heute wirklich andere Aspekte wichtiger, als die künstliche Trennung zwischen Skript- und Programmiersprache. Gibt es gute Richtlinien? Wird die Sprache aktiv und in eine vernünftige Richtung weiterentwickelt (das C++, dass ich heute schreibe, sieht fundamental anders aus, als das C++ meiner Vorgänger)? Gibt es gute Unterstützung durch Werkzeuge (static analyzer, IDE,...)? Wie sieht es mit Bibliotheken aus?

Wenn ich eine moderne JavaScript-Zeile sehe, die da lautet:
var this_can_be_statically_checked: string = 'Hello World';
dann habe ich da mehr Vertrauen, als bei einem (alten) C(++)-Interface, dass da lautet:
void f( void* the_compiler_has_no_idea_whether_this_works_at_runtime, int some_size_that_might_or_might_not_be_correct);

(PS: Das heißt natürlich nicht, dass ich für die Implementierung meiner performancekritischen mathematischen Anwendungen meinen C++(11/14/17)-fähigen Compiler aus der Hand geben würde.)
 
@dpazra: Schon mal versucht die performancekritischen mathematischen Routinen deiner Anwendungen in purem C zu programmieren? Es mag bedeutend sperriger sein als C++, der Performanceschub ist die Mühe jedoch wert.
 
@SegFault: Ich bezweifle, dass es überhaupt ohne weiteres einen Performance-Schub gibt. Mit constexpr und templates kann ich Dinge von kritischen Codepfaden auf die Compile-Zeit verlegen, bei denen ich ohne Metaprogrammierung gar keine Idee hätte, wie ich dafür Verzweigungen zur Laufzeit vermeiden könnte, ohne von den Funktionen 2^Parameterzahl Versionen in den Quelltext zu schreiben.
 
@Tintifax: Da bin ich aber mal gespannt auf Unterschiede zwischen Script- und Programmiersprache. Also abseits davon wie sie kompiliert werden. Kannst da welche nennen?
 
Also Programmiersprachen, die nur wenige benutzen, werden von denjenigen verwendet, weil sie sie cool finden oder daran gebunden sind. Sie werden die dann kaum disliken. Andere, die von Millionen verwendet werden, weil sie keine andere Wahl haben, finden natürlich mehr Dislikes. Es gibt ja auch viele, die Windows hassen, es aber trotzdem benutzen (müssen). Und wer sich Ubuntu Desktop installiert, macht das mit Sicherheit, weil er da voll drauf steht. Ich mag meine Frau auch nicht jeden Tag :D
 
Cobol fehlt !!!!!
 
@sorduk: Jo, und mein gutes altes Pascal auch!
 
Hier gilt dasselbe wie bei der anderen Übersicht auch: Der Interpretationsspielraum ist zu groß. Ergo schreib ich auch nochmal -in etwa- dasselbe:

--- SO ist eine Q&A-Plattform. PERL ist daher nicht die unbeliebteste, sondern die intuitivste Programmiersprache: Man muß dazu nicht fragen, sondern kann einfach losfangen und das, was man möchte, allein umsetzen.

Wie jetzt? Unhaltbare Behauptung?

Kann schon sein, aber nicht haltbarer oder unhaltbarer als die, daß Quantität Schlußfolgerungen auf Qualität zulassen würde. Wäre das anders, wäre die Erde eine Scheibe.
 
@RalphS: Ich zitiere mal den heise-Artikel zum selben Thema: "Die Ergebnisse der Studie basieren dabei auf den Eingaben von Entwicklern im Jobportal Stack Overflow Jobs. Hier können Entwickler nämlich nicht nur Sprachen und Technologien angeben, mit denen sie gerne arbeiten wollen, sondern auch die Sprachen, mit denen sie am liebsten nichts zutun haben wollen"
Du hast also bei deinem Kommentar falsche Annahmen zur Datengrundlage getroffen.
 
@TiKu: Und doch verwendet kein Schwein mehr irgendwelche regulären Ausdrücke, die nicht aus PERL entstammen, und wenn doch, werden Möglichkeiten gesucht, das zu ändern.

Ich wollte auch nur herausstellen, daß der Interpretationsspielraum zu groß ist. Die Studie sagt nichts aus. Genausogut könnte man meterlange Abhandlungen über die Bedeutung von Rorschachklecksen schreiben.
 
@RalphS: "Und doch verwendet kein Schwein mehr irgendwelche regulären Ausdrücke, die nicht aus PERL entstammen, und wenn doch, werden Möglichkeiten gesucht, das zu ändern."

Wenn du das Schwein nicht gerade wörtlich meinst, halte ich das für eine sehr mutige These.
 
@crmsnrzl: Sind Dir Perl-Regex wirklich ein Fremdwort? Mach Dich mal bissel schlau zu dem Thema.
 
@RalphS: Ich weiß was das ist, ich zweifel nur deine Behauptung an. Speziell den hinteren Teil.
 
@crmsnrzl: Aha. Okay, dann laß mal hören, was beliebter ist als PERL regex.
 
@RalphS: Aha. Beliebter? Genau das war meinen Aussage ... o0

Wenn du Probleme beim Erfassen der Bedeutung von Worten hast, sehe ich keinen Sinn darin, das hier weiter zu führen.
 
@crmsnrzl: Dito, weil entweder sind wir derselben Ansicht - in welchem Fall ich die Diskussion eh nicht verstehe -- oder wir sind es nicht, in welchem Fall wir uns sicher darauf einigen können, daß zumindest einer von uns des verstehenden Lesens nicht mächtig ist.

Aber ist auch egal. Ich bin froh, PERL zu können und PERL regex zu haben, auch außerhalb von PERL selber.... nicht daß das so unhandlich wäre wie dargestellt, aber sei's drum.

Andere schwören auf Python, wo ein Leerzeichen zuviel oder zuwenig den Code kaputtmacht.
 
@RalphS: Meine Güte...

"[...] und wenn doch, werden Möglichkeiten gesucht, das zu ändern."
Nein, sondern denen ist es egal.

Jetzt verstanden?
 
Also ich mochte die assembler Ebene im Studium am liebsten. :D
 
@Aerith: Wozu? C vereint die Performance von Assembler mit der Benutzerfreundlichkeit einer höheren Programmiersprache =)
 
@SegFault: Man kann nicht immer logisch begründen warum man etwas mag. Ich mochte einfach die Nähe zur Hardware.
 
@SegFault: Naja, C ist ein Kompromiss, so wie andere Sprachen auch. Um die maximale Performance in einer Berechnung zu erreichen, muss man unter anderem Gebrauch von Vektorbefehlen (SIMD) machen, was man in Assembler direkt ausdrücken kann, bei C-Programmen aber durch Compiler-Optimierungen bekommt (wie bei anderen kompilierten Sprachen auch). Und die Benutzerfreundlichkeit von C ist so eine Sache. Wie schreibt man in C z.B.:
std::map<my_comparable_type, my_value_type> customers;
oder
auto matrix_summe = std::accumulate<meine_matrizen.begin(), meine_matrizen.end(), startwert);
 
@dpazra: Nein, Vektoroperationen lassen sich auch in C direkt und explizit nutzen, dies muss nicht dem Compiler überlassen werden. Hierfür müssen lediglich die entsprechenden Vektorvariablen deklariert werden, auf welche dann Vektoroperationen angewendet werden.

Deine Frage nach "wie setze ich folgende Syntax in C um" trifft genau den Kern des Problems: Höhere Sprachen bringen zwar fantastische Komfortfeatures, am Ende muss all das aber wieder in Maschinencode übersetzt werden. Je näher die Sprache an der Hardware ist, umso einfacher die Übersetzung. Hochsprachenkonstrukte hingegen führen zu übermäßig vielen Kernel calls, temporären Arrays, ineffizienter RAM-Nutzung oder anderen Flaschenhälsen. C hingegen bietet dir die volle Kontrolle darüber, was konkret passiert.

Jenseits performancekritischer Anwendungen wird die Luft hingegen schnell dünn. Wer einmal Anwendungen in C mit GTK-GUI entwickeln musste, lernt die Vorzüge von Python, Java oder C++ schnell zu schätzen.
 
@SegFault: Vielleicht ist mein C-Wissen hier unvollständig, ich dachte, dass es in der C-Sprache keine Anweisungen dafür gäbe und dass es da nur Compiler-Extensions gibt, mit denen soetwas geht.

Was die Kritik an Hochsprachen in dem Post angeht: Sie ist sicher war für die Java- oder C#-Äquivalente dieser Aufrufe, deshalb hatte ich bewusst C++ gewählt. Bei Java würde ich nicht wissen, was hinter diesen Ausdrücken in der VM passiert, aber bei C++ weiß ich es so genau, als würde ich die (weitaus längeren) C-Äquivalente schreiben.
Wenn ich std accumulate aufrufe, läuft das im End-Effekt auf eine inline-Funktion, deren Implementierung ich mit 3 Klicks in der IDE nachschlagen kann und die schlicht in einer for-Schleife besteht, die vom Anfang bis zum Ende läuft und die Elemente zum Startwert addiert. Es gibt keine temporären Arrays, keine zusätzlichen Indirektionen, keine größere RAM-Nutzung als den einen Iterator der das Äquivalent zu "int i" in der manuellen for-Schleife wäre usw. Eine klassische Zero-Overhead-C++-Abstraktion.
Wenn ich etwas nicht-triviales akkumuliere, dann gebe ich noch eine Inline-Funktion mit, die sicherstellt, dass += mit move-Semantik benutzt wird und keine temporären Objekte oder überflüssige Kopien auftreten.

Für std::map gilt das selbe. Es ist ein Rot-Schwarz-Baum, wie man ihn aus dem Grundstudium kennt, ich kann dir auf den Byte genau sagen, wie groß er ist:
Zwei Pointer (4 oder 8 Byte, je nachdem ob 32-Bit oder 64-Bit-Target), davon einer auf den Head-Knoten, ein size_t (auch 4 oder 8 Byte, je nachdem) für die Größe in map-Handle und dann pro Knoten 3 Pointer (zwei Kinder-, ein Eltern-Knoten), ein Short für Rot- oder Schwarz und ein Short um anzuzeigen, ob es ein Dummy-Knoten ist (hier würden natürlich booleans genügen, aber wer mitgezählt hat sieht, dass aus Alignment-Gründen, sowieso 4 Byte genutzt werden müssen) und schlussendlich das Paar aus Schlüssel und Wert (Größe je nachdem, was ich eben als Schlüssel- und Werttyp angegeben habe). Würde ich einen Suchbaum manuell implementieren, würde ich auf exakt die selbe RAM-Nutzung kommen
Für die Methoden das gleiche: ich kann gucken, welche Definition hinter map::at(...) steht und es ist schlicht eine Baumtraversion, so wie man sie auch in C schreiben würde. Wenn man Key kleiner als der betrachtete Knoten ist, gehe ich in den linken Suchbaum, sonst in den rechten.

Eine weitere Zero-Overhead-Abstraktion. RAM-Nutzung, Overhead, etc. nicht anders, als würde man einen Rot-Schwarz-Baum manuell in C implementieren. Nur, dass ich eben hier ein Template habe, die Implementierung für beliebige Typen verwenden kann und der Compiler für mich prüfen kann, ob ich Fehler bei der Typennutzung mache oder nicht. Wenn ich mir tfind aus der GNU Libc anschaue, dann ist es so ziemlich das gleiche, allerdings ist in C natürlich das Interface ein bisschen anders: void * tfind (const void *key, void *const *rootp, comparison_fn_t compar) . Na bei den klaren Typen kann ja nichts schiefgehen.
 
Meine Lieblingsprogrammiersprache ist HTML. Das einzige was mich stört ist, dass es keine If-Schleifen gibt.
 
@FuzzyLogic: HTML ist keine Programmiersprache!
 
@kabuko: ich glaube du kennst dich mit diesem Thema nicht aus...
 
"As young thinglings we are schooled in the wisdom of the universe: physics, mathematics, Fortran - the greatest of the programming languages"

Ein Simpsons-Klassiker.
 
Der Beitrag bedeutet im Ausschlussverfahren, dass die klassischen Programmiersprachen wie Basic, Pascal, Fortran usw. beliebt sind, denn unbeliebt scheinen sie dem Beitrag gemäß nicht zu sein.
 
Programmiersprache r? nochnie davon gehört wird schwirig da was zu finden bei Google :-D
 
@fabian86: R ist für statistische Analysen ...
Kommentar abgeben Netiquette beachten!
Einloggen

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles