Delphi am "Ende"?

[BUG]

OT:

Zitat von Assarbad:

Zitat von DeddyH:

Lisp? Ist das nicht dieses Dings mit den unwahrscheinlich vielen Klammern?

"I eat parentheses for breakfast" -> http://www.youtube.com/watch?v=HM1Zb3xmvMc

Kannst du das da beworbene Buch empfehlen?

[Assarbad]

OT:

Zitat von BUG:

Kannst du das da beworbene Buch empfehlen?

Ich bin derzeit in Kapitel 3, bisher ja. Frag mich in ein paar Wochen nochmal, dann bin ich vermutlich komplett durch. Habe schon drei Leute die es danach ausleihen wollen

[newbe]

Solange die Macher von Delphi mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes (Multicore support, 64 Bit) und damit den Wünschen der Anwender vorbei Entwickeln/Releasen, werden solche Threads auch immer wieder aufkommen. Und das lieber Luckie ist mit Verlaub gesagt auch ligitim. Nur weil ein Thema bereits in anderen Threads behandelt wurde heisst das noch lange nicht, das ich keinen neuen Thread zum selben Thema erstellen darf.
(nur weil es bestimmten Leuten hier aus welchen Gründen auch immer net in den Kram passt)

Etwas anderes ist es natürlich, wenn EINE Person diverse Threads mit dem selben Thema innerhalb kurzer Zeit aufmacht.

mfg newbe

[DSCHUCH]

Zitat von newbe:

Solange die Macher von Delphi mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes (Multicore support, 64 Bit) und damit den Wünschen der Anwender vorbei Entwickeln/Releasen, werden solche Threads auch immer wieder aufkommen.

mfg newbe

irgendwie fehlt mir bei solchen aussagen etwas die differenzierung.

1) kann man problemlos threads mit delphi abbilden (multicore). ich weiß es gibt in .net nette sprachkonstrukte die das wesentlich vereinfachen - ich gehe aber davon aus das das noch kommen wird (will ich zumindest mal hoffen ^^).
2) benötigt man für die meisten gui-anwendungen weder 64 bit noch sonstwas (derzeit). natürlich wird das perspektivisch vom kunden erwartet, derzeit funktioniert allerdings nichtmal ms office richtig unter 64 bit mit allen interfaces. bzw es ist nicht abwärtskompatibel und somit nicht zu gebrauchen. von daher ist diese aussage "mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes...vorbei Entwickeln/Releasen" - entschuldige - lächerlich. (mal von dem ganzen treiber zirkus bei 64 bit abgesehen). problematisch ist hier eher - wie bereits mehrfach angesprochen - das keine belastbare aussage vorhanden ist wann das kommt.
http://www.chip.de/news/Office-2010-..._43428002.html
http://technet.microsoft.com/de-de/l.../ee681792.aspx
http://www.outlookforums.com/showthr...-2010-64-bit-R
3) wir beispielsweise verwenden delphi ausschliesslich für die frontendentwicklung. alles andere läuft über andere technologien ab, die dann mit delphi kommunizieren. unser backend läuft auf 64 bit, das frontend 32 (sicher wäre es nett wenn das von delphi mal käme. ;o) )

[mkinzler]

Für die reine GUI braucht man kein 64Bit, aber für:
-Pluginentwicklung Office
-speicherlastigen Anwendungen
-COM-Dienste
...

[Bernhard Geyer]

Zitat von mkinzler:

Für die reine GUI braucht man kein 64Bit, aber für:
-Pluginentwicklung Office
-speicherlastigen Anwendungen
-COM-Dienste
...

- Plugins für CAD-Systeme (Diverse davon kündigen schon das EOF für die 32-Bit-Version an)
- Plugins für Windows Explorer
- Plugins für IE-64 (Ok, da hier noch Adobe pennt hat man noch etwas zeit)

Zitat von DSCHUCH:

... nichtmal ms office richtig unter 64 bit mit allen interfaces. bzw es ist nicht abwärtskompatibel und somit nicht zu gebrauchen.
...
http://technet.microsoft.com/de-de/l.../ee681792.aspx
...

Hier steht nicht das MS Office 64-Bit nicht richtig funktioniert. Es steht da das es viele Plugins/Extension gibt die nicht als 64-Bit-Version funktionieren (vermutlich sind auch einige davon mit Delphi entwickelt).
Wenn man über COM/OLE Automation geht stört es nicht wenn die 64-Bit Version installiert ist.

Zitat von mkinzler:

Zitat:

Delphi 64 kommt im August.

Hoffen wir mal

Welchs Jahr

[Assarbad]

Zitat von DSCHUCH:

1) kann man problemlos threads mit delphi abbilden (multicore). ich weiß es gibt in .net nette sprachkonstrukte die das wesentlich vereinfachen - ich gehe aber davon aus das das noch kommen wird (will ich zumindest mal hoffen ^^).

Thread == Thema, im Kontext eines Forums. Da war keinerlei Aussage zu Threads (wie: parallele Ausführung) in Delphi enthalten.

Zitat von DSCHUCH:

(mal von dem ganzen treiber zirkus bei 64 bit abgesehen)

Wo siehst du da ein Problem?

Zitat von DSCHUCH:

3) wir beispielsweise verwenden delphi ausschliesslich für die frontendentwicklung. alles andere läuft über andere technologien ab, die dann mit delphi kommunizieren. unser backend läuft auf 64 bit, das frontend 32 (sicher wäre es nett wenn das von delphi mal käme. ;o) )

Heißt das, daß ihr eine Shellerweiterung künstlich zu dem Backend zählt, um gleichzeitig die Macher von Delphi verteidigen zu können und Kunden mit x64 bedienen zu können?

Zitat von Bernhard Geyer:

Zitat von mkinzler:

Zitat:

Delphi 64 kommt im August.

Hoffen wir mal

Welchs Jahr

Voraussichtlich noch in einem mit ner "2" vorn. Und jetzt frag nicht wieviele Stellen!!!

[Robotiker]

Zitat von DSCHUCH:

1) kann man problemlos threads mit delphi abbilden (multicore). ich weiß es gibt in .net nette sprachkonstrukte die das wesentlich vereinfachen - ich gehe aber davon aus das das noch kommen wird (will ich zumindest mal hoffen ^^).

Handgemachte Threads sind kein Thema. Aber die Entwicklung geht weiter, soll sich das Programm automatisch an die Anzahl der Kerne (und das werden zukünftig viele sein) anpassen, braucht man da mehr Logik. Das habe ich in diesem Beitrag gemeint:
http://www.delphipraxis.net/1073199-post153.html

In C++ gibt es dafür z.B. OpenMP, das wird von den meisten Compilern unterstützt, aber natürlich nicht vom C++ Builder.

In der Roadmap steht etwas von "Support for parallelization in the RTL" bei Commodore. Das könnt eine Antwort auf Microsofts Concurreny Runtime sein.
http://msdn.microsoft.com/de-de/library/dd504870.aspx
Nur sind die wohl mal wieder früher dran und mit mehr Manpower unterwegs.

[cookie22]

Zitat von DSCHUCH:

2) benötigt man für die meisten gui-anwendungen weder 64 bit noch sonstwas (derzeit). natürlich wird das perspektivisch vom kunden erwartet, derzeit funktioniert allerdings nichtmal ms office richtig unter 64 bit mit allen interfaces. bzw es ist nicht abwärtskompatibel und somit nicht zu gebrauchen. von daher ist diese aussage "mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes...vorbei Entwickeln/Releasen" - entschuldige - lächerlich. (mal von dem ganzen treiber zirkus bei 64 bit abgesehen). problematisch ist hier eher - wie bereits mehrfach angesprochen - das keine belastbare aussage vorhanden ist wann das kommt.
http://www.chip.de/news/Office-2010-..._43428002.html
http://technet.microsoft.com/de-de/l.../ee681792.aspx
http://www.outlookforums.com/showthr...-2010-64-bit-R

Ich arbeite im Bereich Desktop-Anwendungen und wir brauchen den 64-Bit Compiler schon seit Jahren. Sinnvoll oder nicht, es gibt nunmal die 64-Bit Systeme und die Kunden verlangen 64-Bit Software. Hat man diese nicht oder funktionieren Programmteile nicht unter 64-Bit, kauft der Kunde wo anders.

Es ist nicht mal möglich eine einfache Shell Extension für 64-Bit zu erstellen und eine Shell Extension ist nun wirklich nichts abgedrehtes.

[DSCHUCH]

îch gebe euch ja im prinzip recht, natürlich fehlt hier noch ein ganzes stück. allerdings fehlt mir ein wenig wertschätzung dessen, was doch in den letzten 2 jahren passiert ist. das ist nämlich mehr, als in den 7 jahren zuvor, im prinzip hat sich seit delphi5-2009 nichts wirklich getan bzw. nur chaos gegeben, da sieht man jetzt nun doch endlich wieder etwas licht am horizont.
und das der compiler, welcher im großen und ganzen einen 10 jahre alten stand hat, schwierigkeiten macht weiter oder besser gesagt neuzuentwickeln, sollte klar sein. ^^
ich sage es mal so - müßte ich neu entscheiden, würde ich derzeit wahrscheinlich auch vor delphi abgeschreckt sein. aber im moment habe ich hoffnung das es wieder besser wird. ;o)

ps: das mit dem thread war gut. ^^