f# ist keine konkurenz zu c#. genau so wenig wie c# fu f# keine ist. die sprachen sind komplett unterschiedlich. manche aufgaben lassen sich in c# sehr umständlich lösen, wogegen das in f# ganz leicht ist. wiederum andere sind in f# nur sehr unschön möglich, und in c# kein problem. sie decken unterschiedliche bereiche ab.
f# ist keine konkurenz zu c#. genau so wenig wie c# fu f# keine ist. die sprachen sind komplett unterschiedlich. manche aufgaben lassen sich in c# sehr umständlich lösen, wogegen das in f# ganz leicht ist. wiederum andere sind in f# nur sehr unschön möglich, und in c# kein problem. sie decken unterschiedliche bereiche ab.
Welche Aufgaben sind denn in F# unschöner zu lösen, als in C#?
@Über mir: Ich finds eher ganz erschreckend :D
Davon unabhängig, dass sich meiner Meinung nach so langsam mal C++ als Minimumstandard, auch im Embeddedbereich, durchsetzen könnte, denke ich, dass es bei C(++) zuviel "Ballast" für den Programmierer gibt.
Erst recht wenn es nicht um systemnahe Anwendungszwecke geht. Davon abgesehen, dass die Syntax teilweise einfach nur grausig ist, gibt's da zu viel Ecken und Kanten wo man aufpassen muss, wo man sich selber grundlegende Funktionen/Bibliotheken zusammensuchen und für eine (oder mehrere) Entscheiden muss, kein GC, etc. Man muss sich zuviel um das drumherum kümmern und wird so zusehr von der eigentlichen Aufgabe abgelenkt (okay mag sein, dass sich das nach mehreren Jahren C++ Erfahrung legt, aber das ist ja auch nicht gerade ein schöner Zustand).
Meiner Meinung nach könnten sich Frameworks wie Java/.NET durchsetzen; jedoch nicht mit Runtime, sondern eher so eine Mischung aus C++/C#/.NET. Mit einer C#-vergleichbaren Syntax, fest in jedes System integriert (also ohne, dass zusätzliche Prozesse laufen bzw. installiert werden müssen; plattformübergreifend, aber dennoch nativ), ohne die "Kompliziertheiten" / Ecken und Kanten von C++, dafür mit den Vorteilen von .NET wie GC, mit einer mit der von .NET vergleichbaren Standardbibliothek, ...
Natürlich fehlen auch in .NET/C# noch so einige Sachen bzw. die sind zu kompliziert, die häufiger benötigt werden und die so ein "Framework"/Sprache dann direkt mitbringen und vereinfachen sollte (z.B. Multithreading).
Und natürlich schließt sowas keine spezialisierten Programmiersprachen aus, aber es wäre eine Basis für eine solche (inkl. allen Standardfunktionen) und würde aber allgemein für den Großteil der Anwendungen/Anwendungsentwicklung genug bieten.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Marsti am .
man sollte nicht alles glauben, was geschrieben wird. :-) Wenn man sich anguckt, wie das Ranking ermittelt wurden (TIOBE Programming Community Index Definition), kann man schon ins Grübeln kommen, ob es da überhaupt einen echten Zusammenhang zu der tatsächlichen Verbreitung bzw. tatsächlichen Benutzung von Programmiersprachen gibt. Ich möchte das bezweifeln. Jedenfalls kann man auf dem Ranking keine Schlussforderung aufbauen, bevor man das Ergebnis durch den Vergleich mit auf andere Weise ermittelten Rankings verifiziert hat.
Meiner Meinung nach könnten sich Frameworks wie Java/.NET durchsetzen; jedoch nicht mit Runtime, sondern eher so eine Mischung aus C++/C#/.NET. Mit einer C#-vergleichbaren Syntax, fest in jedes System integriert (also ohne, dass zusätzliche Prozesse laufen bzw. installiert werden müssen; plattformübergreifend, aber dennoch nativ), ohne die "Kompliziertheiten" / Ecken und Kanten von C++, dafür mit den Vorteilen von .NET wie GC, mit einer mit der von .NET vergleichbaren Standardbibliothek, ...
Es gibt schon Sprachen, die zu Maschinencode kompiliert werden und trotzdem einen GC haben (siehe Objective-C und D) und zumindest bei Objective-C ist auch mit Cocoa ein schönes Framework vorhanden. Leider haben beide Sprachen Nachteile, denn Objective-C ist zwar für Windows/Linux/Unix/Mac verfügbar, jedoch nur unter Mac komfortabel verwendbar. Und D hat afaik leider noch nicht so eine umfassende Library. Aber das ist auch alles kein Problem, da die Prozessoren eh immer leistungsfähiger werden und somit nur noch für Systemprogrammierung Sprachen wie ASM und C benutzt werden müssen.
Bezüglich dessen hab ich mir auch schonmal Gedanken gemacht.
Dabei bin ich auf die Überlegung gestoßen, eine höher stufige Sprache in C# mit einem eigenen Compiler zu entwickeln. Dieser Compiler kann dann den Quelltext für diese eigene Sprache in jede beliebige Sprache (C, C++, C#, BlitzBasic, VisualBasic) etc. umwandeln.
Genau diese Vorstellung wäre für mich die Programmiersprache der Zukunft, eine Sprache, die man in alle anderen Sprachen umwandeln kann.
In .NET gibt es allerdings schon die Möglichkeit, in etwa das hinzubekommen, ob man da noch eigene Sprachen implementieren kann, weiß ich nicht, aber auf jeden Fall kann mit einer Reflector Klasse (war das glaub ich) Strukturen in VB.NET, C++, C# oder java.NET umwandeln/zurück geben lassen und dynamisch kompilieren...
C# und alle anderen .Net sprachen werden in eine gemeinsame "Basis-Sprache" übersetzt die IL heißt. In einer .Net-Dll sind auch keine Binärdaten enthalten sondern dieser IL-Code, der zur Laufzeit noch mal kompiliert wird.
(siehe auch in der MSDN)
Also bei uns in der Firma geht es sehr viel um Embedded Programmierung, und da sind wir mit die einzigen, die bei neueren Projekten C++ (teilweise) im Einsatz haben.
Glücklich sind darüber bei weitem nicht alle.
Der Code ist langsamer und braucht viel mehr Speicher. Vor allem wenn man "schön" programmieren will. Ist also in vielen Hinsichten keine Frage, ob C nun nostalgisch ist oder nicht, sondern, was hat man den überhaupt für Voraussetzungen. Bei der PC Programmierung sind ein paar Megabyte mehr oder weniger lächerlich, und Reaktionszeiten...nuja 0.x Sekunden? Im embedded Bereich wird noch um jedes Kilobyte gekämpft und es wird Schnelligkeit gefordert (ms und µs Bereich), das bestimmt ja auch den Preis des Endgeräts.
Nur weil es "schöner" und "moderner" ist C++ einzusetzen, das ist da kein Argument.
Im Bereich der Oberflächenentwicklung denke ich C# und Java (letzteres vor allem bei Web-Entwicklungen) werden noch lange aktuell bleiben. Visual Basic hoffe ich ja immer dass es aussterben wird, aber die Programmierer sind langlebig und schaffen es auch immer wieder Neulinge, die nach einer Einstiegsprogrammiersprache suchen, zu überreden...
Ich sehe keine Notwendigkeit, eine neue Programmiersprache der Art C++, C# oder Java zu entwickeln, die dann nur ne andere Syntax und ein paar kleine Besonderheiten hat. Wenn, dann müsste es was komplett neues geben. Ich seh da aber im Moment auch nicht viel. Vielleicht dass man noch besser verteilt programmieren kann, so wie man jetzt in WPF Oberfläche und Code teilen kann, dass das noch in mehr Teilen so einfach geht (weiß aber auch nicht genau wie genau).
gruß
sth_Weird
~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
Fluchen ist die einzige Sprache, die jeder Programmierer perfekt beherrscht
* * *
Linux is for free...if your time is worth nothing
~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
Im embedded Bereich wird noch um jedes Kilobyte gekämpft und es wird Schnelligkeit gefordert (ms und µs Bereich), das bestimmt ja auch den Preis des Endgeräts.
Es fragt sich halt wo man das Geld investieren will. Wird in C programmiert kann man die schwächeren und günstigeren Prozessoren wählen. Dafür kann man C++ Code später noch erweitern und holt so das Geld für die teureren Prozessoren wieder rein. ;)
warum denkt man eigentlich das c aussterben könnte? um sprachen wie c# und das ganze .net zur verfügung zu stellen braucht man doch eine grundlage, oder irre ich mich da? das würde bedeuten, dass ein kleiner kreis immer noch mit den alten geschichten durch die gegend läuft, um anderen das leben einfacher zu machen. somit würde eigentlich gar nichts so wirklich aussterben ;)
und neue programmiersprachen werden sicher auch nicht mit .net entwickelt sondern werden wieder auf c basieren^^
werdet mal nicht fipsig. :-) Die Diskussion driftet stark in eine "wie werden die Programmiersprachen sich in den nächsten 10 Minuten entwickeln". Oder wie wird sich die Verbreitung dieser oder jene bekannten Programmiersprache entwickeln.
Auf der ersten Seite des Threads gibt es noch um ganze andere Dimensionen und echte neue Sprachen bzw. sogar die Programmierparadigmen. Und das zu recht, denn auch die Eingangsfrage zielt auf diese große Bild.
Berücksichtigt das bitte bei weiteren Antworten. Vielen Dank!
Irrtum
nur weil c weitverbreitet ist, heist das nicht das gleiches nicht auch mit modula oder Lisp machen kann.
MAn unterscheidet in dem was du unbewusst ansprichst nur Konzepte 2G oder 3G. 2G ist im Lowlevel nicht wegzudenken(momentan) hat aber 1G erstetzt, trotz angeblicher Performanceschwächen.
Assembler Rulz ist letztes Jahrzehnt. 2G-Sprachen haben für ein und Ausgaben noch Performancevorteile sind jedoch ungeeignet für höhere Komplexität. Es wird also Anpassungen geben die von 3 oder gar 4D 2D Probleme in angemessener Zeit Lösen. C ist Tot. jetzt schon. Es gibt noch Nischen, aber immer weniger. Assembler kann so gar 3G, wenns not tut - nur tut sich das niemand mehr an(12fache Zeit ggü einer nativen 2g).
Assembler und C sind Spezialfälle, die durch Modula Haskell wegzudenken sind(Andere angepasste Sprachen) C# läuft auf dem Mikroframework noch als Interpreter aber das angenehmer weniger fehleranfällig(billiger). Einer besseren Anpassung steht nichts im Weg. C als Notfall steht noch da. nur kann C nicht mal éin Wort abstrahieren. C folgt Assembler als Notlösung - je Weniger desto besser
