Ist es mit delphi aus?

[argonix]

Das ist das Problem: Es kommt GAR NICHTS dabei heraus. Würde es nicht Sinn machen, die Inhalte dieser ganzen Beiträge geschlossen in einem Brief an Borgear zu übermitteln? Das würde vielleicht nichts bringen, wäre aber dennoch ein Signal. Und eine Petition um endlich ein Delphi für MacOS zu bekommen gibt es ja auch schon. Auch sind ja wir alle Kunden oder potentielle Kunden von CodeGear. Da wäre es ja sinnvoll für CG sich auch nach dem Kunden zu richten.
Ich finde die Delphi-Entwickler sollten sich auch mal im Tiobe-Index die Statistik von Pascal ansehen. Pascal ist dank Lazarus zum ersten mal unter den Top-20 Programmiersprachen. Warum? Schlicht weil Lazarus unter fast allen Platformen läuft und günstiger ist als Delphi.

[christian_u]

Zitat:

Was sich als völlig falsch herausgestellt hat, oder wie soll man deinen Satz verstehen Grübelnd... ?

Ja hat es, damals sollte in 5 Jahren überall nur noch Thin Clients zu finden sein und der Desktop To sein.
Was ist heute ? 95% der Desktop Software ist Nativ.
Nirgends stehen Thin Clients.

Zitat:

Was genau hat jetzt .Net mit interpretiertem Code zu tun Mr. Green ?

.net ist interpretierter Code auch wenn es ein JIT Compiler ist er compiliert auch wärend der Ausführung ständig nach.

Zitat:

MSFT mit seiner enormen Manpower könnte wohl, wenn man wollte, einen JIT/AOT-Compiler entwickeln, der 90% der unmanaged Software an die Wand spielt.

Diese Aussage ist purer Blödsinn Nativer Code wird immer das schnellse sein was geht.

Zitat:

Was natürlich immer noch Ressourcen zieht, ist der Garbage Collector.

.net code is um den Faktor 20 langsamer als nativer code jeglicher art und du häls am garbage collector fest na toll.

Zitat:

Ein paar Sächelchen wie WPF und ClickOnce, vielleicht auch Mono oder CF könnten sich in den nächsten Jahren durchaus herumsprechen, dann wirst du von deinen Kunden "Warum ist Ihr Programm immer noch so hässlich-grau?" gehört bekommen. Und gegen sicherere (ich sage nur Plugins in AppDomains) und fehlerfreiere (vor allem im Vergleich zu C++ Wink) Software wird er ebenfalls nichts einzuwenden haben.

Warum sollte eine native Anwendung anders auschaun als eine .net Anwendung ?
Warum sollte ein .net programm fehlerfreier sein ? Wegen dem garbage Collector ? Na wunderbar Windows entfernt jetzt auch schon ungenutzte Resourcen die beim beenden einer Anwendung nicht freigegeben wurden wenn man sas nicht besser kann kann man also jetzt schon mit dem Speicher rumsauen wie man will.

Zitat:

Und was wäre in diesem Fall Deine einzige Chance als Win32-Entwickler, nicht den Bach runter zu gehen? Du musst Deine Anwendung nach Linux und MacOS portieren. Erste Wahl: .NET

Die erste Wahl um Anwendungen für MacOS zu schreiben ist sicherlich nicht .net und das wird sich NIE ändern.

[Daniel]

ui .. ich möchte darum bitten, sich zuerst weitere Fakten ( != Stammtisch-Meinungen) zum .NET-Framework anzueignen, bevor die Diskussion fortgesetzt wird. Selbst mir als Entwickler, der seine Knete mit nativen Programmen verdient, dreht sich gerade der Magen um bei dem, was ich da über das .NET-Framework lesen muss.


Aber "nativer Code" vs. "managed Code" ist nicht das Thema dieses Threads.

[mschaefer]

Hm Sag mal Daniel eigentlich hast Du zu Super IDE´s contra Delphi doch eine deutliche Meinung !

Grüße // Martin


PS: Delphi geht nicht unter! Wir wissen nur noch nicht was es in zehn Jahren dann ist.

[o0o]

hi leutz,...ich haette mal ne frage zu der ganzen sache^^

also ich bin jetzt nicht grad wild drauf auf .net umzusteigen da ich davon zer0 ahnung habe...mit delphi habe ich vor nem halben jahr angefangen und lohnt es sich eigendlich fuer die zukunft jetzt dass ich mit delphi weitermache?
nebnbei habe ich ein wenig mit asm angefangen da ich davon begeistert bin nur was wuerdet ihr mir empfehlen wie es weitergehen soll?

da sind jetzt so viele beitraege und ich blick da einfach nichtso durch deshalb die dumme frage jetzt

waere nice wenn mir jemand einen rat gebn koennte wie es am sinnvollsten fuer mich waere^^

da o0o

[Der_Unwissende]

Hi,
einen Rat zu geben ist kein Problem, das einzige was immer richtig ist (da hoffe ich mal widerspricht jetzt keiner) ist die Tatsache, dass man nie das eine Werkzeug finden wird. Delphi ist genauso wenig die eierlegende Wollmilchsau, wie es .Net ist (oder je sein wird) oder Java oder Haskell oder was auch immer.
Es gibt bestimmte Probleme, die lassen sich super in Delphi lösen, es gibt andere Probleme die lassen sich viel besser in einer anderen Sprache lösen.
Möchtest Du z.B. eigene Messsysteme mit einem eingebetteten OS bauen, so wird sich hier eine Kombination aus Windows und Delphi kaum anbieten, auch die Treiberprogrammierung ist nicht das wo Delphi seine Stärken hat und Webseiten werden lieber mittels PHP, ASP, JSP oder Perl erzeugt als mit Delphi. Ganz klar muss man hier sagen, dass alles immer auch in Delphi möglich ist, nur der Weg kann manchmal komplizierter / aufwendiger sein (versuch mal Alternativ RAD mit Java...).

Die "großen"/bekannten Sprachen haben in der Regel bestimmte Aufgabenfelder auf denen sie glänzen konnten (also Vorteile gegenüber anderen Systemen zeigen). Pauschal ist aber keine Sprache für alles gleich gut geeignet, das geht einfach nicht da einige Anforderungen gegensätzlich sind (z.B. hoher Grad der Abstraktion und Systemnahe Programmierung).
Wenn Du also fragst, was für Dich am Besten ist, dann kann man die Frage (auch nur für den Moment) höchstens beantworten, wenn man weiß was Du machen möchtest.

Gruß Der Unwissende

[Bernhard Geyer]

Zitat von o0o:

waere nice wenn mir jemand einen rat gebn koennte wie es am sinnvollsten fuer mich waere^^

Kommt darauf an was du machen willst. Im Bereich Server gibt es neben den beiden großen Frameworks Java und .NET auch viele (oft kleinerer) Lösungen auf PHP oder sonstige Skriptsprachen (auch wenn sich einige auch gut ins Frameworks integrieren lassen). Auf Client-Seite (vorrausgesetzt der große Client-Linux-Hype kommt doch) wird unter Windows noch einige Jahre in vielen Bereichen auch noch klassische Win32-Anwendungen einsatz finden (Haben erst vor kurzen einen Delphi-Entwickler eingestellt). Für Neu-Projekte unter Windows wird sehr oft .NET eingesetzt (und primär eigentlich VB und C++ mit MFC damit in die Bedeutungslosigkeit geschickt)

[o0o]

vielen dank fuer die 2 guten ratschlaege
also in welche richtung ich allgemein programmieren will weiss ich selbst noch nicht da ich es liebe von allem ein wenig zu machen^^
natuerlich wuerde ich auch gerne geld verdienen fuers programmieren aber ich denke es bleibt mal beim hobby denn wenn geld ins spiel kommt reichen meine win32 anwendungen nichtso aus^^

aber naja ich hatte oben noch erwaehnt dass ich mit masm jetzt angefangen habe^^
assembler ist ja auch schon ne sehr alte sprache, aber wenn ich mir die die groesse von den endprodukten anschaue bin ich einfach begeistert,...jetzt wuerde mich mal interessieren ob es sich lohnt da noch richtig reinzulehnen denn es kommt ja vista inkl 64bit solangsam zum standart und wird denn asm zukunft haben?

so das waere meine letzte frage

thx im vorraus^^

da o0o

[EWeiss]

wird sehr oft .NET eingesetzt (und primär eigentlich VB und C++ mit MFC damit in die Bedeutungslosigkeit geschickt Quatsch .. während hier die sprachen weitergeführt werden wenn auch in
einer etwas anderen form und sicherlich nicht bedeutungslosd geworden sind
sieht es zur zeit mindestens bei Delphi und mit dem versuch Delphi nach .Net zu portieren
kläglich aus.
Also soltest dann schon lieber deinen Spruch für Delphi
nicht für VB, C++ und MFC verwenden.

gruss Emil

[delphirocks]

Naja, "Classic VB" ist so tot wie eine Sprache nur tot sein kann. VB.NET hat mit VB aber schon überhaupt nichts zu tun. Bei der MFC sieht's anders aus. In VS2008 wird irgendwann im Frühjahr eine neue Version der MFC ausgeliefert.
Was sagt uns das? Der Bedarf nach schnellen Win32 Anwendungen ist nach wie vor vorhanden.

Wir haben eine riesige MFC Anwendung mit .NET neugeschrieben (der alte Code war unwartbar). Das Ergebnis war ernüchternd. Die Entwicklungszeit wurde zwar drastisch verkürzt (in Etwa gleich wie Delphi), dafür war für den Enduser die Software um einiges "zäher" als die Originalversion. Hätten wir das Ding in Delphi geschrieben, wäre das Resultat sicher um einiges besser ausgefallen.