Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Allgemeines (OffTopic) » Eure Einstellung zu Programmiersprachen

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
24.04.2009, 12:41 Uhr
Bruder Leif
dances with systems
(Operator)


Moin!

In den Firmen, in denen ich bisher gearbeitet habe, haben wir immer mal kleine Meinungsautausche durchgefuehrt, in denen wir den anderen unsere Gedanken zu unseren "Lieblingssprachen" mitgeteilt haben, und jeder hat dabei das eine oder andere gelernt, und Vorurteile (negative UND positive) aus dem Weg geraeumt, oder von Sprachen gehoert, die kennenzulernen sich lohnen wuerde...

Daher mal die allgemeine Frage: Wie steht Ihr zu den von Euch _primaer_ eingesetzten Sprachen? Was gefaellt Euch, was stoert Euch? Im einen oder anderen Thread schreibt jeder mal ein paar Zeilen zu seiner Meinung, aber eine kompakte Zusammenstellung aller Rants und Werbung auf einer Seite, das waere doch mal was...

Das soll dabei KEIN Flamewar werden, keine grosse Diskussion ueber die Objektivitaet der einzelnen Aussagen, sondern ausdruecklich eine _subjektive_ Aufstellung _persoenlicher_ Meinungen. Wer sich dann die Meinung der anderen mal in Ruhe durchliest, ohne gleich mit dem Messer aus dem Busch zu springen, hat ordentlich Gelegenheit, was dazuzulernen.

Dann giess ich mal die ersten Liter Benzin aus:


C:
Eigentlich hat C das Zeug, zu meiner Lieblingssprache zu werden. Einfach, kompakt, schnell, keine Ueberraschungen, ueberall verfuegbar. Dummerweise ist der Aufwand beim Programmieren eine grosse Produktivitaetsbremse. Es gibt zwar haufenweise Libs, die die etwas magere Standardbibliothek erweitern, aber keinen wirklich sauberen roten Faden, der sich durch das Ganze zieht. Daher nehme ich C primaer zum Optimieren performance-kritischer Teile von Programmen, die in anderen Sprachen geschrieben sind. Speicherprobleme habe ich keine; wer keine Lust hat, auf seine Allokationen aufzupassen, kann ja die gc-lib dazulinken, und saubere OOP mit Information Hiding ist tatsaechlich moeglich! Wer sich an das Prinzip haelt, statt Implementierungen nur Interfaces zu vererben (was in "echten" OOP-Sprachen ebenso/erst recht gilt!), hat keine Probleme.

C++:
Eine Sprache, deren Kern nicht in hoechstens 100 Seiten A4 vollstaendig beschrieben werden kann, ist in meinen Augen keine gute Sprache, und sei sie noch so maechtig. Wer Meyers und Sutter gelesen und verstanden hat, weiss, was gemeint ist. Dafuer hat C++ einige Features, die ich in anderen Sprachen schmerzlich vermisse: In erster Linie Const Correctness und das deterministische Ausloesen von Destruktoren. Die Templates sind von der Funktionalitaet her ein Traum, aber was die Lesbarkeit der Compilermeldungen bei Fehlern in Template-Code angeht... wei owei... Was mich am meisten an C++ stoert: Die Fallstricke. Da glaubt man, sich mit der Sprache auszukennen, kauft das naechste Buch von Herb Sutter, und faellt _schon wieder_ so richtig ordentlich auf die Nase. Wer hier kann z.B. mit "Koenig Lookup" was anfangen, ohne zu googlen? Komplexe Sprache == komplexer Compiler. Mir persoenlich geht Einfachheit ueber Leistungsfaehigkeit, daher ist C++ einfach nicht meine Lieblingssprache.

C#:
Auf den ersten Blick verlockend. Auf den zweiten auch. Schnelle Resultate, kein grosser Aufwand, gute Tools. Was mich in erster Linie daran stoert: Kaum hat man sich an WinForms gewoehnt, kommt WPF. ASP.net? Silverlight! Achja, wir bauen jetzt ein paar dynamische Features in die Sprache ein. Hm, wie waere es mit Lambda-Ausdruecken? Achja, ein paar deklarative Features (LINQ!) waeren auch toll. Was flanschen wir als naechstes dran? Was mir an C# fehlt, ist eine klare Linie. Staendig kommt was neues dazu, bevor man die Gelegenheit hatte, den bisherigen Wust durchzuackern. Und die Bibliothek ist ganz klar fuer das schnelle Entwickeln von Software designt, und nicht fuer die spaetere Wartung. Sorry, mir ist die Wartung wichtiger als das Neuentwickeln. Und rein proprietaere Systeme und Specs (der ECMA-Standard geht nur auf die untersten Grundlagen ein!) haben vom reinen Idealismus her sowieso gleich verloren. Dummerweise muss irgendwo das Geld herkommen, mit dem ich das Essen fuer meine Kinder kaufe... *ahem*

Java:
Mein Verhaeltnis zu Java war nicht immer das beste, siehe "gewisse Threads" aus der Vergangenheit Inzwischen sehe ich Java als eine der Sprachen an, mit denen ich neue Projekte noch am ehesten angehen wuerde. Auch wenn die "Sauberkeit" der Sprache in den neueren Versionen gelitten hat und immer mehr syntaktischer Zucker dazukommt, ist es im Kern (!) immer noch eine recht schlanke Sprache ohne allzu viele Ueberraschungen. Design Patterns werden in der Standardbibliothek konstruktiv eingesetzt, und zwar da, wo sie Sinn machen. Was mich am meisten daran stoert: Die immer groesser und speicherhungriger werdenden Implementierungen der VMs, und die Inkonsequenzen in der Bibliothek. Man merkt der Lib an, dass sie mal wesentlich kleiner war, und immer wieder neue Teile dazugekommen sind. Trotzdem fuehlt sie sich -- subjektiv -- wesentlich sauberer an, als die von .NET. Was mich noch nervt: Out of memory. Wie oft habe ich die Exception in letzter Zeit bekommen?! Da versucht man, eine 45-MB-Textdatei zu parsen, und die VM steigt aus. Hallo? 4GB RAM, 4GB Swap, und mein Programm kann keine 45-MB-Datei einlesen?!? OK, mit den Non-Standard-Optionen mehr Heap erlauben. Aber was, wenn mal noch mehr Speicher benoetigt wird? Oder die VM die entsprechende Option nicht anbietet? Was noch nervt, wenn auch nicht so sehr: Ist es jetzt die Methode length() oder getLength() oder size() oder getSize() oder die Eigenschaft .length oder... ?! Bei der STL unter C++ ist es IMMER size(), und gut.

Perl:
Was fuer C++ gilt, wird hier auf die Spitze getrieben. Wie gross ist nochmal die Sprachbeschreibung von Perl? Ach, es gibt gar keine? Der Interpreter selbst ist die Spec? Und an welchen Stellen kann nochmal die Perl Magic einspringen und mir einen Strich durch die Rechnung machen? Danke, nein. Perl ist schoen pragmatisch, recht schnell, und CPAN sucht bei anderen Sprachen seinesgleichen. Fuer kleine einmal-und-dann-wegwerfen-Skripte wunderbar, aber groessere Programme in Perl -- agh.

Python:
Ganz so schlecht finde ich Python gar nicht. Zumindest stilistisch sauberer als Perl. Dass Bloecke per Indentation definiert werden statt per Klammern -- na und. Der Code ist lesbar, und man kommt als Einsteiger extrem schnell zu Resultaten. Was nervt, sind die Bugs in der Lib, die Sturkoepfigkeit, mit der der "pythonic way" ueber alles gesetzt und Verbesserungsvorschlaege kommentarlos als "unpythonic" abgewiesen werden, und die Inkonsequenz Strukturiert/OOP. War es jetzt x.length() oder length(x)? Achja, es hiess len(x). Autsch. Dann haben wir zwar funktionale Elemente, aber keine Tail Recursion Elimination. Weil "unpythonic". Und reduce() wird entfernt, weil das fuer die Programmierer zu kompliziert ist. Bitte?!? Wer _damit_ nicht klar kommt, hat als Programmierer eindeutig den falschen Job!

Tcl:
Eine -- leider -- zu oft und leicht uebersehene Sprache. Tcl besitzt die konzeptionelle Reinheit, die ich in anderen Sprachen vermisse, ohne gleich zu Brainfuck oder Lisp zu verkommen. Ein Tcl-Interpreter, mit dem sich Real-World-Programme schreiben lassen, kann in unter 1000 Zeilen C runtergeschraubt werden. Die Sprache ist extrem dynamisch, und erlaubt die komplette Umstellung der Sprachdefinition selbst vom Quellcode aus. Schon mal die Semantik des if-Befehls um Logging-Funktionen erweitert? Funktionsdefinitionen erweitert, so dass eine Funktion ab einer bestimmten Laenge nicht mehr lokal, sondern automatisch auf einem anderen Rechner definiert und dort ausgefuehrt wird, vollkommen transparent? Die Moeglichkeiten sind endlos. Was stoert mich dann daran? Tcl ist laaaaaaaaangsam. Gut, der Geschwindigkeitsnachteil ist O(1), und die Bibliothek selbst ist schnell, aber trotzdem... Und dass assoziative Arrays zwar Teil der Sprache sind, aber keine First-Class-Typen, ist eklig. OK, dazu braeuchte man eine zusaetzliche Regel im Standard, die Sprache waere nicht mehr _ganz_ so rein, und eine Datenuebergabe per Zugriff-auf-die-Variable-im-uebergeordneten-Stack-Frame-ueber-ihren-dort-lokalen-Namen (!!!!!), was in Tcl-Semantik nicht ganz 100%ig by Name entspricht, ist bei groesseren Datenmengen schneller als by Value, aber es waere einfach schoen. In den neueren Versionen gibt es immerhin die OOP-Version "Dict", aber der inherente Typ waere eigentlich gut genug, wenn...

Mein Fazit:
Unix-Prinzip for teh win! Alle diese Sprachen sind unter BSD, Linux, OS X, sonstigen Posix-Systemen und Windows verfuegbar, wobei ich um Mono eher einen Bogen mache. Teilen wir unser Grossprojekt also in mehrere kleine Einzelprogramme auf, die ueber sauber definierte Schnittstellen kommunizieren. Wenn mir dann ein Tcl-Prototyp nicht mehr zusagt, wird er in C umgesetzt. Oder in Java. Oder was auch immer am besten zum jeweiligen Problem passt -- womit wir wieder bei "The right tool for the job" waeren. DIE Lieblingssprache gibt es fuer mich nicht. Und auf eine einzelne Sprache fuer ein monolithisches Grossprojekt lass ich mich nur noch ein, wenn der Chef das alleinige Sagen hat... *hust*
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
24.04.2009, 12:42 Uhr
Bruder Leif
dances with systems
(Operator)


*gack* Was ein Post...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.

Dieser Post wurde am 24.04.2009 um 12:43 Uhr von Bruder Leif editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
24.04.2009, 15:29 Uhr
mike
Pinguinhüpfer
(Operator)


Boah - da hat sich wer Mühe gemacht - super gerschrieben!!

Ergänzend zu C# noch:
Ab .NET 3.0 hat es Gott sei Dank eine wichtige Wende gegeben (teilweise auch wegen Vista denk ich). WinForms ist ansich uralt und basiert auf User32. MS hat das aus gutem Grund mit WPF ersetzt. WPF hilft enorm beim Entwickeln für GUIs (und wird voll von der Graka HW beschleunigt). Hab jetzt z.B. für die Feuerwehr ein verteiltes Protokoll geschrieben. Macht mit WPF einfach Spaß weil man sich nicht auf die GUI konzentrieren muss. Microsoft hat in jedem Bereich eine Technologie - kann man eine wird man die andere auch schnell können. MS selbst ordnet die Technologien ja so:
HTML - AJAX - Silverlight - XBAP - WPF
Schreibst du jetzt eine SmartClient App für Windows kannst du sie im Regelfall zu 99% auch im Browser laufen lassen (XBAP). Hast du nicht exotischen verwendet auch Silverlight.
LINQ - weiß nicht wie ich vorher ohne dem leben konnte. Liste mit Objekten. Und ich kann auf die SQL ähnliche Statements anwenden. Doch ist es ansich egal was dahinter als Datenquelle ist (Array, XML, Datenbank) - genial. IntelliSense unterstützt es - was braucht man mehr.

Trotzdem glaub ich würde es mehr Sinn machen die Kernsprache C# in den Vergleich mit den anderen Sprachen zu schicken (die erwähnten Lambdas wären ok - Threads, Interfaces, Abstrakte Klassen, Reflection, auch delegates *g*). MS zu verurteilen dass es WCF ins Leben gerufen hat ist imo falsch, dann musst du WebSpehere auch bemangeln

Hoffe es kommen noch viele weitere Kommentare - super Thema!!!!
--
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
24.04.2009, 15:49 Uhr
0xdeadbeef
Gott
(Operator)


Ich empfinde C ganz im Gegenteil als ziemlich umständlich, zumindest, sobald das Programm eine bestimmte Größe annimmt oder Eingabedaten von nicht 100%ig vertrauenswürdigen Stellen verarbeiten muss. Das Abdichten und Debuggen frisst einfach zu viel Zeit.

C++ ist meine Hauptsprache, und das mit gutem Grund. Sicher, C++ ist eine sehr komplexe Sprache und sehr schwer zu erlernen, aber wenn man sie einmal beherrscht - und ich meine richtig beherrscht, nicht bloß ein halbes Jahr mal ein bisschen was damit zusammengehackt hat (wenn man den boost.spirit-Code ankucken kann und die verwendeten Techniken versteht) - ist diese strenge Mätresse die effizienteste Sprache, die mir je über den Weg gekommen ist. Zum einen hat man zur Compilezeit eine Turing-Maschine, was mitunter ausgesprochen praktisch ist, viel wichtiger aber ist, dass die Sprache weitestgehend statisch aufgebaut ist, so dass eine ganze Klasse dreckiger Hacks, die in anderen Sprachen zu Features erhoben werden, nahezu unmöglich werden. Wo in C# und Python ganze Typen zur Laufzeit zusammengeschustert werden und man sich nie sicher sein kann, ob die Methode, die man aufrufen will, zur Laufzeit auch tatsächlich vorhanden ist (von Tippfehlern ganz zu schweigen), implementieren gute C++-Bibliotheken wie boost.phoenix noch Lambda-Ausdrücke und Funktionsbindungen statisch, so dass der Compiler über eventuelle Fehler beschweren kann. Sogar typsichere Variants haben die Boost-Leute hingekriegt! Viele Bugs erhalten so niemals die Chance, ausgeliefert zu werden.

Oh, und der Begriff Koenig-Lookup war mir nicht bekannt, nein, aber hättest du "argument dependent name lookup" gesagt, hätte ich gewusst, wovon du sprichst.

Perl dagegen würde ich schon deshalb nicht für größere Projekte einsetzen, weil es interpretiert ist - sowas ist immer aufwändig zu debuggen - aber für kleinere Dinge, die mit Text zu tun haben, ist perl perfekt. Du willst eine Perl-Sprachbeschreibung? http://perldoc.perl.org/ Natürlich muss man sich zu regulären Ausdrücken verhalten wie ein Fisch zum Wasser, sonst bringt das ganze nicht viel, aber ich denke nicht, dass es zur programmatischen Behandlung von Text eine bessere Sprache gibt.

Python ist eine Sprache, die ich nicht einsetze. Punkt. Für rein garnichts. Ich kann mir nicht erklären, wie irgendjemand diese Monstrosität für ernsthafte Programmierung auch nur erwägen könnte. Für die ersten zwei Wochen Skriptkidderei möglicherweise, wenn man es noch nicht besser weiß, aber sobald man nur ein bisschen Erfahrung hat, muss einem dieser ganze dynamische Firlefanz doch gewaltig auf die Eier gehen. Das Ranbappen von Methoden in C# ist ja schon schlimm genug, aber in Python kannste dich außerdem nicht mal mehr darauf verlassen, dass der Code, selbst wenn er denn zur Laufzeit da ist, noch macht, was er soll, weil dir irgendjemand anders in der Zwischenzeit lustig alle Methoden umdefiniert haben kann. Entschuldigung, aber wer kann denn mit so einem Scheiß arbeiten? Es war ein trauriger Tag, an dem Programmierer auf das Buzzwort "dynamisch" reingefallen sind; sie hätten es besser wissen müssen.

Was Java angeht - meh. Java ist nicht überragend, aber in Ordnung. Es gibt ein paar sprachliche Unreinheiten, wie etwa die syntaktische Spezialbehandlung für java.lang.String (da hätte ich mir echte Operatorüberladung gewünscht), aber man kann insgesamt gut damit arbeiten. Und nachdem ich oben so gegen dynamische Programmiersprachen gewettert habe - ja, Java hat eine dynamische Seite, aber sie ist gut ausbalanciert und meistens versteckt. NoSuchMethodError hat in Java etwa den Status eines Linkerfehlers in nativem Code, das Typsystem ist ausreichend verlässlich und Reflection ist zwar vorhanden, aber nicht der Normalfall. Java schafft es hier auf rückblickend sehr beeindruckende Weise, dynamische Features bereitzustellen, ohne die Vorteile einer grundsätzlich statischen Sprache übermäßig anzutasten.

Mit TCL kenne ich mich nicht gut genug aus, um dazu Kommentare abgeben zu können.

Ansonsten benutze ich gelegentlich noch LISP (meistens eLISP), was auf seine Weise eine sehr interessante Sprache ist - aber so radikal verschieden von den üblichen, imperativen Sprachen, dass ein Vergleich schwer fällt. Insgesamt wohl die Sprache für funktionale Programmierung (als möglicher Rivale fällt mir grad nur Haskell ein), wobei das ganze Feld keins ist, das bei meiner täglichen Arbeit eine große Rolle spielt. Wenn ihr mal eine algebraische Umgebung entwickeln wollt...

Oh, und natürlich Shellskripte - in der Unix-Shell kann man ja wirklich programmieren. Wenn die Aufgabe zu simpel ist, um Perl auszupacken, schreibe ich meistens ein kleines Shell-Skript. Natürlich handelt es sich dabei um wirklichen Kleinkram - in etwa "Ich hab hier ein Verzeichnis voll Dateien, lauf da durch, schreib den Kram in die Datenbank und log mir die Ausgabe nach log/foo-$datum.log", aber häufig ist ja genau das das, was gebraucht wird. Ich schaudere bei der Idee, größere Dinge in Shell zu schreiben, nichtsdestoweniger ist es sehr praktisch, sich mit der Shell auszukennen.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ Allgemeines (OffTopic) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: