Bringt C# zusätzlich zu Java etwas?
-
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.
-
knivil schrieb:
Kannst du mir mal bitte die konkreten Punkte nennen, was meine Aussage nicht rechtfertigt!
Eine Aussage "Du hast nicht verstanden" verstopft eine Diskussion. Du stehst da und fühlst Dich im Recht, jemand anderer steht da und erklärt Deine Meinung(!) für irrelevant.
Ob der jenige nicht verstanden hat, oder ob ihr einfach aneinender vorbei redet, werdet ihr so nicht rausfinden. "Du hast nicht verstanden - Punkt" ist nie gerechtfertigt.Wenn Du der Meinung bist, dass Saxo etwas nicht verstanden hast, formuliere halt mal eine Frage: "Kann es sein dass Du das so und so verstanden hast - in dem Fall entsteht doch das und das Problem... ich verstehe das so und so, deswegen geht auch das und das."
knivil schrieb:
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.
Ich zähle mich zum Rest der Welt und sehe gerade das Konstruktive anders.
"Du hast nicht verstanden" ist die Aussage, dass ihr auf unterschiedlichen Leveln seid - und Du auf dem Wissenden, die andere auf dem Unwissenden. Das ist erstmal auch eine Herabstufung.
Konstruktiv ist, wenn man etwas weiß und dem anderen eine Treppe baut, statt nur ein Schild hinzustellen auf dem "Bitte draußen bleiben".Die Aussage "Lern was" (...dann darfst Du irgendwann mitreden) schlägt in die gleiche Kerbe.
Ein "Du hast nicht verstanden" kann die Beschreibung einer Tatsache sein, aber es ist immer auch ein Armutszeugnis, wenn danach nicht versucht wird, auf ein gemeinsames Verständnis zu kommen. Versuchst Du demjenigen ein größeres Verständnis näher zu bringen (!= aufzwängen), dann ist das konstruktiv.
Und Sprüche wie "Neues wirst du wohl nur schwer lernen, da du voll von Vorurteilen, Halbwissen und Hoerensagen bist." erachte ich ebenfalls als nicht konstruktiv, sondern als konfrontativ.
Konfrontation ist an dieser Stelle in meinen Augen nicht erforderlich, daher möchte ich Dich bitten, Deine Wortwahl kooperativer und damit auch konstruktiver zu gestalten, okay?
-
wenn man etwas weiß und dem anderen eine Treppe baut
Die Treppe ist da. Man muss nur mehr als 3 Worter lesen. Zum Rest der Welt habe ich genug gesagt.
Eine Aussage "Du hast nicht verstanden" verstopft eine Diskussion.
Welche Diskussion? Ueber Fakten laesst sich schwer diskutieren. Auch gabs genug Begruendung warum Dinge falsch sind.
Und Sprüche wie "Neues wirst du wohl nur schwer lernen, da du voll von Vorurteilen, Halbwissen und Hoerensagen bist." erachte ich ebenfalls als nicht konstruktiv, sondern als konfrontativ
Selbstverstaendlich ist das konfrontativ. Sogar eine Aufforderung besagte Einstellung abzulegen und Closures nicht als Voraussetzung fuer FP unabdingbar darzustellen. In C wuerde ich keine Closures nachbauen und dort anders FP betreiben als in C++ oder Java und wieder anders in Lisp/Scheme.
Konfrontation ist an dieser Stelle in meinen Augen nicht erforderlich
Ja, vielleicht war mehr Nachsicht angebracht. Die Methoden von uns beiden unterscheiden sich. Manchmal habe ich auch gute Tage.
-
Üblicher Krieg, ob ein Merkmal der Sprache oder dem Code zugesprochen wird.
Btw
Saxo liegt mit seine Aussage daneben, es geht nicht um Closure sondern um First-class-Function/Higher-order Function.
-
knivil schrieb:
Eine Aussage "Du hast nicht verstanden" verstopft eine Diskussion.
Welche Diskussion? Ueber Fakten laesst sich schwer diskutieren. Auch gabs genug Begruendung warum Dinge falsch sind.
Das siehst Du so, erlaube anderen das anders zu sehen. Und wenn Du zum Rest der Welt genug gesagt hast, dann schweige einfach, wenn Dir nicht mehr als "Du hast nicht verstanden" einfällt.
knivil schrieb:
Und Sprüche wie "Neues wirst du wohl nur schwer lernen, da du voll von Vorurteilen, Halbwissen und Hoerensagen bist." erachte ich ebenfalls als nicht konstruktiv, sondern als konfrontativ
Selbstverstaendlich ist das konfrontativ.
Konfrontation ist hier bitte nicht selbstverständlich und in meiner Rolle als Moderator möchte ich Dich bitten, Konfrontation zu vermeiden oder wenigstens sofort danach erkenntbar eine Tür zu öffenen: Heißt: "Du hast nicht verstanden" und es folgt eine konstruktive Erklärung.
Wenn Du für eine konstruktive Erklärung keine Lust oder Zeit hast, dann zieh Dich einfach aus der Geschichte raus, ohne nachzutreten. Ein "So ein Bullshit. Du hast keine Ahnung." kann inhaltlich richtig sein, ist aber einfach keine Art.Wer nicht auf Dich hören will, muss halt eigene Erfahrungen machen. Und da hat jeder auch sein Recht drauf.
Die Behauptung, dass jemand voll von Vorurteilen ist, ist jedenfalls nicht konstruktiv und spricht definitiv nicht dafür, dass Du konstruktiv antworten kannst. Du setzt damit also auch herab, was Du ansonsten so äußerst.
Stell Dir bitte vor dem Absenden die Frage, wem die Konfrontation nutzt und wenn sich niemand findet, lass sie bitte weg.
Zeus schrieb:
Üblicher Krieg
Wenn der "übliche Krieg" in diesem Board Usus wird, dann ziehen sich auch hier die Leute zurück, die darauf keinen Bock haben. Darauf habe ich keinen Bock.
-
Xin schrieb:
Zeus schrieb:
Üblicher Krieg
Wenn der "übliche Krieg" in diesem Board Usus wird, dann ziehen sich auch hier die Leute zurück, die darauf keinen Bock haben. Darauf habe ich keinen Bock.
Ich würde mich freuen, wenn Moderatoren meine Sätze nicht verstümmeln würden.
-
Zeus schrieb:
Btw
Saxo liegt mit seine Aussage daneben, es geht nicht um Closure sondern um First-class-Function/Higher-order Function.Aus meiner Sicht ist eine Closure eine First-class-Function. Was ist mit "Higher-order Function" gemeint? So wie ich das verstanden habe geht es darum, ob von innerhalb einer Funtkion auf freie Variablen zugegriffen werden können (aka Variablen, die außerhalb des Contexts der Funktion liegen):
"When a function refers to a variable defined outside it, it's called a free variable. A function that refers to a free lexical variable is called a closure. (...) The name "closure" is a left over from earlier Lisp dialects. It derives from the way closures have to be implemented under dynamic scope." Paul Graham, ANSI Common Lisp, Prentice Hall, 1996, p.107.
Stammt aus einem berühmten Lisp-Buch...
-- Saxo
