Ratschläge für die Wahl der Programmiersprache

[The Ripper]

Prinzipiell richtig, allerdings zielt .NET-Core eher auf den Server-Bereich ab.

Hab ich ja noch nie gehört davon. Quelle?

Bei Java muss man immernoch viel boilerplate code schreiben nur um dem Paradigma genüge zu tun ohne dass dieser Code in irgendeinerweise der Problemlösung dienlich ist. Das versucht man teilweise durch große und aufwendige Frameworks zu kaschieren.

Beispiele? Von welchen Paradigmen und Frameworks sprichst du? und von welchen Sprachen?

 

[andy_m4]

... Smalltalk .... Scheme ....

​Noch nie von einem der beiden gehört.

Gerade so zum Ende der 80er Jahre hin war Smalltalk durchaus populär (auch Firmen wie IBM steckten viel Geld in Smalltalk). Das Problem war aber, dass Smalltalk für damalige Verhältnisse sehr hardwarehungrig war. Ansonsten dürfte es als Vorbild für sehr viele objektorientierte Sprachen gelten. Inkl. Python und Java.

Scheme gehört zur Lisp-Familie (neben Fortran eine der ältesten Programmiersprachen überhaupt). Von den Lisps gibts heute im Wesentlichen 2 Richtungen. Common Lisp, was aus den Standardisierungsbemühungen verschiedener Lisp-Hersteller hervorgegangen ist und die eher minimalistisch gehaltenenen Scheme-Dialekte. Wobei es da auch Standards gibt (die aktuellste Version ist R7RS -> http://www.scheme-reports.org/ ).

Sind Beides keine Mainstream-Sprachen, weshalb sie kaum jemand kennt. Allerdings lohnt es sich sie zu kennen, weil man davon eine Menge lernen kann.

Ich selbst verwende seit einigen Jahren vorzugsweise Racket, ein Scheme-Dialekt. Oder besser gesagt: Ein System zur Entwicklung von Sprachen.



​

​Hat man nicht gerade am Anfang Vorlesungen, die sich mit Programmierung (prozedural+objektorientiert) beschäftigen und später aufbauend häufig Projekte, die u.a. erfordern Code zu schreiben?

Eher weniger. Das meiste ist vor allem (mathelastige) Theorie. Außerdem gibt es einen Technikteil, wo mit man sich auf primitiver Ebene damit beschäftigt wie elektrische Signale verarbeitet werden bishin zum Entwurf einfacher CPUs. Ein Programmierteil gibt es auch. Da lernt man aber weniger ne Programmiersprache, sondern da werden einem anhand einer Programmiersprache Konzepte vermittelt (Variablen, Konstanten, Verzweifgungen, Schleifen) und es geht um Algorithmen (Hashtable, binärer Baum, Graphen etc.).

Und mal ehrlich. Um Sprachen wie Python oder Java zu lernen, braucht man auch kein Studium. Das macht man so nebenbei.

Vermutlich wird man aber heutzutage mehr an die Hand genommen. Inzwischen sichte ich an Unis sogar Windows und Word-Kurse. Zu meiner Zeit standen in den Rechnerräumen Sun-Workstations und so ein Kram. Kannte man natürlich bis dahin nicht. Da hatte man zuhause vielleicht ne DOS-Büchse oder nen Amiga etc. Und das hieß es ransetzen und loslegen. Vorher mal irgendwie nen wenigstens UNIX-Crashkurs machen? Pustekuchen!
Hat mich damals aber auch nicht wirklich gestört. Im Gegenteil. Ich fands cool mich da reinzufuchsen und ging auch relativ schnell.

Ähnlich sah es bei Programmiersprachen aus. Du musst irgendein Controller programmieren? Da haste nen Compiler (zwar buggy, aber geht irgendwie) und dort ein recht unvollständiges, sehr technisch geschriebenes Handbuch und nu mach mal.

War aber auch völlig ok. Denn wer an solchen Dingen schon gescheitert wäre, der hätte das Informatikstudium eh nicht überlebt.

Ergänzung (26. Juli 2017)

@andy_m4: Schöner Beitrag.

So ist das doch eigentlich immer unter Entwicklern. Das Problem ist dabei meist, dass man sich mit der Sprache die man selbst am häufigsten nutzt ein Stück weit identifiziert und gleichzeitig andere Sprachen (durch weniger intensivere Verwendung) häufig schlechterer beurteilen kann. Zudem kenne ich Kollegen die sich so auf eine Sprache festgefahren haben, dass Sie andere Konzepte gerne voreilig als schlecht abstempeln.

Damit triffst Du den Nagel so ziemlich auf den Kopf. Deswegen ist es bei solchen Diskussionen immer ganz gut zu wissen, wieviel Sprachen der Gegenüber kennt oder was seine Lieblingssprache ist, um das Gesagte auch entsprechend einordnen zu können.

Abgesehen davon, dass man sich bemühen sollte, sich eben bei Empfehlungen nicht davon leiten zu lassen.
Ich selbst greife ja sehr gern zu Racket, würde aber zum Beispiel wie hier das nicht als Empfehlung aussprechen. Die Sprache ist gut, keine Frage.

Aber für die Problemstellungen gibt es halt bessere Sachen. Und gerade zu Python und so gibts halt auch unheimlich viel Tools, Bibliotheken, Dokumentationen, dass es sich einfach anbietet. Selbst wenn es sicher Punkte gibt, die ich an Python nicht so gut finde. Aber letztlich geht es ja ohnehin darum nicht das Optimum zu finden, sondern ein möglichst guten Kompromiss.

Sehe hier häufig die Tendenz, dass Entwickler aus der Riege der älteren, prozeduraleren Sprachen, die moderneren, höheren Programmiersprachen (ähnlich wie im Eingangspost) gerne als "oberflächlich" abstufen.

Ja. Und ein stückweit haben sie ja damit auch nicht Unrecht.

Man muss aber auch anerkennen, dass mit mit höherleveligen Sprachen sein Ziel in kürzerer Zeit erreicht. Klar, der C-Hacker wird Dir ne performante Lösung hinstellen. Aber Performance ist eben nicht alles. Oft reicht ja "schnell genug". Und wenn ich dafür nur ein Bruchteil an Code tippen muss und auch viele Fehlerquellen vermeide (weil z.B. ein Garbage Collector die Speicherverwaltung übernimmt), dann kann das durchaus die geeignetere Vorgehensweise sein.

Kann nur zustimmen. Sprachen wie zB Java bringen viel mit, um in kürzester Zeit große aber dennoch flexible und erweiterbare Software zu schreiben.

Naja. Java verbinde ich jetzt nicht immer mit "kürzester Zeit" oder gar "knappen Code". Java ist eigentlich ziemlich beschränkt was die Ausdrucksmöglichkeiten angeht. Was aber wiederum eine Stärke sein kann, weil der Java-Code eines anderen Programmierers eben gut lesbar ist. Es gibt halt nicht hunderte von Wegen ein bestimmtes Problem zu lösen. Deshalb ist es relativ schnell zu "sehen", was der Codeautor an der und der Stelle machen wollte.
Andere Sachen in Java sind wiederum anstrengend. Man denke nur an die Getter und Setter-Geschichte (wobei das auch schon besser geworden ist; in C# z.B.hat man das aber deutlich besser via Properties gelöst) oder solche Sachen wie

MyOwnCleverClass o = new MyOwnCleverClass();

wo man in C# abkürzen kann mit:

var o = new MyOwnCleverClass();

und ähnliche Fälle, wo es einfach nervig ist, eigentlich unnötig viel Code zu schreiben (biolerplate-Code)

In der Wirtschaft ist meist die Business-Logik entscheidend. Da wird dir kein Chef eine Gehaltserhöhung aussprechen, weil du ein mehrdimensionales Array besonders elegant mittels Pointern durchlaufen hast (flapsig ausgedrückt).

Eben.

Es gibt hier aber natürlich auch verschiedene Anforderungsbereiche und auch Typen von Entwicklern. Ich persönlich behaupte ein Verständnis für die Logiken im Hintergrund (Speicherallozierung als Beispiel) zu haben, möchte mich darum aber gar nicht jedes mal kümmern müssen.

Exakt.

Es braucht natürlich solche und solche.

Ja. Zum Beispiel muss irgendwann mal jemand so ne VM geschrieben haben. Und das geschieht halt häufig in Sprachen wie C bzw. C++.
Aber wie Du schon sagst: Man sollte sich da auch ein bissl am Bedarf orientieren, statt irgendeine Lösung als einzig Wahre hinzustellen.

Ich schaue aktuell recht hoffnungsvoll auf die Zukunft von Kotlin (nativ). Kotlin ist in jedem Fall eine schöne Sprache und wenn sich diese zukünftig auch nativ kompilieren lässt dürfte dass einige Vorzüge vereinen.

Ja. Ich muss sagen, ich verfolge zwar den Werdegang von Kotlin verfolgt, aber mich noch nicht drüber hergemacht. Liegt wohl auch daran, dass ich mit dem Java-Ökosystem derzeit nicht viel in Berührung komme.
Scheint mir aber eine Art Scala-Light zu sein.

Ergänzung (26. Juli 2017)

Prinzipiell richtig, allerdings zielt .NET-Core eher auf den Server-Bereich ab. Für Desktop-Anwendungen fehlt der größte Teil der GUI-Bibliotheken.

Ja. Noch. Aber die Ansage war schon recht klar, dass eben .NET Core langfristig das klassische .NET ablöst aber eben zum jetzigen Zeitpunkt noch nicht alles aus .NET portiert ist.

Mit .NET entwickelte Desktop-Anwendungen lassen sich daher praktisch nur auf Windows ausführen.

Das ist richtig, dass Win.Forms und WPF derzeit nur im klassischen .NET zur Verfügung steht. Es gibt aber Bemühungen die ebenfalls auf .NET Core zu portieren. Vermutlich wird es darauf hinauslaufen, das es Portierungshilfen gibt aber man ein Neues GUI-Toolkit bekommt, da an ein Cross-Platform-Toolkit eben andere Anforderungen gestellt werden. Zum Beispiel, was man mit Elementen macht, die auf anderen Systemen nicht existieren.

Ansonsten hat man heute ja schon die Möglichkeit z.B. mit Eto.Forms Cross-Platform-Anwendungen aufzuziehen.

Ansonsten hast Du natürlich Recht. Mir gings auch vorrangig um den Aspekt, dass C# bzw. .NET win-only ist und das ist selbst abseits von Mono eben nicht mehr so.

Die Verbreitung von C# oder .NET auf anderen Plattformen als Windows ist nach wie vor sehr gering. MS versucht das im Moment im Server- bzw. Business-Bereich zu ändern, aber Java hat sich da eigentlich schon festgesetzt.

Gut, Microsoft hat nicht so den Stand wie Java. Allerdings gibt es durchaus dort auch .NET-Sachen. Das Problem ist, dass selbst Firmen die .NET einsetzen nicht mehr unbedingt auf Windows angewiesen sein wollen. Daher ist es nur folgerichtig da endlich mal was auf die Beine zu stellen.
Ansonsten ist das Problem mit Java eben, dass sich da kaum etwas tut und die Entwicklung nur sehr gemächlich abläuft, was gleichzeitig auch ein Java-Vorteil ist, aber man eben nicht überall haben möchte. Daher auch der Zulauf zu JVM-Sprachen a-la Groovy, Scala, Clojure und jetzt aktuell Kotlin.

Und ansonsten weißt ja C# durchaus eine gewisse Nähe zu Java auf, so dass auch ähnliche Zielgruppen angesprochen werden. Die, die in diesem Umfeld Projekte aufziehen kann es nur Recht sein da eine gewisse Auswahl zu haben und eben nicht nur eine Technologie verfügbar zu haben.

 

[kuddlmuddl]

Nimm die OOP Sprache die ihr auch im Studium benutzt. Häufig ist es Java an Unis.

 

[Limit]

Hab ich ja noch nie gehört davon. Quelle?

Das .NET Core keine GUI Bibliotheken enthält kann man als Hinweis verstehen, aber noch deutlich wird es, wenn man sich den Namen anschaut unter dem .NET Core entwickelt wurde, nämlich "Cloud-optimized .NET Framework".

Beispiele? Von welchen Paradigmen und Frameworks sprichst du? und von welchen Sprachen?

Das fängt schon damit an, dass man für alles Klassen oder Interfaces braucht. Selbst für ein Hello World Programm muss man eine Klasse definieren. Will man Objekte vergleichen müssen alle ein Interface implementieren. Hat eine Funktion ein Tupel als Rückgabewert muss man auch dafür eine extra Klasse schreiben. Kurz gesagt man braucht einfach mehr Code als bei manch anderer Sprache um das gleiche zu erreichen.

Python

print("Hello World\n")

for line in open("liesmich.txt"):
    print(line)

Java

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World\n");

        String line = null;
        try {
            BufferedReader br = new BufferedReader("liesmich.txt");
            while ((line = br.readline()) != null) {
                System.out.println(line);
            }
        } catch(Exception e) {
            e.printStackTrace();
        }
    }
}

Ein einfaches Beispiel und schon hat die Java-Version gleich das vierfache an LOC. Bei kompexeren Problemen sind die Unterschiede zwar nicht mehr so groß, aber bei einem Projekt, dass ich von Java nach Python portiert habe, ergab das trotzdem noch gut 40% weniger LOC und das obwohl die Python-Version noch zusätzliche neue Features erhalten hat.

Ja. Noch. Aber die Ansage war schon recht klar, dass eben .NET Core langfristig das klassische .NET ablöst aber eben zum jetzigen Zeitpunkt noch nicht alles aus .NET portiert ist.

Gut möglich, dass man die GUI-Libs nachreicht, aber mMn hat das für MS keine sonderlich hohe Priorität, denn bei den Clients hat man mit Windows immer noch fast ein Monopol. Im Cloud-/Server-Bereich hingegen nicht, so dass man etwas tun musste um Java und anderen Sprachen/Frameworks das Feld nicht kampflos zu überlassen. Das wird man aber noch sehen.

Ansonsten hast Du natürlich Recht. Mir gings auch vorrangig um den Aspekt, dass C# bzw. .NET win-only ist und das ist selbst abseits von Mono eben nicht mehr so.

Das ist schon richtig. Man kann durchaus C# auch auf anderen Plattformen verwenden. In der Praxis ist die Verbreitung außerhalb von Windows aber nach wie vor gering. Im Business-Bereich mag es mehr geben, bei normalen Desktop-Anwendungen sind C# Anwendungen für Nicht-Windows-Systeme aber eher rar.

 

[crvn075]

@Limit

Ich stimme dir generell zu, dass Java kein Effizienzwunder ist, was LOCs angeht. Deine Beispiele sind aber nicht besonders toll gewählt.

Will man Objekte vergleichen müssen alle ein Interface implementieren.

Gegenfrage, was musst du in Python machen, um Objekte eigener Klassen zu vergleichen? Stimmt, Methoden implementieren.

Ein einfaches Beispiel und schon hat die Java-Version gleich das vierfache an LOC.

Warum hast du bei Python das Error-Handling weggelassen, bei Java jedoch nicht?

Warum verwendest du in Java mit dem BufferedReader die umständlichste Methode von allen? Geht mit Scanner genau so kurz wie in Python, ebenso mit Streams in Java 8.


Das mit den Tupeln ist tatsächlich etwas schade, schließlich sind Tupel in vielen anderen JVM-Sprachen out of the box dabei.

 

[BlooDFreeZe]

Ich stimme dir generell zu, dasss Java kein Effizienzwunder ist, was LOCs angeht. Deine Beispiele sind aber nicht besonders toll gewählt.

This. Ich weiß nicht genau wie viel besser es noch in Java geht, aber in C# geht es bspw. auch in essentiell vier Zeilen:

class Program {
    static void Main(string[] args) {
        System.Console.WriteLine("Hello world");

        foreach (var line in System.IO.File.ReadAllLines("liesmich.txt"))
            System.Console.WriteLine(line);
    }
}

Tuples kann C# übrigens auch.

 

[andy_m4]

Selbst für ein Hello World Programm muss man eine Klasse definieren.

Gut, dass ist nervig. Allerdings gibt es schon länger die sogenannte Beanshell, mit der sozusagen Scripting-Language-Features in der JVM verfügbar sind bzw. jetzt den Nachfolger die JShell.
Da kannst Du Dein Hello-World ähnlich knapp wie unter Python und Co formulieren.

Will man Objekte vergleichen müssen alle ein Interface implementieren.

Exakt. Allerdings sind Interfaces gleichzeitig vor allem Typinformationen. Der Schreibaufwand ist höher, allerdings kannst Du damit schon zur Compilezeit (oder bei entsprechender IDE "beim tippen") feststellen, ob zwei Objekte überhaupt vergleichbar sind.
In Python fliegt Dir das erst zur Laufzeit um die Ohren. Oder noch schlimmer, man hat implizit ne generische Vergleichsoperation von einer Superklasse geerbt, die dann zwar erstmal funktioniert, aber eben falsche Ergebnisse liefert, so das das Problem nicht offensichtlich ist.

Hat eine Funktion ein Tupel als Rückgabewert muss man auch dafür eine extra Klasse schreiben.

Wobei man das aber auch nicht unbedingt häufig hat.

Es stimmt, Java ist nervig. Aber Python ist auch nicht perfekt. Die fehlende statische Typisierung ist schon oft ärgerlich. Klar kann man alles mit Unit-Tests abdecken, allerdings lässt sich dann kaum noch argumentieren, dass man man mit Python weniger Code schreiben muss, wenn die Unit-Tests umso länger ausfallen (was bleibt, ist dass dann der Produktivcode knapper und klarer formuliert ist).

Das Angenehme an Racket ist hier, dass es Gradual-Typing bietet, so dass ich sowohl mit statischer Typisierung als auch Ohne arbeiten kann und beides sich sogar mischen oder vorhandene dynamisch-typisierte Sourcen im nach hinein mit Typinformation versehen lässt.

Außerdem hatte Python noch ein Problem. Nämlich der ganze Ärger um den Wechsel von Python2 nach Python3. Javas Stärke ist ja hier gerade die Kontinuität.
Klar haben dann Sprachen wie Python es einfacher zwischendurch mal irgendwelche obskuren Konstrukte wegzuwerfen, wenn Kompatibilität keine Rolle spielt.

Dann ist in Python zwar (fast) alles ein Objekt (im Gegensatz zu Java, wo es z.B. die primitiven Typen gibt *urgs*).
Aber dann schwer nachvollziehbare Entscheidungen bei Funktionen bzw. Methoden. Warum ist die Längenbestimmung (len(str)) ne funktion und keine Methode? WTF?

Was Python als unangenehme Eigenschaft mit Java teilt ist die Unterscheidung zwischen Statements und Expressions.

Was mich an Python am meisten genervt hat sind die semantischen Whitespaces. Gerade in der Anfangszeit kommt es ja mal vor, dass man Code aus anderen Quellen (Internet) übernimmt, kurz anpasst und dann laufen lässt. Und dann hat man eben schöne Laufzeitfehler, weil irgendwo ein Tab dazwischen ist und Ähnliches.
Kann man sich mit arrangieren. Wird wohl deshalb als so nervig empfunden, weils so gut in die Kategorie "unnötig" passt.

So hat eben jede Programmiersprache seine Nachteile. Letztlich muss man entscheiden, mit welchen man (besonders in Hinblick auf den Anwendungsbereich) am ehsten Leben kann.

Gut möglich, dass man die GUI-Libs nachreicht, aber mMn hat das für MS keine sonderlich hohe Priorität, denn bei den Clients hat man mit Windows immer noch fast ein Monopol. Im Cloud-/Server-Bereich hingegen nicht, so dass man etwas tun musste um Java und anderen Sprachen/Frameworks das Feld nicht kampflos zu überlassen.

Cloud heißt aber nicht automatisch, dass man weniger GUI macht. Cloud heißt ja erst mal nur, dass das Programm nicht nur auf den Client läuft, sondern auch auf dem Server. GUI brauchst Du weiterhin. Nur eben dann oft in Form von HTML/CSS und Javascript.

Aber selbst bei serverless-software gibt es durchaus einen gewissen Trend HTML/CSS/Javascript (sprich Browser) als GUI-Engine zu nehmen. Man denke nur an den Kram rund um Electron und Co.
Kein Wunder, dass dann klassisch-nativ-GUI erstmal hinten angestellt wird. Das heißt aber dann nicht automatisch, dass GUI keine Rolle spielt.

Das ist schon richtig. Man kann durchaus C# auch auf anderen Plattformen verwenden. In der Praxis ist die Verbreitung außerhalb von Windows aber nach wie vor gering. Im Business-Bereich mag es mehr geben, bei normalen Desktop-Anwendungen sind C# Anwendungen für Nicht-Windows-Systeme aber eher rar.

Gerade Mono ist ja das Paradebeispiel für C#-Anwendungen auf dem Desktop (eben via GTK+).
Der im Linux-Umfeld durchaus beliebte Banshee-Media-Player ist zum Beispiel ein C# entwickelt mit Mono. Oder auch die Beagle-Desktopsuche.
Aber selbst beim klassischen .NET gibt es Einiges, was mir spontan einfällt. Das Bildbearbeitungsprogramm Paint.NET oder auch der beliebte Passwort-Manager KeePass.
Ok. Das ist in der Anzahl an Programmen jetzt nicht viel. Aber die Installationsbasis ist immerhin beachtlich. Jetzt mal außen vorgelassen ob das an C# liegt oder nicht.

 

[birday]

Privat: Lern c++. Das wird dir helfen, mit Rechnerarchitektur, Betriebssytemvorlesungen was anzufangen, da du direkt mit dem OS zusammenarbeitest. Java zB ist da eher uninteressant, da man durch die JVM zu weit weg vom Betriebssystem und der Hardware ist.

 

[Limit]

Ich stimme dir generell zu, dass Java kein Effizienzwunder ist, was LOCs angeht. Deine Beispiele sind aber nicht besonders toll gewählt.

Zugegebenermaßen sind die Beispiele nicht ideal und man kann sicherlich bessere finden. Da ist mir gerade noch eine Sache eingefallen, nämlich überladen von Operatoren. Ich wollte mal meine eigene Money-Klasse implementieren. Damit zu rechnen ist in Python (genauso wie schon in C++ oder auch in Scala) mit überladenen Operatoren genauso einfach wie bei int/floats. In Java muss man hingegen komplett auf die Funktionsschreibweise zurückgreifen.

Exakt. Allerdings sind Interfaces gleichzeitig vor allem Typinformationen. Der Schreibaufwand ist höher, allerdings kannst Du damit schon zur Compilezeit (oder bei entsprechender IDE "beim tippen") feststellen, ob zwei Objekte überhaupt vergleichbar sind.

Bevor ich mehr mit dynamischen Programmiersprachen gearbeitet habe, dachte ich auch, dass es ohne explizite Typenangaben bei größeren Programmen schnell zu reinstem Typenchaos kommen müsse. In der Realität hat sich das nicht bewahrheitet.

In Python fliegt Dir das erst zur Laufzeit um die Ohren. Oder noch schlimmer, man hat implizit ne generische Vergleichsoperation von einer Superklasse geerbt, die dann zwar erstmal funktioniert, aber eben falsche Ergebnisse liefert, so das das Problem nicht offensichtlich ist.

Ganz normale Unittests sollten solche falschen Ergebnisse schnell offensichtlich machen und zum Glück lassen sich solche Bugs schnell finden und leicht beheben.

Es stimmt, Java ist nervig. Aber Python ist auch nicht perfekt. Die fehlende statische Typisierung ist schon oft ärgerlich. Klar kann man alles mit Unit-Tests abdecken, allerdings lässt sich dann kaum noch argumentieren, dass man man mit Python weniger Code schreiben muss, wenn die Unit-Tests umso länger ausfallen (was bleibt, ist dass dann der Produktivcode knapper und klarer formuliert ist).

Explizite Abfrage des Types werden weder im Programm selbst noch bei Unit-Tests empfohlen. Es gibt sicherlich Ausnahmen wo es sinnvoll ist, aber die sind eher rar. Zudem gibt es mittlerweile die Möglichkeit an kritischen Stellen den Typ per Annotation anzugeben und die Unittest-Bibliotheken überprüfen das dann automatisch.

Außerdem hatte Python noch ein Problem. Nämlich der ganze Ärger um den Wechsel von Python2 nach Python3. Javas Stärke ist ja hier gerade die Kontinuität.

Da hast du Recht. In der Übergangsphase hab ich mich über mehr als nur eine Bibliothek geärgert, die ich plötzlich nicht mehr nutzen konnte, weil sie noch nicht angepasst worden war. Im Nachhinein war es den Aufwand mMn aber Wert. Vor allem die Umstellung auf Unicode als Default-Representation von Strings hat mir so einigen Ärger erspart.

Dann ist in Python zwar (fast) alles ein Objekt (im Gegensatz zu Java, wo es z.B. die primitiven Typen gibt *urgs*).
Aber dann schwer nachvollziehbare Entscheidungen bei Funktionen bzw. Methoden. Warum ist die Längenbestimmung (len(str)) ne funktion und keine Methode? WTF?

Genau genommen ist es eine Methode oder besser gesagt gibt es in jeder Klasse mit der man len nutzen kann eine Methode namens __len__(). Das len eine Funtion ist hat wohl irgendwelche historischen Gründe. Warum man es mit dem Sprung zu Python3 nicht geändert hat kann ich allerdings auch nicht sagen. Andere Inkonsistenzen würde beseitigt, diese aber aus irgendeinem Grund nicht.

Was Python als unangenehme Eigenschaft mit Java teilt ist die Unterscheidung zwischen Statements und Expressions.

Ich finde Scala in der Hinsicht besser, aber so richtig gestört hat mich das ganze weder in Python noch in Java.

Was mich an Python am meisten genervt hat sind die semantischen Whitespaces. Gerade in der Anfangszeit kommt es ja mal vor, dass man Code aus anderen Quellen (Internet) übernimmt, kurz anpasst und dann laufen lässt. Und dann hat man eben schöne Laufzeitfehler, weil irgendwo ein Tab dazwischen ist und Ähnliches.
Kann man sich mit arrangieren. Wird wohl deshalb als so nervig empfunden, weils so gut in die Kategorie "unnötig" passt.

Das ist wohl Geschmackssache. Ich finde es besser als ewiges Klammernzählen. Nicht ohne Grund benutzt man die gleiche Methode auch bei Sprachen mit Klammern, obwohl das Syntax-mäßig eigentlich vollkommen überflüssig ist.

So hat eben jede Programmiersprache seine Nachteile. Letztlich muss man entscheiden, mit welchen man (besonders in Hinblick auf den Anwendungsbereich) am ehsten Leben kann.

Dem ist nichts hinzuzufügen.

Cloud heißt aber nicht automatisch, dass man weniger GUI macht. Cloud heißt ja erst mal nur, dass das Programm nicht nur auf den Client läuft, sondern auch auf dem Server. GUI brauchst Du weiterhin. Nur eben dann oft in Form von HTML/CSS und Javascript.

Das mag schon stimmen, aber meine Aussage war ja, dass .NET Core hauptsächlich auf den Server-Bereich abzielt und selbst mit GUI sind diese Clouddienste in erster Linie Server-Anwendungen. Der Browser oder die Smartphone-Apps wären die Clients.

Aber selbst bei serverless-software gibt es durchaus einen gewissen Trend HTML/CSS/Javascript (sprich Browser) als GUI-Engine zu nehmen. Man denke nur an den Kram rund um Electron und Co.
Kein Wunder, dass dann klassisch-nativ-GUI erstmal hinten angestellt wird. Das heißt aber dann nicht automatisch, dass GUI keine Rolle spielt.

Es gibt einen Trend dahingehend, aber ob der Bestand hat muss man erstmal sehen. FirefoxOS z.B. ist mit dem Konzept gescheitert.

Gerade Mono ist ja das Paradebeispiel für C#-Anwendungen auf dem Desktop (eben via GTK+).
Der im Linux-Umfeld durchaus beliebte Banshee-Media-Player ist zum Beispiel ein C# entwickelt mit Mono. Oder auch die Beagle-Desktopsuche.
Aber selbst beim klassischen .NET gibt es Einiges, was mir spontan einfällt. Das Bildbearbeitungsprogramm Paint.NET oder auch der beliebte Passwort-Manager KeePass.
Ok. Das ist in der Anzahl an Programmen jetzt nicht viel. Aber die Installationsbasis ist immerhin beachtlich. Jetzt mal außen vorgelassen ob das an C# liegt oder nicht.

Wie gesagt, es gibt durchaus C# Anwendungen für andere Systeme, deren Anteil ist allerdings sehr gering und zumindest für mich ist kein Trend erkennbar, der daran etwas ändern würde. Von Keepass gibt es ja z.B. auch eine C++ Version, weil es viele Nutzer gab, die zwar die Software mochten, das .NET Framework aber nicht installieren wollten.

 

[andy_m4]

Privat: Lern c++. Das wird dir helfen, mit Rechnerarchitektur, Betriebssytemvorlesungen was anzufangen, da du direkt mit dem OS zusammenarbeitest. Java zB ist da eher uninteressant, da man durch die JVM zu weit weg vom Betriebssystem und der Hardware ist.

Die JVM ist quasi ein Betriebssystem im Betriebssystem wenn Du so willst. Die Ausführungseinheit selbst ist kann man sogar als eine Emulation einer CPU verstehen.

Abgesehen davon weiß ich gar nicht was das Argument soll, dass man weiter von der Hardware und dem Betriebssystem entfernt ist. Heutzutage ist selbst C++ komfortabel zu dem, wie man vor 40 Jahren noch Software schrieb. Aus damaliger Sicht ist heutiges C++ viel zu weit weg von der Hardware und dem Betriebssystem. Ja und nu?

Oder um mal den beliebten Autovergleich zu bringen, ich kann auch ein Auto fahren ohne zu wissen, wie der Motor funktioniert.
Und wenn ich z.B. auf ein Computer zwei Zahlen addieren möchte, warum soll ich es dann nicht einfach tun können ohne mich erst mit Zahlentypen, Bitbreiten etc. auseinanderzusetzen?

Klar kann es sinnvoll sein sich auf gewisse Tiefen herabzusetzen. Und klar hilft das auch beim Verständnis. Aber das irgendwie immer als unumgänglich und den einzig wahren Weg hinzustellen, nervt dann irgendwie doch.
Man muss bedenken, dass man nur begrenzt Zeit hat. Stell Dir mal vor, Du müsstest für alle Dinge, die Dein Leben betreffen ein tiefgehendes Verständnis mitbringen. Deine Lebenszeit würde gar nicht ausreichen, um alles Notwendige dafür zu lernen.

Man muss also Prioritäten setzen und auch Dinge notfalls weglassen. Anders ist das gar nicht praktisch umsetzbar.

 

[birday]

Den Part mit dem Autovergleich habe ich mit Absicht jetzt nicht gelesen.

C++ Pointerarithmetik und direkter Speicherzugriff werden ihm dabei helfen, das gelernte aus Betriebssysteme & Rechnerarchitektur (Vorlesungen) zu verstehen und anzuwenden. Das gibt es in Java nicht.
Dass c++11 toll ist, hat hier niemand angezweifelt.

 

[Fonce]

C++ Pointerarithmetik...

Sollte man niemals verwenden da eine der häufigsten Ursachen für Bufferoverflows! Es ist einfach schlechter stil und absolut unnötig. Jeder, wirklich jeder Best Pratice Guide zu modern C++ sagt einem das man es nicht verwenden soll!

Mit welcher Sprache man anfängt ist eigentlich ziemlich egal, da es erstmal darum geht Konzepte zu erlernen. Wenn man dann eine Sprache und die benötigten Konzepts halbwegs beherrscht ist es ein leichtes eine neue Sprache und deren Eigenheiten zu erlernen.

EDIT:
Achja und bzgl. Betriebssysteme verstehen. Die sind eh alle in C und nicht C++. Das Buch Moderne Betriebssysteme von Andrew Tannenbaum mit dem man bei dem Thema wohl sehr wahrscheinlich in berührung kommt hat auch nur Codebeispiele in C.

 

[Miuwa]

Ich kenne zu wenige Programmiersprachen gut um wirklich einen Ratschlag geben zu können, welche Sprache sich am Besten eignet (wichtiger als die Sprache sind meiner Meinung nach die Bibliotheken/Frameworks), aber ich würde dir sehr ans Herz legen nicht die gesamte Entwicklung der Programmiersprachen ans Vorlage für das Curriculum zu nehmen.

Erst mit C anzufangen, dann mit C++ weiterzumachen, dann Java, dann C#, dann python, javascript etc macht keinen Sinn. Genausowenig erst rein prozedural, dann objektporientiert, dann funktional etc.. Bei diesem Vorgehen lernt man letztlich nur immer wieder Dinge, die mann sich dann nachher wieder abgewöhnen muss. Ich sehe auch keinen Sinn darin erst alles auf die Harte Tour zu lernen under erst viel später zu erfahren, dass es seit 5 Jahren einen Weg gibt mit dem sich das viel einfacher lösen lässt.

Fang mit einer Sprache an, mit der sich schnell Ergebnisse erziehlen lassen, such dir ein buch / tutorial, das von anfang an auf den Neuesten Sprachstandard setzt und wenn du dann das Gefühl hast, dass du mehr wissen willst, performance Probleme bekommst kannst du dich Stück für Stück in die Details einarbeiten.

Das soll nicht heißen, dass Details oder low-level Konzepte und Sprachen nicht wichtig sind, aber ein Top-Down approach funktioniert meiner meinung nach besser. Ich finde z.B. bücher Grausam, die die verschiedenen Sprachfeatures in der Reihenfolge behandeln, in der sie eingeführt wurden. Für Jarhzehnte haben intelligente menschen daran gearbeitet Sprachen zu verbessern und zugänglicher zu machen - kein grund davon nicht von anfang an zu profitieren.

Ergänzung (30. Juli 2017)

Sollte man niemals verwenden da eine der häufigsten Ursachen für Bufferoverflows! Es ist einfach schlechter stil und absolut unnötig. Jeder, wirklich jeder Best Pratice Guide zu modern C++ sagt einem das man es nicht verwenden soll!

Naja, praktisch jeder best practice guide zu modernem C++ empfiehlt einem standard library algorithmen zu verwenden und die Parameter dafür sind sehr häufig pointer. Bis ranges entlich mal in den standard kommen oder gsl::span auf breiter Front genutzt wird wirds noch ne ganze Weile dauern.

 

[Fonce]

Pointer als Parameter und Pointerarithmetik sind zwei Paar Schuhe!

 

[Miuwa]

@Fonce, nicht unbedingt: wenn duz.B. std::copy /_n aufrufst machst du letztendlich auchnichts anderes al pointer Arithmetik (begin+n). Das ist genauso unsicher wie das manuelle iterieren übers array. Das gleiche gilt für ne ganze Reihe weiterer Algorithmen. Ist jetzt auch nicht soo wichtig. Ich wollte nur darauf hinweisen, dass man Pointerarithmetik zwar manchmal (oft?) vermeiden kann, aber wir noch weit davon entfernt sind kanz ohne sie auszukommen.

 

[Fonce]

Also die Implementierung von std::copy ist ja nicht vorgegeben und kann sich je nach STL Implementierung unterscheiden.
Man sollte die Implementierungen der STL auch nicht als Vorlage für eigene Implementierungen sehen. Statt den Iterator einfach zu inkrementieren sollte man lieber std::advance/std::next nutzen, deshalb sind sie ja da/neu eingeführt worden. Als ich den Code eines unserer Produkte auf C++11 umgestellt habe(bzw. zum Teil noch dabei bin) konnte ich eigentlich auch alle Stellen an denen mit Iteratoren zum durchlaufen von std::vector Objekten genutzt wurde auf Range Based For Loops umstellen.
Dieses Thema ist ähnlich zu dem Thema wie ich auf Elemente von Container zugreife. Zu oft sieht man das operator[] genutzt wird statt die Methode at() welche Bound Checks enthält.