Delphi am "Ende"?

[DeddyH]

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

[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

Zitat von mschaefer:

Das mit dem BPL-Konzept war mal ein Nachteil als die Datenträger zum ausliefern noch klein waren und man nicht das ganze Programmpaket ausliefern könnte. Heute würde ich sagen, bei einer neuen Version alles neu compileren auf DVD oder Web und das war es. Ist heute kein relvanter Nachteil mehr.

Aber der Vorteil ist hin, wenn man doch wieder alles zusammen ausliefern muß, anstatt die sauber getrennten BPLs einzeln auszuliefern.

[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
...

[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.