Delphi am "Ende"?

[Chemiker]

Hallo,

Zitat:

Versuch Dich doch mal mit dem Reflector an dem Teil

Es wurden auch verschiede Schutzmaßnahmen vorgestellt, trotzdem war es relativ einfach den Quellcode offen zulegen, Ob Deine dabei waren kann ich zurzeit nicht sagen, weil ich die Aufzeichnungen irgendwie verlegt habe.

Bis bald Chemiker

[hanspeter]

Zitat:

Zitat von Phoenix (Beitrag 1073191)

Weil viele von diesen Sprachkonstrukten auf IL-Internas basieren. Ich rede hier insbesondere von LINQ. Zumal der (neue) Prism-Compiler auch zu 100% managed ist. Das kann man nicht einfach so in einen nativen Compiler nachimplementieren ohne die Rückwärtskompatibilität zu opfern. Und wenn Embc. das macht, dann ist Delphi wirklich tot.

So tief hatte ich eigentlich nicht gedacht.
In Delphi "method" als zusätzliches Schlüsselwort, Case mit String, compatible Generics ...
Einfach eine Klassendeclaration in beiden Systemen parallel verwenden können.
Es geht hier um die Weiterverwendung bestehenden Delphi - Codes.

Zitat von Insider2004:
und für Delphi gibt es hunderttausende Komponenten/Code-Beispiele (für .net gibts nix)

Man darf nicht übersehen, das das Net-Framwork um Größenordnungen vollständiger als die VCL ist.
In der VCL gibt es einige hundert Klassen im Net-Framework einige tausend.
Viele Delphi - Toolhersteller bieten Net Versionen an oder sind gar ganz auf net umgeschwenkt.
Viele unter Delphi erfogreiche Tools stehen auch in Net zur Verfügung. (z.B. Express quantum, Fastreport ...)

Gruß
Peter

[Robotiker]

Zitat:

Zitat von littleDave (Beitrag 1073164)

Um wieder etwas mehr mitmischen zu können, muss man erstmal versuchen, Boden unten den Füßen zu bekommen - und zwar am Besten mit dem, was .NET nicht kann: native(!) Anwendungen für Win32, Win64, MacOS, Linux, iOS und Android erstellen zu können.

Ich habe schon Zweifel, wenn ich hier lese Delphi sei für native Win32 Programmierung das beste Tool ...

Abseits von GUI und Datenbanken tut sich da bei anderen im Moment sehr viel:

Intel hat sein Parallel Studio, Visual C++ 2010 seine Concurrency Runtime
http://msdn.microsoft.com/de-de/library/dd504870.aspx

Mein C++ Builder XE hat TThread und Synchronize. :oops:
Fragen zur Unterstützung von Intels Threading Building Blocks werden im Embi-Forum so beantwortet:
https://forums.codegear.com/message....essageID=42979
(Sinnigerweise ist der Beantworter der Frage inzwischen zu Apple gewechselt.)

Vor lauter Unicode, Win64 und Mac wird da die nächste Entwicklung verschlafen.

[p80286]

Zitat:

Zitat von hanspeter (Beitrag 1073198)

In der VCL gibt es einige hundert Klassen im Net-Framework einige tausend.

Wenn diese Klassen aber die gleiche Qualität wie in VBA haben, und die Vermutung liegt nahe, dann kann ich gut darauf verzichten.

Gruß
K-H

[holliesoft]

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer)

Das kann ich nicht bestätigen...

Ich verarbeite auf der Arbeit mit einem .net-Programm z.B. Logdateien, die ich vorher mit einem Delphi-Programm verarbeitet hatte. Das .net Programm ist min. doppelt so schnell!

Gruß
Patrick

[Assarbad]

Zitat:

Zitat von littleDave (Beitrag 1073164)

Ich finde das an sich eine gute Idee. Jedoch nicht wegen dem 'ComponentStore', sondern eher als Community-Förderung. Die Anzahl der kommerziellen Delphi-Entwickler geht nun mal leider bergab, das ist nicht anfechtbar. [...] Es ist keine Schande zu sagen: wir schaffen es nicht bis zum xx.xx.201x -> wenn ihr wenigstens glaubwürdig darstellt, was bereits fertig ist und wie lange ihr noch brauchen werdet. Und wenn das dann zum neu prognostizierten Termin wirklich eine lauffähige Version mit den angekündigten Features in den Regalen steht, werdet ihr wieder Vertrauen genießen.

Wow, ich denke du sprichst einigen anderen hier auch aus dem Herzen.

Zitat:

Zitat von Phoenix (Beitrag 1073177)

Selbst wenn: Das kommt dann aber dank der Embc.-Politik wieder als 'neue Version' raus und nicht als SP.

Klartext! :thumb:

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer) und für Delphi gibt es hunderttausende Komponenten/Code-Beispiele (für .net gibts nix)

Huch, geht mein Kalender falsch? Hier steht 2011, hast du noch 2004? :stupid:

Zitat:

Zitat von Phoenix (Beitrag 1073180)

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer)

Das ist ein Gerücht. Und zwar ein schlechtes und unhaltbares.

Es ist definitiv kein Gerücht, wie dir ein Profiler schnell beweisen wird. Natürlich reicht es nicht auf die Verhältnisse zu schauen, sondern man muß schon auf die absoluten Zahlen schauen bei sowas. Allerdings hat .NET ja andere Vorteile ... am Ende heißt es einfach (wie so oft): abwägen.

Zitat:

Zitat von Phoenix (Beitrag 1073191)

Mit genau so wenig Aufwand kann man den Quellcode aber auch entsprechend schützen. Der kostenlos herunterladbare Oxygene-Compiler von Delphi Prism ist ein .NET Programm. Versuch Dich doch mal mit dem Reflector an dem Teil ;-)

... und dann versuch's nochmal mit IDA Pro. Auch wenn die richtig bequemen Methoden damit wegfallen, sind die .NET-Primitiven noch deutlich einfacher lesbar als x86-Assembly.

Allerdings ist ohnehin fragwürdig wieviel Schutz notwendig ist usw. ... und im Zweifelsfall implementiert man etwas über nativen Code und bindet per P/Invoke an.

Zitat:

Zitat von Robotiker (Beitrag 1073199)

Ich habe schon Zweifel, wenn ich hier lese Delphi sei für native Win32 Programmierung das beste Tool ...

Echt? Also ich würde da mitgehen, allerdings konkretisieren: das beste RAD-Tool für den Zweck.

Zitat:

Zitat von holliesoft (Beitrag 1073219)

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer)

Das kann ich nicht bestätigen...

Ich verarbeite auf der Arbeit mit einem .net-Programm z.B. Logdateien, die ich vorher mit einem Delphi-Programm verarbeitet hatte. Das .net Programm ist min. doppelt so schnell!

Da hätte ich doch gern mal die Rahmendaten. Auch wäre hier ein Vergleich der benutzten Funktionen und eine Überprüfung der Testmethoden angebracht. Wird bspw. nach jedem Testlauf neu gebootet? .NET-Code läuft meiner Erfahrung nach oft ein wenig langsamer, auch wenn ich mich auf das 15fache nicht festlegen wöllte ...

[DSCHUCH]

Zitat:

Zitat von hanspeter (Beitrag 1073173)

geht über das BPL Konzept,

ist zwar etwas OT, aber:
ich höre es des öfteren, dass das bpl konzept nicht gut wäre. wieso eigentlich? ich finde es äußerst praktisch und flexibel und vor allem sehr einfach zu verwenden. globale klassen/variablen über dll's automatisch verteilen, funktionalitäten in großen projekten über alle module gleich halten, was gibt es hier zu bemängeln?

[mirage228]

Zitat:

Zitat von mschaefer (Beitrag 1073148)

Was ich mir doch als neue Funktion vorstellen könnte, wäre so eine Art 'ComponentStore' zentral für Delphi im Web mit Anbindung an die IDE, sodass man eigene Komponenten dort einstellen und von anderen, mit direkter IDE-Installation, abrufen kann.

Finde ich von der Idee her interessant. Wäre eine prima Ergänzung zu den vielen bestehenden Komponentenseiten und den viel zahlreicheren Einzelseiten im Internet. Besonders kurz zum Ausprobieren die angesprochene IDE-Installation bestimmt auch nützlich. Außerdem könnte Embarcadero über Umsatzbeteiligungen an einem dort integrierten e-Payment ggf. neue Gewinnfelder erschließen (muss sich für die ja auch lohnen).

[hanspeter]

Zitat:

Zitat von DSCHUCH (Beitrag 1073317)

ist zwar etwas OT, aber:
ich höre es des öfteren, dass das bpl konzept nicht gut wäre. wieso eigentlich? ich finde es äußerst praktisch und flexibel und vor allem sehr einfach zu verwenden. globale klassen/variablen über dll's automatisch verteilen, funktionalitäten in großen projekten über alle module gleich halten, was gibt es hier zu bemängeln?

Arbeite ich mit bpl muss das gesamte Projekt immer gegen die gleiche Compilerversion und innerhalb der Version meist auch noch das gleiche Release compiliert sein.
Ändere ich in irgendeiner bpl etwas im Interfaceteil, müssen alle Bpl und alle Exe, welche sich auf diese beziehen neu kompiliert werden.
Tut man das nicht, kommt gerne der Fehler ".. wurde mit unterschiedlicher Version compiliert".
Befinden sich aus irgendwelchen Gründen mehrere bpl Versionen im Zugriff des Programms, ist das Chaos perfekt. (< Delphi 7 hat BPL nach Windows/System oder ähnlich kopiert). Also kleine Programmänderung und alle 250 BPL der Umgebung neu mit ausliefern. Das betrifft auch andere Programme, wenn diese auf den gleichen BPL Pool zugreifen. Ohne saubere Versionsverwaltung, tritt der Fehler erst beim Kunden auf.
Assemblys verwenden ,ähnlich wie ein Com-Objekt eine Signierung. Das Programm ist in der Lage im Assembly-Cache die richtige Bibliotheksversion zu finden.

Was auch noch zum Thema passt. Heute ist der neue Tiobe-Index für Januar erschienen. DElphi dümpelte immer auf Platz 10/11. Mal im Vergleich der 10
wichtigsten Sprachen drinnen, dann wieder draußen. Im Januar erstmalig auf Platz 12 abgerutscht.


Gruß
Peter

[Assarbad]

Zitat:

Zitat von hanspeter (Beitrag 1073327)

Was auch noch zum Thema passt. Heute ist der neue Tiobe-Index für Januar erschienen. DElphi dümpelte immer auf Platz 10/11. Mal im Vergleich der 10
wichtigsten Sprachen drinnen, dann wieder draußen. Im Januar erstmalig auf Platz 12 abgerutscht.

... dicht gefolgt von Lisp. Eine gute Wahl, daß ich jetzt angefangen habe Lisp zu lernen :zwinker: