Einzelnen Beitrag anzeigen

tommie-lie
(Gast)

n/a Beiträge
 
#46

Re: Vor und Nachteile von Delphi 8 for .net vs c#, vb.net

  Alt 14. Jun 2004, 13:58
Zitat von MaBuSe:
(obwohl das schon recht amüsant zu lesen ist )
Stimmt

Zitat von MaBuSe:
Ich wollte keinen Glaubenskrieg zuwischen den verschiedenen Sprachen anfesseln.
Aber du hast ihn nicht angezettelt...

Zitat von MaBuSe:
Diese Liste wird Teil des Entscheidungsprozesses hier in der Firma sein.
Wie groß ist denn euer Softwareetat? Bei genügend Kleingeld wäre es meines Erachtens sinnvoll, sowohl Delphi.NET, als auch das VS.NET zu kaufen, selbst wenn letzteres nur für einige Arbeitsplätze verfügbar sein wird. Besonders wenn ihr vorher schon Entwickler hattet, die's nicht so mit Delphi hatten und lieber mal ihren C-Compiler angeworfen haben, würde das die Gesamtproduktivität erhöhen, weil sie die C-Leute nicht erst in eine komplett neue Syntax einarbeiten müssen (ich persönlich habe mich in C# sofort wohl gefühlt).
Wenn der Etat sowieso schon zu eng bemessen ist, würde ich auch in Betracht ziehen, die Architects nicht für alle 50 Mitarbeiter zu kaufen sondern den Rest mit Professionals auszustatten. Das mag zwar jetzt ein wenig nach Klassentrennung klingen, halte ich aber in einem solchen Fall, wo der Komplettumstieg nicht finanzierbar aber erwünscht ist, aber für einige die Architect unumgänglich ist, für sinnvoll. Mit dem gesparten Geld bleibt dann auch für das VS.NET übrig.
Wenn vorher ausschließlich Delphi eingesetzt wurde und keiner der 50 Leute auch nur eine if-Bedingung in C oder Basic hinkriegt, wäre es bei knappem Etat sinnlos, sich das VS.NET zu beschaffen, die Kosten für die Weiterbildung wären dann wohl doch eher in einer guten Delphi-Version angelegt als in einem Compiler, mit dessen Sprache keiner umgehen kann.

Du siehst schon, ich würde das nicht von der Sprache an sich abhängig machen, wenn ihr eh alle Delphi und C oder Basic könnt, sondern vielmehr von den aktuellen Firmenverhältnissen. Wenn ihr ohnehin einen großen Ausbau plant und demnächst nochmal 50 Programmierer ins Boot holen wollt, wäre es vielleicht nicht unklug, wenn die neuen Mannen C(#) können, dann würde sich auch das VS.NET lohnen, selbst wenn aus dem alten Team keiner C kann. Da wäre eine Unterteilung in Arbeitsgruppen nach Programmiersprachen eh angebrachter. Die Aufgaben werden dann so auf die Arbeitsgruppen verteilt, daß am Ende Assemblies rauskommen, die sowohl in C#, als auch in Delphi.NET entwickelt wurden, und eingebunden wird es dann in ein Hauptprojekt, bei dem man die Sprache ja auslosen kann
Wenn ihr viel Wert auf Abwärtskompatibilität legt und mit Sicherheit alte Delphi-Projekte nach .NET portieren wollt, ohne sie neuzuschreiben, seit ihr auf jeden Fall auf Delphi.NET angewiesen, aber selbst die VCL.NET hat viele Einschränkungen, was Portabilität angeht, ein wenig dran rumfummeln wird man immer müssen. Da würde ich mir dann auch überlegen, ob der Aufwand der Portierung lohnt, oder ob ich das dann doch neu entwickle, dann auch gerne mit dem VS.NET oder dem CSB.

Alles eine Frage der Umgebung, bei .NET fällt nunmal die Sprache an sich einfach hinten runter, das ist ja Sinn der ganzen Sache.



------------------------------------

Zitat von Hansa:
Zitat von MaBuSE:
ps: Warum schreibt man nicht einfach. Result:=1=0; ist doch viel kürzer alsResult := False; und der Compiler macht das selbe draus.
Genau das habe ich gemeint. Denn in C wird so was auf die Spitze getrieben. Und die Spitze ist noch nicht genug, da muß notfalls auch noch Assembler ran. Da es sich sogar um ein größeres Team handelt, wäre C&Co. für mich allenfalls 3. Wahl.
Ich glaub' ich spinne
In C gibt es die konstanten false und true genauso wie in Delphi auch (und das sogar bequemer/sauberer als in Delphi). Wenn du deinen C-Code so schreibst, weiß ich, warum du meinst, daß das unübersichtlich sei, aber das ist deine Sache, es gibt auch Leute die können vernünftigen C-Code schreiben
Und in C muss man genauso selten auf Assembler zurückgreifen wie in Delphi auch, dafür gibt's nämlich die ganzen C-Bibliotheken, die du bei Delphi auch dabei hast, nur merkst du es da nicht und fragst dich hinterher, warum die Anwendung 300kb groß ist.

Nachtrag: Guck dir mal an, wieviel Assemblercode in den ganzen RTL-Units von Delphi drin ist (Win32), dann können wir uns nochmal drüber unterhalten, daß man in C oft auch noch Assembler ran muss
  Mit Zitat antworten Zitat