Diskurs: Programmiersprachen |
| 23.11.2016, 20:19 | Auf diesen Beitrag antworten » | |||||
| InformaTiger | Diskurs: Programmiersprachen Liebes Board, bin jetzt schon länger in der Softwareentwicklung (=Ausbildung) unterwegs und habe mittlerweile mehrere Programmiersprachen erlernt. Darunter sind C#, Java und Php. Weiteres habe ich auch kurz mal in Python, C++ und derzeit in Vala und C gestöbert. Wenn man so über das Programmierdasein nachdenkt, kommt man bald zu Frage: Was ist nun eigentlich die "beste" Programmiersprache? Ich habe meinen Favoriten gefunden: Vala. Wollte euch fragen, wer alles Vala kennt und damit arbeitet? Und was sind eure Lieblingsprogrammiersprachen? 
Mit freundlichen Grüßen informaTiger |
|||||
|
|
||||||
| 23.11.2016, 21:07 | Auf diesen Beitrag antworten » | |||||
| eulerscheZahl | Hallo. Ich muss gestehen, Vala kenne ich nicht. Ich kann mich dunkel erinnern, dass du es hier schon einmal erwähnt hast, abseits davon bin ich dem noch nicht begegnet. Meine Lieblingssprache ist C#. Es nimmt eine Menge Arbeit ab, wo man Dinge in C/C++ noch von Hand erledigen muss. Und meiner Meinung nach wurde das Konzept von Anfang an besser durchdacht als bei Java. Java ist auch in Ordnung, aber es gibt einige Kleinigkeiten, die mich stören. z.B. ist in Java ein int kein Objekt. Deshalb kann ich keine List<int> erstellen, sondern nur List<Integer>. Dazu kommen mit Linq schöne Abkürzungen, man kann in einer Zeile schreiben, wofür man sonst eine Schleife und Hilfsvariablen bräuchte. Auch sage mag ich. Das ist im Wesentlichen Python, hat aber eine umfangreiche Mathematikbibliothek: Gleichungen lösen, Funktionen differenzieren und integrieren, umendliche Reihen ausrechnen, .... An Mathematica kommt es zwar nicht ganz ran, ist dafür aber kostenlos. Was ich mir schon lange mal anschauen wollte, aber irgendwie nie dazu kam: Haskell. Letztendlich bleibt die Sprache für mich aber ein Werkzeug. Was mich eigentlich interessiert ist das Problem, das ich damit lösen will. |
|||||
| 23.11.2016, 21:22 | Auf diesen Beitrag antworten » | |||||
| InformaTiger | Hallo, ich muss mit eingestehen, dein letzter Satz bringt es auf den Punkt. Nichtsdestotrotz ist die Programmiersprache ein wichtiges Werkzeug - je größer die Standardbibliothek, die sie mitbringt, desto geringer der Aufwand bestimmte Probleme zu lösen. Wie du bereits erwähnt hast, bringt C# diese mit und hat eine Menge Features, die einem das Leben leicht machen. Ein konkretes Beispiel wäre der UdpClient; während ich bei Java noch mit den Sockets herumhantieren muss, ist in C# bereits der fertige Client dabei und ich kann ihn nur noch an eine Adresse binden. Mein Problem mit C# liegt allerdings in der Verfügbarkeit auf anderen Plattformen. Es gibt Projekte wie Mono, aber nichts desto trotz braucht C# eine Runtime zum Laufen. Aus diesem Grund war ich auch mit Java - meiner bisherigen Lieblingssprache - nicht zufrieden. Die Lösung dieser Probleme ist Vala. Der Vala-Kompiler kompiliert den Vala-Quelltext direkt auf C als Intermediate Code und lässt den Rest vom C-Kompiler erledigen. Die Sprache ist von der Syntax her sehr stark an C# und damit auch an Java angelehnt weshalb der Umstieg einfach ist. Aber auch hier gibt es Lücken und Tücken: 1. es gibt keine IDE mit der man Vala (vernünftig) entwickeln kann. 2. Grafische Oberflächen sind an das GTK+ Toolkit gebunden, da Vala auf C kompiliert. Mit freundlichen Grüßen informaTiger |
|||||
| 23.11.2016, 22:04 | Auf diesen Beitrag antworten » | |||||
| eulerscheZahl | Ich verwende C# mit Mono. An einigen Stellen merkt man leider noch, dass es eben nicht .net ist - insbesondere wenn es an Nutzeroberflächen geht. Aber für die Console taugt es allemal. Zu Vala habe ich mir vorhin den Wikipedia Artikel durchgelesen. Dafür dass es schon 10 Jahre alt ist, ist es noch recht unbekannt. Das ist für mich ein weiteres Kriterium: wenn ich nicht weiter weiß, kommt meine Frage zu google. Von da aus geht es dann meist zu stackoverflow und dort steht die Antwort. Bibliotheken sollten ja kein Problem sein, wenn man sich da bei C bedienen kann. Wenn es um Hilfe zu sprachlichen Feinheiten geht, könnte es schon schwerer werden (Vermutung, wie gesagt habe ich mich damit noch nicht beschäftigt). |
|||||
| Anzeige | ||||||
|
|
||||||
| 23.11.2016, 22:17 | Auf diesen Beitrag antworten » | |||||
| InformaTiger | Ja, dass es unbekannt ist kann man wohl kaum bestreiten. Ursprünglich kommt Vala ja aus der GNOME Welt, weswegen auch nicht so viele Projekte damit umgesetzt werden. Der Linux eigene Bildmanager "Shotwell", wäre aber ein Beispiel. Ich bin auch relativ neu in der Vala-Welt und bisher ist die einzige vernünftige Quelle zu Vala-Fragen die Dokumentation oder die Vala-Tutorials. Was ich da wiederum cool finde ist, dass sich die Entwickler von Vala die Mühe angetan haben eigene Beiträge für Java und C# Programmierer zu schreiben, wo denen erklärt wird wie sich Vala von der "gewohnten" Programmiersprache unterscheidet. In vielen Fällen wird man aber mit Problemen leider alleine gelassen, da es eben nicht viele Programmierer gibt, die sich mit der Sprache beschäftigen |
|||||
| 24.11.2016, 07:19 | Auf diesen Beitrag antworten » | |||||
| eulerscheZahl | Ui, das ist ja auch schon wieder veraltet:
async hat C# mittlerweile auch. Das Argument checking sieht recht angenehm aus. |
|||||
| 24.11.2016, 11:04 | Auf diesen Beitrag antworten » | |||||
| InformaTiger | In der Tat gibt es Programmierkonstrukte die in Vala nicht so angenehm sind. Ich finde es beispielhaft schwer verschiedene (sinnvolle) Namen für überladene Konstruktoren und Methoden zu finden - dafür gibt es aber ein Konzept Parameter (und Rückgabewerte) zu überprüfen ohne händisch Exceptions zu werfen, wie eben requires oder ensures. Was wiederum etwas nachteilig ist sind die Exceptions in Vala. Es gibt zwar eine Basisklasse Error, welche aber sich im Konstruktor nicht mit einer message zufrieden gibt. Der Regelfall ist, dass man sich eine Errordomain mit verschiedenen Errorcodes definiert und diese dann mit einer message versieht. Ist zwar etwas umständlich für einzelne Fälle, bringt aber den Vorteil, dass die message an sich spezifischere Details enthalten kann, da bereits der Errorcode den eigentlichen Fehler enthält. Und ein weiterer kleiner Nachteil ist, dass Enumeratoren integerbasiert sind und deshalb der Name des Enumerators nur über eine selbstdefinierte Methode herausgefunden werden kann. Täusche ich mich, oder ist die Syntax wirklich zum verwechseln ähnlich mit C#? Ich weiß zwar, dass die Syntax an C# angelehnt ist, aber mir scheint die mehr kopiert als angelehnt zu sein... 
Edit: Und da wir vorhin schon bei Mono C# waren: wie sieht das eigentlich mit der Performance aus? Und kommt die Mono-Bibliothek an die .NET Variante vom Funktionsumfang ran? |
|||||
| 24.11.2016, 11:56 | Auf diesen Beitrag antworten » | |||||
| eulerscheZahl | Ja, es sieht sehr ähnlich aus. Ich kann es zumindest ohne Probleme lesen. Mono hat eine ganz vernüftige Performance. Mit .net kann man zwar noch ein paar Prozent rauskitzeln, aber mehr auch nicht. Bei manchen Dingen ist .net sogar langsamer, insgesamt würde ich es aber vorne sehen. Wenn man sich auf Konsolenanwendungen beschränkt, habe ich noch nicht festgestellt, dass etwas fehlt. Bei System.Drawing wollte ich mal Pfeilspitzen zeichnen, habe aber nur eckige Enden bekommen. Entweder bin ich unfähig oder das ist einfach nicht implementiert. Bei Windows Forms merkt man an manchen Stellen, dass etwas fehlt (z.B. DataVisualization.Charting wirft noch NotImplementedExceptions). Insgesamt ist es aber möglich, eine Nutzeroberfläche zu erstellen (auf einen Designer muss man bei MonoDevelop aber verzichten, der kann nur GTK, keine WinForms). WPF wird überhaupt nicht unterstützt. Weite Teile von .net sind inzwischen Open Source (MIT), kann sein, dass sich da noch was tut. WPF denke ich aber eher nicht, das ist zu tief in Windows verwurzelt. |
|||||
| 24.11.2016, 12:05 | Auf diesen Beitrag antworten » | |||||
| InformaTiger | Meine Erfahrung mit Mono auf Linux war seiner Zeit nicht die beste. Vielleicht lag dass auch nur am Rechner, aber jedes mit Mono kompiliertes Programm benötigte eine Sekunde um die Assemblys zu laden. Kann aber wie gesagt nur von der Maschine abhängen. 
Die WinForms sind aber auf Nicht-Windows Platformen kaum zu gebrauchen? Oder hab ich das falsch im Kopf? Wenn ich mich recht erinnere bekommt man da eine grässliche Win98 Anwendung, wenn man das beispielhaft auf Linux oder Mac ausführt. Ich hab aber auch einmal die Gtk-Anbindung getestet, war aber leider auch davon nicht so begeistert. Meiner Meinung nach ist Mono in Sachen GUI noch etwas zu wenig ausgereift - Konsolenanwendungen können aber durchaus zuverlässig programmiert werden. Hast du GTK schon mal ausprobiert? Ist bei mir wie gesagt eine Weile her und kann inzwischen auch schon besser integriert sein. Wie sieht es eigentlich mit Ressourcenverbrauch aus? Ich weiß nur, dass Java aufgrund der JVM auch bei einfachen Programmen wie Hello World schon 30 MB RAM frisst 
Edit: Und noch etwas: stimmt es dass GTK+ für ein normales Fenster ohne Inhalt bereits 3 Threads laufen hat? Ich glaub ich hab das irgendwo einmal gelesen. |
|||||
| 24.11.2016, 13:17 | Auf diesen Beitrag antworten » | |||||
| eulerscheZahl | Mit graphischen Oberflächen unter Linux kenne ich mich nicht gut aus. Wenn ich unter Linux arbeite, dann privat. Nur für mich brauche ich keine Oberfläche, da reicht eine Konsolenanwendung. In der Arbeit habe ich ein WinForms Projekt "geerbt", aber unter Windows. Was die Optik angeht, habe ich keine hohen Ansprüche. Ich kann nicht einmal mehr sagen, wie die Oberfläche bei Mono aussieht. Wenn man .net WinForms Programme ausführt, kann es leider zu abstürzen kommen, hängt vom Programm und den verwendeten Bibliotheksfunktionen ab. |
|||||
| 24.11.2016, 13:22 | Auf diesen Beitrag antworten » | |||||
| InformaTiger | Da muss ich dir zustimmen! Vielleicht ist es ja ein Programmiererprivileg, dass wir uns mit minimalen Interfaces zufriedengeben. Trotzdem finde ich, dass nicht alle Aufgaben in der Konsole lösbar sind - vorallem was Threading angeht finde ich, dass eine Nutzeroberfläche deutlich besser ist. |
|||||
|
|