AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Delphi am "Ende"?

Ein Thema von Mavarik · begonnen am 3. Jan 2011 · letzter Beitrag vom 3. Apr 2011
Antwort Antwort
Seite 1 von 2  1 2      
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#1

AW: Delphi am "Ende"?

  Alt 7. Jan 2011, 18:56
Das kann man natürlich nur schaffen, wenn man sich mehr um die Weiterentwicklung kümmert.
Ich persönlich finde, daß man sich statt "Weiterentwicklung" (im Sinne von Hinzufügen) erstmal auf die Behebung der bekannten Probleme konzentrieren sollte.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.656 Beiträge
 
Delphi 12 Athens
 
#2

AW: Delphi am "Ende"?

  Alt 7. Jan 2011, 19:08
Das ist aber ein allgemeines Problem, nicht nur bei Emba. Vielerorts ist man meiner Beobachtung nach einer gewissen "Featuritis" erlegen. Wobei ich zugeben muss, dass die Kunden daran auch eine gewisse Mitschuld tragen.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#3

AW: Delphi am "Ende"?

  Alt 7. Jan 2011, 20:50
Das ist aber ein allgemeines Problem, nicht nur bei Emba. Vielerorts ist man meiner Beobachtung nach einer gewissen "Featuritis" erlegen. Wobei ich zugeben muss, dass die Kunden daran auch eine gewisse Mitschuld tragen.
Die Kunden? Wohl eher die sog. Entscheider, die die jedem wolkigen Wortgeklingel hinter her laufen.
Haupsache chic!

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#4

AW: Delphi am "Ende"?

  Alt 7. Jan 2011, 21:02
Das ist aber ein allgemeines Problem, nicht nur bei Emba. Vielerorts ist man meiner Beobachtung nach einer gewissen "Featuritis" erlegen. Wobei ich zugeben muss, dass die Kunden daran auch eine gewisse Mitschuld tragen.
Die Kunden? Wohl eher die sog. Entscheider, die die jedem wolkigen Wortgeklingel hinter her laufen.
Haupsache chic!
Ich halte es für eine Kombination. Man kann das mit diversen anderen Dingen vergleichen, wo die Mehrheit auch nicht durch die lauteste Gruppe vertreten wird. Wenn aber die lautesten Gehör finden? (Benutzer/Kunden) ... oder die Entscheider sogar aufgrund diverser Buzzwords den Realitätssinn verlieren und sich in die Buzzwords verlieben? (Entscheider)

Ich denke man kann es nicht auf eine Seite schieben, auch wenn man in den Foren bei Emba deutlich sehen kann von wo der Wind weht ("Entscheider"), wenn Leute die gezwungen werden unter Klarnamen zu posten als Trolle diffamiert werden, nur weil sie berechtigte Kritik anbrachten. Wie schon gesagt: so kann man mit seinen Kunden auch umgehen. Nur wie lange, ist die Frage ... womit wir wieder beim Thementitel wären
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
hanspeter

Registriert seit: 26. Jul 2003
Ort: Leipzig
1.350 Beiträge
 
Delphi XE2 Professional
 
#5

AW: Delphi am "Ende"?

  Alt 8. Jan 2011, 02:15
Wo der Vorteil von Delphi gegenüber Net liegen soll, ist im Moment schwer zu begründen.
Da gibt es eigentlich nur zwei Begründungen. Einmal riesige Altlasten an vorhandenen Programmcode und zum anderen ein fortgeschrittenes Lebensalter beim Programmierer.
Um mit Delphi wieder neue Projekte anzufangen, müsste sich nach meiner Meinung konzeptionell einiges mehr tun.
Das beginnt bei der nicht threadsicheren VCL, geht über das BPL Konzept, was nur noch ein Klotz am Bein ist und endet nicht zuletzt bei der fehlenden Kompatibilität zu Net.
Wenn wenigstens in der IDE die lästigsten Fehler langsam behoben würden.
Wenn man zumindest aus Delphi heraus ein Assembly aufrufen könnte oder ein Delphiprogramm problemlos in Net einbinden könnte.
Allein schon die Entschärfung der Dll - Hölle durch das Assemblykonzept wäre ein Gewinn.
Prism sehen wir auch nur als Zwischenschritt zu C#. Dazu sind die Sprachelemente zu unterschiedlich.
Auch wenn GUI und Code strikt getrennt sind, kann man nicht einfach die GUI in Net neu schreiben und Delphi-Code über Prism ohne erhebliche Anpassungen weiterverwenden.
Der gleiche VCL - freie Quelltext in Prism und Delphi ist Illusion. Prism hat die moderneren Sprachkonstrukte. Warum diese nicht in Delphi nachziehen?
Multiplattform ist sicherlich interessant, darf aber nicht überbewertet werden.
In unserem Betrieb gibt es unter Java ein Projekt, welches auf Windows, Linux und Mac laufen soll.
Daraus sind inzwischen fast drei Projekte geworden. Eins für Window, eins für Linux ...
Was solche Diskussionen immer wieder aufkommen läßt, ist die mangelhafte Planungssicherheit und Informationspolitik.
Wenn Embacadero endlich mal Butter bei die Fische tut und eine belastbare Roadmap veröffentlicht wäre schon viel gewonnen.
Im Moment sind zu viele Fragezeichen, als das ich mich bei Entscheidungen zu Neuprojekten mit Delphi durchsetzen könnte.

Gruß
Peter
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#6

AW: Delphi am "Ende"?

  Alt 8. Jan 2011, 02:58
Allein schon die Entschärfung der Dll - Hölle durch das Assemblykonzept wäre ein Gewinn.
Dafür hast du jetzt die NET-Framewok Hölle. Wie oft habe ich es schon erlebt, dass ein NET Programm mit dem installierten Framework nicht klar kam, weil es nicht abwärts kompatibel ist. Also einen wirklichen Fortschritt sehe ich da nicht wirklich.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.643 Beiträge
 
#7

AW: Delphi am "Ende"?

  Alt 8. Jan 2011, 06:29
Wo der Vorteil von Delphi gegenüber Net liegen soll, ist im Moment schwer zu begründen.
Das stimmt leider. Man kann (wenn man es kann ) auch in .NET eine DB-Oberfläche zusammenklicken wie mit Delphi.

Da gibt es eigentlich nur zwei Begründungen. Einmal riesige Altlasten an vorhandenen Programmcode und zum anderen ein fortgeschrittenes Lebensalter beim Programmierer.
Zweiteres zählt eigentlich auch nicht mehr. Wer sich von der VCL an das .NET Framework - zumindest mal im Bereich Windows Forms - umgewöhnen möchte kann das sehr schnell tun, denn die Frameworks sind sich zumindest dort sehr ähnlich.

Um mit Delphi wieder neue Projekte anzufangen, müsste sich nach meiner Meinung konzeptionell einiges mehr tun.
Das beginnt bei der nicht threadsicheren VCL, geht über das BPL Konzept, was nur noch ein Klotz am Bein ist und endet nicht zuletzt bei der fehlenden Kompatibilität zu Net.
Auch in .NET gibt es sehr vieles, was nicht Threadsicher ist. Und manches muss man leider am eigenen Leib erfahren (ich mache viel ASP.NET, da fällt das schneller auf weil da je nach Serverkapazität schonmal etliche hundert Threads gleichzeitig losrattern können).
BPL's: Muss niemand nutzen. Kompatibilität: Wäre für mich hier kein Argument. Mann kann (reverse) P/Invokes machen und gut ist. Und auch hier gibts fertige Tools für - wenn es wirklich notwendig ist.

Wenn wenigstens in der IDE die lästigsten Fehler langsam behoben würden.
Selbst wenn: Das kommt dann aber dank der Embc.-Politik wieder als 'neue Version' raus und nicht als SP.

Wenn man zumindest aus Delphi heraus ein Assembly aufrufen könnte oder ein Delphiprogramm problemlos in Net einbinden könnte.
Hydra?

Allein schon die Entschärfung der Dll - Hölle durch das Assemblykonzept wäre ein Gewinn.
Prism sehen wir auch nur als Zwischenschritt zu C#. Dazu sind die Sprachelemente zu unterschiedlich.
Yikes. Von Prism dann der Rückschritt zu C#?
Wartet nochmal ein halbes Jahr ab, und überlegt Euch dann nochmal ob ihr mit den Features-To-Come wirklich auf Prism verzichten wollt (nein, ich darf nicht verraten welche ich meine)

Auch wenn GUI und Code strikt getrennt sind, kann man nicht einfach die GUI in Net neu schreiben und Delphi-Code über Prism ohne erhebliche Anpassungen weiterverwenden.
Der gleiche VCL - freie Quelltext in Prism und Delphi ist Illusion. Prism hat die moderneren Sprachkonstrukte. Warum diese nicht in Delphi nachziehen?
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.

Multiplattform ist sicherlich interessant, darf aber nicht überbewertet werden.
In unserem Betrieb gibt es unter Java ein Projekt, welches auf Windows, Linux und Mac laufen soll.
Daraus sind inzwischen fast drei Projekte geworden. Eins für Window, eins für Linux ...
Fat clients sind auch kein Multiplatform-Ziel. Wenn man so eine Anforderung hat, dann sollte man einen Application Server hinstellen der auf (mindestens) einer Platform läuft (die verbreitetste ist ein guter Ansatz, wobei man hier mit .NET bzw. Mono tatsächlich unabhängig sein kann), man packt eine X-Platform Bibliothek hin die den Zugriff auf diesen Application-Server abhandelt und baut für jede Platform einen *nativen* thin-client, der über diese Bibliothek mit dem Server spricht.

Was solche Diskussionen immer wieder aufkommen läßt, ist die mangelhafte Planungssicherheit und Informationspolitik.
Wenn Embacadero endlich mal Butter bei die Fische tut und eine belastbare Roadmap veröffentlicht wäre schon viel gewonnen.
Im Moment sind zu viele Fragezeichen, als das ich mich bei Entscheidungen zu Neuprojekten mit Delphi durchsetzen könnte.
Wahr. Leider zu wahr.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org

Geändert von Phoenix ( 8. Jan 2011 um 06:30 Uhr) Grund: Quote-Tags verschwurbelt
  Mit Zitat antworten Zitat
Insider2004
(Gast)

n/a Beiträge
 
#8

AW: Delphi am "Ende"?

  Alt 8. Jan 2011, 06:40
Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer) und für Delphi gibt es hunderttausende Komponenten/Code-Beispiele (für .net gibts nix)
  Mit Zitat antworten Zitat
DSCHUCH

Registriert seit: 6. Jun 2007
Ort: Dresden
187 Beiträge
 
Delphi 11 Alexandria
 
#9

AW: Delphi am "Ende"?

  Alt 8. Jan 2011, 19:44
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?
  Mit Zitat antworten Zitat
hanspeter

Registriert seit: 26. Jul 2003
Ort: Leipzig
1.350 Beiträge
 
Delphi XE2 Professional
 
#10

AW: Delphi am "Ende"?

  Alt 8. Jan 2011, 20:37
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
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:54 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz