Delphi bzw. FreePascal neu erlernen?

[milos]

Hallo Leute, ^^
Nach langer Zeit bin ich wieder hier und habe mir als erstes meine alten Beiträge durchgelesen; Sorry dafür xDD, war gerade mal 12-13 Jahre alt und noch sehr unerfahren im Programmieren. ^^
Habe jedoch seit dem PHP, JavaScript, vb6, vb.Net und C# bis zu einem fortgeschrittenem Stadium gelernt und kenne nun die Grundlagen der Programmierung sehr gut. ^^

Nun programmiere ich seit ca. 1.5 Jahre in C#, die bisher meine Lieblingssprache ist. Doch seit einiger Zeit frage ich mich ob es die richtige Sprache für mich ist. Ich habe vor in naher Zukunft ein kommerzielles Projekt zu starten. Die Idee habe ich bereits. Diese könnte ich auch in C# umsetzen jedoch würde ich dieses Projekt gerne ohne die .NET abhängikeit und mit multi platform lösung anbieten wollen und da stelle ich mir die frage ob ich nun nicht (wieder) anfangen sollte mich in Delphi bzw FreePascal ein zu arbeiten.

Man liest überall Delphi würde aussterben, und das ist das, was mir angst macht und mir zweifel gibt diese sprache zu lernen.

Wie seht ihr es? Seht ihr es als sinnvoll Delphi bzw. FreePascal zu lernen?
Oder könnt ihr mir eine andere empfehlen?
Momentan sehe ich nur Delphi bzw FreePascal und C++ als potenzielle sprachen, da beide eine Native Anweundung erstellen, multi-platform sind und auch gute IDEs zur verfügung haben.

Java wäre auch eine variante aber da fehlt mir der aspekt der nativen anwendung.

Ich bin gespannt auf eure antworten. ^^

MfG

€dit: Kleine Info: Würde für Delphi die Lazarus IDE und für C++ den C++ Builder benutzen.

Ps: sry für rechtschreibfehler, bin mom am handy^^

[Furtbichler]

Wenn Du Freunde hast, die auch Delphi programmieren, kannst Du auch in Delphi programmieren. Gleiches gilt, wenn Du eh alles alleine machen willst.

Ansonsten bist Du -bis auf die DP- ziemlich einsam. Daher würde ich Dir empfehlen, C# zu verwenden oder gleich auf Java umzusteigen. Nicht das Delphi so schlecht wäre, aber für deine (berufliche) Zukunft empfehle ich Dir, mit dem Strom zu schwimmen, d.h. eine Programmiersprache von Grund auf und 100% zu lernen, für die Du auf dem Arbeitsmarkt Angebote bekommst bzw. Verstärkung, wenn Du dein kommerzielles Projekt durchziehen willst.

[milos]

Zitat:

Zitat von Furtbichler (Beitrag 1216655)

Wenn Du Freunde hast, die auch Delphi programmieren, kannst Du auch in Delphi programmieren. Gleiches gilt, wenn Du eh alles alleine machen willst.

Ansonsten bist Du -bis auf die DP- ziemlich einsam. Daher würde ich Dir empfehlen, C# zu verwenden oder gleich auf Java umzusteigen. Nicht das Delphi so schlecht wäre, aber für deine (berufliche) Zukunft empfehle ich Dir, mit dem Strom zu schwimmen, d.h. eine Programmiersprache von Grund auf und 100% zu lernen, für die Du auf dem Arbeitsmarkt Angebote bekommst bzw. Verstärkung, wenn Du dein kommerzielles Projekt durchziehen willst.

Erstmal danke für die antwort ^^
Ich dachte mir schon, dass mir jemand, aufgrund des grösseren Stellenmarktes in anderen Sprachen, mir diese empfehlen wird.

Ich bin momentan im ersten Lehrjahr als Informatiker im bereich Applikationsentwicklung und arbeite schon hauptsächlich mit C# und HTML/PHP/JS/CSS.

Jedoch geht es mir hier nicht um den Beruf, C# werde ich ja schon nicht verlernen, so leicht wie das ist ^^

Das Delphi ausstirbt finde ich sehr schade, da es doch ein sehr grosses Potenzial hat, aber Delphi stirbt nur, wenn es keine Entwickler mehr dafür gibt und leider ist es so das es sehr wenige gibt. Doch wieso sollte mich das abhalten?

Hat Delphi wirklich so einen grossen Nachteil, den ich nicht sehe, oder haben sich andere Sprachen aufgrund der bequemlichkeit durchgesetzt? Mein Projekt kann ich nämlich gut alleine durchziehen, denn so gross ist es nicht und die Planungen sind schon so weit, dass ich anfangen könnte. Nur stellt sich bei mir eben die Frage: Sofort C# oder Delphi, Java oder C++ lernen und dann loslegen?

Es wäre toll, wenn mir einige von euch sagen könnten warum ihr gerade bei Delphi geblieben seid und was euch davon überzeugt euer Projekt in Delphi umzusetzen.

MfG

[Perlsau]

Zitat:

Zitat von milos (Beitrag 1216658)

Es wäre toll, wenn mir einige von euch sagen könnten warum ihr gerade bei Delphi geblieben seid und was euch davon überzeugt euer Projekt in Delphi umzusetzen.

Also ich bin und bleibe bei Delphi, weil ich mir so ca. 1994, also vor fast 20 Jahren, (Turbo-) Pascal selber beigebracht habe und inzwischen zu alt bin, um nochmal schnell was ganz Neues zu lernen. Meine alten Hirnwindungen sind zu träge, um nochmal so schnell zu begreifen, wie das vor 20 Jahren noch der Fall gewesen sein mag. Außerdem hab ich erstens schon viel Geld, Zeit und Energie in Delphi investiert, zweitens etliche Projekte mit Delphi am Laufen und drittens keine Zeit, mich in eine völlig andere Sprache einzuarbeiten. Auch wenn Delphi angeblich aussterben soll, sehe ich nicht den geringsten Anlaß, nun eine andere Sprache zu erlernen.

[WM_CLOSE]

Was Delphi fehlt ist eigentlich nur die marktbeherrschende Stellung. Das aber auch nur aufgrund der meiner Meinung nach schlechten Preispolitik. Ich meine jetzt mal im Ernst: welcher Programmierer will um eine Sprache mal auszuprobieren überhaupt Geld ausgeben? FreePascal wird keiner anfassen, der Visual Studio gewohnt ist. (ich möchte keine Diskussion vom Zaum brechen)

Dazu kommt noch, dass Delphi im RAD Bereich einfach zu wenig out-of-the-box zu bieten hat.
Inkonsestens der Komponenten in verschiedenen Versionen ist auch nicht gerade hübsch.

Da ist das .Net Framework deutlich im Vorteil, vor allem weil es ja auch nur auf die schon vorhandenen Windows APIs zurückgeift. Das .Net Framework ist einfach enorm umfangreich, weshalb man eigentlich kaum noch etwas selber basteln muss. Und viel langsamer als nativ ist es auch nicht (~90% je nach Anwendung).
Und man bekommst die Doku und Tools aus einer Hand.

Weitgehende Plattformunabhängigkeit hat man übrigens mit Mono und .Net auch. Man nuss nur darauf achten, dass man nicht in einen Bug oder ein nicht implementiertes Feature in Mono stolpert.

c++ Hat ähnliche Probleme wie Delphi, fragmentierte Frameworks, teilweise inkonsestente Compiler, fehlende Sprachfeatures. Dafür hat es in den letzten 20 Jahren einfach eine so marktbeherrschende Stellung eingenomen, dass eigentlich jeder Programmierer (sofern er denn ernst genommen werden will) c++ zumindest rudimentär beherrschen muss.
Außerdem hat es noch die große c Fanbasis aus dem *nix Bereich.

Java würde ich jetzt nicht unbedingt für die Zukunft empfehlen, da es meiner Ansicht nach auf dem absteigenden Ast ist, seit dem Oracle damit zu tun hat. Es hat aber den Vorteil, dass das Programm einaml kompilliert, wirklich auf jedem Toaster läuft.

Für kleinere Anwendungen, vor allem im Netzwerkbereich setze ich mittlerweile auf Node.JS, wobei es da mit kommerziell etwas schlechter aussieht (Quellcode ist einsehbar (bei .Net über Umwege übrigens auch)).

Fazit: Im Bereich multiplattform RAD hat Delphi enorm aufgeholt und mir FreePascal im Team ist es nicht zu schlagen. Echte multiplatform-Profis scheinen jedoch aud c, oder java (im low performance-Bereich) zu setzen.
Die c Leute sind jedoch dann eher solche Neckbeards, dass sie mit vim und gcc statt einer IDE arbeiten.

PS: Für die Zukunft empfehle ich dir, währen deiner Ausbildungszeit ein oder zwei Zertifikate zu machen (das CCNA macht man glaube ich sowieso zur Halfte in der Schule), vor allem, weil du in deinem Alter vermutlich kein Studium und auch kein Abi hast. Dabei geht es nur darum deinem potenziellen Arbeitgeber zu zeigen, dass du dein Fachgebiet beherrschst und das auch unter Beweis stellen willst. Wenn man etwas Konkurrenz hat, sind diese Papiere Gold wert.

PPS: Wenn du glaubst, du bist jetzt ein guter Programmierer, sieh dir deinen Code in 1 oder 2 Jahren nochmal an.

PPPS: Wenn du es ernst meinst mit Plattfromunabhängigkeit brauchst du von jeder Plattform, die du unterstützen willst ein Gerät. Kannst du dir das leisten beim Ausbildungsgehalt? Ich denke da an Windows PC, Virtuelles Linux System, einen Mac, ein iPhone, noch ein Android Gerät. Ich meine ein Leben hat man doch auch noch, oder? Bei mir hätte das den Geldbeutel gesprengt, da Auto (Versicherung 2k€ im Jahr), Wohnung (4k€ warm im Jahr), neuer PC (1k), diverse Software Lizenzen (1k im Jahr) und Lebensmittel. Und da war ich noch nicht unterweg mit Kumpels oder so...

[Der schöne Günther]

Zitat:

Zitat von milos (Beitrag 1216658)

Doch wieso sollte mich das abhalten?

Sehe ich ehrlich gesagt, ähnlich. Leute, die dir irgendein x-beliebiges Webzeug in PHP und JavaScript findest du wie Sand am Meer. Ich sehe es eher umgekehrt: Nicht auf Teufel komm raus das zu nehmen, was jetzt gerade hipp ist gefällt mir besser (vielleicht auch einfach nur, weil ich eben das getan habe).

Und natürlich verlernt man eine Sprache nach ein paar Jahren nicht, aber richtig drin bist du dann auch nicht mehr. Als reiner Anwendungsentwickler wird einem das sicherlich negativ ausgelegt, wenn jemand einen Entwickler für ein bestimmtes Projekt in XYZ sucht und du kannst nur sagen "Ja, damit habe ich vor zehn Jahren mal für zwei Jahre etwas gemacht, aber so richtig drin bin ich da auch nicht mehr..."

Auf der anderen Seite bin ich in meinem vorletzten Bewerbungsgespräch zweieinhalb Stunden lang (so als Überraschung) in Java auf Herz und Nieren geprüft worden. Zwei Tage später hatte ich den Arbeitsvertrag im Briefkasten obwohl ich zu dem Zeitpunkt Java seit über einem Jahr (!) nicht mehr angefasst hatte.


Von daher, wie gesagt: Ich habe die letzten Jahren mit anderen Sprachen verbracht - Hauptsächlich Java und C++. Jetzt bin ich bei Delphi. Und bereue es ehrlich gesagt keine Minute. Wenn man sich heute umschaut, scheint es so viele verschiedene Nischensprachen (mit entsprechend komischen Namen) zu geben wie nie zuvor. Und alle Sprachen haben ihre Anwender.

Warum also nicht auch Delphi?


PS: Die Diskussion um Java verstehe ich nicht. Java für Frontend-Entwicklung wie Client-Oberflächen oder generell auf dem Desktop halte ich für Quatsch. Es kommt ganz darauf an, was du machen willst. Die ganz großen Business-Dinger sind allesamt gruselig riesige Java EE-Anwendungen, das hat mit Java Runtime Environment für deinen Windows-PC fast nichts mehr zu tun.

[D-User]

Zitat:

Zitat von milos (Beitrag 1216651)

... Diese könnte ich auch in C# umsetzen jedoch würde ich dieses Projekt gerne ohne die .NET abhängikeit und mit multi platform lösung anbieten wollen und da stelle ich mir die frage ob ich nun nicht (wieder) anfangen sollte mich in Delphi bzw FreePascal ein zu arbeiten.

...


Momentan sehe ich nur Delphi bzw FreePascal und C++ als potenzielle sprachen, da beide eine Native Anweundung erstellen, multi-platform sind und auch gute IDEs zur verfügung haben.

Java wäre auch eine variante aber da fehlt mir der aspekt der nativen anwendung.

Ich bin gespannt auf eure antworten. ^^

MfG

€dit: Kleine Info: Würde für Delphi die Lazarus IDE und für C++ den C++ Builder benutzen.

Ps: sry für rechtschreibfehler, bin mom am handy^^

meine Meinung:

eigentlich nennst du alle wesentlichen Aspekte.

-Delphi bzw FreePascal sind m.E. nicht so schwer zu erlernen, und da du dich
ja schon mit beschäftigt hast wirst du schnell drin sein

-wie richtig geschrieben, nativ bekommst du nur mit Delphi / FreePascal bzw. C++.
So was ist durchaus wesentliches Kriterium.

-sehr praktisch find ich in Delphi / FreePascal /Lazarus auch
dieses praktische Komponentenkonzept.
Die Komponenten kann man ja dann sogar im C++-Builder verwenden,
seh ich als echten Vorteil an.
Und wenn man Spass dran hat kann man die Komps dann auch ncoh
(weiter)verkaufen

-was dieses ganze Geunke angeht denk ich da sind so einige bezahlte Leute
unterwegs, die ungeliebte Konkurrenz aus dem Weg schaffen sollen.
Das geht ja jetzt schon ne ziemliche Weile so, weit über 10 Jahre.
Würd mich echt mal interessieren wieviel man dafür so bekommt.


Mein Tipp:
Wenn du mit wenigen Leuten entwickelst, mußt du über Aufwand nachdenken.
Da ist dann Delphi / FreePascal durchaus ne gute Option.

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

[mkinzler]

Zitat:

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

Delphi ist eigentlich nicht langsamer als C++. Man kann nur keine Treiber o.ä. darin entwickeln

[D-User]

Zitat:

Zitat von mkinzler (Beitrag 1216670)

Zitat:

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

Delphi ist eigentlich nicht langsamer als C++. Man kann nur keine Treiber o.ä. darin entwickeln

vllt noch zu ergänzen:
man kann auch in Delphi selber optimieren, z.B. statt
Stringkonkatenation mit Format diese schlicht mit +.
Ist bei mir deutlich schneller.

zudem natürlich immer die Möglichkeit, Assembler direkt
einzubinden, wenn man brutal optimieren möchte.
Da wirds dann in .NET-Sprachen auch knifflig...

[TReader]

Was den Stellenmarkt angeht: Bin auch gerade beruflich in die Programmierung eingestiegen. Bei dem Unternehmen bei dem ich jetzt arbeite sah es folgendermaßen aus (auf das wesentliche zusammengekürzt): "Haben Sie neben C# und Objective-C auch Erfahrung mit Delphi?" - "Ja" --> Höheres Bruttogehalt, da Delphientwickler Mangelware sind.

Bei den Vergleichen, was ein Objective-C Entwickler verdient und was ein Delphi-Entwickler verdient hat Delphi die Nase vorn, weil es für die populären Sprachen einfach Programmierer wie Sand am Meer gibt. Klar ist dort die Qualität auch sehr weit gestreut, aber ich trau mich zu behaupten, dass wenn du mit Delphi und der Sprache umgehen kannst immer einen Job finden wirst, der - wie in meinem Fall - sogar besser bezahlt ist als eine der Mainstream-Sprachen.

Just my 2c

[D-User]

noch ein paar kleine Argumente:

Wenn du deine Entwicklungs-Bemühungen in der Gegend verteilen willst,
das .Net -Decompilieren wird anscheinend teilweise als Sport
angesehen:

.Net Decompilierung:
http://www.heise.de/developer/artike...T-1773804.html

und es wäre nebenbei mal sehr interessant zu erforschen ob im
Bytecode tatsächlich nur Programm-Info enthalten ist oder auch
Zusatzinfo.
Ich würde ne Wette eingehen, dass auch Zusatzinfo.
Für VB-"Compilat" gabs diverse Decompiler und auch entsprechende
Storys dazu, sollte sich mit einiger Suche noch finden lassen.


Pascal Vorteilhaft für Cross-Platform-Development
http://www.zdnet.com/pascal-still-an...rs-7000014743/


Meine eigene Experience:
Ich hatte vor ner ziemlichen Weile in VB ein größeres Projekt
quasi komplett fertig.
Dann trat ein Fehler auf, VB kam mit der Komplexität irgendwo
nicht zurecht.
Das war auch nicht sinnvoll zu umgehen, was dann den Umstieg
auf Delphi ausgelöst hat. Da gings dann.

Später noch mal was mit VB 6 probiert, das war aber so buggy
direkt die Finger von weggelassen, für so was hatte ich keine Zeit.

Was mich in letzter Zeit ziemlich geschockt hat waren die
Sicherheitswarnungen vor Java, wohl ein Grundsatz-Problem von
gelayerter (ge-"managter", hahaha, was ein dämlicher Euphemismus ) App-Entwicklung wie in Java oder .Net:

http://www.heise.de/newsticker/meldu...a-1784782.html

[WM_CLOSE]

Zitat:

Was mich in letzter Zeit ziemlich geschockt hat waren die
Sicherheitswarnungen vor Java, wohl ein Grundsatz-Problem von
gelayerter (ge-"managter", hahaha, was ein dämlicher Euphemismus ) App-Entwicklung wie in Java oder .Net:

Nein, meiner Meinung nach sind die Sicherheitsprobleme eher das Ergebnis inkonsequenter Sicherheismechanismen, sowie auch der Versuch das Sicherheitskonzept vom Betriebssystem zu abstrahieren anstatt mit den vorhandenen, auf Kernelebene vom Betriebssystem bereitgestellten Mechanismen zu interagieren.
.Net ist da wieder im Vorteil, da es konsequent das Sicherheitskonzept von Windows benutzt (eben nur schön verpackt). (wie Mono ds macht weiß ich nicht).
Java ist mehr eine Art VM als ein "Layer". Was in der VM geschieht bestimmt nur Oracle (und eben Java Bugs).

Ich muss zugeben, ich bin ein großer Fan von .Net, aber ich glaube es ist zum großen Teil auch berechtigt.
Schließlich ist C# eine Art Weiterentwicklung von beidem: Delphi und Java.

PS: Umfangreiche (kostenpflichtige) Software für den Massenmarkt (z.B. Photoshop) würde ich mit .Net aber nicht herstellen, wegen der Dekompillierbarkeit. Da würde ich eher zu C tendieren, oder eben Delphi (je nach Anwendungsgebiet). Auf exotische Sprachen würde ich aber nicht setzen, weil es einen einfach beruflich nicht weiterbringt und wenn das Projekt umfangreicher wird, hat man Probleme Verstärkung zu finden. (Natürlich muss man sich auf dem laufenden halten, was es neues gibt, aber einen Webserver mit BF will ich jetzt auch nicht umsetzten).

[milos]

Wow, erst mal danke für die vielen, ausführlichen Antworten! :)

Zitat:

Zitat von Perlsau (Beitrag 1216660)

Zitat:

Zitat von milos (Beitrag 1216658)

Es wäre toll, wenn mir einige von euch sagen könnten warum ihr gerade bei Delphi geblieben seid und was euch davon überzeugt euer Projekt in Delphi umzusetzen.

Also ich bin und bleibe bei Delphi, weil ich mir so ca. 1994, also vor fast 20 Jahren, (Turbo-) Pascal selber beigebracht habe und inzwischen zu alt bin, um nochmal schnell was ganz Neues zu lernen. Meine alten Hirnwindungen sind zu träge, um nochmal so schnell zu begreifen, wie das vor 20 Jahren noch der Fall gewesen sein mag. Außerdem hab ich erstens schon viel Geld, Zeit und Energie in Delphi investiert, zweitens etliche Projekte mit Delphi am Laufen und drittens keine Zeit, mich in eine völlig andere Sprache einzuarbeiten. Auch wenn Delphi angeblich aussterben soll, sehe ich nicht den geringsten Anlaß, nun eine andere Sprache zu erlernen.

Fast 20 Jahre und nie zu einer anderen gewechselt? Respekt, nach so einer Zeit wäre mir glaube ich die Lust an der Sprache vergangen xD Aber schön zu sehen das du es geschafft hast. ^^

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

Was Delphi fehlt ist eigentlich nur die marktbeherrschende Stellung. Das aber auch nur aufgrund der meiner Meinung nach schlechten Preispolitik. Ich meine jetzt mal im Ernst: welcher Programmierer will um eine Sprache mal auszuprobieren überhaupt Geld ausgeben? FreePascal wird keiner anfassen, der Visual Studio gewohnt ist. (ich möchte keine Diskussion vom Zaum brechen)

Dies könnte ein Grund sein, jedoch gibt es dafür doch Lazarus. Das einer Lazarus nicht anfasst, als Visual Studio User kann ich mir auch denken, aber da ich anfangs mit Delphi 3 gearbeitet habe, mag ich es. Das bringt bei mir so ein „Ahhh, die alten Zeiten“-Feeling. :D

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

Dazu kommt noch, dass Delphi im RAD Bereich einfach zu wenig out-of-the-box zu bieten hat.
Inkonsestens der Komponenten in verschiedenen Versionen ist auch nicht gerade hübsch.

Naja, das wirft bei mir die Frage auf, ob RAD-Tools überhaupt zwingend von nöten sind? Sind zwar Nice-To-Have, aber Delphi bietet m.M.n. andere, wichtigere Vorteile als RAD-Tools die man sich eigentlich auch selbst basteln könnte, bei bedarf.

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

Da ist das .Net Framework deutlich im Vorteil, vor allem weil es ja auch nur auf die schon vorhandenen Windows APIs zurückgeift. Das .Net Framework ist einfach enorm umfangreich, weshalb man eigentlich kaum noch etwas selber basteln muss. Und viel langsamer als nativ ist es auch nicht (~90% je nach Anwendung).

Der Grund warum ich auf .NET verzichten möchte ist wie genannt, dass ich Multi-Platform Lösungen bringen will und ohne das .NET Framework auskommen will. Aber .NET ist schon eine tolle Sache, aber ich mag „vorgebasteltes“ Zeug nicht so ^^ Wenn möglich, alles selber schreiben. ^^

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

Weitgehende Plattformunabhängigkeit hat man übrigens mit Mono und .Net auch. Man nuss nur darauf achten, dass man nicht in einen Bug oder ein nicht implementiertes Feature in Mono stolpert.

Über Mono bin ich auch schon seit einiger Zeit gestossen, jedoch würde ich wie gesagt gerne Nativ-Anwendungen schreiben, was mir durch Mono auch nicht möglich ist. Habe ausserdem Mono mal auf meinem Linux-Rechner ausprobiert und war gar nicht zufrieden damit. :-/

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

Java würde ich jetzt nicht unbedingt für die Zukunft empfehlen, da es meiner Ansicht nach auf dem absteigenden Ast ist, seit dem Oracle damit zu tun hat. Es hat aber den Vorteil, dass das Programm einaml kompilliert, wirklich auf jedem Toaster läuft.

Ja, der grösste (und wohl auch der einzige) Vorteil von Java bleibt wohl, dass jeder, ohne grosse Probleme, Anwendungen für die meisten Betriebssysteme erstellen kann.

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

Für kleinere Anwendungen, vor allem im Netzwerkbereich setze ich mittlerweile auf Node.JS, wobei es da mit kommerziell etwas schlechter aussieht (Quellcode ist einsehbar (bei .Net über Umwege übrigens auch)).

Genau, habe ich vergessen zu nennen. Mir ist auch wichtig das mein Code nicht einsehbar ist, wobei C# kläglich versagt.

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

PS: Für die Zukunft empfehle ich dir, währen deiner Ausbildungszeit ein oder zwei Zertifikate zu machen (das CCNA macht man glaube ich sowieso zur Halfte in der Schule), vor allem, weil du in deinem Alter vermutlich kein Studium und auch kein Abi hast. Dabei geht es nur darum deinem potenziellen Arbeitgeber zu zeigen, dass du dein Fachgebiet beherrschst und das auch unter Beweis stellen willst. Wenn man etwas Konkurrenz hat, sind diese Papiere Gold wert.

Danke für den Vorschlag, habe ich gar nicht bedacht und werde ich Mal mit meinen Arbeitgeber ansehen. ^^

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

PPS: Wenn du glaubst, du bist jetzt ein guter Programmierer, sieh dir deinen Code in 1 oder 2 Jahren nochmal an.

Ich verzweifle schon nur wenn ich sehe welche Fragen ich vor 4 Jahren gestellt habe und nicht einmal Grundlagen der Programmierung kannte und wirklich nichts kapiert habe, obwohl alles gut erklärt war, wenn ich es mir jetzt so ansehe. xD

Zitat:

Zitat von WM_CLOSE (Beitrag 1216665)

PPPS: Wenn du es ernst meinst mit Plattfromunabhängigkeit brauchst du von jeder Plattform, die du unterstützen willst ein Gerät. Kannst du dir das leisten beim Ausbildungsgehalt? Ich denke da an Windows PC, Virtuelles Linux System, einen Mac, ein iPhone, noch ein Android Gerät. Ich meine ein Leben hat man doch auch noch, oder? Bei mir hätte das den Geldbeutel gesprengt, da Auto (Versicherung 2k€ im Jahr), Wohnung (4k€ warm im Jahr), neuer PC (1k), diverse Software Lizenzen (1k im Jahr) und Lebensmittel. Und da war ich noch nicht unterweg mit Kumpels oder so...

Ja, ich meine es ernst und ja die meisten Geräte besitze ich. ^^
Windows und Linux PC, Mac OS X für x86 Prozessoren als VMImage (somit kann ich auch einen iOS Emulator benutzen), Android-Smartphone mit 2.2 (HTC Desire) und 4.x (SGS3) und ein älteres Windows Phone von meinem Vater besitze ich alles. Sollte somit den grössten Teil des Marktes abdecken ^^

Zitat:

Zitat von Der schöne Günther (Beitrag 1216667)

Sehe ich ehrlich gesagt, ähnlich. Leute, die dir irgendein x-beliebiges Webzeug in PHP und JavaScript findest du wie Sand am Meer. Ich sehe es eher umgekehrt: Nicht auf Teufel komm raus das zu nehmen, was jetzt gerade hipp ist gefällt mir besser (vielleicht auch einfach nur, weil ich eben das getan habe).

Genau, wieso sollte ich in einen vollen Zug steigen, der auch noch dreckig ist, wenn ich in einen halbvollen gehen könnte, der wenigstens alles richtig macht und dabei auch noch besser aussieht? :D

Zitat:

Zitat von Der schöne Günther (Beitrag 1216667)

Und natürlich verlernt man eine Sprache nach ein paar Jahren nicht, aber richtig drin bist du dann auch nicht mehr. Als reiner Anwendungsentwickler wird einem das sicherlich negativ ausgelegt, wenn jemand einen Entwickler für ein bestimmtes Projekt in XYZ sucht und du kannst nur sagen "Ja, damit habe ich vor zehn Jahren mal für zwei Jahre etwas gemacht, aber so richtig drin bin ich da auch nicht mehr..."

Wie gesagt bin werde ich beruflich immer noch mit der Sprache C# konfrontiert, somit wird auch mein Wissen in der Sprache immer weiter ausgebaut. Ausserdem habe ich noch noch ein Projekt das weiterhin gepflegt werden muss und in C# geschrieben wurde. Ich denke, dass ich so schnell C# nicht ganz aufgeben werde ^^

Zitat:

Zitat von Der schöne Günther (Beitrag 1216667)

Von daher, wie gesagt: Ich habe die letzten Jahren mit anderen Sprachen verbracht - Hauptsächlich Java und C++. Jetzt bin ich bei Delphi. Und bereue es ehrlich gesagt keine Minute. Wenn man sich heute umschaut, scheint es so viele verschiedene Nischensprachen (mit entsprechend komischen Namen) zu geben wie nie zuvor. Und alle Sprachen haben ihre Anwender.

Warum also nicht auch Delphi?

Naja, man hört überall das es aussterben wird, das wäre ein Grund um nicht Delphi zu lernen.

Zitat:

Zitat von D-User (Beitrag 1216669)

-Delphi bzw FreePascal sind m.E. nicht so schwer zu erlernen, und da du dich
ja schon mit beschäftigt hast wirst du schnell drin sein

Hoffe ich doch! ^^ Was mir momentan mühe bereitet sind immer die verschiedenen Wörter die die Sprachen benutzen, aber das gleiche anstellen. Aber daran hat man sich ja relativ schnell gewöhnt.

Zitat:

Zitat von D-User (Beitrag 1216669)

-sehr praktisch find ich in Delphi / FreePascal /Lazarus auch
dieses praktische Komponentenkonzept.
Die Komponenten kann man ja dann sogar im C++-Builder verwenden,
seh ich als echten Vorteil an.

Heisst das ich könnte auch in C++ *.DLLs erstellen die auf Hardwarebasis arbeiten und die dann in einem FreePascal Projekt verwenden?

Zitat:

Zitat von D-User (Beitrag 1216669)

Mein Tipp:
Wenn du mit wenigen Leuten entwickelst, mußt du über Aufwand nachdenken.
Da ist dann Delphi / FreePascal durchaus ne gute Option.

Momentan arbeite ich alleine an meine Privaten Projekte, aber bin schon einen Freund am „Rekrutieren“ in vb.NET. Werde ihm wohl dann C# oder FreePascal beibringen sobald ich es kann und er das Grundprinzip des programmieren einigermassen verstanden hat ^^

Zitat:

Zitat von D-User (Beitrag 1216669)

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

Kompletten Source Code in meine Projekte einzubauen, die nicht von mir bzw. von dem Team sind, kommt bei mir nicht in frage. Soweit ich mich erinner kann, habe ich bisher noch nie eine Libary von anderen genutzt, ausser jQuery und die Excel API von M$, worauf ich auch recht stolz bin :).

Zitat:

Zitat von D-User (Beitrag 1216673)

zudem natürlich immer die Möglichkeit, Assembler direkt
einzubinden, wenn man brutal optimieren möchte.
Da wirds dann in .NET-Sprachen auch knifflig...

Wow, das ist eine sehr coole Nachricht! :D
Wäre es dann möglich mit Assembler einen JIT-Compiler zu erstellen der die Controls von Pascal benutzt, oder wäre dies dann wieder Pascal und kein Assembler?

Zitat:

Zitat von TReader (Beitrag 1216678)

Was den Stellenmarkt angeht: Bin auch gerade beruflich in die Programmierung eingestiegen. Bei dem Unternehmen bei dem ich jetzt arbeite sah es folgendermaßen aus (auf das wesentliche zusammengekürzt): "Haben Sie neben C# und Objective-C auch Erfahrung mit Delphi?" - "Ja" --> Höheres Bruttogehalt, da Delphientwickler Mangelware sind.

Bei den Vergleichen, was ein Objective-C Entwickler verdient und was ein Delphi-Entwickler verdient hat Delphi die Nase vorn, weil es für die populären Sprachen einfach Programmierer wie Sand am Meer gibt. Klar ist dort die Qualität auch sehr weit gestreut, aber ich trau mich zu behaupten, dass wenn du mit Delphi und der Sprache umgehen kannst immer einen Job finden wirst, der - wie in meinem Fall - sogar besser bezahlt ist als eine der Mainstream-Sprachen.

Das ist auch eine tolle Nachricht, leider werden hier keine Delphi entwickler gesucht >.< Aber vielleicht wird es Mal so weit kommen ^^

Ich bedanke mich noch mal für alle Antworten, ich glaube diese haben mich dazu bewegt, mich endgültig zu entschliessen FreePascal zu lernen ^_^
Vielen dank für die Informationen liebe Leute :D

[WM_CLOSE]

Zitat:

Heisst das ich könnte auch in C++ *.DLLs erstellen die auf Hardwarebasis arbeiten und die dann in einem FreePascal Projekt verwenden?

Ja. Genau das haben früher alle Peripheriehersteller gamacht. Es resultierte in einem totalen Desaster, weil natürlich jeder meinte er müsste einen eigenen Treiber haben und diesen nach 2 Jahren nirgends mehr anbieten*. Setze daher nach möglichkeit auf USB und HID wenn du Hardware ansteuern willst.
Außerdem bist du mit Treibern grundsätzlich Bertriebssystemgebunden. (Linux und Apple Systeme könnten noch funktionieren, aber Windows und *nix eher nicht). Mit HID bist du Plattformunabhängig.

*Versuch mal für eine ältere Webcam oder einen Scanner aus der Zeit Treiber zu finden.
spoiler es wird dir nicht gelingen /spoiler

[jfheins]

Also ich melde mich dann auch mal mit ein paar Sachen:

"C# kann man einfach dekompilieren und den Quellcode offenlegen"
:arrow: Stimmt. Verwendet man jedoch einen Obfuscator, schaut die Sache anders aus. Mit Glück lässt sich der Code nach dem Dekompilieren direkt wieder kompilieren, aber die Logik nachzuverfolgen ist eher nicht drin. (Stell' dir vor, alle Variablen-, Klassen- und Methodennamen bestehen nur aus 2 zufälligen Buchstaben...) Natürlich: Bei einem trivialen Stück Code (Hallo Welt) kann auch der Obfuscator nicht viel machen.

"Ich will nativ entwickeln"
:arrow: Naja, also Firemonkey habe ich jetzt selber noch nicht benutzt, aber es scheint noch ein paar Problemchen zu geben. Und man hat die gleiche GUI auf allen Plattformen (?) Falls dem so ist: Das will man eigentlich nicht. Maus und Finger erfordern grundsätzlich andere Oberflächen.
Mit Xamarin kannst du übrigens auch mit C# nativ für iOS und Android entwickeln. In der kostenlosen Version ist die Anwendungsgröße limitiert. Aber für 300$ wird's unlimitiert. Die GUI musst du natürlich für Mobile Geräte neu entwickeln.
Ich denke es ist nur eine Frage der Zeit, bis .net als "native" gilt, und die WIN32 als "Low Level"

Was in meinen Augen ganz wesentlich ist, ist auch die IDE. Bei Delphi bedeutet das: ErrorInside ( :-P ) und dank Andreas wird die IDE etwas flotter und hat weniger Bugs. Im Visual Studio hatte ich noch nie eine falsch unterstrichene Stelle.

Und dann wäre da vielleicht noch ein Punkt "GUI für Windows".
Win8 ist ja jetzt im kommen - afaik kann Delphi keine Metro-Apps. Und einige Notebooks haben schon FullHD Bildschirme.
Mit WPF skaliert diene GUI völliug problemlos. Im Grunde ist alles vektorbasiert und lässt sich beinahe stufenlos zoomen. Stelle in der Systemsteuerung mal 150 dpi ein und schaue was mit 90% der Anwendungen passiert :-P

Zitat:

ber ich mag „vorgebasteltes“ Zeug nicht so ^^ Wenn möglich, alles selber schreiben. ^^

Naja das hat auch seine Grenzen! Ich hätte keine Lust jedes Mal einen Quicksort wieder neu zu schreiben. Zumal jetzt (endlich...) in .net etwas besseres als Quicksort benutzt wird.

Zitat:

einen JIT-Compiler zu erstellen der die Controls von Pascal benutzt, oder wäre dies dann wieder Pascal und kein Assembler?

Falls dich das reizt: Es gibt PascalScript, damit kannst du zur Laufzeit Code zusammenstellen und Ausführen. In .net geht das übrigens auch.

Zitat:

Ich bedanke mich noch mal für alle Antworten, ich glaube diese haben mich dazu bewegt, mich endgültig zu entschließen FreePascal zu lernen

Sei dir gegönnt. Mein Post ist jetzt vielleicht etwas C# lastig, aber das liegt daran dass ich vor 6 Jahren von Delphi zu C# gegangen bin und es nicht bereut habe.

Btw.: Delphi wird nicht aussterben - weil Delphi besonders rückwärtskompatibel ist. Es kann also getesteter Code oft lange verwendet werden. In C# gibt es noch gar keinen so alten Code. Es wird aber eine Nische bleiben, da die IDE im Vergleich teuer ist und der Entwicklung hinterher hinkt. (Microsoft kann Windows und VS parallel entwickeln, Delphi kann erst weiterentwickelt werden wenn der Windows RC veröffentlicht wird...)

[cookie22]

Zitat:

Zitat von jfheins (Beitrag 1216779)

"C# kann man einfach dekompilieren und den Quellcode offenlegen"
:arrow: Stimmt. Verwendet man jedoch einen Obfuscator, schaut die Sache anders aus. Mit Glück lässt sich der Code nach dem Dekompilieren direkt wieder kompilieren, aber die Logik nachzuverfolgen ist eher nicht drin. (Stell' dir vor, alle Variablen-, Klassen- und Methodennamen bestehen nur aus 2 zufälligen Buchstaben...) Natürlich: Bei einem trivialen Stück Code (Hallo Welt) kann auch der Obfuscator nicht viel machen.

Dass man den Code dekompilieren kann, ist viel weniger schlimm, als sich die meisten eingestehen wollen. Bei 99%, allen Codes, in normalen Anwendungen handelt es sich um 08/15 Code, der keinen interessiert. Die Leute, die Obfuscator benutzen, nehmen sich selbst oft viel zu wichtig. ;)

[Viktorii]

Zitat:

Zitat von milos (Beitrag 1216651)

Oder könnt ihr mir eine andere empfehlen?

Schau Dir mal Qt an:
http://de.wikipedia.org/wiki/Qt_(Bibliothek)

Framework für C++
- plattformübergreifend
- kostenlos auch für kommerzielle Nutzung
- intuitiv und sehr logisch aufgebaut
- extrem umfangreiche, gut verständliche und ausführliche Doku (leider nur englisch)
- Zahllose Beispielprogramme zu fast allen Themen

[D-User]

Zitat:

Zitat von Viktorii (Beitrag 1216848)

...
Framework für C++
...
- kostenlos auch für kommerzielle Nutzung
...

unter der Einschränkung:

Zitat:

Qt can be used under open source (LGPL v2.1) or commercial terms.

http://qt-project.org/

[D-User]

vllt noch interessant zum Thema:

32bit-Version von Lazarus hat von Mitte März bis jetzt ca.
64000 downloads (s. sourceforge);

evtl. interessant zum Schnell-Check aktuell ne neue Möglichkeit:
"Instant Trial" XE4, allerdings mit ziemlich mickriger
Testzeit von 1 monat
http://www.delphifeeds.com/go/s/104486
bis auf die idiotisch kurze Dauer von der Idee her nicht
schlecht, habs aber noch nicht ausprobiert

[messie]

Zitat:

Zitat von milos (Beitrag 1216705)

Naja, man hört überall das es aussterben wird, das wäre ein Grund um nicht Delphi zu lernen.

Oder man trifft heute auf viele Leute, die von Delphi schon mal etwas gehört haben, aber es nicht kennen. Grund ist unter Anderem, dass es in den Hochschulen und Berufsschulen nicht mehr gängig ist. Da hat MS das Visual Studio optimal zu einem Zeitpunkt platziert als nicht klar war ob Delphi "weiter lebt". Embarcadero versucht mit seiner Preispolitik im Kielwasser von MS zu schwimmen hat aber die Vorleistung nicht erbracht. Daher bleibt das Visual Studio im Vorteil - zumal die kostenlosen Express-Versionen sehr umfangreich sind.
Klar auch, dass sich viele beim VS für C# entscheiden - ist es als Abkömmling von Delphi doch das einzig wirklich produktive Tool im MS-Portfolio :wink:.
Ich habe die Projekte, in denen ich Delphi nicht durchsetzen und wir mit C# arbeiten mussten, bitter bereut. Das ging es um große Datenmengen, Performance bei Berechnungen und bei der Visualisierung. Besonders gestört hat mich aber .NET mit seinen Inkompatibilitäten. Eigentlich sollte es ja besonders portabel sein, ist es aber nicht.

[mentaltec]

Zitat:

Zitat von messie (Beitrag 1217074)

Klar auch, dass sich viele beim VS für C# entscheiden - ist es als Abkömmling von Delphi ... im MS-Portfolio

he? das musst Du mir mal erklären

[messie]

Zitat:

Zitat von mentaltec (Beitrag 1217092)

Zitat:

Zitat von messie (Beitrag 1217074)

Klar auch, dass sich viele beim VS für C# entscheiden - es ist als Abkömmling von Delphi ... im MS-Portfolio

he? das musst Du mir mal erklären

Ich habe mal im Netz rausgefunden, dass MS den leitenden Entwickler von Delphi 1 bei Borland abgeworben hat, der dann die Grundlagen von C# geschaffen hat (oder so, ist schon eine Weile her). Mal sehen ob ich den Link noch finde.

Grüße, Messie

[Olli73]

Zitat:

Zitat von messie (Beitrag 1217094)

Ich habe mal im Netz rausgefunden, dass MS den leitenden Entwickler von Delphi 1 bei Borland abgeworben hat, der dann die Grundlagen von C# geschaffen hat (oder so, ist schon eine Weile her). Mal sehen ob ich den Link noch finde.

Hier steht eigentlich schon das Wesentliche drin:

http://de.wikipedia.org/wiki/Anders_Hejlsberg

[mentaltec]

die Welt ist ein Dorf, trotzdem ist die Formulierung sehr gewagt bzw. irreführend

[p80286]

Nicht weitersagen, aber Du bist hier in einem Delphiforum und da ist doch wohl klar was der Nabel der Programmierwelt ist.:wink:

Gruß
K-H

[messie]

Zitat:

Zitat von p80286 (Beitrag 1217120)

Nicht weitersagen, aber Du bist hier in einem Delphiforum und da ist doch wohl klar was der Nabel der Programmierwelt ist.:wink:

Klare Zustimmung :wink::wink:

Ich habe das aber so formuliert wie es sich anfühlte, als ich nach vielen Jahren Delphi mit C# anfing. Ich habe dann oft gedacht bei Delphi war das so gelöst, nun komm' schon, das muss doch auch etwa so gehen. Und es ging dann. Für mich fühlte sich C# durchaus wie von Delphi abgeleitet an. Später habe ich dann nach einem Zusammenhang gesucht, leider bin ich nicht einfach bei dem Wikipedia-Artikel gelandet...

Grüße, Messie

P.S. Einmal Danke-Button an Olli!

[D-User]

vllt zum Thema auch interessant:

1. schönes, professionelles Demo-Projekt in FreePascal/Lazarus:
der Greenfish Icon Editor. Gogl.
Wenn die Autoren so weitermachen haben'se Photoshop bald eingeholt ;-)

2. nette Einführung in Delphi kostenlos hier:
http://de.wikibooks.org/wiki/Delphi

3. Wird durchaus auch noch an Unis weiterentwickelt, hier
unlängst eine FPC Standard lib, man gogl
FPC_StandardLib_INFOL101.pdf

Zitat:

Zitat von messie (Beitrag 1217074)

...
Ich habe die Projekte, in denen ich Delphi nicht durchsetzen und wir mit C# arbeiten mussten, bitter bereut. Das ging es um große Datenmengen, Performance bei Berechnungen und bei der Visualisierung. Besonders gestört hat mich aber .NET mit seinen Inkompatibilitäten. Eigentlich sollte es ja besonders portabel sein, ist es aber nicht.

ich habs jetzt auch schon 2 mal gehört dass Leute über die Portierung einer Delphi-App nach C# ziemlich geflu... haben.

Und mal ehrlich, wieviel Interesse kann MS an einer echten Portierbarkeit von C# haben(abgesehen davon dass es das nach Jit sowieso nicht ist)?
Iso-Normung hört sich zwar toll an, aber man macht das dann halt wie mit dem OOXML: soviel Spezifikation dass kein anderer Laden als einer in der Größe von MS es mehr umsetzen kann.
Kann man MS keinen wirklichen Vorwurf draus machen.

[D-User]

Obfuskator:
auf dieses immer wieder auftauchende etwas dämliche
"ich hab nen Obfuskator deswegen c# etc sicher"-
Argument muss auch noch mal eingegangen werden:

es sollte eigentlich jedem mit etwas "IT-Gefühl" ziemlich klar
sein dass das eine Milchmädchenrechnung ist, wird auch klar
kommuniziert, man beachte das Wort
"grundsätzlich"!!!!!! :
(zudem wirds obfuskiert auch noch langsamer,s.u.)

Zitat:

Möchte sich ein Software-Hersteller vor dem Zugriff Anderer auf seinen Sourcecode schützen, muss er einen erheblichen Aufwand mit fragwürdigem Ergebnis betreiben. Es gibt grundsätzlich nichts, was in der .NET-Welt nicht dekompiliert werden kann (gleiches gilt übrigens auch für die Java-Welt).

. Obfuskatoren verschlüsseln den IL-Code einer Assembly bis zur Unlesbarkeit und erzeugen dabei einen nicht zu vernachlässigenden Performance-Impact, ohne die Software wirksam schützen zu können.

http://msdn.microsoft.com/de-de/library/bb979521.aspx

sehr ehrlicher Artikel von Microsoft.


und auch

Don’t rely on obfuscation:
http://www.codeproject.com/Articles/...on-obfuscation


und es gibt noch diverse weitere Artikel auch aus anderen Quellen,
die alle das Gleiche sagen

[D-User]

für Leute, die eigene weitgehende Präsentation ins Programm
einbinden wollen oder Richtung Gaming 2D oder 3D tendieren sicher sehr beachtenswert:

http://www.delphipraxis.net/176299-p...-new-post.html

[milos]

Nettes Tool, werd ich mir noch ansehen.

Schnell ne Frage: Ich habe gleich mein alpha GUI-System in C# auf einen brauchbaren, stabilen Stand gebracht. Mir sind jedoch noch einige Ideen gekommen die einen Versuvh Wert sein könnten. Ich habe für die Inputs und der Tastatur für das EventHandling ohne WinForms mit MausPosition usw. von .NET in Delphi eine kleine Bibliothek geschrieben und sie in das C# Projekt eingebunden.

Ich will nun eine Form-Schnittstelle für verschiedene Sprachen schreiben, die entweder die VCL oder die LCL (Glaube nehme die, ist ja MultiPlatform-fähig^^) ansprechen und dann in C# verwenden kann. Mein Ziel ist es die C# Projekte zum Teil zu schützen und die Performance dank nativ kompillierter Bibliothek die ja die Forms, Controls, Events und einiges mehr schützt.

Wird die Performance wirklich besser? Ich mein, ich bind die .dll in eine .NET Anwendung ein. xP
Und welche Libary würdet ihr mir grundsätzlich empfehlen. Ich würde eine platformübergreifende bevorziehen. ^^

Oder was ich mir auch noch gedacht habe wäre ne GUI die mit OpenGL gezeichnet wird.
Das würde ich dann in FP lösen.
Aber was sagt die Performance da? Gibts sonst empfehlenswerte Libaries oder denkt ihr sogar ich könnt mich an einer versuchen, hat bei C# ja auch geklappt aber .NET hat viel arbeit weg genommen xD

Würde mich über ne antwort freuen ^^

Mfg

[Phoenix]

Zitat:

Zitat von milos (Beitrag 1216705)

Der Grund warum ich auf .NET verzichten möchte ist wie genannt, dass ich Multi-Platform Lösungen bringen will und ohne das .NET Framework auskommen will. Aber .NET ist schon eine tolle Sache, aber ich mag „vorgebasteltes“ Zeug nicht so ^^ Wenn möglich, alles selber schreiben. ^^

So war ich auch mal drauf. Das Nennt sich "Not invented here"-Syndrom und hat einige Nachteile:

1.) Du investierst viel Zeit damit, Infrastruktur-Code zu schreiben, den jemand anderes schonmal geschrieben hat.
2.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
3.) Du verbringst viel Zeit damit, Dich in problemfremde Domänen (Logging, Datenbankzugriff um nur zwei zu nennen) einzuarbeiten um Deinen Infrastruktur-Code überhaupt schreiben zu können.
4.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
5.) Ausnahmslos jeder Entwickler macht Fehler und produziert Bugs. Am Anfang mehr und trivialere, später weniger, aber dafür schwerer zu findende. Je mehr Code Du schreibst, desto mehr Bugs sind da drin. Du verbringst also einen Großteil Deiner Zeit damit, Bugs im Code für Logging und im Datenbankzugriff (nur um mal zwei zu nennen) zu suchen und zu fixe.
6.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
7.) Der Infrastruktur-Code, der Dein Projekt seinem Ziel nicht näher bringt, ist da. Also muss er gewartet werden.
8.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.

Letzendlich wirst Du, wenn das wirklich so versuchst, Dein Projekt nie zuende bringen weil Du immer erst nötigen Kleinkram schreiben musst bevor Du Dich um die eigentliche Aufgabe kümmern kannst.

Das kannst Du mir jetzt einfach glauben, oder Du wirst diese Erfahrung selber machen. Letzteres wird teuer (Zeit ist Geld, verlorene Zeit rausgeworfenes Geld).


Andere Leute haben viel Zeit in diese Probleme investiert. Die meisten Lösungen gibt es als Open-Source Komponenten die Du einfach reinziehen kannst. Insbesondere im Java- und im .NET Bereich gibt es hier eigentlich *alles* schon fertig. Sogar mit Unit-Tests. Du kannst Dich also auch davon überzeugen das das Zeug zuverlässig funktioniert.

Schau Dir mal (selbst kommerzielle) Delphi-Komponenten an. Wie viele von denen kommen zusammen mit Unit-Tests?


Zudem: Technologisch ist C# lediglich eine Weiterentwicklung von Delphi. Das, was in Delphi run-time Packages sind, ist das .NET Framework. Die Assembler-Optimierungen, die vorhin mal angesprochen wurden und die Du so cool fandest, finden bei .NET durch das Framework statt. Du kannst niemals bei einer statischen Kompilierung auf das konkrete Zielsystem optimieren, sondern Du kannst nur allgemein pro CPU-Typ optimieren. Mit zig ifdefs. Bei .NET / Mono übernimmt das der Compiler der aus Deinem IL-Code Plattformspezifischen Code bastelt. Und der wird regelmäßig von Leuten optimiert, die davon Ahnung haben und die das Hauptberuflich machen. Glaubst Du, Du kannst neben dem eigentlichen Programmieren in Deiner Problemdomäne auch noch CPU-spezifische Optimierungen auf Assembler-Ebene so gut lernen, dass Du es wirklich beherrschst? Und falls ja: Warum machst Du das dann nicht zu Deinem Hauptjob? Solche Leute werden *sehr* gut bezahlt. Okay, das mag jetzt etwas kätzerisch klingen, aber Grundsätzlich läuft es darauf hinaus:

Nutze das, was Dir geschenkt wird, und kümmere Dich nicht um Probleme am Strassenrand für die es schon Lösungen gibt. Sie führen Dich nur von Deinem Weg ab.

Das was ich da geschrieben habe trifft Grundsätzlich zu. Es gibt Ausnahmen. Und die sind vermutlich für Dich sogar im Moment relevant: Solchen Infrastruktur-Code zu schreiben, dabei Fehler zu machen, diese Fehler zu verstehen und zu korrigieren, ist ein wichtiger Teil des Lernprozesses eines Entwicklers. Diese Fehler darfst Du aber in Deiner Ausbildung machen - bezahlt von Deinem Arbeitgeber. Du solltest das Risiko und die Kosten solcher Fehler nicht in Bereichen eingehen, in die Du persönlich kommerziell investierst.

Cross-Platform als Argument gegen .NET aufzuführen wirkt im übrigen eher uninformiert. Wenn Du Cross-Platform bauen magst, ist Mono definitiv das richtige Werkzeug. Wenn Du Mobile Anwendungen schreiben willst, schau Dir Xamarin an. Sehr viele sehr erfolgreicher Anwendungen für iOS, Android und Windows Phone sind damit geschrieben. Viele Mac-Anwendungen sind mit Xamarin geschrieben (und das funktionier hervorragend). Und - nativ ist das auch noch. Xamarin bzw. auch die OS-X Toolchain für Mono kann IL mit den verwendeten Framework-Klassen in ein natives Kompilat herunterkompilieren. Du brauchst keine Runtime auf dem System. Das ist genauso wie bei Delphi, wo die Runtime-Umgebung und die Komponenten (RTL, VCL) auch direkt einkompiliert werden.

Und um nochmal auf die Verwandschaft von Delphi und C# zurück zu kommen:
Delphi ist inzwischen leider technologisch ein massiver Rückschritt von Delphi. Wenn man die Konzepte hinter LINQ (z.B. Expression Trees) einmal richtig kapiert hat, wird die Sprache als Werkzeug sehr elegant einsetzen können und selbst komplexe Aufgaben sehr einfach und verständlich lösen können. Delphi mangelt es da massiv an modernen Sprachkonstrukten. Du würdest also dort auch noch viel Zeit damit verbringen, um dich um unzulänglichen in der Sprache herumzuprogrammieren, während Du das in C# direkt nutzen könntest. Noch so ein Zeitfresser.

Die Qualitätsprobleme der Delphi-IDE wurde ja hier schon erwähnt (Error Insight, falsche Unterstrichelungen in der IDE, sehr beschränkte Refaktoring-Optionen). Im VS wirst Du solche Probleme nicht finden (dazu investiert Microsoft zu viel in die QS-Abteilung als das Embarcadero es jemals wirtschaftlich sinnvoll könnte - das merkt man aber leider am anderen Ende). Und für's VS findest Du zusätzlich noch geniale Helferlein (ich sage nur ReSharper), die einem das Leben nochmal massiv einfacher machen und die Produktivität stark steigern.

Letzlich ist es also auch eine Frage der Effizienz - und die ist mit C# im VS einfach deutlich höher als mit Delphi. Insbesondere dann, wenn Du C# schon kannst. Sonst kommen natürlich immer noch die Umlern-Aufwände dazu, die einen Anfangs ausbremsen, (was immer auch gerne als Argument "gegen X" genannt wird) aber auch die sind nur einmalig da und hinterher schneller wieder aufgeholt als man nachrechnen könnte.

[Olli73]

Zitat:

Zitat von Phoenix (Beitrag 1226183)

Zudem: Technologisch ist C# lediglich eine Weiterentwicklung von Delphi. Das, was in Delphi run-time Packages sind, ist das .NET Framework. Die Assembler-Optimierungen, die vorhin mal angesprochen wurden und die Du so cool fandest, finden bei .NET durch das Framework statt. Du kannst niemals bei einer statischen Kompilierung auf das konkrete Zielsystem optimieren, sondern Du kannst nur allgemein pro CPU-Typ optimieren. Mit zig ifdefs. Bei .NET / Mono übernimmt das der Compiler der aus Deinem IL-Code Plattformspezifischen Code bastelt. Und der wird regelmäßig von Leuten optimiert, die davon Ahnung haben und die das Hauptberuflich machen.

Dazu hätte ich auch mal eine Frage, denn ich habe mich bisher nur oberflächlich damit beschäftigt.

Genau das, was du schreibst, habe ich mir auch immer gedacht; nämlich, dass die .net-Programme nach dem ersten Starten (= "Kompilieren für Zielplattform" ?) ja wegen der Optimierungen für die konkrete Zielplattform schneller sein müssten. Man liest aber immer, dass .net i.d.R. langsamer ist. Woran liegt das nun? Ist es nur die garbage collection? Ist das OS/Framework einfach (noch) nicht gut genug dafür optimiert? Oder stimmen die Aussagen nicht, die man überall so liest?

Also zweites frage ich mich, wie die Zukunft von .net aussieht. Als MS damit gestartet ist, hatte ich es so aufgefasst, dass es zwar zunächst ein Framework/Laufzeitumgebung ist, aber zukünftige Betriebssysteme "darum herum" gebaut werden sollen, also .net das "native Kernsystem" werden soll und "alte" Technologien (Win32, COM, ...) dann nur noch emuliert werden. Also in etwa so, wie Windows am Anfang nur ein Aufsatz für DOS war und später dann DOS in Windows "emuliert" wurde.

.net/C# wird zwar nicht verschwinden, aber oben skizzierten Stellenwert wird es wohl auch nicht mehr erreichen? Hier beziehe ich mich auf die Entwicklung von z.B. Windows Phone. Bei WP7 hat MS noch voll auf C#/.net/silverlight gesetzt. Bei WP8 und Win RT ist die neue "Schlüsseltechnologie" auf einmal ein (modernisiertes) COM. Sieht für mich so aus, als ob MS zwar weiterhin .net/C# supportet, aber nur als Option, mit einem geringeren Stellenwert.

Wäre schön, wenn jemand meine Darstellungen bestätigen oder widerlegen könnte (wie gesagt, habe mich nur oberlächlich damit beschäftigt).

[Robotiker]

Ich denke das ist etwas offtoppic, vielleicht sollte man die Frage abtrennen.

Aber zu zwei Details der Frage gab es erst kürzlich Antworten von MS.

Zitat:

Zitat von Olli73 (Beitrag 1226242)

Als MS damit gestartet ist, hatte ich es so aufgefasst, dass es zwar zunächst ein Framework/Laufzeitumgebung ist, aber zukünftige Betriebssysteme "darum herum" gebaut werden sollen, also .net das "native Kernsystem" werden soll und "alte" Technologien (Win32, COM, ...) dann nur noch emuliert werden.

Zitat:

This is a 199x/200x meme that’s hard to kill – “just wait for the next generation of (JIT or static) compilers and then managed languages will be as efficient.” Yes, I fully expect C# and Java compilers to keep improving – both JIT and NGEN-like static compilers. But no, they won’t erase the efficiency difference with native code, for two reasons.

Ganzer Text
http://herbsutter.com/2012/04/02/rea...-managed-code/

Zitat:

Zitat von Olli73 (Beitrag 1226242)

Also zweites frage ich mich, wie die Zukunft von .net aussieht.

Nun, zumindest kommt kein nativer Ersatz:

Zitat:

The main reason for this is that there are many open questions about what is the future of traditional desktop app development in C++. Certainly, we intend to continue supporting existing code, but there are questions about the future.

Ist aus den Kommentaren hierzu
http://channel9.msdn.com/Shows/C9-Go...ingNative-2013

[Olli73]

Zitat:

Zitat von Robotiker (Beitrag 1226245)

Ich denke das ist etwas offtoppic, vielleicht sollte man die Frage abtrennen.

Da hast du natürlich Recht.

Trotzdem Danke für die Links.

[Phoenix]

Zitat:

Zitat von Olli73 (Beitrag 1226242)

Dazu hätte ich auch mal eine Frage, denn ich habe mich bisher nur oberflächlich damit beschäftigt.

Genau das, was du schreibst, habe ich mir auch immer gedacht; nämlich, dass die .net-Programme nach dem ersten Starten (= "Kompilieren für Zielplattform" ?) ja wegen der Optimierungen für die konkrete Zielplattform schneller sein müssten. Man liest aber immer, dass .net i.d.R. langsamer ist. Woran liegt das nun? Ist es nur die garbage collection? Ist das OS/Framework einfach (noch) nicht gut genug dafür optimiert? Oder stimmen die Aussagen nicht, die man überall so liest?

Das wird jetzt tatsächlich etwas Offtopic, daher hier nur soviel dazu:

Die meisten Aussagen die man überall so liest sind in aller Regel stark in die eine oder die andere Richtung gefärbt.
Sagen wir es mal so: Wenn .NET wirklich in der Regel langsamer wäre, würden wir bei Smarthouse nicht um die 200.000 Wertstellungen pro Sekunde von einer Börse auf einem einzelnen CPU-Kern damit verarbeiten können. Das funktioniert aber. Zugegeben, wir mussten auch dort optimieren und ein gutes Know-How über das haben, was das Framework macht. Aber: Assembler-Optimierung in Delphi braucht ein ebenso tiefes Know-How über das was genau auf der CPU abläuft.

Letztlich muss man sich eingestehen, dass sich das nicht viel schenkt.
Managed Code (sei es jetzt .NET oder auch Java) ist nicht grundsätzlich langsamer, und CPU-Kompilate (der Begriff nativ wurde hier in letzter Zeit deutlich überstreckt) müssen nicht zwangsläufig schneller sein. Es gibt Anwendungsfälle, bei denen managed Code massive Vorteile ausspielen kann, und genauso gibt es Anwendungsfälle wo sich diese ins Gegenteil verkehren und die Software tatsächlich ausbremsen könnten.

Wichtig ist aber vor allem auch ein weiterer Aspekt: Wann kommt es bei einer normalen Line of Business Anwendung denn tatsächlich auf das letzte Quäntchen Performance an, das man aus einem System theoretisch rausquetschen könnte? Unser Marktdatensystem ist da eher eine Ausnahme.

Eine normale Desktop-Anwendung - und das ist das, was mit Delphi üblicherweise erstellt wird - verbringt über 90% seiner Zeit damit, auf User-Eingaben oder auf Antworten von Drittsystemen, meist der Datenbank, zu warten. Wenn eine Eingabe erfolgt, oder Daten zurück kommen, dann muss die Anwendung mal kurz etwas hektik betreiben und versuchen möglichst schnell darauf zu reagieren, aber das beschränkt sich in der Regel auf die Anzeige von Daten oder kurzen Berechnungen. Hier wird man als Anwender keinen Unterschied zwischen managed oder unmanaged Code bemerken können.

Der eigentliche Unterschied zwischen den Systemen liegt hier darin, wie effizient eine solche Anwendung mit den jeweiligen Tools erstellt werden kann und um wieviel Code sich der Entwickler tatsächlich kümmern muss. Die Performance der Entwicklung ist hier aussagekräftig. Und die ist für normale Desktop-Anwendungen nunmal auch in aller Regel dort, wo der Entwickler sein tiefstes Know-How hat.

Selbst wenn der Entwickler jetzt aber ein kompletter Delphi-Crack ist, wird er eine Webanwendung für eine Server-Farm damit nur mäßig schnell umsetzen können. Hier sind andere Technologien gefragt. Und hier spielen dann auch managed Umgebungen einen großen Vorteil aus: Sie skalieren in aller Regel deutlich besser. Wenn man in .NET mit der TPL (Task Parallel Library) arbeitet bzw. mit dem Äquivalent für Java, dann weiss ein managed Framework einfach deutlich mehr über die Plattform auf der es läuft und kann die Nutzung der Systemressourcen (CPU-Kerne und Speicher) deutlichst effizienter steuern als man es mit unmanaged Code jemals könnte (ohne krasse Massen an Infrastruktur-Code, der eigentlich ein eigener Task- und Memory-Manager wäre, womit man seinen Code auch managed machen würde).

Es ist grundsätzlich also immer eine Frage von zwei Dingen:
1.) Ist es überhaupt das richtige Werkzeug für die Aufgabe?
2.) Kenne ich mich mit dem Werkzeug auch gut genug aus um es korrekt zu bedienen oder gibt es Alternativen, bei denen ich mit einem gewissen Einarbeitungsaufwand am Ende effizienter bin und/oder ein besseres Produkt erzeugen kann?

[Robotiker]

Zitat:

Zitat von Phoenix (Beitrag 1226346)

Letztlich muss man sich eingestehen, dass sich das nicht viel schenkt.
Managed Code (sei es jetzt .NET oder auch Java) ist nicht grundsätzlich langsamer, und CPU-Kompilate

Ich denke bei Herb Sutters Aussagen ging es nicht um Geschwindigkeit, sondern um Effizienz.Ein Grund dafür, dass die Windows 8 Runtime in C++ und COM hochgezogen wurde, dürfte Energieeffizienz gewesen sein.

Auf jeden Fall, um die Kurve zum Thema zurückzukriegen, liest man seine Artikel auch bei Emba. So schrieb David I letzten Monat

Zitat:

While I was in Seattle in April presenting our Delphi for iOS release, I also was able to visit with Herb at the Microsoft campus - that was a real honor!

Vielleicht hilfts ja dem FireMonkey. :stupid:

Mit seinem Native-GUI Ansatz steht Delphi jedenfalls heute eher in Konkurrenz zu Qt, als zu anderen C++ Entwicklungsumgebungen an sich. MS entwickelt VC++, abseits der Spieleprogrammierung, eher zu einer Systemsprache für die Entwicklung leistungsfähiger Komponenten für andere Sprachen. (In gewisser Weise löst das auch das angesprochene Dotfuscator Problem.) Gleicher Trend bei IBM, wo es neuerdings wieder C++ unterhalb von Java gibt.

Pascal muss da keine schlechter Ansatz sein, es gibt ja auch noch andere native Ansätze, wie D, Go und Rust. C++ ist nicht per se schneller als diese, sondern weil viele Leute an schnellen C++ Compilern und Bibliotheken arbeiten. Der C++ Builder z.B. ist leider nicht schneller als Delphi, andere Compiler schon.

[D-User]

Zitat:

Zitat von Phoenix (Beitrag 1226183)

Zitat:

Zitat von milos (Beitrag 1216705)

Der Grund warum ich auf .NET verzichten möchte ist wie genannt, dass ich Multi-Platform Lösungen bringen will und ohne das .NET Framework auskommen will. Aber .NET ist schon eine tolle Sache, aber ich mag „vorgebasteltes“ Zeug nicht so ^^ Wenn möglich, alles selber schreiben. ^^

...
3.) Du verbringst viel Zeit damit, Dich in problemfremde Domänen (Logging, Datenbankzugriff um nur zwei zu nennen) einzuarbeiten um Deinen Infrastruktur-Code überhaupt schreiben zu können.

DB-Zugriff ist doch weitestgehend mit Komponenten regelbar, soweit man das nicht selber mit Hand machen will;

Zitat:

Zitat von Phoenix (Beitrag 1226183)

5. ..Entwickler verbringt..Großteil Seiner Zeit damit, Bugs im Code für Logging und im Datenbankzugriff (nur um mal zwei zu nennen) zu suchen und zu fixe.

s.o.

Zitat:

Zitat von Phoenix (Beitrag 1226183)

Die meisten Lösungen gibt es als Open-Source Komponenten die Du einfach reinziehen kannst. Insbesondere im Java- und im .NET Bereich gibt es hier eigentlich *alles* schon fertig.

hmmmmmm, hört sich interessant an:
Dann kann man jetzt die dummen Uni-Abteilungen, die sich mit Algorithmen, theoretischer Informatik etc befassen alle schliessen?
Und das "alles fertige" nur noch in Komponenten packen, so dass dann jeder Laie diese nur noch zusammenstöpseln braucht?

Zitat:

Zitat von Phoenix (Beitrag 1226183)

Das, was in Delphi run-time Packages sind, ist das .NET Framework.

interessant, sind Delphi run-time Packages gemanaged?
Wäre mir jetzt neu



seid ihr bei Remobjects jetzt so sauer auf Emba, weil die euch nen Entwickler geklaut haben? ;-)

[Daniel]

Zitat:

Zitat von D-User (Beitrag 1226364)

Seid ihr bei Remobjects jetzt so sauer auf Emba, weil die euch nen Entwickler geklaut haben? ;-)

Sebastian ist nicht mehr bei RO. :roll: Das hat er nun schon mehrfach geschrieben.

[Furtbichler]

Zitat:

Zitat von Daniel (Beitrag 1226367)

Zitat:

Zitat von D-User (Beitrag 1226364)

Seid ihr bei Remobjects jetzt so sauer auf Emba, weil die euch nen Entwickler geklaut haben? ;-)

Sebastian ist nicht mehr bei RO. :roll: Das hat er nun schon mehrfach geschrieben.

Wenn ich Dir dein Auto klaue und dann weiterverkaufe, ist es nicht mehr geklaut? :roll: ;-)

[mkinzler]

Aber da Sebastian schon länger nicht mehr bei RO ist, kann man ihm dass nicht unterstellen.