Hallo zusammen, bezugnehmend auf diesen Thread: Beitrag "Delphi: For-Schleifen und Timer" Prinzipiell möchte ich auf die Diskussion am ende zu sprechen kommen. Ich baue Frequenzumrichter und möchte in naher Zukunft mit Delphi Anwendersoftware schreiben, womit man die Umrichter parametrieren kann. Jetzt lese ich in dem Thread, dass Delphi nicht zukunftsicher ist. Ist da was dran? Ich verstehe den .net Einwand nicht, kann mich da wer aufklären? Warum ist C# besser und was ist der Unterschied zwischen C++ und C#? Vielen Dank!
.NET: M$ gebunden Wenn es zukunftssicher sein soll, nimm normales C.
Der Thread ist von 2008 und Delphi wird immer noch weiterentwickelt. Frage beantwortet? :-) Über die Zukunft von .NET wird zur Zeit viel spekuliert: http://www.heise.de/developer/meldung/Nur-noch-HTML-und-JavaScript-Windows-8-verunsichert-NET-Entwickler-1255775.html http://www.heise.de/developer/artikel/Windows-8-HTML5-und-die-Folgen-fuer-NET-1267153.html Letztendlich ist doch alles geeignet womit Du dein Ziel erreichst und was nicht heute schon offensichtlich das tote Pferd von morgen ist.
danke für die schnellen Antworten und die links. Ja, ich habe mich schon mit dem Embacadero RAD Studio XE auseinander gesetzt und wollte es bestellen. Mit Delphi lässt sich auf jeden fall recht einfach und mit wenig Zeit für die Einarbeitung genau das realisieren, was ich brauche. War halt dennoch etwas verunsichert als ich den Thread gelesen hatte.
Chris (Gast) schrieb: ... > Über die Zukunft von .NET wird zur Zeit viel spekuliert: Leute könnt ihr eigentlich alle nicht mal richtig lesen, statt immer die beiden gleichen Links hier sinnentlehrt zu kommentieren? .NET ist und bleibt ein zentraler Bestandteil des Windows OS und der Ausbau einer Skriptsprache kann das nicht ersetzen, es sei denn, Windows schrumpft irgendwann zu einem Web-Tablett-ichKlickMalWasAn-OS. Solange man aber Applikationen auf Windows entwickelt UM DAMIT AUCH ZU ARBEITEN (und nicht nur zu surfen wie auf Tabletts) wird und muss es ein gut ausgebautes API geben und die alte Win32-API ist nun mal überholt und Museumsreif. Und schon aus Rückwärtskompatibilitätsgründen muss .NET weiter gepflegt werden. Der Rest ergibt sich auch den gerne zitierten Links wenn ihr mal mehr als nur die Überschrift lest, nämlich die Zusammenfassung. "JavaScript und .NET? Nimmt man nun all die genannten Faktoren zusammen, ergibt sich ein relativ überschauberes Bild: HTML5 und JavaScript werden mittel- bis langfristig XAML und C# als Sprache für die UI-Logik ablösen. UI-Techiken wie Windows Forms, WPF und Silverlight werden im Hinblick auf plattform- und geräteunabhängige Entwicklung zu Bürgern zweiter Klasse. .NET und C# werden die Grundlage für ein serviceorientiertes und damit statusloses Backend bilden, das mit HTTP, REST und XML oder JSON auf Basis von AJAX und WebSockets angebunden wird. IIS Express, SQL Server CE und Azure bilden die Grundlage für das Hosting dieses Backends und stellen zugleich sicher, eine Desktop- zu einer Web- oder einer mobilen Anwendung zu migrieren. Parallelisierung von Code ist das wesentliche Werkzeug, um die zukünftige Skalierbarkeit einer Anwendung zu gewährleisten. C# 5.0 wird vermutlich die Async CTP integrieren und hierfür neue Werkzeuge und Schlüsselwörter zur Verfügung stellen. JavaScript wird als funktionale Sprache eine wichtige Ergänzung zu C# werden, speziell auch im Bereich der Parallelisierung, da die objektorientierte Programmierung hierbei an ihre Grenzen stößt." Quelle: http://www.heise.de/developer/artikel/Windows-8-HTML5-und-die-Folgen-fuer-NET-1267153.html?artikelseite=4
.... schrieb: > Leute könnt ihr eigentlich alle nicht mal richtig lesen, statt immer die > beiden gleichen Links hier sinnentlehrt zu kommentieren? .NET ist und > ... Dies ist eine objektive Einschätzung der Zukunft von .NET, die ich mir eigentlich von Heise gewünscht hätte. Vielen Dank und Respekt an den Autor.
Wenn du erst einsteigst nimm evtl. Lazarus + FreePascal. Delphi ist ja nicht gerade billig.
>Der Thread ist von 2008 und Delphi wird immer noch weiterentwickelt. >Frage beantwortet? :-) Griechenland ist pleite und wird immer noch weiterentwickelt. Frage beantwortet?
.... schrieb: > muss es ein gut ausgebautes API geben und die alte Win32-API ist > nun mal überholt und Museumsreif. Die Win32-API ist die native Schnittstelle zum OS, .Net ist nur ein Schichtkuchen, der darauf aufsetzt.
.... schrieb: > Chris (Gast) schrieb: > > ... > >> Über die Zukunft von .NET wird zur Zeit viel spekuliert: > > Leute könnt ihr eigentlich alle nicht mal richtig lesen, statt immer die > beiden gleichen Links hier sinnentlehrt zu kommentieren? .NET ist und > bleibt ein zentraler Bestandteil des Windows OS und der Ausbau einer > Skriptsprache kann das nicht ersetzen, es sei denn, Windows schrumpft > irgendwann zu einem Web-Tablett-ichKlickMalWasAn-OS. Solange man aber > Applikationen auf Windows entwickelt UM DAMIT AUCH ZU ARBEITEN (und > nicht nur zu surfen wie auf Tabletts) wird und muss es ein gut > ausgebautes API geben und die alte Win32-API ist nun mal überholt und > Museumsreif. Und schon aus Rückwärtskompatibilitätsgründen muss .NET > weiter gepflegt werden. Der Rest ergibt sich auch den gerne zitierten > Links wenn ihr mal mehr als nur die Überschrift lest, nämlich die > Zusammenfassung. > > "JavaScript und .NET? > > Nimmt man nun all die genannten Faktoren zusammen, ergibt sich ein > relativ überschauberes Bild: > > HTML5 und JavaScript werden mittel- bis langfristig XAML und C# als > Sprache für die UI-Logik ablösen. UI-Techiken wie Windows Forms, WPF und > Silverlight werden im Hinblick auf plattform- und geräteunabhängige > Entwicklung zu Bürgern zweiter Klasse. Langfristig vielleicht, wenn man versucht alles über einen Kamm zu scheren und dann in Kauf nimmt in jedem Fall nicht die beste, sondern nur eine bestenfalls mittelmäßige Lösung zu erhalten. Und der Autor übersieht das MS mit Razor schon einen VB/C# + HTML-Hybriden hat. Es muss also nicht ausschließlich JavaScript + HTML werden. Des weiteren werden die Gerätehersteller allen voran Apple versuchen genau diese Entwicklung zu verhindern. Wenn alle Apps auf allen Geräten laufen und gleich aussehen, gäbe es kein Alleinstellungsmerkmal mehr und somit keinen Grund mehr dies zu einer Kaufentscheidung zu machen. > .NET und C# werden die Grundlage für ein serviceorientiertes und > damit statusloses Backend bilden, das mit HTTP, REST und XML oder JSON > auf Basis von AJAX und WebSockets angebunden wird. Darauf würde ich auch nicht wetten. Warum soll bspw. ein simpler Integer erst in Text umgewandelt, dann in XML/JSON, HTTP, TCP/IP und Ethernet verpackt, dann auf der anderen Seite entpackt, konvertiert und verarbeitet zu werden und die Antwort dann wieder in Text, XML/JSON, HTTP, TCP/IP und Ethernet verpackt und beim Client erneut entpackt werden um wieder in die Binärdarstellung konvertiert zu werden um dann endlich verarbeitet werden zu können. Schwachsinn. Die Server könnten dagegen leicht zu "dummen" Datenservern werden ohne den XML/JSON/HTTP-Overhead. Letztlich könnten sogar die Browser eingestampft werden, da sie bei entsprechendem App-Angebot nicht mehr benötigt würden (z.Z. sieht man viele Apps die nur die Funktionalität einer Webseite nachbilden, warum dann noch die Webseite?). Wie sinnvoll diese Varianten sind, ist eine andere Frage. > JavaScript wird als funktionale Sprache eine wichtige Ergänzung zu > C# werden, speziell auch im Bereich der Parallelisierung, da die > objektorientierte Programmierung hierbei an ihre Grenzen stößt." JavaScript kann wie eine funktionale Sprache verwendet werden (es enthält die notwendigen Konstrukte), ist aber geradezu das Paradebeispiel dessen, was man nicht als Programmiersprache haben will: Es ist (fast) write-only, selbstmodifizierend, extrem stark typisiert (nur ein einziger Typ), usw. und genauso wenig/viel funktional/objektorientiert wie C#/C++/D/Delphi irgendwas. Hinzu kommen bei JS die fehlenden Controls, das fehlende Databinding, die schlechte Unterstützung von Threads, der fehlende/nicht standardisierte Zugriff auf Geräte Objektorientierte Programmierung stößt auch nicht bei der Parallelisierung an ihre Grenzen, außer der Autor versteht den Unterschied zw. den engl. Begriffen Parallelism und Concurrency, wie viele andere, nicht. http://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/ > Quelle: > http://www.heise.de/developer/artikel/Windows-8-HTML5-und-die-Folgen-fuer-NET-1267153.html?artikelseite=4 Danke für den Link, ein FBler mehr den man guten Gewissens seinen Konkurrenten empfehlen kann... Zum Thema: Selbst wenn Borland oder wie auch immer die Firma jetzt heißt irgendwann mal den Betrieb einstellt, die Erfahrungen mit einer imperativen, objektorientierten Sprache, kann man immer weiterverwenden (die meisten anderen Sprachen unterscheiden sich nur durch ihre Syntax, der größte Unterschied sind die notwendigen Frameworks/Bibliotheken). Windows 7 wird von MS noch bis 2020 supported, Windows 8 noch länger d.h. läuft die Software, hätte man genügend Zeit sie anzupassen, falls es notwendig wird. p.s. falls sich jemand wundern sollte, warum hier nicht C# angepriesen wird: Delphi, die VCL und C#, .NET sind alle maßgeblich von Anders Hejlsberg entwickelt worden und sind sich ziemlich ähnlich...
Rufus Τ. Firefly (rufus) (Moderator) schrieb: .... schrieb: >> muss es ein gut ausgebautes API geben und die alte Win32-API ist >> nun mal überholt und Museumsreif. > Die Win32-API ist die native Schnittstelle zum OS, Ja. > .Net ist nur ein > Schichtkuchen, der darauf aufsetzt. NEIN, EBEN NICHT! (ein oft gemachter Denkfehler!) .NET setzt nicht "einfach nur" auf der Win32-API auf. NET bringt vielmehr seine eigene UMFASSENDE STANDARDBIBLIOTHEK mit, die BCL (Base Class Library), die selbst bereits als Managed Code vorliegt und die ist (inzwischen) sehr umfassend. Der Prozessor unabhängige IL-Code (eine stack-orientierte Assemblersprache) wird anders als bei JAVA zudem NICHT INTERPRETIERT, sondern stückweise DIREKT vom extrem schnellen JIT-Compiler in MASCHINENCODE übersetzt, dabei aber zusätzlich während der Ausführung von der CLR (der Laufzeitumgebung) auf Korrektheit und Integrität überprüft (eben gemanaged). Der so vom VES (Virtual Execution System) aus dem IL-Code übersetzte Maschinencode wird NATIV ausgeführt (deswegen ist die Gegenüberstellung in C++ = nativ und C# = "nicht nativ" sprich irgendwie "lahm" schlicht FALSCH. Der Unterschied hierbei zu Compilaten wie deren von C++ ist nur das die Übersetzung sowohl VOR als auch WÄHREND der Programmausführung erfolgen kann. Zusammen mit der Überwachung durch das CLR besteht damit (je nach dem in der Auswirkung) ein kleiner Nachteil in der Ausführungsgeschwindigkeit gegenüber dem Compilat eines C++ Programms. Dafür gewinnt man deutlich mehr Sicherheit und die geht halt wie immer im Leben auf Kosten der Geschwindigkeit. Wenn du alle möglichen Sicherheitsabfragen in dein C/C++/Delphi Programm einbaust (d.h. Rückgabewerte konsequent immer überprüfst) ist es u.U. auch spürbar langsamer als das gleiche Programm ohne diese Prüfung. Wobei .NET unabhängig von der Programmiersprache natürlich auch mit Delphi, F#, Eiffel oder sonst was anprogrammiert werden kann (habe als Beispiel halt mal willkürlich die Platzhirsche C++ vs. C# gewählt). .NET untersützt also beliebige Programmiersprachen im Unterschied zu JAVA. MS hat mit der Einführung von C#/.NET das bisherige Komponentenmodell COM/COM+ abgelöst, natürlich besteht letzteres aber noch. Und wie Arc Net (arc) (jetzt muss ich aufpassen, der Nick klingt wie eine weitere Programmiersprache ;)) geschrieben hat läuft der Support für Windows 7 bis 2020. Solange wird es also minimum .NET geben und so schwierig ist es auch nicht wenn man in C#/.NET mal fitt ist sich auch in was anderes wie JAVA/C++ oder sonstwas objektorientiertem reinzufinden.
.... schrieb: >> .Net ist nur ein >> Schichtkuchen, der darauf aufsetzt. > > NEIN, EBEN NICHT! (ein oft gemachter Denkfehler!) .NET setzt nicht > "einfach nur" auf der Win32-API auf. NET bringt vielmehr seine eigene > UMFASSENDE STANDARDBIBLIOTHEK mit, die BCL (Base Class Library), die > selbst bereits als Managed Code vorliegt ... Da hast Du was falsch verstanden. Es ist vollkommen wurscht, wie .Net arbeitet, ob das interpretiert wird, ob es eine noch so tolle Standardlibrary ist, ob es handgedengelter Assembler oder superdupertoller von Hochleistungscompilern übersetzter Maschinencode ist -- es kommuniziert mit dem Betriebssystem über die Win32-API. Und damit ist es ein Schichtkuchen, der zwischen dem auf .Net aufsetzenden Programm und der Win32-API liegt. Wenn per .Net eine Datei aufgemacht wird, wird irgendwann die Win32-Funktion CreateFile aufgerufen. Wenn per .Net ein Fenster geöffnet wird, wird üblicherweise* die Win32-Funktion CreateWindow aufgerufen. Und so zieht sich das Grundkonzept durch die gesamte .Net-Schicht. Geht auch nicht anders, solange das Betriebssystem nicht selbst durch was anderes ersetzt wird, muss mit dem Betriebssystem kommuniziert werden, und das geschieht nunmal durch die native API, die das Betriebssystem Anwendungsprogrammen zur Verfügung stellt. Und das ist auch unter Windows 7 die Win32-API (resp. die auf 64 Bit aufgebohrte Variante davon). Das Schichtkuchen-Konzept trifft auf echte C++-Klassenbibliotheken wie Qt, wxWidgets und die MFC exakt genauso zu, ein Differenzierungsgrad ist die Schichtstärke, die bei der MFC am dünnsten ist, gefolgt von wxWidgets und dann Qt. *) Üblicherweise, weil dieser vergurkte Kram mittlerweile sein komplett eigenes Fensterhandling innerhalb echter Windows-Fenster verpackt; wenn man sich mal den Aufbau von z.B. Visual Studio 2010 genauer ansieht. (Damit habe ich mich beschäftigt, weil von Hause aus das Scrollrad mit diesem Hochleistungsprodukt annähernd komplett unbrauchbar ist, und die Hilfsmittel, die bei normalen Programmen das kaputte Scrollradhandling von Windows reparieren, an Visual Studio 2010 scheitern. Ich brauche den Kram aber für meine Arbeit)
.net ist der vorläufige 64-Bit-Höhepunkt der alten Geschichte: Windows 98 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor; written by a 2 bit company that can't stand 1 bit of competition.
wenn dir Delphi gefällt nimm Lazarus ;-) (wie auch schon von Thomas (Gast) vorgeschlagen) läuft auf linux/osx/win/wince/... wenn es (auch) auf android/iphone/ laufen soll wirds schwieriger dann wird es eher java werden müssen.. wegen der win32-api vs. .NET diskussion hier (ist ja recht "lustig" ) einfach mal nach MONO suchen..
Mal ne blöde Zwischenfrage von jemandem der seit geraumer Zeit nicht mehr die Windows API programmieren musste :-) Ist die Win32 API bzw das .net Geraffel eigentlich 64Bit oder noch alles 32Bit? Sprich, kann ich mal auf die Schnelle eine sehr große (z.B. 1Gig) große XML Datei einlesen und komplett in entsprechende Objekte verpackt im Speicher halten wenn ich genug Speicher habe, das heisst mehr als 2 oder gar 4 Gigabyte Speicher für eine Anwendung allozieren? Danke
ja es gibt (seit kurzem) auch ein 64bit windows ;-) ABER: auch 32bit windows Programme können (natürlich) files größer 4gbyte bearbeiten.. aber (natürlich) nicht im ganzen im Speicher behalten ein win32 Programm kann immer nur maximal (theoretisch) 4gbyte Speicher allozieren 1gbyte große files im Speicher zu behalten, wäre/ist aber kein Problem..
Udo Schmitt schrieb: > Ist die Win32 API bzw das .net Geraffel eigentlich 64Bit oder noch alles > 32Bit? Hängt vom verwendeten Windows ab. Unter 32-Bit-Windows gibt es nur die 32-Bit-Ausführung, unter 64-Bit-Windows gibt es für 32-Bit-Programme die 32-Bit-Ausführung, und für 64-Bit-Programme eine 64-Bit-Ausführung.
Ich schließe mich auch der Lazarus-Empfehlung an. Hier die Links: Das Forum: http://www.lazarusforum.de/ Die neueste Snapshot-Versionen: ftp://ftp.hu.freepascal.org/pub/lazarus/ So kann ein in Lazarus geschriebenes Programm aussehen: Beitrag "EleLa - Elektronik Lagerverwaltung" Lazarus funktioniert mindestens genauso gut, wenn nicht sogar besser als Delphi XE. Seit Delphi 7 bin ich vor einigen Jahren auf Lazarus umgestiegen und verwende seither kein Delphi mehr. (Einmal musste ich ein Delphi-7 Projekt auf Delphi-XE hoch ziehen, konnte es leider nicht auf Lazarus portieren, daher kenne ich auch die XE Version) Nahezu gratis gibt es bei Lazarus die Möglichkeit die EXE unter Linux zu kompilieren (Besonderheiten von Linux, Pfade usw. berücksichtigen). C oder C# ist IMMER gebunden an das Betriebssystem. Bzw. um Sourcen auf Windows/Linux hinzu bekommen kann man eigentlich nur eine Console-App schreiben. (Siehe z.B. OpenOCD) Das Linux würde ich mir nicht verbauen, denn so wie man hier sieht (Anzahl Downloads) wird Linux sehr viel genutzt! Beitrag "Re: EleLa - Elektronik Lagerverwaltung"
Robert L. schrieb: > ABER: auch 32bit windows Programme können (natürlich) files größer > 4gbyte bearbeiten.. Das ist mir schon klar, wobei die Standard C Funktion fread() zumindest früher bei Datein > 2G buggy war. Von Microsoft wurde mir damals empfohlen die Win32 API zu benutzen (toll portabel!) Robert L. schrieb: > 1gbyte große files im Speicher zu behalten, wäre/ist aber kein Problem.. Ich rede davon ein komplexes XML komplett incl. etwaiger Indices und Hashtabellen als Objektbaum bzw. als Listen von Objekten im Speicher zu halten zwecks schnellem Suchen und Filtern der Daten. Da reichen bei einer physisch 1G großen Datei die max. 2G Speicher ganz schnell nicht mehr aus.
Rufus Τ. Firefly schrieb: > Hängt vom verwendeten Windows ab. Unter 32-Bit-Windows gibt es nur die > 32-Bit-Ausführung, unter 64-Bit-Windows gibt es für 32-Bit-Programme die > 32-Bit-Ausführung, und für 64-Bit-Programme eine 64-Bit-Ausführung. Genau das war die Frage: Gibt es ein extra .net64? Wie heisst das und was habe ich wenn ich das kostenlose Visual Studio hole. Bei Office geht ja wohl die Empfehung von MS sogar dahin die 64 Bit Version nur dann zu nutzen wenn man es unbedingt braucht, und ansonsten weiter auf die 32 Bit Version zu setzen. Wie verbreitet ist denn die 64 Bit Programmierung schon?
@udo soll ich es für dich g.. naja egal http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6523 genau so wie es eben auch java für x64 gibt z.Z: haben 64bit programme unter windows praktisch keine vorteile (ausgenommen die typischen "Speicherfresser" Videobearbeitung, 3D CAD usw.) deine XML frage ist nicht zu beantworten.. nachdem objekte im speicher meist binär abgelegt sind xml dagegen TEXT ist und mit SEHR SEHR viel overhead (jede feldbezeichnung ist ja 1000fach identisch vorhanden) brauch XML files oft viel mehr platz auf der festplatte als im speicher... deine aufgabenstellung würd ich auch eher dahingehend "lösen" die XML datei ein eine datenbank einzulesen..
Naja, um etwas Salz in die Wunde zu streuen, sag ich es mal so: Es war vor vielen Jahren ein Fehler, überhaupt mit C anzufangen. Natürlich haben viele Leute es gepriesen, daß sie mit C solche Dinge wie eine recht strikte Typunterscheidung, relativ viele Buchstaben bei den Schlüsselwörtern und die tunliche Vermeidung von Seiteneffekten endlich losgeworden sind. Endlich die große Freiheit, beim Programmeschreiben die Sau rauslassen zu können. C ist das Karnickel. Wenn ich dran denke, was es alles schon an Verbesserungsversuchen gegeben hat, C, Ansi-C, C++, Java, C#, vielleicht demnächst ein neues C** oder C$$ ? Nun, C und seine Kinder sind etabliert und seine Geburtsfehler sind nicht mehr zurückzudrehen. Man muß damit leben oder sich eben Mühe geben, solche Dinge wie Delphi, Freepascal, Lazarus, MSeide nicht untergehen zu lassen. Es kommt auf uns an. So herum wird ein Schuh draus. W.S.
C ist gut, aber nur solange man Hardware nah programmieren tut, also Mikrocontroller. Und da es irgend wann einmal Windows gab und darin dann auf einmal Fenster, spätestens dann war C (und deren Kinder) nicht mehr wirklich eine optimale Programmiersprache. Alleine die Trennung zwischen Ressource eines Windows-Fensters und dem Quellcode ist ein Hindernis das mindestens 20% Mehrarbeit bedeutet (aber das verstehen die C-Progger nicht, da sie noch nie was anderes gesehen haben).
Rufus Τ. Firefly schrieb: > Udo Schmitt schrieb: >> Ist die Win32 API bzw das .net Geraffel eigentlich 64Bit oder noch alles >> 32Bit? > > Hängt vom verwendeten Windows ab. Unter 32-Bit-Windows gibt es nur die > 32-Bit-Ausführung, unter 64-Bit-Windows gibt es für 32-Bit-Programme die > 32-Bit-Ausführung, und für 64-Bit-Programme eine 64-Bit-Ausführung. Es gibt (gab) sie sogar dann noch in dreifacher Ausführen, einmal ANSI, einmal Unicode und einmal 'automatisch'... C ist garnicht verkehrt. Viele meinen aber, wegen einiger Schwächen gleich eine neue Sprache konstruieren zu müssen. DAS ist der Knackpunkt.
Nimm für GUI-Sachen Lazarus oder TCL/TK. Wenn Du C oder C++ wirklich kannst, und nicht nur glaubst dass Du es kannst, dann kannst Du das auch machen. Da es aber nur ein paar hundert Leute auf der Welt gibt, die das können, ist Lazarus wohl doch die bessere Wahl. Bei C(++) hast du halt das Problem, dass es keine gute Standardbibliothek gibt. Falls Du Dir nicht sicher bist, ob Du C(++) kannst, poste hier mal ein kleines Programm, welches das 2. Wort eines der Eingabe wieder ausgibt. Sprich ich gebe "Dies ist ein Testtext" ein, und das Programm gibt "ist" aus. Ich kann auch C(++) nicht vollständig, aber ich kenne die Fehler, die da meistens gemacht werden. C# hat hingegen keine Zukunft. Das ist ein Standard der nur unter Windows so wirklich funktioniert. Im Prinzip so wie Delphi.
Christian Berger schrieb: > Nimm für GUI-Sachen Lazarus oder TCL/TK. Eine weitere Alternative zu Delphi ist MSEide+MSEgui: http://developer.berlios.de/projects/mseide-msegui/ Im Gegensatz zu Lazarus benützt MSEgui keine externe Widget-Bibliothek, sondern ruft direkt die Graphik-Schnittstelle des Betriebsystems auf (GDI32 auf Windows und X11/xlib auf Linux). In Arbeit ist eine MSEgui-Schnittstelle zu OpenGL. MSEgui Programme können sowohl mit Free Pascal als auch mit Delphi 7 kompiliert werden. Mittels MSEide können auch GNU-toolchain basierte C-Projekte entwickelt werden. Beispielsweise programmiere ich meine AVR32 Systeme mit MSEide und GCC und die PC-gestützten Bediener-Tools mit MSEgui. Ebenfalls mit Erfolg eingesetzt wird MSEide+MSEgui in Datenbank-Projekten, z.B. das soeben erschienene Acosys V4: http://www.acosys.co.id/ Einige Videos sind hier: http://www.youtube.com/watch?v=JdcUSg1b4_w&feature=mfu_in_order&list=UL Das Erscheinungsbild der MSEgui widgets ist in hohem Masse parametrierbar, die widgets in den Videos entsprechen wohl dem indonesischen Geschmack. ;-) Durch den Verzicht auf eine zwischengeschaltete externe widget-Bibliothek ist das gewählte Aussehen der MSEgui Programme auf Linux und Windows falls gewünscht absolut identisch oder kann durch Änderung der Parameter angepasst werden. Martin
Delphi war auch vor 10 Jahren nicht zukunftsicher. Es ist so, an den UNIs wurde früher nicht C/C++ gelehrt, sondern Pascal. Aus dem Grund gibt es in der E-Technik Branche immer noch viele Delphi Fans. Wenn man es richtig machen sollte, muss man mindestens 3 gängige Programmiersprachen beherschen. C gehört auf jeden Fall dazu. Wenn man gewisse Vorkentnisse hat, kann man jede andere "gängige" Sprache leicht erlernen. So war es für mich leicht dank C PHP zu erlernen, dank MySQL LINQ unter C# und dank C# Java zu programmieren...
Eigentlich wollte ich mich bei soviel Voreingenommenheit hier nicht mehr zur Sache äußern, aber manche Postings fordern das ja geradezu heraus. Christian Berger (casandro) schrieb: > Nimm für GUI-Sachen Lazarus oder TCL/TK. Für Windows keine gute Wahl. > Wenn Du C oder C++ wirklich kannst ... Der TE hat gefragt, wo der Unterschied zwischen C# und C++ ist und da schreibst du er solle C++ nehmen? Das ist für mich keine angemessene Antwort. > Bei C(++) hast du halt das Problem, dass es keine gute > Standardbibliothek gibt. Für C# gibt es diese. > C# hat hingegen keine Zukunft. Das ist ein Standard der nur unter > Windows so wirklich funktioniert. Im Prinzip so wie Delphi. Meine Güte, tut mir leid, aber das ist ein so hirnloser Satz. Deine ganze "Hilfe" hier geht mal wieder (wie so oft) davon aus, der Fragesteller hätte mit Windows so rein gar nichts zu tun. Woher willst du das eigentlich wissen? Was ist denn Zukunft für DICH? Glaubst du deine Empfehlung für TCL/TK hat überhaupt die Lebenszeit, die ein .NET Framework noch für Minimum die nächsten 10 eher 20 Jahre aufbringt? Ist dir eigentlich bewusst, das der Marktanteil von Windows alle Zukunft für sich bereits inne hat? Glaubst du die vielen Linux-Distributionen die es gibt würden in 10 Jahren so noch bestehen wie augenblicklich? Woher nimmst du die Gewissheit, dass es ein QT in 5 Jahren noch gibt und dieses auch noch weiter geflegt wird? Diese Gewissheit gibt es nicht. Wenn überhaupt, dann hat .NET noch die besten Chancen recht alt zu werden auf dem PC, ganz einfach, weil die Win32-API auch bereits seit Urzeiten existiert und MS nicht so leicht bestehende Zöpfe kappt, sondern immer etwas neues hinzustrickt. Rufus Τ. Firefly (rufus) (Moderator) schrieb: .... schrieb: >>> .Net ist nur ein >>> Schichtkuchen, der darauf aufsetzt. >> >> NEIN, EBEN NICHT! (ein oft gemachter Denkfehler!) .NET setzt nicht >> "einfach nur" auf der Win32-API auf. NET bringt vielmehr seine eigene >> UMFASSENDE STANDARDBIBLIOTHEK mit, die BCL (Base Class Library), die >> selbst bereits als Managed Code vorliegt ... > Da hast Du was falsch verstanden. Nein habe ich nicht. Was ich schrieb kannst du in der iX Spezial 1/03 von 2003 nachlesen vom Autor Michael Stal, der u.A. damals Chefredakteur der Zeitschrift Java Spektrum war. Ein sehr guter und ausführlicher Bericht. > Es ist vollkommen wurscht, wie .Net > arbeitet, Wer glaubt dies sei "WURSCHT" schreibt höchstens "KÄSE". > ob das interpretiert wird, Es ist ein RIESEN Unterschied, ob "nur" interpretiert oder aber nativer Code just in Time compiliert und dann sofort ausgeführt wird. Als jemand der Ahnung von der Materie hat solltest du das wissen. > ob es eine noch so tolle > Standardlibrary ist, Gerade DIE macht den großen Unterschied zur Win32-API. Die hat nämlich sehr viel mehr (nennen wir es) Anwenderfunktionen (besser Anwenderklassen) zu bieten, als die alte Win32-API hat. > ob es handgedengelter Assembler oder > superdupertoller von Hochleistungscompilern übersetzter Maschinencode > ist -- es kommuniziert mit dem Betriebssystem über die Win32-API. Dort wo die Funktionen vorhanden sind werden sie genutzt. Da ist nichts verwerfliches dran. Die Win32-API sind bei Kernfunktionen bereits geladene DLLs und .NET besteht ebenfalls aus DLLs. Sowohl .NET kann die API aufrufen als auch umgekehrt. Das ist keine Einbahnstrasse, das ist ein sehr ausgefuchstes System, was sich MS da Anfang Millenium ausgedacht hat. Auch ein Framework wie QT hat nicht die Windows-API nachgestrickt, sondern bedient sich derer. > Und > damit ist es ein Schichtkuchen, der zwischen dem auf .Net aufsetzenden > Programm und der Win32-API liegt. Es existiert mit, auf und neben der API. API-Funktionen können von .NET aus auch direkt aufgerufen werden, wenn es einen Bedarf dafür gibt (oder man das möchte). "Microsoft Win32 to Microsoft .NET Framework API Map" http://msdn.microsoft.com/en-us/library/aa302340.aspx > Wenn per .Net eine Datei aufgemacht wird, wird irgendwann die > Win32-Funktion CreateFile aufgerufen. Ja das stimmt. Du wirst es nicht glauben, ich hab mir mal den Spass erlaubt mit dem OllyDbg die C# Methode FileMode.Create zu tracen (die Express-Version von C# bei mir gibt das selber leider nicht her, ich muss wohl aufstocken ;)). Hat mich sehr viel Zeit gekostet, da sich der Debugger (noch) keine Breakpoints (beim Restart) merkt (oder ich ihn nicht gescheit bedienen kann, weil eher selten benutzt). Nachdem der mein ca. 10 Zeilen C# Programm zum Erstellen einer Datei hat durch alle möglichen DLLs hüpfen lassen (springt dabei immer wieder mal ins Modul der CLR) landete der letzte und entscheidene CALL in der mscorlib_ni (gehört zu .NET) von wo aus dann der Aufruf KERNEL32.CreateFileW geschieht. Die DLL braucht nicht geladen zu werden, ist sowieso geladen. Man sieht sehr schön den Filenamen, das Setzen der Zugriffsrechte usw. Ich hab das aber auch nicht anders erwartet. Inzwischen hab ich rausbekommen, dass auch die Sourcen von .NET frei downloadbar sind unter http://referencesource.microsoft.com/netframework.aspx so dass man das wohl auch etwas bequemer hätte haben können, wohl aber nicht mit der C# Express-Version. > Wenn per .Net ein Fenster > geöffnet wird, wird üblicherweise* die Win32-Funktion CreateWindow > aufgerufen. Und so zieht sich das Grundkonzept durch die gesamte > .Net-Schicht. Geht auch nicht anders, solange das Betriebssystem nicht > selbst durch was anderes ersetzt wird, muss mit dem Betriebssystem > kommuniziert werden, und das geschieht nunmal durch die native API, die > das Betriebssystem Anwendungsprogrammen zur Verfügung stellt. Und das > ist auch unter Windows 7 die Win32-API (resp. die auf 64 Bit aufgebohrte > Variante davon). Du weißt genau, dass Windows niemals so einfach die bestehende API hinwegfegen könnte, ohne die berühmte Rückwärtskompatibilität über den Haufen zu werfen. Die API hat auch noch obsolete Win16 Funktionen, ist also ein Hort der zeitlichen Constanz wenn man so will. Deswegen läuft ja auch noch so viel von der alten Software unter Windows (mit Ausnahmen). > Das Schichtkuchen-Konzept trifft auf echte C++-Klassenbibliotheken wie > Qt, wxWidgets und die MFC exakt genauso zu, ein Differenzierungsgrad ist > die Schichtstärke, die bei der MFC am dünnsten ist, gefolgt von > wxWidgets und dann Qt. Auf .NET bezogen ist die Zeit die mit dem Verwalten d.h. Prüfen des Codes verbracht wird viel länger, als ein (bloßer) Aufruf einer Win32-Funktion. Beim tracen aus dem Beispiel oben ist mir das aufgefallen wie oft in die CLR eingeteten und wieder ausgetreten wird. Aber selbst das spielt für eine Funktion wie der Dateierstellung mit Sicherheit keine Rolle, weil die sowieso nicht ein paar Millionen mal pro Sekunde aufgerufen wird. Die Flaschenhälse die es da bestimmt auch gibt liegen woanders (auch nicht in der Fensterverwaltung, von der auch ein Teil auf der Grafikhardware geschieht). Für den Anwender - hier speziell dem Programmierer - spielt das alles erst mal eine völlig untergeordnete Rolle. Für den ist viel wichtiger, dass er möglichst ohne zuviel Gehirnakrobatik und Hintergrundwissen sein Programm um graphische Elemente aufpeppen kann, sprich Windows-Konform hinbekommt. Dem Threadersteller ging es um Umrichter und nicht um den Wettbewerb "wie schaffe ich die messbar schnellste GUI im Land". Was glaubst du denn warum immer mehr Skriptsprachen auf dem Desktop sich breitmachen? Aus reinen Performancegründen bestimmt nicht. Da dürfte es das ganze XML Zeugs ja gar nicht geben. Proprietär ist nicht nur immer eine Lizenzfrage, Proprietär war in der Vergangenheit auch meist Binär dateicodiert (bestes Beispiel ist das Cadsoft-Dateiformat). Nicht-proprietär setzt hingegen auf Text-codierte Dateien und Skriptverarbeitung in XML und sonstwas. Da wird auch bewusst immer öfter Performance (Möglichkeit) aufgegeben, um Offenheit und Umgänglichkeit für Jedermann zu erreichen (neben anderen Vorteilen). Wo soll da noch der Nachteil bei .NET sein? Der Zug geht nunmal in diese Richtung und die Anwendungen wo es mal wirklich auf extreme Performance ankommt sind doch eh die Ausnahme. Das meiste was der Rechner noch immer macht ist warten, warten und nichts als warten (kommt ja auch der Stromrechnung zu gute, nicht wahr?! ;-)).
Und was soll ich jetzt damit anfangen? Erst widersprichst Du mir, dann belegst Du genau das, dem Du ein paar Sätze vorher widersprochen hast. .Net setzt wie Qt, die MFC, wxWidgets, das VCL-Konzept aus der Delphi-Ecke, egal was auch immer schlussendlich auf der Win32-API auf.
(es gibt/gab übrigens auch ein delphi .NET für alle die lieber Pascal anstelle von C# programmieren ;-) inzwischen Delphi Prism XE .. (ist aber glaub ich nur mehr "pascal ähnliche" sprache?) damit könnte man .NET anwendungen für MacOSX/linux und windows schreiben.. (scheinbar auch iPhone?) ich möchte (diesbezpgich) auch nochmal auf MONO hinweisen (ich weiß nicht warum hier so oft behauptet wird, .NET wäre nur für windows...)
Bis Delphi 3 habe ich noch die Umgebungen gekauft. Da ich eventuell wieder einsteigen möchte ist die Frage: gibt es heute überhaupt noch ein Äquivalent zu den damaligen Umgebungen?
ja lazarus ;-) das ist optisch noch ziemlich Delphi 3/5/7 like ... hat auch einen delphi->lazarus "converter" falls du alte Programme Konvertieren willst: bis Delphi 2007 sollte es "halbwegs" problemlos gehen Delphi 3 Projekte zu compilieren (weil NICHT Unicode) ab delphi 2009 ist dann unicode..
Geiler Rant von unserem anonymen Gast. 1. Microsoft hat schon viele Techniken mal einfach so von heute auf morgen eingestellt, die sie vorher noch als "Zukunftstechniken" gepriesen haben. Und bei .net ist es dann halt vorbei. Das kann ohne Microsoft nicht überleben. Warum glaubst Du, dass Microsoft bei den wichtigen Anwendungen wie dem Internet Explorer, kein .net verwendet? 2. TCL/TK gibts seit 1988 und wird heute immer noch entwickelt und benutzt. Damals gab es unter Windows gerade mal Windows 2. Neuestes Feature: Überlappende Fenster.
Christian Berger (casandro) schrieb: > Geiler Rant von unserem anonymen Gast. Und was hat das mit dem Inhalt meines Postings zu tun? > 1. Microsoft hat schon viele Techniken mal einfach so von heute auf > morgen eingestellt, die sie vorher noch als "Zukunftstechniken" > gepriesen haben. Tja, ist eben eine innovative Firma und keine Schnarchnase. Schließlich hat MS auch c# erfunden und zum ECMA Standard verholfen und c# ist eine ideale Programmiersprache für das .NET Framework. Es passt also alles schön zusammen. Herz was willst du mehr?! > Und bei .net ist es dann halt vorbei. Was soll da vorbei sein? .NET gibt es jetzt seit bald 10 Jahren. > Das kann ohne > Microsoft nicht überleben. Mach dir mal nix draus, aber MS lebt noch lange genug, da kannst du drauf wetten. Ganz abgesehen davon, gibt es .NET Techniken auch für andere Plattformen, auch wenn dir das ein Dorn im Auge ist. Damit hast du dich abzufinden. > Warum glaubst Du, dass Microsoft bei den > wichtigen Anwendungen wie dem Internet Explorer, kein .net verwendet? Könnten sie sicher machen, aber warum glaubst du sollte MS jetzt plötzlich schon lange bestehende BS-Teile "ummodeln"? Dazu besteht doch gar kein Grund oder Anlass. .NET ist leistungsfähig genug für so ziemlich jede Anwendung und dort wo es vielleicht mal einen Performance Engpass gibt lässt man sich eben was einfallen. > 2. TCL/TK gibts seit 1988 und wird heute immer noch entwickelt und > benutzt. Damals gab es unter Windows gerade mal Windows 2. Neuestes > Feature: Überlappende Fenster. Dann denke mal darüber nach warum eine "so tolle und leistungsfähige App" es nicht geschafft hat für sich den Markt zu erobern. Genau genommen winken selbst die meisten Linuxer ab und wenden sich lieber QT zu.
>ja >lazarus ;-) >das ist optisch noch ziemlich Delphi 3/5/7 like ... ... und das ist auch gut so. Ich finde diese Oberfläche viel übersichtlicher. Die neue Delphi-Oberfläche ist lange nicht so übersichtlich und viel zu viele fette Fenster die man braucht und einem den Bildschirm wegnehmen. Die alte Oberfläche, da konnte man die einzelnen Fenster überlagern.
"Schließlich hat MS auch c# erfunden und zum ECMA Standard verholfen" Genauer gesagt war Hewlett-Packard und Intel auch beteiligt. Auszug aus Wikipedia http://de.wikipedia.org/wiki/C-Sharp "C# greift Konzepte der Programmiersprachen Java, C++, Haskell, C sowie Delphi auf. C# zählt zu den objektorientierten Programmiersprachen und unterstützt sowohl die Entwicklung von sprachunabhängigen .NET-Komponenten als auch COM-Komponenten für den Gebrauch mit Win32-Applikationen."
.... schrieb: >> "Schließlich >> hat MS auch c# erfunden und zum ECMA Standard verholfen" > > Genauer gesagt war Hewlett-Packard und Intel auch beteiligt. > Auszug aus Wikipedia http://de.wikipedia.org/wiki/C-Sharp "In January 1999, Anders Hejlsberg formed a team to build a new language" und "C#'s principal designer and lead architect at Microsoft is Anders Hejlsberg" 1) Davor hatte MS intern ein "Simple Managed C" entwickelt 1) Zusammen mit "...Hewlett-Packard and Intel Corporation co-sponsored the submission of specifications ... to the standards organization" ist die deutsche Wikipedia-Version, "Microsoft reichte ... zusammen mit Hewlett-Packard und Intel C# bei der Normungsorganisation Ecma International zur Normung ein.", freundlich gesagt, sinnentstellend formuliert 1) http://en.wikipedia.org/wiki/C_Sharp_(programming_language)
.... schrieb: > Der Prozessor unabhängige IL-Code (eine stack-orientierte > Assemblersprache) wird anders als bei JAVA zudem NICHT INTERPRETIERT, > sondern stückweise DIREKT vom extrem schnellen JIT-Compiler in > MASCHINENCODE übersetzt, dabei aber zusätzlich während der Ausführung > von der CLR (der Laufzeitumgebung) auf Korrektheit und Integrität > überprüft (eben gemanaged). und > Es ist ein RIESEN Unterschied, ob "nur" interpretiert oder aber nativer > Code just in Time compiliert und dann sofort ausgeführt wird. Als jemand > der Ahnung von der Materie hat solltest du das wissen. Tja, das hast du auch die letzten 10 Jahre Java-Entwicklung verschlafen. Reine Interpretierung gibts beim normalen Java-System auch nicht mehr. Dein so toller JIT-Compiler existierte zuerst für Java. Gerade Java hat das ganze Forschungsgebiet der Binary Translation ziemlich gepusht und eine Menge an neuen Konzepten aufgebracht. Laufzeitchecks sind da übrigens auch drin und "normal". MS hat das ganze System einfach nur gut kopiert und ein paar Dinge verbessert, einzigartig ist das Konzept der CLR aber nicht. Ebensowenig wie das Konzept der virtuellen Maschine von Java/C# erfunden wurde. BTW: Ich finde diese Sprach-(Flame)wars immer sehr spassig. Typischerweise sind die mit der "nur X taugt was, alles andere ist Bullshit"-Haltung diejenigen, gar keinen Überblick haben und ihre eigene Weltsicht übers Brett vorm Kopf hinaus extrapolieren. Gute Programmierer erkennt man IMO daran, dass sie ein "Portfolio" von verschiedenen Sprachen mit verschiedenen Konzepten (und damit Anwendungsgebieten) haben und die jeweils passende dann einsetzen. Klar kann es Lieblinge geben, aber genau eine (egal wie gut beherrscht und penetrant vertreten) ist armselig.
"Portfolio" ... He ho! Willst du behaupten, dass aus den Profi-WIFI-AMS-Kursen keine echten vollständigen Vollprofis rauskommen? "In 3 Monaten vom Nubbler zum IT-Profi mit .NET - Ihr Kurs beim AMS" - da kommen 99% aller Selbständigen aka Freelancer in Österreich her! Das sind waschechte Profis mit MSCE Zertifikat® ... Abgesehen davon, die einzig ernstzunehmende Sprache ist LISP!
Georg A. (Gast) schrieb: > Tja, das hast du auch die letzten 10 Jahre Java-Entwicklung verschlafen. > Reine Interpretierung gibts beim normalen Java-System auch nicht mehr. Ich bezog mich auf einen Artikel aus dem Jahre 2003 der Zeitschrift iX. Das es seit dem inzwischen eine enorme Weiterentwicklungen gibt ist klar, betrifft aber auch C#/.NET (ist auch nicht mehr bei v1.0). Es war auch nicht meine Absicht mich hier groß über Java auszulassen. Im Kern ging es um eventuelle Geschwindigkeitsvorteile von rein nativen Frameworks wie QT (primär C++) gegenüber einem (wie ich es ausdrücken würde) gemischt- teil- oder (weil gemanaged) bedingt-nativem Framework wie .NET (multible Programmiersprachen, vorzugsweise C#). Java hat längst einen nicht zu vernachlässigenden Marktanteil erreicht, was aus der Sicht von Performancegründen eher ein Argument für als gegen .NET ist, da JAVA wohl kaum als sonderlich performanter gilt als .NET-Compilate und schon gar nicht als C++ via QT-Compilate. > Dein so toller JIT-Compiler existierte zuerst für Java. Gerade Java hat > das ganze Forschungsgebiet der Binary Translation ziemlich gepusht und > eine Menge an neuen Konzepten aufgebracht. Laufzeitchecks sind da > übrigens auch drin und "normal". Gewiss, MS hat sich meines Wissens auch stark mit dem Thema JAVA auseinandergesetzt, hatte aber wohl für sich gute Gründe entdeckt, warum man nicht mit auf den Java-Zug aufspringt (auch firmenpolitische, marktstrategische Gründe). > MS hat das ganze System einfach nur gut > kopiert und ein paar Dinge verbessert, Warum sagst du nicht gleich, sie hätten alles abgekupfert? Kannst du dir eigentlich überhaupt vorstellen was in einem komplexen Framework wie .NET und dem Erfinden einer Sprache wie C# für gewaltige Ressourcen drinstecken? Glaubst du das hat ein Frickler über nacht auf die Beine gestellt?! > einzigartig ist das Konzept der > CLR aber nicht. Ebensowenig wie das Konzept der virtuellen Maschine von > Java/C# erfunden wurde. Du kannst bei Wikipedia nachlesen, dass C# sich schlauerweise die positiven Aspekte bestimmter Sprachen wie JAVA, C++ etc. zu eigen gemacht hat und bestimmte Bestandteile bewusst (aus Gründen der Sicherheit respektive Fehleranfälligkeit) weggelassen hat. Ich sehe da nichts verwerfliches dran, im Gegenteil, es ist gut und vernünftig aus dem Fehlerpotential bestehender Dialekte zu lernen. > BTW: Ich finde diese Sprach-(Flame)wars immer sehr spassig. Ich finde was ganz anderes. Ich finde es völllig daneben und lächerlich grundsätzlich alles was im Zusammenhang mit MS steht abzubashen und gleichzeitig alles was MS nicht zuzurechnen ist völlig kritikfrei zu sehen. Das ist weder ehrlich, noch klug, noch hilft es jemandem wie dem TE bei der Entscheidungsfindung - das ist einfach nur ideologisch und als solches meistens auch leicht zu entkräften. > Typischerweise sind die mit der "nur X taugt was, alles andere ist > Bullshit"-Haltung diejenigen, gar keinen Überblick haben und ihre eigene > Weltsicht übers Brett vorm Kopf hinaus extrapolieren. Und was meinst du was Leute machen, wenn sie Sätze raushauen wie ".NET hat keine Zukunft" oder "MS hat alles nur abgekupfert" oder "ist nicht plattformunabhängig, dann taugt es nicht" etc machen? Solche Äußerungen bedienen genau dieses (DEIN) Argument. Oder hast du irgendwo von mir gelesen, dass nur .NET was taugen würde? Wohl kaum. > Gute Programmierer > erkennt man IMO daran ... Es ging hier nicht darum wer gut programmieren kann und wer nicht. Das ist völlig irrelevant. Hier ging es um die Wahl der Mittel (des Werkzeugs). Im übrigen ist DIE RICHTIGE Programmiersprache immer die, die man selber am besten kann (das muss längst nicht die sein, die für ein Problem am besten geeignet ist). Jeder darf seine Vorlieben ausleben. Wer noch keine hat, dem darf man Tipps geben sich für das ein- oder andere zu entscheiden. Es muss noch nicht mal ein entweder-oder geben, es kann auch ein sowohl als auch geben. Viele Unterschiede liegen sowieso eher im Detail als im großen Gegensatz. Manche mögen dasjeilige Detail jedoch als großen Unterschied zu empfinden. Jeder wie er mag. Wenn wir das alles ein wenig berücksichtigen sind wir schon weiter und können uns ganz entspannt über solche Themen (im positivsten) Sinn des Wortes streiten. Einen "Flamewar" braucht es dazu nicht. Ein paar knackscharf formulierte Worte können aber dann und wann (wie ich finde) hilfreich sein. Bewusstes Bashen ist jedoch ein no go.
> Im übrigen ist DIE RICHTIGE Programmiersprache immer die, >die man selber am besten kann (das muss längst nicht die sein, die für >ein Problem am besten geeignet ist) scherz oder ? da fehlt wohl ein ;-) (ich hab zwar den Faden verloren, wer jetzt für und gegen .Net ist..) aber, wie weiter oben schon steht, wer programmieren KANN, hat sowieso keine problem sich innerhalb ein paar tagen/wochen auf eine andere programmiesprache einzulernen, und wir dies auch tun (müssen) noch was zum thema plattformunabhängigkeit.. sowas gibt es nicht sieht man schön an den JAVA apps für android (die ja alle 1:1 am iphone laufen ;-)... oder am PC ... (teilweise) laufen ja nicht mal die Telefon -Apps auf den Tablet mit "selben" betriebssystem...
nachtrag:
>sowas gibt es nicht
damit meinte ich: es hat nichts mit der SPRACHE zu tun
sondern WIE man programmiert...
(bzw. macht man ja nicht alles selber, also auch wie die frameworks die
man verwendet programmiert sind)
jenachdem ist ein TEIL von seinem programm dann
plattformunabhängig(er)..
.... schrieb: > Ich bezog mich auf einen Artikel aus dem Jahre 2003 der Zeitschrift iX. > Das es seit dem inzwischen eine enorme Weiterentwicklungen gibt ist... Zu dem Zeitpunkt gab es JITs für Java schon ca. 6 Jahre. Das HotSpot-Konzept, das dynamisch zwischen Interpretierung und JIT umschaltet, wurde von Sun schon 1999 vorgestellt. Öffentlich war da von .NET oder der CLR AFAIR noch gar nichts bekannt. > Warum sagst du nicht gleich, sie hätten alles abgekupfert? Kannst du dir > eigentlich überhaupt vorstellen was in einem komplexen Framework wie > .NET und dem Erfinden einer Sprache wie C# für gewaltige Ressourcen > drinstecken? Ja, kann ich durchaus. Allerdings war der Kraftaufwand für MS auch bitter notwendig, nachdem sie der Java-Hype so um '97 rum eiskalt erwischt hat. Sie waren vermutlich der Überzeugung, dass die JVM längerfristig auch Windows als OS überflüssig macht. Es gab ja dann auch relativ schnell auch ein MS-Java, das hatte AFAIR aber schon ein paar inkompatible Erweiterungen. Die riesige .NET-Infrastruktur hat ja dann noch ein Weilchen gedauert. > Glaubst du das hat ein Frickler über nacht auf die Beine gestellt?! Was ich glaube, tut hier nichts zur Sache. Es geht hier nur darum, dass deine Aussagen zu .NET (vs. Java) wenig mit der Realität zu tun haben. > Ich sehe da nichts verwerfliches dran, im Gegenteil, es ist gut und > vernünftig aus dem Fehlerpotential bestehender Dialekte zu lernen. Ich sehe da auch nichts verwerfliches, aber man wird doch auch mal sagen dürfen, dass hier keiner im luftleeren Raum arbeitet und MS erst recht nicht. Java hat zB. viel von C++ und Objective-C übernommen, die JVM hat viele Anleihen beim p-code genommen. BTW: Weder C# noch Java gehören zu meinen Lieblingssprachen.
Georg A. (Gast) schrieb: .... schrieb: >> Ich bezog mich auf einen Artikel aus dem Jahre 2003 der Zeitschrift iX. >> Das es seit dem inzwischen eine enorme Weiterentwicklungen gibt ist... > Zu dem Zeitpunkt gab es JITs für Java schon ca. 6 Jahre. Das > HotSpot-Konzept, das dynamisch zwischen Interpretierung und JIT > umschaltet, wurde von Sun schon 1999 vorgestellt. Öffentlich war da von > .NET oder der CLR AFAIR noch gar nichts bekannt. Ja und? Es ist überall nachzulesen, dass JAVA bei der Entwicklung von C#/.NET eine beachtliche Rolle gespielt hat. Dein Einwand hier ist ein Werfen von Nebelkerzen. >> Warum sagst du nicht gleich, sie hätten alles abgekupfert? Kannst du dir >> eigentlich überhaupt vorstellen was in einem komplexen Framework wie >> .NET und dem Erfinden einer Sprache wie C# für gewaltige Ressourcen >> drinstecken? > Ja, kann ich durchaus. Deswegen gebe ich auch auf deine Einlassung hier nichts. Sie ist nur von Neid und Missgunst motiviert. > Allerdings war der Kraftaufwand für MS auch > bitter notwendig, nachdem sie der Java-Hype so um '97 rum eiskalt > erwischt hat. Man wächst an seinen Gegnern. > Sie waren vermutlich der Überzeugung, dass die JVM > längerfristig auch Windows als OS überflüssig macht. Absolut dummes Zeug. > .. Die riesige .NET-Infrastruktur hat ja dann > noch ein Weilchen gedauert. Siehst du, daran kannst du ablesen wie komplex es ist ein solch großen FW wie .NET aus dem Boden zu stampfen. >> Glaubst du das hat ein Frickler über nacht auf die Beine gestellt?! > Was ich glaube, tut hier nichts zur Sache. Doch das tut es, denn deinen Glauben zur Sachlage hast du hier ja bereits geäußert. > Es geht hier nur darum, dass > deine Aussagen zu .NET (vs. Java) wenig mit der Realität zu tun haben. Na im Vergleich zu deinem missgönnenden Geschwurbel hier braucht sich mein wirklich Schriftgut nicht zu verstecken. >> Ich sehe da nichts verwerfliches dran, im Gegenteil, es ist gut und >> vernünftig aus dem Fehlerpotential bestehender Dialekte zu lernen. > Ich sehe da auch nichts verwerfliches, aber man wird doch auch mal sagen > dürfen, dass hier keiner im luftleeren Raum arbeitet und MS erst recht > nicht. Hättest du nur das gesagt, hätte auch keiner was dagegen geschrieben. Deine Sätze waren aber ganz anderer Natur. > Java hat zB. viel von C++ und Objective-C übernommen, die JVM hat > viele Anleihen beim p-code genommen. Siehst du, deswegen brauchst du JAVA nicht über den Klee zu loben und C++ hat die Objektorientiertheit auch nicht erfunden. > BTW: Weder C# noch Java gehören zu meinen Lieblingssprachen. Das darfst du halten wie du möchtest. BTW: Das alles führt zu nichts und um den TE geht es Leuten die hier gerne immer wieder alle möglichen historischen Entwicklungen ins Spiel bringen, um ein FW in Misskredit zu zerren, schon lange nicht mehr. Diese überflüssigen ideologischen Grabenkämpfe helfen niemanden bei der Orientierung in der Frage mit welcher Programmierumgebung man sich mal ein wenig näher beschäftigt.
> Diese überflüssigen ideologischen Grabenkämpfe helfen niemanden bei der > Orientierung in der Frage mit welcher Programmierumgebung man sich mal > ein wenig näher beschäftigt. Aber klar hilft das! Jetzt weiss der TE, wie es ist, wenn einäugige Hühner um ein Korn kämpfen. Als klar denkender Mensch weiss er jetzt, um welche Sprachen er besser einen Bogen macht :-)
@.... lass es bitte a) ist es OT b) kapiert sowieso keiner mehr (ich zumindest nicht) was du überhaupt willst.. ist Word, Exel, MySQL server, ... oder sonst irgend ein MS mayor produkt eigentlich mal nach .NET portiert worden ?!?!?
> b) kapiert sowieso keiner mehr (ich zumindest nicht) was du überhaupt > willst.. Richte deinen Appell an den Poster Georg A. (Gast), der unbedingt meint hier einen Grabenkrieg vom Zaun brechen zu müssen. > Als klar denkender Mensch weiss er jetzt, um > welche Sprachen er besser einen Bogen macht :-) Dass wären dann die Sprachen JAVA, C# und C++. Gerade die erfolgreichsten Programmiersprachen um die man einen Bogen machen soll. Sehr "sinnig". :-)
es gibt übrigens (scheinbar) auch einen "aktuellen" beitrag http://www.heise.de/developer/artikel/Java-versus-NET-962309.html allerdings wohl nur java vs. .NET und das geht (erwartungsgemäß) wohl unentschieden aus.. flameware ala amd<>intel, amd<>nvidia, diesel<>benzin... sind ja wohl kindergarten..
.... schrieb: > Deswegen gebe ich auch auf deine Einlassung hier nichts. Sie > ist nur von Neid und Missgunst motiviert. Nö, ich bin einfach nur über das Alter hinaus, in dem man von irgendwas "100%-Fan" sein und jeden Hype mitmachen muss. > Richte deinen Appell an den Poster Georg A. (Gast), der unbedingt meint > hier einen Grabenkrieg vom Zaun brechen zu müssen. Grabenkrieg? Ich fahr hier grad mit'm Ballon in 100m über den Gräben und knabber Popcorn... Du (....) erzählst einfach technischen Mist, und den wollte ich richtigstellen. Du hast rumgeschwurbelt, wie toll JITs bei .NET sind, im Gegensatz zum interpretierten Java. Dass das schon schon zu Einführung von .NET auch bei Java kein Thema mehr war, wusstest du ja offensichtlich nicht. Das kommt davon, wenn man selber im Graben sitzt und nicht mal den Kopf rausstreckt ;) Ich habe den starken Verdacht, dass du die Zeit, wo Java und die JITs aufgekommen sind, noch gar nicht so bewusst mitbekommen hast...
Georg A. schrieb: > .... schrieb: > >> Ich bezog mich auf einen Artikel aus dem Jahre 2003 der Zeitschrift iX. >> Das es seit dem inzwischen eine enorme Weiterentwicklungen gibt ist... > > Zu dem Zeitpunkt gab es JITs für Java schon ca. 6 Jahre. Wenn schon dann 3 Jahre (HotSpot ab 1999, .Net ab 2002)...Sun hatte die Technik dazu (ebenso wie die für HotSpot 1) 2)) mit den Strongtalk-Entwicklern eingekauft und dann das bessere System sterben lassen. Die Ideen dazu sind wesentlich älter (1960) und kommen, wie vieles was heute als modern verkauft wird, aus dem LISP Umfeld 3). 1) http://en.wikipedia.org/wiki/Strongtalk 2) http://en.wikipedia.org/wiki/HotSpot 3) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.3985&rep=rep1&type=pdf > Das > HotSpot-Konzept, das dynamisch zwischen Interpretierung und JIT > umschaltet, wurde von Sun schon 1999 vorgestellt. Öffentlich war da von > .NET oder der CLR AFAIR noch gar nichts bekannt. C# wurde 2000 vorgestellt, intern lief das Projekt (ASP.NET, CLR) seit 1997, C# wurde erst 1999 "gestartet" 4) Vorteile hat das Konzept allerdings bis heute weder bei Java noch bei C# gezeigt. 4) http://en.wikipedia.org/wiki/C_Sharp_(programming_language) > Ja, kann ich durchaus. Allerdings war der Kraftaufwand für MS auch > bitter notwendig, nachdem sie der Java-Hype so um '97 rum eiskalt > erwischt hat. > Es gab ja dann auch relativ schnell auch ein MS-Java, das hatte AFAIR aber > schon ein paar inkompatible Erweiterungen. Visual Studio 97 gab's wie der Name schon sagt ab 1997 und unterstützte Java (Visual J++ 1.1). Wenn sie kalt erwischt worden wären, hätten sie zu dem Zeitpunkt keine IDE und inkompatible Erweiterungen gehabt. > BTW: Weder C# noch Java gehören zu meinen Lieblingssprachen. und C++ bei mir auch nicht mehr... Robert L. schrieb: > ist Word, Exel, MySQL server, ... oder sonst irgend ein MS mayor produkt > eigentlich mal nach .NET portiert worden ?!?!? Abgesehen davon, dass auch .NET ein "Major Product" ist, warum sollte man mal eben so mehrere 10 Millionen SLOCs portieren? Beim aktuellen VS wurde dies z.T. gemacht (Oberfläche ist nun WPF) und insg. mittlerweile die Hälfte managed ~22 Millionen SLOCs 5). Andere Software von MS siehe 6) Und MS hat mit Singularity 7) (und davon abgeleitet Verve 8)) auch vollständige Betriebssystem in managed Code... Verve enthält keine einzige Zeile C und C++Code und ist vollständig verifiziert. 5) http://stackoverflow.com/questions/228024/what-major-applications-does-microsoft-sell-which-use-the-net-framework bzw. http://channel9.msdn.com/shows/Going+Deep/Rico-Mariani-Visual-Studio-Today-Tomorrow-and-Beyond/ 6) http://blogs.msdn.com/b/danielfe/archive/2005/12/16/504847.aspx (2005 waren es laut diesem Post min. 16 Millionen SLOCs) 7) http://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf 8) http://research.microsoft.com/pubs/122884/pldi117-yang.pdf > es gibt übrigens (scheinbar) auch einen "aktuellen" beitrag > http://www.heise.de/developer/artikel/Java-versus-... über die Artikel (auch den oben verlinkten) könnte man noch lange diskutieren (div. Fehler, Ungenauigkeiten etc.)
@ Robert L. (lrlr) Tja siehst du, der Poster gibt keine Ruhe. Was will man da machen? Georg A. (Gast) schrieb: > Nö, ich bin einfach nur über das Alter hinaus, in dem man von irgendwas > "100%-Fan" sein und jeden Hype mitmachen muss. So alt bisst du gar nicht, sonst würdest du hier diese Kinderei nicht abziehen. > Grabenkrieg? Ich fahr hier grad mit'm Ballon in 100m über den Gräben und > knabber Popcorn... Leute die Popkorn knabbernd dauernd andere Leute am Rechner anmachen erfüllen die Definition eines Trolls perfekt. > Du (....) erzählst einfach technischen Mist, und den wollte ich > richtigstellen. Wenn der Herr meinen. > .. schon zu Einführung von .NET auch bei Java .. Du hast einfach noch nicht mitbekommen, dass ich mich hier gar nicht großartig zu Java geäußert habe, bis auch den Vergleich aus der iX aus dem Jahre 2003 den ich hier einbrachte. Es ging um etwas ganz anderes. Nochmal damit auch du Schnarchnase es endlich mal kapierst: ICH VERWENDE KEIN JAVA! PUNKT. Mir ist Java sowas von egal, da kannst du dich noch weitere 10 Postings dran hochziehen und JAVA verteidigen was du nicht mal selber verwendenst. Das ist totale Idiotie. BITTE DEN THREAD HIER ENDLICH SCHLIEßEN! Begündung: Die Deppenposter nehmen hier einfach überhand.
Latten haben die schon noch alle, denn die brauchen sie um ihre Tassen im Schrank zu zerdeppern (wenn da noch eine heil ist) :-)
@Zwie Blum: Glückwunsch, das war der erste vernünftige Beitrag zu diesem Thema. Auf ARD läuft jetzt gleich noch der Hitchcock-Klassiker "Psycho". Kann man glatt vergessen gegen dem, was hier so abläuft.
Arc Net schrieb: >> Zu dem Zeitpunkt gab es JITs für Java schon ca. 6 Jahre. > > Wenn schon dann 3 Jahre (HotSpot ab 1999, .Net ab 2002)...Sun hatte die Hot Spot!=JIT. Hot Spot war die Antwort auf das Problem der "normalen" JITs, dass sie auch für nur einmal angesprungende Methoden den ganzen Übersetzungsaufwand haben. Gerade beim Startup und für GUIs war das eher lästig. Schon JDK1.2 (98 oder so) hatte einen JIT, ich hatte damals jedenfalls schon Benchmarks mit JIT vs. ohne gemacht. Inoffizielle JITs für Java gabs aber schon 96-97 (zB. Cacao, IBM hatte doch auch irgendwas, AFAIR sogar vor Sun). > Visual Studio 97 gab's wie der Name schon sagt ab 1997 und unterstützte > Java (Visual J++ 1.1). Wenn sie kalt erwischt worden wären, hätten sie > zu dem Zeitpunkt keine IDE und inkompatible Erweiterungen gehabt. Dass MS Trends schnell adaptieren und in 0,nix viel Code aus dem Boden stampfen kann, ist bekannt. Hat ja mit dem IE schon gut funktioniert ;) Ich denke aber nicht, dass das VM-Thema in dem Ausmass (oder überhaupt) in der strategischen Planung vorkam. Dass sie mit ihrem "eigenem" Java auch noch am Lizenz-Tropf (samt Patenten) von Sun hingen und sich Sun da auch nicht gerade nett aufgeführt hat, hat den Zwang für was eigenes nur noch verstärkt. .... schrieb: > Mir ist Java sowas von egal, da kannst du dich noch weitere 10 Postings > dran hochziehen und JAVA verteidigen was du nicht mal selber > verwendenst. Das ist totale Idiotie. Wenn pubertierende Fanboys Mist erzählen, finde ich eine kleine Korrektur durchaus angemessen. Sonst glaubts glatt noch jemand. Und ob ich jetzt Java verwende oder nicht, ändert daran nichts.
Georg A. (Gast) schrieb: .... schrieb: >> Mir ist Java sowas von egal, da kannst du dich noch weitere 10 Postings >> dran hochziehen und JAVA verteidigen was du nicht mal selber >> verwendenst. Das ist totale Idiotie. > Wenn pubertierende Fanboys Mist erzählen, finde ich eine kleine > Korrektur durchaus angemessen. Sonst glaubts glatt noch jemand. Und ob > ich jetzt Java verwende oder nicht, ändert daran nichts. Jeder hat seine Vorlieben, die Linux Fanboys haben die ihren und ich die meinen. Daran ist nichts verwerfliches. Ich habe niemandem etwas aufgezwängt. Ich hab mich hier überhauot nur zu Wort gemeldet, weil der .NET-Artikel von heise Developer ein einigen Schergen missbraucht wird um .NET als überholt darzustellen, was eine bewusste Falschdarstellung des Inhaltes ist. Mit der "Pupertät" muss ich dich leider enttäuschen, das ist lange her (länger als bei dir). Davon abgesehen hast DU hier diesen Kindergartenstreit vom Zaun gebrochen und noch dazu mit falschen Behauptungen gefüllt. Meine Aussagen kann jeder in der Quelle die ich angab nachlesen und die Quelle ist SEHR GUT. Das es zwischenzeitlich auch Entwicklung gegeben hat hab ich ebenfalls hier hinzugeschrieben. Insofern lügst DU hier anderen etwas vor, indem du meine Aussage bewusst in ein falsches Licht rückst, was ich als bösartig und hinterlistig empfinde. Es ist schon lustig mitzulesen, wie verzweifelt die Ideologen versuchen gegen C#/.NET, aber vor allem auch gegen Mono anzuschreiben und zwar wider jedes gute Argument, wie z.B. hier http://www.heise.de/open/news/foren/S-Re-Welchen-Grund-gibt-es-eigentlich-fuer-Mono-C/forum-161618/msg-16985455/read/ http://www.heise.de/open/news/foren/S-Re-Welchen-Grund-gibt-es-eigentlich-fuer-Mono-C/forum-161618/msg-16986889/read/ Aber es ist schon klar aus welcher Ecke das alles kommt. Wenn ein Debian-Sprecher bekannt gibt Mono nicht in die Standardinstallation mit aufzunehmen, aus Angst (siehe einige Kommentare), Mono könnte vielleicht beliebt werden und dem komplizierten C++ den Rang ablaufen, dann ist schon klar, dass gebasht und diffarmiert wird, von gewissen Agitatoren der Szene, was das Zeug hält. Wenn ich schon lese, Mono die wortwörtlich "umstrittene Programmierumgebung". Das ist genau so lächerlich wie dein Versuch hier .NET kleinzureden und als Abkupferrei darzustellen. Zum Glück aber bleibt das nicht unwiedersprochen wie man sieht. So jetzt hab' ich mich doch noch mal verleiten lassen. Mein Aufruf den Thread zu schließen bleibt bestehen.
.NET = geht net (feed the Trolls! - eine Aufforderung des Umweltministeriums)
Anmerkung : DELPHI XE2 : win 32 und Win 64, iOS, .... DELPHI XE3 (2012) : incl LINUX.... native cross plattformsupport
Haha, wie immer und lustich, die Zeit holt alles ein: Ironie in Reinstform: > Autor: .... (Gast) > Datum: 18.07.2011 17:50 > Chris (Gast) schrieb: >> ... >> Über die Zukunft von .NET wird zur Zeit viel spekuliert: >> ... > Skriptsprache kann das nicht ersetzen, es sei denn, Windows schrumpft irgendwann zu einem Web-Tablett-ichKlickMalWasAn-OS. > Solange man aber Applikationen auf Windows entwickelt UM DAMIT AUCH ZU ARBEITEN > (und nicht nur zu surfen wie auf Tabletts) wird und muss es ein gut ... ..und dann kam Win8 ... Wie sich sowas entwickeln kann. ;) (Hab den Beitrag eben erst durch Zufall entdeckt, und konnte mir nicht verkneifen, einen piep von mir zu geben)
Mit einem Web-Tablett kann man aber nicht arbeiten. Und Ja. Ich hab auch ein Tablett.
Keine Frage - mit einem Web-Tablett-ichKlickMalWasAn-*OS* auf einem Desktop-PC, welcher nach Möglichkeit noch nen Touchmonitor haben sollte aber auch nicht - und das wollte ich eigentlich damit ausdrücken ;)
An beiden Gerätearten kann man ne Maus anschließen. Win8 scheint mir aber noch überflüssiger als Vista zu sein.
Jeder Windowsentwickler weiss wie langsam .net ist. Mal eine xaml MessageBox aus einer MFC Applikation gestartet? Das dauert, bis die angezeigt ist. Schlimm! Aber MS ist noch viel schlimmer: Microsoft Shamepoint. Da lernt man erst mal wie langsam Webseiten sein können. ASP.NET!! Was da an unnötigem Ballast über die Leitung geht. Stromverschwendung! Da die Kunden alle mit der Geschwindigkeit ihres Intranets (Shamepoint!) unzufrieden sind, muss Microsoft etwas tun. Und was? Die Kunden bekommen eine Server Farm. Dafür müssen sie extra Lizenzen kaufen. Toller Trick, oder? Produkt ist schlecht. Kunde muss aufrüsten und noch mehr Geld ausgeben. Aus Scheisse Gold machen! Wer das kann, wird Milliardär.
Hallo,
als ziemlicher Computer- und Programmier-Laie habe ich diverse
GUI-Programmieroberflächen ausprobiert.
"Lazarus" ("Delphi"-Nachfolger) gefiel mir am besten:
Open-Source, "Frei" und "Cross-Compiling" für Windows und Linux möglich.
Damit gelangen mir am schnellsten recht ordentliche Ergebnisse.
A. Geigenberger
(Falls es jemand interessiert: Google: " MyMemoryDB ")
Ich hab ja bis vor kurzem in einer Firma gearbeitet in der ich ein kleines Softwareprojekt in Lazarus gemacht habe. Man merkt, dass die Kunden genau von den Sachen begeistert sind, die von Lazarus her rühren. Zum Beispiel haben wir da statisch gelinkte Programme. Sprich man hat unter Windows eine .exe-Datei und führt die einfach aus. Man muss keine .net-Umgebung oder so was nachinstallieren, sondern es geht einfach. Die x86-Linux, die Win32 und die MacOSX-Version laufen alle ohne Installation und sehen jeweils nativ aus, ohne dass man da groß Code ändern hätte müssen. Ach ja und die Windowsversion läuft ab Windows 2000, unter Win98 läuft die leider nicht mehr, wir haben da nicht groß nachgeforscht warum das so ist. Die Kunden wollen keine große Installationsorgie machen um eine Laufzeitumgebung zu installieren. Die wollen einfach nur das Programm ausführen.
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.