Bringt C# zusätzlich zu Java etwas?
-
Die meisten hier Programmieren nicht des Geldes wegen, auch wenn sie dafuer bezahlt werden.
-
Machst du das professionell oder als Hobby? Wenn du das beruflich machst, wirst du sehr wahrscheinlich nicht mit einer einzigen Sprache auskommen. Wär ja auch irgendwie langweilig
Mir persönlich gefällt C# als Sprache besser als Java.
-
Mechanics schrieb:
Machst du das professionell oder als Hobby? Wenn du das beruflich machst, wirst du sehr wahrscheinlich nicht mit einer einzigen Sprache auskommen. Wär ja auch irgendwie langweilig
Mir persönlich gefällt C# als Sprache besser als Java.Ich mache das schon professionel ... *smile* Ja, C# ist traurigerweise in einigen Punkten weiter als Java (traurig für Java meine ich), aber dafür ist das Java-Ökosystem größer. Ich kenne nur ganz wenig Java-Entwickler, die auch C#-Ahnung haben. Die ganz große Masse der Java-Leute macht sich keine Gedanken wegen 2.Standbein. Ich dachte eher als "Leistungsausweis" über OO-Verständnis/allgemeines Verständnis noch Sccala. Aber Scala ist auch wieder JVM und hilft nur als Zusatzausweis um wieder eine Java-Stelle zu bekommen ...
-
Ich hab früher in paar kleineren Firmen gearbeitet und alles mögliche gemacht. Das kommt auf den konkreten Kunden und den Auftrag an. Das meiste war C#, war aber auch einiges an Java und Scala, paar Projekte PHP oder Perl, C++, Python. Sogar ein Embedded Projekt in Assembler. Die meisten kleineren Softwareklitschen kämpfen ums Überleben und nehmen so gut wie jeden Auftrag an, da ist es auf jeden Fall von Vorteil, viele Sprachen zu beherrschen.
Jetzt arbeite ich in einer größeren Firma, die ein eigenes Produkt macht, und mache fast nur C++. Kann aber gut sein, dass ich in paar Jahren wieder woanders arbeite und was ganz anderes mache.
-
Mechanics schrieb:
Ich hab früher in paar kleineren Firmen gearbeitet und alles mögliche gemacht. Das kommt auf den konkreten Kunden und den Auftrag an. Das meiste war C#, war aber auch einiges an Java und Scala, paar Projekte PHP oder Perl, C++, Python. Sogar ein Embedded Projekt in Assembler. Die meisten kleineren Softwareklitschen kämpfen ums Überleben und nehmen so gut wie jeden Auftrag an, da ist es auf jeden Fall von Vorteil, viele Sprachen zu beherrschen.
Jetzt arbeite ich in einer größeren Firma, die ein eigenes Produkt macht, und mache fast nur C++. Kann aber gut sein, dass ich in paar Jahren wieder woanders arbeite und was ganz anderes mache.@Mechanics: You saved my day :-). Was du da schreibst hört sich für mich schon viel besser an. Ich hab' einfach Lust neben Java auch noch was anderes zu machen. Mit Scala habe ich schon ein bisschen angefangen. Das mache ich dann weiter. Python wäre cool (Perl nicht so ...). So'ne kleine Firma, bei der man vieles machen muss, wäre vielleicht mal was für mich. Mehr Stress, aber mehr Abwechslung. Habe einfach keine Lust mehr heute SOA und morgen Cloud-Computing hinterherzurennen, wenn ich genau weiß, dass es overhyped ist und nie Tagesgeschäft sein wird. Bin schon so lange in dem Beruf, dass ich keine Zukunftsangst bei 'nem kleinen Laden hätte. Hauptsache mehr Spaß und nicht immer nur das Gleiche ;-).
Gruß, Saxo
-
Saxo schrieb:
Was du da schreibst hört sich für mich schon viel besser an. Ich hab' einfach Lust neben Java auch noch was anderes zu machen. Mit Scala habe ich schon ein bisschen angefangen. Das mache ich dann weiter.
Klingt in meinen Augen sinnvoll, weil es eine zusätzliche Kompetenz ist, die sich mit Java gut kombinieren lässt.
Saxo schrieb:
Python wäre cool (Perl nicht so ...).
Python ist nett... ich programmiere gerade in Python. Allerdings bin ich überhaupt kein Fan von dynamischer Typisierung.
Saxo schrieb:
So'ne kleine Firma, bei der man vieles machen muss, wäre vielleicht mal was für mich. Mehr Stress, aber mehr Abwechslung.
Nach dem Studium wollte ich in eine große Firma. Ich bewarb mich für ein Praktikum online bei einer Firma mit einer hervorragenden Adresse bei einem Gebäude, das über mehrere Hausnummern ging.
Wer sich dort ein Gebäude über mehrere Hausnummern leisten kann, muss also was richtig machen.
Beim Bewerbungsgespräch kam ich erstmals zu der Adresse und stellte fest, dass es ein sehr, seeeeehr großes Klingelschild gibt und die Firma, bei der ich mich bewarb ein großes Büro dort besaß in dem 6 Leute programmierten.
Egal, dachte ich, üben wir Bewerbungsgespräche, gehen nach Hause und lachen drüber.Ich habe nicht nur mein Praxissemester da gemacht, sondern später auch noch eine Weile weiter da gearbeitet. Nirgendwo habe ich schneller und mehr gelernt. Als Praktikant war ich überall auf allen Leveln eingebunden: Java, C#, Datenbanken wie MSSQL und welche, von denen ich nie zuvor gehört hatte, JavaScript, HTML/PHP, C++ mit .COM-Programmierung, Delphi.
Gut, Delphi und Java habe ich mich verweigert.Eine kleine Firma kann es sich einfach nicht leisten, Dich an Deinem Schreibtisch sitzen lassen und Deine Kompetenzen verkümmern zu lassen.
Aber: Wenn Du Karriere machen willst, muss eine Leiter da sein. Die Firma hatte vier Geschäftsführer, einen Fachinformatiker als Angestellten und mich als Praktikanten. Als Angestellter hätte ich direkt auf Stufe 2 gestanden: Angestellter Informatiker. Aber weiter geht's halt nicht.
-
Python ist nett... ich programmiere gerade in Python. Allerdings bin ich überhaupt kein Fan von dynamischer Typisierung.
Dann kann ich Google Go empfehlen: Ist wie ein typisiertes Python, fühlt sich aber an wie eine Skript-Sprache (da die Builds unheimlich schnell sind). Performance ist etwa wie bei Java (müsste mit der Zeit noch etwas besser werden). Nur die Libraries sind nicht so umfangreich wie sie bei Python sein sollen.
Als Praktikant war ich überall auf allen Leveln eingebunden: Java, C#, Datenbanken wie MSSQL und welche, von denen ich nie zuvor gehört hatte, JavaScript, HTML/PHP, C++ mit .COM-Programmierung, Delphi.
Das Problem ist dabei, dass die Leute mit allen möglichen Sachen rumspielen, aber nie lernen Design zu machen, Konzeption zu machen, sich erst mal was zu überlegen und ständig sich was zu überlegen. Wenn sie erst mal 40 sind, kann man es ihnen nicht mehr beibringen nicht einfach drauf los zu programmieren. Leider ist das mittlerweile zum großen Teil in der Java-Welt auch so.
-- Saxo
-
Nun, die meisten neuen Sprachen sind irgendwie OOP + Lispfeatures, okay Lisp hat OOP, also nur Lispfeatures in anderer Syntax. Also warum sich mit Python abgeben, wenn man gleich Lisp haben kann. Clojure ist ein moderneres Lisp fuer die JavaVM. Scala ... ist mehr OOP.
-
knivil schrieb:
Nun, die meisten neuen Sprachen sind irgendwie OOP + Lispfeatures, okay Lisp hat OOP, also nur Lispfeatures in anderer Syntax. Also warum sich mit Python abgeben, wenn man gleich Lisp haben kann. Clojure ist ein moderneres Lisp fuer die JavaVM. Scala ... ist mehr OOP.
FP und OOP beißen sich. Bei OOP ändern Operationen einer Klasse Daten, die zur einer Instanz dieser Klasse gehören. Dies ist ganz gegen dem Prinzip in FP, wo Funktionen Daten weiterverarbeiten >ohne< diese zu verändern.
Es gibt einen berühmten Spruch von Rich Hickey: "Object-orientation is overrated" (siehe http://clojure.org/rationale). Aus meiner Sicht eine katastrophale Aussage. Aber das verdeutlicht das Denken in der FP.
-
Saxo schrieb:
Python ist nett... ich programmiere gerade in Python. Allerdings bin ich überhaupt kein Fan von dynamischer Typisierung.
Dann kann ich Google Go empfehlen: Ist wie ein typisiertes Python, fühlt sich aber an wie eine Skript-Sprache (da die Builds unheimlich schnell sind). Performance ist etwa wie bei Java (müsste mit der Zeit noch etwas besser werden). Nur die Libraries sind nicht so umfangreich wie sie bei Python sein sollen.
Go werde ich mir auf jeden Fall noch ansehen. Steht recht weit oben auf meiner Liste.
Saxo schrieb:
Als Praktikant war ich überall auf allen Leveln eingebunden: Java, C#, Datenbanken wie MSSQL und welche, von denen ich nie zuvor gehört hatte, JavaScript, HTML/PHP, C++ mit .COM-Programmierung, Delphi.
Das Problem ist dabei, dass die Leute mit allen möglichen Sachen rumspielen, aber nie lernen Design zu machen, Konzeption zu machen, sich erst mal was zu überlegen und ständig sich was zu überlegen. Wenn sie erst mal 40 sind, kann man es ihnen nicht mehr beibringen nicht einfach drauf los zu programmieren. Leider ist das mittlerweile zum großen Teil in der Java-Welt auch so.
Hmm... ich gehe schwer auf die 40 zu, ich gehöre vermutlich auch eher zu den Leuten, die erstmal drauf los programmieren.
Dazu gehören aber auch Programme - Prototypen - die ich vor dem eigentlichen Projekt schreibe, um Erfahrungen zu haben, wie ich das eigentlich Projekt anfassen will.Ich habe hier im Forum mal eine Art Softwaretechnik für den Hausgebrauch definiert, denn (leider?) ist in den meisten Firmen überhaupt keine Zeit für eine ausführliche Planung. Ich muss aber auch zugeben, dass ich kein Freund von übertriebener Planung bin, sondern eher professionelles Bauchgefühl und Improvisationstalent schätze, das in Kombination mit einer Planung agiert, die darauf ausgelegt ist, nichts zu planen, was nicht garantiert stattfindet.
Ich habe bisher nicht die Erfahrung gemacht, dass der Kunde sich für meinen Plan interessiert hätte ("Ich hätte da noch eine Idee...") oder dass sich auf dem Weg der Umsetzung nicht noch irgendwelche Probleme ergeben hätten.
Ich habe aber die Erfahrung gemacht, dass ich mit meiner Methode eher eine Punktlandung setze, weil ich bis zum letzten Augenblick frei agieren kann.
Der einzige erkennbare Nachteil ist, dass Kunden in den letzten Zügen schonmal nervös werden...Saxo schrieb:
FP und OOP beißen sich. Bei OOP ändern Operationen einer Klasse Daten, die zur einer Instanz dieser Klasse gehören. Dies ist ganz gegen dem Prinzip in FP, wo Funktionen Daten weiterverarbeiten >ohne< diese zu verändern.
Ich glaube nicht daran, dass sich Dinge beißen. Ich glaube daran, dass es Lösungen gibt, die sich für manche Probleme besser eignen als andere. Und ich glaube daran, dass es Probleme gibt, die sich aus der Kombination von objektenorientierter Sicht und FP gut lösen lassen.
OOP sagt schließlich eben nicht aus, dass die Objekte verändert werden müssen, sondern gibt nur mehr Auswahl bei der Wahl der Funktion, die aufgrund des Objektes etwas ausrechnet.
OOP ist ein Design Pattern, kein Paradigma.
Und ich glaube, dass man FP und OOP recht gut kombinieren kann, wenn man - mal wieder - die Perspektive ein wenig verrückt.
Solange man sich nicht stur an das hält, was gelehrt wird, wird man auch Mittel und Wege finden, die nicht gelehrt werden.
-
1.) Lisp ist nicht FP.
2.) FP und OOP beissen sich nicht.
3.) FP hat die Probleme von OOP nicht, bspw. in Paralleler Programmierung.
5.) Ich kann in allen Sprachen FP in meine Programme nutzen und einbauen.
6.) Konzepte aus FP/Lisp sind Vorbild fuer Sprachfeatures in vielen anderen Sprachen oder Bibliotheken.
7.) Saxo, wie willst du das beurteilen mit nur Java?Beispielsweise C++ std::accumulate <--> fold-left uvm.
-
Mechanics schrieb:
Machst du das professionell oder als Hobby? Wenn du das beruflich machst, wirst du sehr wahrscheinlich nicht mit einer einzigen Sprache auskommen.
Ich kenne Entwickler die über einige Jahrzehnte mit einer einzigen Sprache ausgekommen sind und ich selbst habe bislang auch beruflich zu mehr als 95% mit C++ zu tun gehabt (übrigens auch tendenziell kleinere Firmen). Man kommt also auch recht lang mit einer Sprache aus, selbst wenn man irgendwann (bei uns z.B. der seeeehr langsame Umstieg Richtung C#) vielleicht doch weitere lernen muss.
-
Ich kenne Entwickler die über einige Jahrzehnte mit einer einzigen Sprache ausgekommen sind und ich selbst habe bislang auch beruflich zu mehr als 95% mit C++ zu tun gehabt (übrigens auch tendenziell kleinere Firmen).
Ja, das kann man mit Java wohl auch. Problem ist halt, dass es nach über 10 Jahren irgendwann sich wiederholt und wie gesagt ist die Java-Entwicklung zur Commodity-Ware geworden (wenigstens teilweise) und so ist der Spaß einfach nicht mehr so da (viel Datengeschiebe statt ineressante Logik, etc.). Das ist wohl auch ein Grund warum viele Java-Entwickler andere JVM-Sprachen anschauen wie Scala, Kotlin, Groovy, Ceylon, Fan, Clojure, etc.
Ich kann in allen Sprachen FP in meine Programme nutzen und einbauen.
Diese Aussage lässt sich nicht halten. Mir kommt diese Aussage auch etwas affektmäßig vor. Bei den anderen Ausssagen kann man den Wahrheitsgehalt mit ein bisschen Googeln und lesen überprüfen. Ohne Closures lässt sich etwa FP nicht umsetzen. Viele Sprachen haben gar keine Closures. Closures allein sind aber auch nicht ausreichend für FP. Ich will ja nicht den Elan und das Interesse von knivil unterbinden. Deswegen ein Link zu einem kleinen Online-Buch, ist ein sehr guter Einstieg in FP um sich weiter darin einzulesen: http://learnyouahaskell.com/chapters u.v.a. um langsam dahinte rzukommen.
Have fun, Saxo
-
Ohne Closures lässt sich etwa FP nicht umsetzen. Viele Sprachen haben gar keine Closures. Closures allein sind aber auch nicht ausreichend für FP.
So ein Bullshit. Du hast keine Ahnung. Beispiel C++03 hatte keine 'lambdas' .. und? Nimmt man Funktoren. Und dann kannst du mir gern mal verraten wie Clojure FP sein kann und auf der selben VM laeuft wie Java. Sollte nach deiner Aussage ein Ding der Unmoeglichkeit sein. Wie kann das eine 'Closures' haben und das andere nicht?
Closures are poor man's objects. Objects are a poor man's closure
Und hier haben wir schon den Punkt. Lern irgendeine funktionale Programmiersprache. Beispielsweise (Lisp), Scheme, ML, ... Nein, ich wuerde nicht mit Haskell anfangen. Dein Wissen ist begrenzt. Wie waers mal mit etwas FP um deinen Horizont zu erweitern. Ich kann Scheme empfehlen: http://mitpress.mit.edu/sicp/ . Weitere fancy Sachen sind McCarthys Amb-Operator oder call/cc im Allgemeinen.
Deswegen ein Link zu einem kleinen Online-Buch, ist ein sehr guter Einstieg in FP um sich weiter darin einzulesen: http://learnyouahaskell.com/chapters u.v.a. um langsam dahinte rzukommen.
Ich praktiziere bereits FP in C++ und habe mehrere Jahre in Scheme programmiert. Deine Links sind bereits abgearbeitet. Das hat nichts mit Elan zu tun, es ist schlichtweg Erfahrung.
-
nd dann kannst du mir gern mal verraten wie Clojure FP sein kann und auf der selben VM laeuft wie Java. Sollte nach deiner Aussage ein Ding der Unmoeglichkeit sein. Wie kann das eine 'Closures' haben und das andere nicht?
Java in pre-JDK8 hat keine Closures. Die Lambdas in JDK8 sind auch nicht ganz Closures (weil Zugriff auf freie Variablen im Closure-Ausdruck nur lesend erlaubt ist). Trotzdem kann man auf der JVM Closures implementieren. Das haben ja Scala, Kotlin, Groovy, Clojure und noch andere Sprachen gezeigt.
So ein Bullshit. Du hast keine Ahnung.
Ansonsten: Closed as not constructive.
-
Deine haltlosen Behauptungen sind konstruktiv? Was du sagst, ist einfach falsch. Was soll ich denn anderes schreiben? Selbst meine Argumentation hast du voellig ignoriert. Und dann willst du ueber etwas diskutieren, dass du erst ergooglen musst? lol.
Neues wirst du wohl nur schwer lernen, da du voll von Vorurteilen, Halbwissen und Hoerensagen bist. Viel Spass bei LINQ in C# ...
Trotzdem kann man auf der JVM Closures implementieren
Du hast einfach nicht verstanden, was Closures sind und wie sie ausgedrueckt werden koennen.
-
Mein Kung Fu ist besser als Deins!
Programmieren ist ein Job wie jeder andere auch, nur dass 'wir' uns mehr
mit dem Job identifizieren als andere Berufszweige und viele eine stetige
Verbesserung nur in der Wahl der Sprache suchen. Das ist m.E. völliger Quatsch.
Es gibt weder die beste Sprache noch den goldenen Weg um zukunftssicher zu sein.
Lebenslanges Lernen heisst das Motto, dazu gehört auch sich mal C#, I@ oder O*!^2
anzuschauen. Man lernt stets dazu, egal was in 20 Jahren ist, dümmer wird man
jedenfalls nicht. Der besten Sprache hinterherzulaufen ist jedenfalls der falsche Weg.
Unterhaltet euch mal mit Cobol oder Delphi Programmierern. Ja die überleben auch heute noch sehr gut. Und vor allem ist der Programmierer 'Dienstleister' des Kunden. Dem
ist es mehr als egal, in welcher Sprache sein Anwendungsprogramm ist und wie elitär der Quellcode strukturiert ist. Das Ergebnis zählt.just my 2 cents
-
knivil schrieb:
Trotzdem kann man auf der JVM Closures implementieren
Du hast einfach nicht verstanden, was Closures sind und wie sie ausgedrueckt werden koennen.
Mal abgesehen davon, dass "Du hast einfach nicht verstanden" eine wertende Aussage ist, die die Behauptung in den Raum stellt, dass Du etwas besser wüsstest, als der minderwertige Rest der Welt.... da Du offenbar Experte bist, Du mit Saxo das Thema inzwischen soweit ins Off-Topic gebracht hast, dass es eigentlich auch egal ist, bring doch bitte mal mehr konstruktive Information, denn ehrlich gesagt, habe ich mir den Wikipedia-Artikel zu Closures schon mehrfach durchgelesen und am Schluss komme ich immer wieder dazu, dass es nichts anderes ist als ein Funktionsobjekt.
Wenn das hinkommt, dann sehe ich kein Problem, Funktionsobjekte auf einer JVM zu implementieren.Aber Da Du die Sache offenbar besser verstehst als Saxo und ich, wäre zumindest ich Dir dankbar, wenn Du eine leichtverständliche Erklärung für Closures liefern könntest, damit ich Dir danach sagen kann, ob ich Closures verstanden habe oder nicht.
Vielen Dank.
-
Kannst du mir mal bitte die konkreten Punkte nennen, was meine Aussage nicht rechtfertigt!
Mal abgesehen davon, dass "Du hast einfach nicht verstanden" eine wertende Aussage ist, die die Behauptung in den Raum stellt, dass Du etwas besser wüsstest, als der minderwertige Rest der Welt
Das ist eine reine Unterstellung. Ich habe direkt Saxo angesprochen. Der Rest der Welt war auch nicht zugegen und alle Beitraege waren konstruktiv. Mir ist auch der logische Schluss von 'Du hast nicht verstanden' zu 'minderwertige Rest der Welt' voellig unverstaendlich.
Wenn das hinkommt, dann sehe ich kein Problem, Funktionsobjekte auf einer JVM zu implementieren.
Meine Rede, Closures sind was triviales. Ganz leicht mit Objekten beschrieben mit beispielsweise
classumzusetzen. Das Lesen und Verstehen meiner Beitraege kann ich dir leider nicht abnehmen. Java hat Closures, jede Objektorientierte Sprache hat Closures, bei C waere mir der Aufwand zu gross. Und dennoch programmiere ich in C funktional, nein nicht im gesammten Programm, aber dort wo es sich anbietet.Hier mal fuer dich die Argumentationskette von Saxo:
Ohne Closures lässt sich etwa FP nicht umsetzen
Behauptung ohne Argument, aber egal
Viele Sprachen haben gar keine Closures
Ja nehme ich Funktoren. Funktoren sind Funktionsobjekte. Hier mein Zitat dazu:
Nimmt man Funktoren ... Object poor man's cloure blahblahblah
D.h. Voraussetzung nach Saxo erfuellt.
Closures allein sind aber auch nicht ausreichend für FP
Ja sehr konkret.
1.) Aussage schlichte Behauptung. Ich brauche keine Closures fuer FP, wobei das von der Definition FP abhaengt.
2.) Aussage falsch, da es beisielsweise in C++ wie auch in Java leicht umzusetzen ist. Ein No-Brainer sozusagen.
3.) Was braucht man denn noch? Disziplin beim Programmieren um auf Zuweisung zu verzichten.Warum soll das meine Aussage nicht rechtfertigen?
Off-Topic gebracht
Wieso? Meine Rat: Willste besserer Programmierer werden, nichts sprich gegen C# oder mache etwas FP. Willste mehr Geld, investiere in Aktien und verschwende nicht deine Zeit mit Programmieren.
bring doch bitte mal mehr konstruktive Information
Stelle doch konkrete Fragen und nimm auf bereits genannte Informationen zu Closures Bezug.
-
I can't go to bed yet. Somebody is wrong on the Internet.
