Guten Abend zusammen, ich habe eine Diskussion mitbekommen und würde gerne das Forum dazu befragen. An der Berufsschule sagen Programmierlehrer, dass C# unsere Zukunft ist und das C bzw. C++ bald nicht mehr von Bedeutung ist. Ich würde mich auf eine Meinung des Forums freuen. MfG HB
Troll? Die drei Sprachen haben andere Einsatzgebiete und andere Ziele: C#: Unter Windows umfangreiche Allroundsau für Softwaregroßprojekte, aber keine hardwarenahen Anwendungen C: Hardwarenahe Sauereien, Treiber, im Vergleich zu anderen Sprachen einfach auf der Zielplattform zum Laufen zu bringen: Man braucht "nur" einen Compiler, keine Laufzeitumgebung C++: Halbwegs objektorientierte und relativ performante Sprache, die sich auf Mikrocontrollern durchsetzen könnte (ist ja schon verfügbar) und die m.M.n. klassischem C den Rang ablaufen könnte C# und C/C++ bedienen andere Anforderungen und die eine kann die andere nur bedingt ersetzen.
Harald B. schrieb: > An der Berufsschule sagen Programmierlehrer, dass C# unsere Zukunft ist > und das C bzw. C++ bald nicht mehr von Bedeutung ist. Das sind keine Lehrer, das sind weltfremde Trottel aus einem weit entfernten Paralleluniversum welches kurz vor dem Kältetod steht. Glaub denen kein Wort. Die wollen Dich nur auf die dunkle Seite der IT ziehen.
:
Bearbeitet durch User
Harald B. schrieb: > An der Berufsschule sagen Programmierlehrer, dass C# unsere Zukunft ist > und das C bzw. C++ bald nicht mehr von Bedeutung ist. Sowas hatte mal ein Dozent an der FH Regensburg anno 1988 über Lisp erzählt: Lisp-Prozessoren seien die Zukunft, alles andere würde verschwinden. Nur hatte er dabei nicht bedacht, daß die meisten Lisp gar nicht erst raffen. Was die Zukunft ist, wird erst die Zukunft zeigen. Bisher waren noch so ziemlich alle Zukunftsprognosen eher ein Griff ins Klo. EDIT: andere prognostizierten 4GL wie Powerbuilder und Ingres 4GL als die Zukunft. Und wo stehen die heute?
:
Bearbeitet durch User
Harald B. schrieb: > dass C# unsere Zukunft ist > und das C bzw. C++ bald nicht mehr von Bedeutung ist. Für klassische, reine Windows-Anwendungen von reinen Windows-Programmierern stimmt das wahrscheinlich. Für eine unternehmensweite Büromittelausgabeverwaltungssoftware mit etwas GUI, etwas Datenbank und einer Prise Netzwerk will man kein C++ und erst recht kein C. Java ginge, aber C# ist das bessere Java.
Wenn man für C# irgendwann mal einen gescheiten GUI-Editor bereitstellt, dann wird das auch was ;-) Da kann C# noch so schön sein. Das was es derzeit von Microsoft als Werkzeuge für die GUI gibt, ist ne Frechheit.
Nase schrieb: > Wenn man für C# irgendwann mal einen gescheiten GUI-Editor > bereitstellt, dann wird das auch was ;-) > > Da kann C# noch so schön sein. Das was es derzeit von Microsoft als > Werkzeuge für die GUI gibt, ist ne Frechheit. was stört dich daran? das ist einer der punkte, die ich gut an C# finde.
Nase schrieb: > Wenn man für C# irgendwann mal einen gescheiten GUI-Editor > bereitstellt, dann wird das auch was ;-) > > Da kann C# noch so schön sein. Das was es derzeit von Microsoft als > Werkzeuge für die GUI gibt, ist ne Frechheit. Huch? Hast du ein anderes VS als ich? Nicht, dass das VS nicht in vielen Punkten durchaus verbesserungswürdig wäre, aber gerade der Bereich des GUI-Design ist doch eher gelungen. Man kann recht schnell funktionale GUIs damit designen. Natürlich ist es dazu notwendig, die verschiedenen möglichen Layout-Konzepte zu beherrschen, diese zweckentsprechend auszuwählen und anzuwenden. Kann es sein, dass da bei dir herbe Defizite beim Basiswissen bestehen?
Hallo Zusammen, vielen Dank für diese Beiträge. Joschua C. schrieb: > Troll? > > Die drei Sprachen haben andere Einsatzgebiete und andere Ziele: > > C#: Unter Windows umfangreiche Allroundsau für Softwaregroßprojekte, > aber keine hardwarenahen Anwendungen > C: Hardwarenahe Sauereien, Treiber, im Vergleich zu anderen Sprachen > einfach auf der Zielplattform zum Laufen zu bringen: Man braucht "nur" > einen Compiler, keine Laufzeitumgebung > C++: Halbwegs objektorientierte und relativ performante Sprache, die > sich auf Mikrocontrollern durchsetzen könnte (ist ja schon verfügbar) > und die m.M.n. klassischem C den Rang ablaufen könnte > > C# und C/C++ bedienen andere Anforderungen und die eine kann die andere > nur bedingt ersetzen. Meine Meinung liegt auch eher hier, wasJoschua C. geschrieben hat. Der Beitrag von Markus L. Datum: 17.04.2016 02:02 ist aber auch interesant ;O) Danke!
Bernd K. schrieb: > Harald B. schrieb: >> An der Berufsschule sagen Programmierlehrer, dass C# unsere Zukunft ist >> und das C bzw. C++ bald nicht mehr von Bedeutung ist. > > Das sind keine Lehrer, das sind weltfremde Trottel aus einem weit > entfernten Paralleluniversum welches kurz vor dem Kältetod steht. > > Glaub denen kein Wort. Die wollen Dich nur auf die dunkle Seite der IT > ziehen. Danke dafür ;o) !!!!!!!! HB
c-hater schrieb: > Kann es sein, dass da bei dir herbe Defizite beim > Basiswissen bestehen? Ja und nein... Ich habe irgendwann aufgegeben, mich durch das mäßig dokumentierte Durcheinander von gefühlt fünf verschiedenen Konzepten zu wühlen, und bin woanders (hier konkret bei Qt) gelandet. Layoutmanagement ist ja bis heute noch seeeeehr dünn mit WinForms.
Richard St. schrieb: > Harald B. schrieb: >> dass C# unsere Zukunft ist >> und das C bzw. C++ bald nicht mehr von Bedeutung ist. > > Für klassische, reine Windows-Anwendungen von reinen > Windows-Programmierern stimmt das wahrscheinlich. Vielleicht. Das ist allerdings nur ein kleiner Bruchteil der gesamten Software, die programmiert wird. Den Löwenanteil dürfte die Software ausmachen, an die viele gar nicht denken, die aber gerade hier im Forum eigentlich im Hauptfokus steht: Embedded-Software. Es gibt doch heute kaum mehr ein Gerät, das nicht mindestens einen µC hat. Viele haben sogar mehrere. Die müssen auch alle programmiert werden, und da spielt C# praktisch keine Rolle. Nase schrieb: > Layoutmanagement ist ja bis heute noch seeeeehr dünn mit WinForms. Microsoft ist, was das betrifft, ja auch weit hintendran. Deshalb gibt's ja dort bis heute so viele Dialoge, deren Größe sich nicht ändern lässt oder Buttons, die sich nicht an den enthaltenen Text anpassen können. Qt hatte da schon vor 18 Jahren, als ich mit GUI-Programmierung angefangen hab, komfortable Layout-Funktionen. Ich kenne das gar nicht anders.
Die Open University hat mal in einer ziemlich groß angelegten Studie untersucht, was einen erfahrenen Programmierer (ein sogenannter expert programmer) von weniger erfahrenen (naive programmers) unterscheidet, insbesondere welche Sprachkonstrukte, Sprachen und Paradigmen Experten bevorzugen. Das ziemlich eindeutige Ergebnis war, dass Experten keine besonderen Sprachkonstrukte bevorzugen, sondern dass Experten ganz im Gegenteil sich genau dadurch auszeichnen, extrem schnell zwischen verschieden Sprachkonstrukten, Paradigmen und Abstraktionsebenen wechseln zu können. Ein wirklicher Experte wird sich daher niemals auf eine bestimmte Sprache oder einen bestimmten Programmierstil festlegen lassen, sondern stets dass nehmen, was für die Lösung der jeweiligen Aufgabe am ehesten geeignet ist. Vor diesem Hintergrund sollte es Dir jetzt nicht schwer fallen zu beurteilen, ob die Aussage Deiner Lehrer die eines Experten oder doch eher die eines naiven Nutzers ist. Allerdings muss man zu ihrer Verteidigung anführen, dass die Wahl einer Sprache nicht immer von Ingenieuren getroffen wird, manchmal spielen auch ganz andere Gesichtspunkte die entscheidende Rolle. Sollte der Experte aber irgendwann gar keinen Einfluss mehr auf die Wahl der Sprache haben würde sich natürlich die Frage stellen, ob es sich dann überhaupt noch lohnt, Experte zu werden.
:
Bearbeitet durch User
Rolf M. schrieb: > Den Löwenanteil dürfte die Software > ausmachen, an die viele gar nicht denken, die aber gerade hier im Forum > eigentlich im Hauptfokus steht: Embedded-Software. Es gibt doch heute > kaum mehr ein Gerät, das nicht mindestens einen µC hat. Viele haben > sogar mehrere. Die müssen auch alle programmiert werden, und da spielt > C# praktisch keine Rolle. Und auch nicht zu verachten ist der ganze Komplex aus "Cloud"-Plattformen und Diensten, In dem Bereich ist Microsoft und C# heutzutage überhaupt nicht mehr anzutreffen, da haben die sich selbst gründlich und vollständig rausgekegelt durch ihr bockiges selbstauferlegtes Exil auf ihrer zugemauerten Insel. In dem Bereich hast Du es ausschließlich mit unixoiden Systemen zu tun und dort trifft man auf Sprachen wie Java, Go, Python, Ruby, JavaScript, etc.
Bernd K. schrieb: > In dem Bereich hast > Du es ausschließlich mit unixoiden Systemen zu tun und dort trifft man > auf Sprachen wie Java, Go, Python, Ruby, JavaScript, etc. So unbedeutend ist Microsoft Azure nun auch nicht und dort spielt .NET sehr wohl eine Rolle.
Peter II schrieb: > So unbedeutend ist Microsoft Azure nun auch nicht Doch so unbedeutend ist Azure. Sie mussten jetzt schon Linux Unterstützung einbauen, damit das Ding überhaupt mal ein paar Leute nutzen.
T.roll schrieb: > Peter II schrieb: >> So unbedeutend ist Microsoft Azure nun auch nicht > > Doch so unbedeutend ist Azure. Sie mussten jetzt schon Linux > Unterstützung einbauen, damit das Ding überhaupt mal ein paar Leute > nutzen. Azure ist nach AWS z.Z. noch die Nummer 2 (und wächst deutlich schneller als AWS), Google ist mit ihren Angeboten deutlich abgeschlagen. Und was bieten AWS und Google aber auch bspw. RedHat/OpenShift an? .NET/MSSql/Windows https://aws.amazon.com/de/net/ https://aws.amazon.com/de/windows/products/sql/ https://cloud.google.com/compute/docs/tutorials/deploy-aspnet-app https://blog.openshift.com/microsoft-dot-net-on-openshift/
A. H. schrieb: > Allerdings muss man zu ihrer Verteidigung anführen, dass die Wahl einer > Sprache nicht immer von Ingenieuren getroffen wird, manchmal spielen > auch ganz andere Gesichtspunkte die entscheidende Rolle. Sollte der > Experte aber irgendwann gar keinen Einfluss mehr auf die Wahl der > Sprache haben würde sich natürlich die Frage stellen, ob es sich dann > überhaupt noch lohnt, Experte zu werden. Da muß ich Dir leider recht geben. Ich muß jetzt mein Programm (Objectpascal, ca.200TZeilen) auch auf C#/.Net umschreiben, weil das grad in ist. Versteht zwar keiner denn das Programm funktioniert. Aber ich bekomme halt meine Brötchen von meinem Arbeitgeber und solche Entscheidungen werden einige Gehaltsstufen weiter oben getroffen.
Zeno schrieb: > Da muß ich Dir leider recht geben. Ich muß jetzt mein Programm > (Objectpascal, ca.200TZeilen) auch auf C#/.Net umschreiben, weil das > grad in ist. Versteht zwar keiner denn das Programm funktioniert. Aber > ich bekomme halt meine Brötchen von meinem Arbeitgeber und solche > Entscheidungen werden einige Gehaltsstufen weiter oben getroffen. Damit, wenn du mal nicht mehr bist jemand anderes deinen Code pflegen kann? Damit dein Code auch auf kommenden Betriebssystemen läuft?
Marc S. schrieb: > jemand anderes deinen Code pflegen kann? C#-Code pflegen??? Marc S. schrieb: > Damit dein Code auch auf kommenden Betriebssystemen läuft? Auf kommenden Betriebssystemen hat C# und .NET absolut keine Relevanz mehr.
T.roll schrieb: > Auf kommenden Betriebssystemen hat C# und .NET absolut keine Relevanz > mehr. aber vermutlich mehr als Objectpascal
Marc S. schrieb: > Zeno schrieb: >> Da muß ich Dir leider recht geben. Ich muß jetzt mein Programm >> (Objectpascal, ca.200TZeilen) auch auf C#/.Net umschreiben, weil das >> grad in ist. Versteht zwar keiner denn das Programm funktioniert. Aber >> ich bekomme halt meine Brötchen von meinem Arbeitgeber und solche >> Entscheidungen werden einige Gehaltsstufen weiter oben getroffen. > > Damit, wenn du mal nicht mehr bist jemand anderes deinen Code pflegen > kann? > Damit dein Code auch auf kommenden Betriebssystemen läuft? Also das sind vermutlich die allerletzten Argumente für C#/.NET Was in den meisten Fällen eher von oben kommt: 1.) Da steht MS dahinter, das kann nicht schlecht sein. 2.) Die anderen machen das auch so. 3.) Alles was gut is, is zwangsweise closed Source und bestenfalls auch noch kostenpflichtig. Nicht dass die Kombination schlecht wäre, aber grad in höheren Gehaltsstufen und bei älteren Semestern hört man diese "Argumente" immer und immer wieder... Dass es sowas wie Python jetzt auch schon... 25? Jahre gibt interessiert da keinen. :)
Vincent H. schrieb: > Also das sind vermutlich die allerletzten Argumente für C#/.NET > > Was in den meisten Fällen eher von oben kommt: > 1.) Da steht MS dahinter, das kann nicht schlecht sein. > 2.) Die anderen machen das auch so. > 3.) Alles was gut is, is zwangsweise closed Source und bestenfalls auch > noch kostenpflichtig. was hätte man denn für alternativen? Java - da ist die Zukunft auf dem Desktop nicht absehbar C++ - wenn man keine umfangreiche Standardbibliothek braucht und alles von Hand machen will und dabei doch wieder einiges beachten muss, wenn man Plattformunabhängig sein will. Javascript? Diverse Scriptsprachen (Ruby usw.)? .net wird von MS auch unter Linux unterstützt. So schlecht ist die Wahl gar nicht.
Marc S. schrieb: > Damit dein Code auch auf kommenden Betriebssystemen läuft? Es gibt Object-Pascal Compiler für alle gängigen Unixe und Prozessorplattformen, das ist also kein Argument.
Bernd K. schrieb: > Es gibt Object-Pascal Compiler für alle gängigen Unixe und > Prozessorplattformen, das ist also kein Argument. und wird es auch weiterentwickelt?
Peter II schrieb: > Bernd K. schrieb: >> Es gibt Object-Pascal Compiler für alle gängigen Unixe und >> Prozessorplattformen, das ist also kein Argument. > > und wird es auch weiterentwickelt? Ja.
Bernd K. schrieb: >> und wird es auch weiterentwickelt? > Ja. von wem, gibt es eine Organisation die das macht? Wiki liefert nichts aktuelles.
Peter II schrieb: > Bernd K. schrieb: >>> und wird es auch weiterentwickelt? >> Ja. > > von wem, gibt es eine Organisation die das macht? Wiki liefert nichts > aktuelles. https://www.openhub.net/p/freepascal ~100 Commits pro Monat, 35 Core Developer, Tendenz stabil bis steigend. Community sehr aktiv.
:
Bearbeitet durch User
Bernd K. schrieb: "Object Pascal .. und wird es auch weiterentwickelt?" > https://www.openhub.net/p/freepascal > ~100 Commits pro Monat, 35 Core Developer, Tendenz stabil bis steigend. > Community sehr aktiv. Finde ich auch. In Sachen Beteiligung braucht sich das Lazarus-IDE Forum wirklich nicht zu verstecken. Da kann sich die SharpDevelop Community als Beispiel noch eine Scheibe abschneiden (selbst der schläfrig wirkende Delphi-Treff). Da würde ich mir keine Sorgen um die Zukunft machen. Da ist die Frage doch eher, was aus einst Borland-, dann Embarcadero-, nun Idera- "Kommerz-Delphi" mal wird, nachdem es erst kürzlich an einen neuen Besitzer verscherbelt wurde: forum.lazarus.freepascal.org/index.php/topic,29906.0.html
Peter II schrieb: > Java - da ist die Zukunft auf dem Desktop nicht absehbar Ich würde es kürzer formulieren: Java ist tot. > C++ - wenn man keine umfangreiche Standardbibliothek braucht und alles > von Hand machen will und dabei doch wieder einiges beachten muss, wenn > man Plattformunabhängig sein will. > Javascript? Das meinen einige ersthaft... "Studie: Java, C und JavaScript sind die Top-Sprachen im Internet der Dinge" http://www.heise.de/newsticker/meldung/Studie-Java-C-und-JavaScript-sind-die-Top-Sprachen-im-Internet-der-Dinge-3175329.html und nicht nur für/im IoT siehe Node.js und anderes Zeug aus der JS-Ecke. > Diverse Scriptsprachen (Ruby usw.)? > > .net wird von MS auch unter Linux unterstützt. So schlecht ist die Wahl > gar nicht. Und MS hat Compiler, Frameworks etc. pp. unter OSS-Lizenz(en) 1) freigegeben: https://github.com/dotnet http://www.dotnetfoundation.org/ 1) afaik steht dort alles unter Apache License 2.0
Joschua C. schrieb: > keine Laufzeitumgebung Die Runtime Library packt der Linker dazu. Nur mal so angemerkt. ;-)
RTL schrieb: > Joschua C. schrieb: >> keine Laufzeitumgebung > > Die Runtime Library packt der Linker dazu. Nur mal so angemerkt. ;-) Die "Runtime Library" ist keine Laufzeitumgebung mit virtueller Maschine, die einen Interpreter oder Just-in-Time-Compiler enthält. Warum man bei der libc oft von "Runtime Library" spricht, hab ich eh noch nicht verstanden. Werden die anderen Libs etwa nicht zur Laufzeit benutzt?
Arc N. schrieb: >... > Das meinen einige ersthaft... > "Studie: Java, C und JavaScript sind die Top-Sprachen im Internet der > Dinge" > http://www.heise.de/newsticker/meldung/Studie-Java-C-und-JavaScript-sind-die-Top-Sprachen-im-Internet-der-Dinge-3175329.html > und nicht nur für/im IoT siehe Node.js und anderes Zeug aus der JS-Ecke. > Wenn man den Heise-Artikel aufmerksam durchliest sieht man den Hinweis darauf, daß die Umfrage innerhalb der Eclipse community stattfand und somit der Fokus auf Java und C++ nicht verwundert.
Rolf M. schrieb: >... > Warum man bei der libc oft von "Runtime Library" spricht, hab ich eh > noch nicht verstanden. Werden die anderen Libs etwa nicht zur Laufzeit > benutzt? Mehr braucht ein C-Programm nicht um mit dem OS zu kommunizieren. Ist nicht viel was da geboten wird, aber genug um Speicher und I/O zu abstrahieren. Das Konzept erlaubt sehr kleine executables, halt das Gegenteil einer VM.
Marc S. schrieb: > Damit, wenn du mal nicht mehr bist jemand anderes deinen Code pflegen > kann? > Damit dein Code auch auf kommenden Betriebssystemen läuft? Was hat die Wartbarkeit mit der Programmiersprache zu tun. Es gibt nur 2 Gründe warum das so gemacht werden soll 1. Es ist eine Art Konzernrichtlinie, die aber von Leuten kommt die mit Softwareentwicklung nichts am Hut haben, aber es steht halt MS dahinter und da muß es gut sein. 2. Weil der der da jetzt mit machen soll und später auch das Programm pflegen soll zu bequem ist sich in eine andere Programmiersprache einzuarbeiten. Da ist es besser wenn sich der "Alte" in C# einarbeitet. Zeno
Zeno schrieb: > Was hat die Wartbarkeit mit der Programmiersprache zu tun. Nichts direkt, es geht eher um die Popularität, also wie viele Leute du auf dem Markt findest die den Code warten können. Siehe zum Beispiel hier: http://www.tiobe.com/tiobe_index http://redmonk.com/sogrady/2016/02/19/language-rankings-1-16/ http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages http://pypl.github.io/PYPL.html C# ist bei allen auf platz 5, Objectpascal ist bei einem auf platz 11, bei den anderen nicht mal im Ranking.
Marc S. schrieb: > Nichts direkt, es geht eher um die Popularität, also wie viele Leute du > auf dem Markt findest die den Code warten können. Ich behaupte mal daß jemand der sich in so einer einfachen und klaren Sprache wie Object-Pascal nicht zurechtfindet so jemand wird auch mit keiner anderen Programmiersprache irgendwas zustande bringen. Object-Pascal ist nicht wie Brainfuck oder dergleichen. Es verwendet auch keine abgehobenen Paradigmen wie Haskell bei denen man sich erstmal ein paar Semester Gruppentheorie reinziehen muss bevor man versteht warum es in Haskell erlaubt ist ein Hello World zu schreiben. Es ist ne ganz normale bodenständige imperative objektorientierte Sprache mit strengen statischen Typsystem und schön viel Boilerplate, fast so störrisch wie Java, nur ungefähr 100 mal leichtgewichtiger (Systemsprache, keine VM), und insgesamt eleganter und lesbarer (kontextfreie Grammatik), also insgesamt absolut nix neues oder gar abschreckendes für den durchschnittlichen Enterprise-Codiersklaven. Wer damit nicht zurecht kommt hat auch mit C# nix am Hut. </meinung>
:
Bearbeitet durch User
Bernd K. schrieb: > Ich behaupte mal daß jemand der sich in so einer einfachen und klaren > Sprache wie Object-Pascal nicht zurechtfindet Das sehe ich genauso. Ohne jetzt zu verallgemeinern mußte ich immer wieder fest stellen, daß viele C- (C++, C#) Programmierer nicht bereit sind mal über den Tellerrand zu schauen und sich mal mit was anderen zu beschäftigen. mittlerweile meinen viele mit C# lassen sich alle Probleme lösen weil es von MS so suggeriert wird. Wenn ich aber bedenke, das der junge Kollege seit einem Jahr sich an dem Programm versucht und derzeit maximal 10% der Funktionalität des bestehenden Programmes geschafft hat und das bei einem äußert instabilen Programm (ich bringe das neue Prog. mit 2 Mausklicks zum Absturz und zwar so das es danach neu installiert werden muß), dann ist Programmierung mit C# wohl doch nicht so effizient bzw. einfach insbesondere dann wenn es sehr komplex wird. Natürlich hat C# auch Features die ich persönlich gut finde, beispielsweise die recht aussagekräftigen Fehlermeldungen, was bei einem Just in Time Compiler allerdings auch kein Hexenwerk ist. Ebenso das Datenbinding ist eine feine Sache wenn man es mal geschnallt hat. Was viel schwerer wiegt ist der Overhead den ich C# und der .Net Umgebung mit mir rum schleppen muß. Das .Net Framework schlägt mit einigen 100MB zu Buche und ich brauche es selbst für ein einfaches "Hello World" auf der Console. Ist nicht sehr effizient und man merkt das auch bei den Ladezeiten. Ich bin nach wie vor für native Exe'n. Ist alles meine persönliche Meinung die natürlich nicht repräsentativ ist. Das darf auch jeder gern anders sehen. Zeno
Bernd K. schrieb: > Es verwendet auch keine abgehobenen Paradigmen wie Haskell bei denen > man sich erstmal ein paar Semester Gruppentheorie reinziehen muss > bevor man versteht warum es in Haskell erlaubt ist ein Hello World zu > schreiben. Nicht die Gruppentheorie, sondern die Kategorientheorie sollte man sich dazu reinziehen und innerhalb der Kategorientheorie insbesondere den Begriff der Monade: https://de.wikipedia.org/wiki/Kategorientheorie https://de.wikipedia.org/wiki/Monade_%28Kategorientheorie%29 Aber auch nur dann, wenn man an den mathematischen Hintergründen interessiert ist. Für das bloße Verständnis braucht man die nicht unbedingt. Das nur so am Rande ;-)
Zeno schrieb: > mittlerweile meinen viele mit C# lassen sich alle Probleme lösen weil es > von MS so suggeriert wird. Wenn ich aber bedenke, das der junge Kollege > seit einem Jahr sich an dem Programm versucht und derzeit maximal 10% > der Funktionalität des bestehenden Programmes geschafft hat und das bei > einem äußert instabilen Programm (ich bringe das neue Prog. mit 2 > Mausklicks zum Absturz und zwar so das es danach neu installiert werden > muß), sorry, dann hat einer keine Ahnung was er macht. Warum sollte man das Programm neu installieren müssen? Es wird vermutlich nur eine kaputte Konfiguration irgendwo liegen, mit der es nicht zurecht kommt. Wenn jemand nicht Programmieren kann, dann hilft auch .net nicht weiter - das stimmt. > Was viel schwerer wiegt ist der Overhead den ich C# und der .Net > Umgebung mit mir rum schleppen muß. für ein Programm mag das stimmen, wenn ich aber 20 Programme auf den PC habe die alle das Framework nutzen sieht es schon besser aus. Im System32 liegen weit über 100mbyte DLLs rum, das ist das Framework für die nativen Programme. > Ist nicht sehr effizient und man merkt > das auch bei den Ladezeiten. welche Ladezeiten?
Peter II schrieb: > von wem, gibt es eine Organisation die das macht? Wiki liefert nichts > aktuelles z:B. Embacadero (früher Borland)
Peter II schrieb: > sorry, dann hat einer keine Ahnung was er macht. Warum sollte man das > Programm neu installieren müssen? Es wird vermutlich nur eine kaputte > Konfiguration irgendwo liegen, mit der es nicht zurecht kommt. Keine Ahnung was der Kollege bis jetzt gemacht hat, ich habe bis jetzt das alte noch gepflegt, - wir müssen ja weiterhin arbeitsfähig sein, das prog wird weltweit eingesetzt. Warum das Teil dann nicht mehr startet weiß keiner, selbst der der es verbockt hat. Ist mittlerweile das 3. Update wo das so ist. So ein Scheiß ist mir noch nie passiert weder mit div. Basics, Objectpascal, C++ oder Python. Was mir aber aufgefallen ist, das C# Progs die bei uns eingesetzt werden schon häufiger abstürzen als die alten nativen. Warum das so ist weis ich nicht. Ich denke mal schon, das da viel zu viel unnötiger Ballast mit geschleppt wird. Zeno
Peter II schrieb: > Im System32 liegen weit über 100mbyte DLLs rum, das ist das Framework > für die nativen Programme. Das hat aber nichts mit den nativen Programmen an sich zu. Wenn das Windows braucht dann ist das eine Systemsache. Ich kann ja ein Programm auch für Linux oder OSX übersetzen, was mit Lazarus kein Problem darstellt, und dann haben diese DLL's definitiv keine Bedeutung. Wie das jeweilige System die FEnster zeichnet ist dem nativen Programm egal - es gibt nur den Befehl dazu. Zeno
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.