1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Microsoft: .Net…

C# + F# ... das goldene Zeitalter beginnt

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


  1. C# + F# ... das goldene Zeitalter beginnt

    Autor: spaceMonster 13.11.14 - 09:37

    Endlich stehen meine Lieblings sprachen auf einem zukunftssicheren Fundament.

  2. +1

    Autor: Trollversteher 13.11.14 - 09:50

    sehe ich genau so.

  3. Re: +1

    Autor: savejeff 13.11.14 - 09:57

    dito. Ich finde C# einfach genial

  4. Abwarten!

    Autor: Anonymer Nutzer 13.11.14 - 10:02

    > Endlich stehen meine Lieblings sprachen auf einem zukunftssicheren
    > Fundament.

    Noch ist nicht klar ob wirklich alle für ein typisches Projekt erforderlichen Komponenten veröffentlicht werden. Es würde mich nicht wundern wenn einzelne - aber fundamentale - Komponenten weiterhin nur für von Microsoft bevorzugte Systeme (also ihre eigenen) erhältlich sein werden.

    Das könnte auch wieder diese typische Microsoft-Taktik sein: Das blaue vom Himmel ankündigen - und dann in der Realität kleine aber entscheidende Lücken lassen die erst auffallen wenn man bereits viel Zeit und Geld in ihre Technologien investiert hat.

  5. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: patrik.stutz 13.11.14 - 10:22

    Die Frage ist nur ob es überhaupt noch Sinn macht diese Sprachen zu verwenden.

    Heutzutage wird doch möglichst alles webbasiert entwickelt, was bedeutet, dass die Sprache schonmal für 50% (den client Teil) der Anwendung nicht zur verfügung steht.

    Da es erhebliche Vorteile hat, Client und Server in der selben Sprache zu schreiben, wird JavaScript auch immer häufiger auch gleich für die Server-Seite benutzt. Das sieht man auch am enormen Wachstum der Node.js - Community.

    Was schlussendlich übrig bleibt, sind Anwendungen die Zugriff auf System-APIs benötigen, die das Web nicht bietet, oder die besonders gute Performance benötigen.
    Da die Browser immer mehr APIs anbieten, werden erstere Anwendungsfälle wohl immer seltener, wobei letztere (Games) gleich komplett eine andere Sprache verwenden sollten (C/C++).

    Wirklich von Bedeutung wird ein offenes C# wohl also nur für bestehende Software sein, die bereits in dieser Sprache geschrieben ist.

  6. Re: Abwarten!

    Autor: bofhl 13.11.14 - 10:26

    Dazu reicht ein Blick auf die github-Seiten des dotnet-Projekts sowie die bereits veröffentlichen Sourcen der anderen Projekte (z.B. JIT, Roslyn,...)

    Was eigentlich noch fehlt sind die rein Windows-Spezifischen Namespaces/Klassen - aber mit denen fängt man für eine Entwicklung z.B. für Linux oder OSX so wie so wenig bis gar nichts an.

  7. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: Trollversteher 13.11.14 - 10:31

    >Die Frage ist nur ob es überhaupt noch Sinn macht diese Sprachen zu verwenden.
    >Heutzutage wird doch möglichst alles webbasiert entwickelt, was bedeutet, dass die Sprache schonmal für 50% (den client Teil) der Anwendung nicht zur verfügung steht.

    Der Sinn von Webbasierten Projekten ist ja gerade, den Client möglichst schlank und "Dumm" zu halten, Javascript wird dort vermutlich nicht so schnell abgelöst werden. (Und das wird übrigens von den .Net Klassen automatisch generiert).
    Die serverseitige Logik ist in den meisten Fällen also deutlich komplexer, als dass sie nur einen Anteil von 50% ausmacht.

    >Da es erhebliche Vorteile hat, Client und Server in der selben Sprache zu schreiben, wird JavaScript auch immer häufiger auch gleich für die Server-Seite benutzt. Das sieht man auch am enormen Wachstum der Node.js - Community.

    Schlimm genug, das Leute auf solche Gedanken kommen...
    Aber da es genügend Compiler gibt, die ordentliche Programmiersprachen in Javascript-Friggelcode übersetzen, ist der umgekehrte Weg auch kein Problem.

    >Was schlussendlich übrig bleibt, sind Anwendungen die Zugriff auf System-APIs benötigen, die das Web nicht bietet, oder die besonders gute Performance benötigen.
    >Da die Browser immer mehr APIs anbieten, werden erstere Anwendungsfälle wohl immer seltener, wobei letztere (Games) gleich komplett eine andere Sprache verwenden sollten (C/C++).

    Falsch, gerade für Games ist C# perfekt geeignet, weil sich eben unmanaged Code (also die Anteile, die aus Performancegründen in einer nativen Sprache wie C++ oder Assembler geschrieben wurden) so einfach mit managed C# Code mischen lässt.

    >Wirklich von Bedeutung wird ein offenes C# wohl also nur für bestehende Software sein, die bereits in dieser Sprache geschrieben ist.

    Unsinn.

  8. Re: Abwarten!

    Autor: Anonymer Nutzer 13.11.14 - 10:39

    > Was eigentlich noch fehlt sind die rein Windows-Spezifischen
    > Namespaces/Klassen - aber mit denen fängt man für eine Entwicklung z.B. für
    > Linux oder OSX so wie so wenig bis gar nichts an.

    Was aber bedeutet das z.B. Programme mit GUI nicht plattformübergreifend entwickelt/genutzt werden kann. Der Nutzen dieser Offenlegung würde sich damit dann sehr in Grenzen halten. Ich hoffe das meine Befürchtungen diesbezüglich falsch sind - aber aktuell sieht es noch nach einem typischen Marketing-Schachzug aus. Groß verkünden das .NET nun OpenSource ist - indirekt damit Java schaden... und im Endeffekt nur die Daumenschrauben fester anziehen...

  9. Re: Abwarten!

    Autor: PiranhA 13.11.14 - 10:54

    Plattformübergreifende GUI Bibliotheken sind mittlerweile gar nicht mehr richtig möglich, weil die sich dermaßen weit voneinander entfernt haben. Klar kann man wie gehabt auch GTK oder Qt unter C# oder Mono nutzen, aber kann man die nicht wirklich mit nativen Bibliotheken vergleichen.
    Also da müsste wenn dann was komplett neues entwickelt werden, worauf sich erstmal Apple und Microsoft einigen müssten und entsprechend von der Linux Community unterstützt werden. Alleine der erste Punkt ist schon unmöglich. Ohne Interoperabilität zu WinForms/WPF würde da auch kein .net Entwickler mitziehen.
    Also WinForms oder WPF unter Linux/Mac kann man von vornherein vergessen. Da kann auch Microsoft nichts dran ändern. Wer plattformübergreifend die gleiche GUI haben will muss wie gehabt zu GTK/Qt greifen, bei Java bleiben oder gleich eine Web-Anwendung machen.

  10. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: patrik.stutz 13.11.14 - 11:04

    > Der Sinn von Webbasierten Projekten ist ja gerade, den Client möglichst
    > schlank und "Dumm" zu halten, Javascript wird dort vermutlich nicht so
    > schnell abgelöst werden. (Und das wird übrigens von den .Net Klassen
    > automatisch generiert).
    > Die serverseitige Logik ist in den meisten Fällen also deutlich komplexer,
    > als dass sie nur einen Anteil von 50% ausmacht.

    Ich kenne sehr wenige Anwendungen, bei denen der Server-Teil bzw. der Nicht-UI Teil grösser ist als der Client-Teil. Der Client sollte auch nicht möglichst dumm sein! Er sollte eher eigenständing funktionieren können und nur für den Datenabgleich und zum laden der Ressourcen den Server kontaktieren. Im Idealfall hat der server rein gar nichts mit dem UI zu tun (es sei denn der Code kann zwischen Client und server geteilt werden, z.B. mit React). Die Tendenz liegt also eher bei mehr Client- als Servercode.

    > Schlimm genug, das Leute auf solche Gedanken kommen...
    > Aber da es genügend Compiler gibt, die ordentliche Programmiersprachen in
    > Javascript-Friggelcode übersetzen, ist der umgekehrte Weg auch kein
    > Problem.

    Was ist an Fortschritt, Vereinfachung und bedeutend weniger Aufwand schlimm?
    Was Friggelcode ist, sieht jeder anders. Ich benutze bei der Arbeit C# und JS/HTML/CSS etwa gleichermassen und für mich ist C# das "gefriggel", da sich kaum Probleme elegant und mit wenig Code lösen lassen. Ja, Intellisense ist eine schöne Sache, und schon im voraus zu wissen das Code nicht funktionieren wird auch. Aber in meinem Kopf fängt das gefriggel an, wenn ich total unnötige Klassen & sonstigen unnötigen Code schreiben muss, den ich z.B. bei JavaScript komplett weglassen könnte.

    > Falsch, gerade für Games ist C# perfekt geeignet, weil sich eben unmanaged
    > Code (also die Anteile, die aus Performancegründen in einer nativen Sprache
    > wie C++ oder Assembler geschrieben wurden) so einfach mit managed C# Code
    > mischen lässt.

    Das mag sein. Aber ich wage zu bezweifeln, dass C# in diesem Sektor der Standard wird. C/C++ wird noch lange der Big-Player bleiben. Dazu kommt, dass Mozilla unter anderem mit ASM.js versucht, auch Games in den Browser zu holen. Die Zukunft der Spiele könnte also gerade so gut eine Mischung aus C/C++ und JavaScript sein anstatt von C/C++ und C#. Das bleibt abzuwarten.

    > Unsinn.

    Begründung?



    1 mal bearbeitet, zuletzt am 13.11.14 11:07 durch patrik.stutz.

  11. Re: Abwarten!

    Autor: Anonymer Nutzer 13.11.14 - 11:04

    > Also WinForms oder WPF unter Linux/Mac kann man von vornherein vergessen.

    Das sehe ich definitiv nicht so! Es wäre durchaus möglich GUI-Frameworks auf beliebige Plattformen zu portieren. Technisch sehe ich da keine Hindernisse. Ich glaube nur nicht das dies von Microsoft gewünscht ist. Vermutlich werden sie aber tatsächlich angebliche technische Hürden als Begründung vorschieben.

  12. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: Trollversteher 13.11.14 - 11:14

    >Ich kenne sehr wenige Anwendungen, bei denen der Server-Teil bzw. der Nicht-UI Teil grösser ist als der Client-Teil. Der Client sollte auch nicht möglichst dumm sein! Er sollte eher eigenständing funktionieren können und nur für den Datenabgleich und zum laden der Ressourcen den Server kontaktieren. Im Idealfall hat der server rein gar nichts mit dem UI zu tun (es sei denn der Code kann zwischen Client und server geteilt werden). Die Tendenz liegt also eher bei mehr Client- als Servercode.

    Das hängt vom Projekt ab - in einer komplexen Datenbankanwendung zB. ist die Logik selbstverständlich serverseitig implementiert. Bei kleinen Webprojekten bleibt Dir die Serverseitige Logik vielleicht verborgen, weil Du auf fertige Lösungen wie Content Management Systeme zurückgreifst.

    Aber klar, die meiste clientseitige Komplexität liegt in der GUI - aber der Client-GUI-Code wird ja von .Net, auf Basis einer .Net Sprache wie C#, automatisch in Javascript generiert. Also kein Argument gegen C#, im Gegenteil, eher ein weiteres dafür.

    >Was ist an Fortschritt, Vereinfachung und bedeutend weniger Aufwand schlimm?

    Fortschritt? Sehe ich bei Javascript selbst keinen. Mächtige Frameworks wie JQUERY, ja, aber die Sprache an sich? Ist tiefste Steinzeit. Und weniger Aufwand? Unsinn.

    >Was Friggelcode ist, sieht jeder anders. Ich benutze bei der Arbeit C# und JS/HTML/CSS etwa gleichermassen und für mich ist C# das "gefriggel", da sich kaum Probleme elegant und mit wenig Code lösen lassen.

    Also wennDu C# gegenüber js als "gefriggel" siehst, dann würde ich Dir mal einen guten Lehrgang, oder zumindest ein wenig "Extremeprogramming" mit einem erfahrenen C# Entwickler empfehlen - wenn man natürlich unter C# arbeitet, wie man es von js gewohnt ist, dann kann dabei nur Murks herauskommen.

    >Ja, Intellisense ist eine schöne Sache, und schon im voraus zu wissen das Code nicht funktionieren wird auch. Aber in meinem Kopf fängt das gefriggel an, wenn ich total unnötige Klassen & sonstigen unnötigen Code schreiben muss, den ich z.B. bei JavaScript komplett weglassen könnte.

    "Unnötige Klassen", "Unnötiger Code"? Da kräuseln sich bei jedem Erfahrenen Entwickler die Nackenhaare vor gruseln... Klar hat eine Scriptsprache den Vorteil, mal eben schnell unstruktiert etwas herunterschreiben zu können, aber für komplexe Logik und umfangreiche Projekte ist das einfach völlig ungeeignet und mer als Schädlich, was Wartbarkeit und Erweiterbarkeit betrifft.

  13. Re: +1

    Autor: Kleba 13.11.14 - 11:26

    +1

  14. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: patrik.stutz 13.11.14 - 11:41

    > Das hängt vom Projekt ab - in einer komplexen Datenbankanwendung zB. ist
    > die Logik selbstverständlich serverseitig implementiert.

    Genau. Je nach dem wie komplex der Code hinter der API für den Client ist, kann der Server-Code durchaus grösser sein. Deshalb hatte ich pauschal ja auch 50% gesagt.

    > Aber klar, die meiste clientseitige Komplexität liegt in der GUI - aber der
    > Client-GUI-Code wird ja von .Net, auf Basis einer .Net Sprache wie C#,
    > automatisch in Javascript generiert. Also kein Argument gegen C#, im
    > Gegenteil, eher ein weiteres dafür.

    Ach so, das Client-GUI wird also auf magische Weise anhand des Server-Codes erstellt? Das kannte ich noch gar nicht. Natürlich muss man auch in C# GUI-Code schreiben, und dieser ist meist deutlich komplexer und unübersichtlicher als bei web-basierten anwendungen.

    > Fortschritt? Sehe ich bei Javascript selbst keinen. Mächtige Frameworks wie
    > JQUERY, ja, aber die Sprache an sich? Ist tiefste Steinzeit. Und weniger
    > Aufwand? Unsinn.

    Die Sprache wird ziemlich stark weiterentwickelt. Auch wenn von den neuen Features noch nicht allzu viele in den Engines verfügbar sind, so sind sie trotzdem auf dem weg.

    > Also wennDu C# gegenüber js als "gefriggel" siehst, dann würde ich Dir mal
    > einen guten Lehrgang, oder zumindest ein wenig "Extremeprogramming" mit
    > einem erfahrenen C# Entwickler empfehlen - wenn man natürlich unter C#
    > arbeitet, wie man es von js gewohnt ist, dann kann dabei nur Murks
    > herauskommen.
    >
    > "Unnötige Klassen", "Unnötiger Code"? Da kräuseln sich bei jedem Erfahrenen
    > Entwickler die Nackenhaare vor gruseln... Klar hat eine Scriptsprache den
    > Vorteil, mal eben schnell unstruktiert etwas herunterschreiben zu können,
    > aber für komplexe Logik und umfangreiche Projekte ist das einfach völlig
    > ungeeignet und mer als Schädlich, was Wartbarkeit und Erweiterbarkeit
    > betrifft.

    Das kommt ganz auf die Sichtweise an. Wenn sich Entwickler die nicht-typisierte Sprachen bevorzugen typisierten Code ansehen, dann sehen sie nunmal viele Dinge, die da nicht sein müssten.

    Wenn sich Entwickler die typisierte Sprachen bevorzugen nicht-typisierten Code ansehen, sehen sie Gefriggel und Chaos. Ebenfalls sehen sie in ihrem eigenen Code nichts überflüssiges. Es hat alles seinen Zweck.

    Ehrlich gesagt möchte ich diese ewige Diskussion hier gar nicht führen. Beides hat viele vor und Nachteile. In gewissen Programmteilen macht Typisierung oder ähnliches Sinn, bei gewissen ist es den Mehrwaufwand und andere Nachteile nicht wert. Grundsätzlich muss ich hier aber noch sagen: Nur weil code nicht typisiert ist, heisst das noch lange nicht, dass dies der Wartbarkeit und Erweiterbarkeit schadet. Es gibt Bibliotheken und andere Strategien, die man für diese besonders wichtigen Teile des Programms einsetzen kann, um dies zu garantieren.

  15. Re: Abwarten!

    Autor: mw88 13.11.14 - 11:59

    Es wäre schon möglich WPF und ähnliches auf GTK/QT zu portieren. Es gibt ja auch schon GTK# auf das man evtl. aufbauen könnte aber das ist schon eine Menge Arbeit und wie kompatibel man mit der Windowsimplementierung wäre ist die andere Frage. Hier müsste man Kompromisse wie bei Swing oder SWT eingehen...

  16. Re: Abwarten!

    Autor: Anonymer Nutzer 13.11.14 - 12:01

    > (...). Hier müsste man Kompromisse wie bei Swing oder SWT
    > eingehen...

    Natürlich läuft das auf Kompromisse heraus... aber das muss ja nicht unbedingt nachteilig sein.

  17. Re: Abwarten!

    Autor: Beazy 13.11.14 - 12:11

    PiranhA schrieb:
    --------------------------------------------------------------------------------
    > Plattformübergreifende GUI Bibliotheken sind mittlerweile gar nicht mehr
    > richtig möglich, weil die sich dermaßen weit voneinander entfernt haben.
    > Klar kann man wie gehabt auch GTK oder Qt unter C# oder Mono nutzen, aber
    > kann man die nicht wirklich mit nativen Bibliotheken vergleichen.

    Wieso nicht? Was unterscheidet GTK und Qt von einer "nativen" Bibliothek? Was macht eine native Bibliothek aus? Ich kenne mich da nicht aus, kannst Du mir das erklären?

  18. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: supersux 13.11.14 - 12:11

    patrik.stutz schrieb:
    --------------------------------------------------------------------------------
    > Grundsätzlich muss ich hier aber noch sagen:
    > Nur weil code nicht typisiert ist, heisst das noch lange nicht, dass dies
    > der Wartbarkeit und Erweiterbarkeit schadet.

    erm, doch?! Genau deswegen macht man diesen "unnötigen Kram" schließlich...

    > Es gibt Bibliotheken und
    > andere Strategien, die man für diese besonders wichtigen Teile des
    > Programms einsetzen kann, um dies zu garantieren.

    oh ja, genau, die ominösen frameworks & dev-strategies mit denen sich alle grundsätzlichen Probleme erschlagen lassen...
    "hey, es gibt ja Aspirin, also ist es kein Problem sich mit dem Hammer auf den Kopf zu hauen"

    > Ehrlich gesagt möchte ich diese ewige Diskussion hier gar nicht führen.
    dann stelle doch bitte auch nicht in erster Instanz solche Behauptungen auf, sondern steh auch bitte einfach zu den Nachteilen (Vorteile gibt es ja ebenso genug).

  19. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: t-master 13.11.14 - 12:21

    patrik.stutz schrieb:
    --------------------------------------------------------------------------------
    > Ach so, das Client-GUI wird also auf magische Weise anhand des Server-Codes
    > erstellt? Das kannte ich noch gar nicht. Natürlich muss man auch in C#
    > GUI-Code schreiben, und dieser ist meist deutlich komplexer und
    > unübersichtlicher als bei web-basierten anwendungen.

    a) Gerade z.B. mit WPF ist der GUI-Code meiner Erfahrung nach deutlich übersichtlicher als Html (vor allem wenn man dann noch für jeden der große Browser eigene Ausnahmen reinfrickeln muss)
    b) ja, es gibt sowas, nennt sich Asp.Net, erzeugt automatisch aus C# Code auf dem Server Html und Javascript-Code für den Clienten

  20. Re: C# + F# ... das goldene Zeitalter beginnt

    Autor: bstea 13.11.14 - 12:23

    supersux schrieb:
    --------------------------------------------------------------------------------
    > patrik.stutz schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Grundsätzlich muss ich hier aber noch sagen:
    > > Nur weil code nicht typisiert ist, heisst das noch lange nicht, dass
    > dies
    > > der Wartbarkeit und Erweiterbarkeit schadet.
    >
    > erm, doch?! Genau deswegen macht man diesen "unnötigen Kram"
    > schließlich...

    Sicher das du schon mal programmiert hast? Code irgendwo auschecken und auf Compile drücken zählt nicht. Typiserung ist ein Hilfe vom Compiler für den Programmierer und erlaubt weitere interne Optimierungen. Ich komme ganz gut ohne klar.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Expert Partner & IT-Resource Management (m/w/d)
    operational services GmbH & Co. KG, verschiedene Standorte
  2. DevOps - Engineer BMC Helix ITSM - Remedy - (m/w/div)
    Deutsche Rentenversicherung Bund, Berlin
  3. Mitarbeiter IT-Support Arbeitsmedizinische Software (Samas) (m/w/d)
    DEKRA Automobil GmbH, Stuttgart
  4. IT-Systemadministrator (m/w/d)
    Kommunaler Versorgungsverband Baden-Württemberg, Karlsruhe

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 114,99€ (Angebot auch bei Saturn erhältlich. Vergleichspreis 140,89€)
  2. 0,99€ (Tiefstpreis!)
  3. 125,11€ - Tiefstpreis! (Vergleichspreis über 200€)
  4. u. a. Patriot Viper VENOM 64-GB-Kit DDR5-6000 für 159€ statt 210€ im Vergleich, PowerColor...


Haben wir etwas übersehen?

E-Mail an news@golem.de