Ist RemObjects die Zukunft von Delphi?

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1250888)

Zitat:

Zitat von p80286 (Beitrag 1250887)

Zunächst muß der Code funktionieren, dann sollte er wartbar und verständlich sein!

Falsch. Zunächst sollte der Code verständlich und wartbar sein.

Falsch. Die Reihenfolge ist: Make it work, make it right, make it fast.

Hier nur einmal drei gute von mehreren hundert Artikeln zu dem Thema:
http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
http://cbednarski.com/articles/make-...-make-it-fast/
http://agileinaflash.blogspot.de/200...e-it-fast.html

Und das hat nichts mit mangelndem Qualitätsbewusstsein zu tun.
Zuerst muss ein Problem erstmal grundsätzlich gelöst sein, bevor man sich auf schöne/richtige Lösungen konzentriert.

Es bringt Dir nämlich genau nichts, wenn Du das Problem erst 'schön' angehst, und dann Deinen schönen, lesbaren, wartbaren Code Stundenlang weiterhin schön les- und wartbar herumschubbst, und es am Ende des Tages immer noch nicht funktioniert.

Wenn es funktioniert, dann ist der Code in aller Regel auch ziemlich schnell aufgeräumt. Wenn er dann aufgeräumt ist kann man noch anfangen, ihn zu optimieren ohne ihn wieder kaputt zu machen.

[Sherlock]

Zitat:

Zitat von Phoenix (Beitrag 1250895)

Und das hat nichts mit mangelndem Qualitätsbewusstsein zu tun.
Zuerst muss ein Problem erstmal grundsätzlich gelöst sein, bevor man sich auf schöne/richtige Lösungen konzentriert.

Es bringt Dir nämlich genau nichts, wenn Du das Problem erst 'schön' angehst, und dann Deinen schönen, lesbaren, wartbaren Code Stundenlang weiterhin schön les- und wartbar herumschubbst, und es am Ende des Tages immer noch nicht funktioniert.

Wenn es funktioniert, dann ist der Code in aller Regel auch ziemlich schnell aufgeräumt. Wenn er dann aufgeräumt ist kann man noch anfangen, ihn zu optimieren ohne ihn wieder kaputt zu machen.

Nein. In einer Firma, deren Geschäftsführung schnelle Lösungen erwartet, und auch noch viele Produkte oder Probleme vor sich her wälzt. Ist nach der erfolgreichen Implementierung keine Zeit mehr es dann richtig zu machen. Darum sollte man es im wirklichen Leben lieber gleich richtig machen, sonst schiebt man die garstigen, unkommentierten, un-ge-unit-testeten Tricksereien bis zum Sankt Nimmerleins Tag vor sich her. Und das kann doch keiner wollen.

Sherlock

[jensw_2000]

Trifft doch alles irgendwie zu. Und ich unterstelle mal, dass wir alle schon ein paar Spaghetti-Code Projekte geschrieben haben. :duck:

Das Ansatz - erst funktionell, dann gut - ist ein Kernprinzip beim Testdriven-Development.
Wer nicht testet, muss halt von vornherein so strukturiert und übersichtlich programmieren, dass er selbst jederzeit alles überblicken kann. Sonst besteht eben die Gefahr, dass man Schwachstellen ausliefert oder große Teile des Codes übersichtlicher neu schreiben muss.

[sh17]

Zitat:

Zitat von Sherlock (Beitrag 1250892)

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!

Ich auch

[Lemmy]

Zitat:

Zitat von Sherlock (Beitrag 1250896)

Nein. In einer Firma, deren Geschäftsführung schnelle Lösungen erwartet, und auch noch viele Produkte oder Probleme vor sich her wälzt.

Gibt es auch andere Firmen/Geschäftsführer? Die mal ausgenommen, die kurz vor der Insolvenz stehen bzw sich darin befinden?

Zitat:

Zitat von Sherlock (Beitrag 1250896)

Ist nach der erfolgreichen Implementierung keine Zeit mehr es dann richtig zu machen.

das ist eine Definitionsfrage. Eine erfolgreiche Implementierung ist eben NICHT erreicht, wenn das Programm kompiliert und ein manueller Kurztest des Entwicklers die neue Funktion nicht zum abschmieren bringt.

[jensw_2000]

Zitat:

Zitat von sh17 (Beitrag 1250899)

Zitat:

Zitat von Sherlock (Beitrag 1250892)

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!

Ich auch

So daneben fand' ich meinen Post eigentlich nicht. :duck:
Ok, dann bin ich eben der Einzige, der schon einmal ein Update auf eine "stark überarbeitete Version 2.0" verkauft hat, und dabei eigentlich "nur" den Spaghetticode entwirrt hat. Friede!

[p80286]

[QUOTE=jensw_2000;1250905]

Zitat:

Zitat von sh17 (Beitrag 1250899)

Zitat:

Zitat von Sherlock (Beitrag 1250892)

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!

Ich auch

Ich würde auch gerne bewerten!

Zitat:

Zitat von jensw_2000 (Beitrag 1250905)

Ok, dann bin ich eben der Einzige, der schon einmal ein Update auf eine "stark überarbeitete Version 2.0" verkauft hat, und dabei eigentlich "nur" den Spaghetticode entwirrt hat. Friede!

Nö bist Du nicht. Sobald wieder einmal ein wenig Pflege ansteht, wird auch aufgehübscht. Mit etwas (zeitlichem) Abstand fällt dann auch die eine oder andere nicht so optimale Stelle auf.

Gruß
K-H

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1250882)

Dies nun als Argument anzuführen, das Linq/Delphi/You name schlecht ist, ist schlecht.

Dass es schlecht sei, habe ich ja auch nicht geschrieben. Ich nutze es ja selbst ganz gerne mal (wohldosiert...).

Ich meinte damit nur, dass es damit einfacher ist schlecht lesbaren und dafür kompakten Code zu erzeugen als ohne. Das hat aber nichts damit zu tun, dass es schlecht wäre oder nicht, das war einfach nur eine ungewertete Feststellung.

[Sherlock]

Dann sind wir ja alle wieder auf einer Linie :D

:dp:

Sherlock

[jensw_2000]

Um nochmal etwas Fachliches, bezogen auf die ursprüngliche Frage, zu sagen ...

Für mich ist RemObjects nicht die Zukunft von Delphi.
Die wollen das Produkt auch nicht mal geschenkt haben. ( Bewundert ruhig mein 6 monatiges DDR Schulenglisch. Iss mir nicht peinlich :) )
Allerdings sind Oxygene und C# für mich der Schritt nach Delphi. Ich migriere lebende Projekte momentan zu .Net und fange auch keine neuen Sachen mehr mit Delphi an. Cross Plattform kann RemObjects ganz klar besser als EMBT und an .Net gewöhne ich mich auch schon langsam. Am schwersten finde ich dabei, mir das "alles neu erfinden" abzutrainieren und stattdessen die passenden gemanagten Klassen von .Net zu finden.

[Furtbichler]

Zitat:

Zitat von Phoenix (Beitrag 1250895)

Falsch. Die Reihenfolge ist: Make it work, make it right, make it fast.

Das ist eine Betrachtungsweise. Eine andere ist: Worauf kommt es bei der (Software)Entwicklung vorangig an?
Ich kann ein Problem übrigens grundsätzlich lösen, ohne Code produziert zu haben. Das ist eigentlich meistens so. Und das hat was mit Qualitätsbewusstsein zu tun.

Zitat:

Wenn es funktioniert, dann ist der Code in aller Regel auch ziemlich schnell aufgeräumt. Wenn er dann aufgeräumt ist kann man noch anfangen, ihn zu optimieren ohne ihn wieder kaputt zu machen.

Das geht nur, wenn man (halbwegs) guten Code geschrieben hat. Und das geht nur, wenn man wartbaren Code geschrieben hat. Und das geht nur, wenn man testbaren Code geschrieben hat. Und nur(!) wenn man testbaren Code geschrieben hat, kann man ihn in Ruhe optimieren und aufräumen. Wo fängt es also an? Bei gutem Code und Qualitätsbewustsein? Oder beim 'Hauptsache et läuft'. Schrottcode wird nie guter Code. Nie. Aber guter Code wird sehr schnell funktionieren.

Ich muss dir das alles nicht erklären und die agile Softwareproduktion will ja den Theorieschnulzen endlich das Handwerk legen und das ist auch gut so. Apropos Handwerk: Erst mit einem gewissen Maß an handwerklichem Können wird das 'Make it work, make it right, make it fast' überhaupt machbar. Ein Haus aus Pappkarton, das den ersten Regen abhält, wird niemals ein Haus aus Stein mit negativer Energiebilanz. Aber ein halbwegs gut gebautes Haus kann nachträglich problemlos optimiert werden. Allerdings muss das Fundament und die Mauern stimmen.

Du gehst davon aus, das man automatisch halbwegs knetbaren (=optimierbaren) Code schreibt. Davon kannst Du aber nicht ausgehen, weil das Quatsch ist. Leider. Code ist -ohne das man mit der Peitsche hinter den Programmierern steht- fast immer Müll. Leider meine Erfahrung. Natürlich, wenn man handverlesene Spezialisten hat, die gut geschult sind und sich weiterbilden, dann... klar. Aber nicht bei einem durschnittlichen Frickelverein oder gar einer IT-Abteilung eines Piepenbrinkbetriebes.

[Jens01]

Da muß ich mal kurz eingreifen!

Zitat:

Ein Haus aus Pappkarton, das den ersten Regen abhält, wird niemals ein Haus aus Stein mit negativer Energiebilanz.

Also ein Haus mit Steinen kann man nicht mit negativer Energiebilanz bauen(das gibt es übrigens eigentlich gar nicht). Das geht nur mit Häusern mit Wänden aus Holz.

Zitat:

Aber ein halbwegs gut gebautes Haus kann nachträglich problemlos optimiert werden. Allerdings muss das Fundament und die Mauern stimmen.

Das würde ich erst einmal bezweifeln. Der Aufwand ist meist so hoch, dass Du auch neu bauen kannst. Geht nicht so einfach wie mit Quellcode.

[michaelthuma]

Davon gelebt hab ich auch so ist es ja nicht. Ich verstehe deine Argumentation. Man entkommt eher nicht, da die Kunden und Projekte größer werden zumindest komplexer. Das wäre meine Erfahrung. Dann geht es an. Dann geht es um die Korrektheit. Das schließe ich an sich für Delphi aus bei uns. So weltfremd bin ich nicht. Mit der Hand zu schreiben war bei uns auch keine Option mehr, respektive die große Teile der Anwendung wurden gegen ein mächtiges Framework (selbst) generiert. Selbst das Generat war codeminimal. In dem Umfeld ist/war Delphi keine Option. Es hat so 2003 ein paar Ansätze gegeben die Kosten/Nutzen Relation für größere Projekte ähnlich zu verbessern, aber die sind alle gescheitert.

Die Projekte wie in den 90ern mit Kunden als Partner sind rar. Du bist bei uns in der C# Welt. Ich selbst halt mich eher am MS Stack selbst. Das ist auch eine Form von Purismus ein sehr kuscheliger, wenn es denn mal läuft. Das höchste der Gefühle sind noch Third-Party GUI Controls, aber ganz ganz Sachte und ohne Hersteller spezifischen ORM und ähnlichen Sparänzchen. Darum ist mir jeder Weg außerhalb vom Studio lieber, dass ich gar nicht in Versuchung komme.

Den Traffic von meiner Stadt bezüglich Delphi mache ich wenn man Google Trends nachschaut.

Man soll allein nicht glauben das Konzept des manuellen Codings, respektive des Programmierbüro, über Sprachfeatures am Leben erhalten zu können.

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Dann stehst Du vermutlich auch auf esoterische Programmiersprachen wie Whitespace oder Brainfuck? Viel puristischer geht es ja kaum noch.

Zitat:

Zitat von Medium (Beitrag 1250821)

Und dann gibt es noch Leute, die mit Softwareentwicklung ihr täglich Brot verdienen müssen...

Das ist eher der Punkt. Es geht bei der Sprachentwicklung primär um usability und ease of use.

Jede Zeile die ich als Entwickler nicht mehr schreiben muss, ist schonmal eine Zeile weniger die einen Bug enthalten könnte und eine Zeile weniger die ich testen muss.

Im professionellen (= man verdient Geld damit) Bereich ist man auf Mittel angewiesen, die die Produktivität steigern und es gleichzeitig erlauben, sehr sauberen, gut les- und wartbaren Code zu produzieren der am Ende auch noch funktioniert.

[Furtbichler]

Zitat:

Zitat von Jens01 (Beitrag 1250951)

Da muß ich mal kurz eingreifen!

Und? Was hast Du jetzt davon? Irgendwelche Erkenntisse oder weiterführende Argumente? :roll:

[Insider2004]

Managed Sprachen sind absolut tabu! Wer will schon, dass die Konkurrenz den Sourcecode einsehen kann?

[Union]

Die meisten Entwickler scheinen ja ihren eigenen Code bereits nach wenigen Tagen nicht mehr zu verstehen. Ansonsten muß man das eben verschleiern so gut es geht.

[Medium]

Zitat:

Zitat von Insider2004 (Beitrag 1251013)

Managed Sprachen sind absolut tabu! Wer will schon, dass die Konkurrenz den Sourcecode einsehen kann?

Der Kerl schon wieder :stupid::lol: Wie gehts dir da hinten im Wald so?

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1251013)

Managed Sprachen sind absolut tabu! Wer will schon, dass die Konkurrenz den Sourcecode einsehen kann?

Das gilt für Java ja genauso. Und .NET und Java werden beide gut genutzt, nur eben mit Obfuscator.

Schön ist dann nur, wenn man vom Kunden einen Stacktrace bekommt, dass in Methode axyz eine Exception aufgetreten sei nachdem xcyz aufgerufen wurde... :lol: Da kann man ihm natürlich sofort weiterhelfen...

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1251032)

Schön ist dann nur, wenn man vom Kunden einen Stacktrace bekommt, dass in Methode axyz eine Exception aufgetreten sei nachdem xcyz aufgerufen wurde... :lol: Da kann man ihm natürlich sofort weiterhelfen...

Wieso ist das ein Problem? Jeder guter Obfuscator legt lokal eine Umsetztabelle an so das man auf Knopfdruck wieder Klartextnamen bekommt.

[Furtbichler]

Zitat:

Zitat von Insider2004 (Beitrag 1251013)

Managed Sprachen sind absolut tabu! Wer will schon, dass die Konkurrenz den Sourcecode einsehen kann?

Ich habe in meinem über 30 jährigen Leben noch keine Software gesehen, die es wert gewesen wäre, den Quelltext zu klauen. Mag sein, das es für Trojaner und Viren nicht sinnvoll ist, aber sonst ist 99% der Software so schlecht, das ich die Idee dahinter gerne übernehme, aber den Quelltext lieber nicht.

Weiterhin arbeite ich mit meinen Kunden zusammen. Die können natürlich gerne die Software entschlüsseln, aber falls sie das tun (und ich komme dahinter), bin ich eh finanziell abgesichert. Diese typisch deutsche Kleinkindparanoia ist schon -hmm- wie soll ich es sagen. Ach, gar nicht.

Und: Natürlich gibt es Programme, die schützenswert sind. Die kann man ja in C schreiben (grausligem C). Das kann man zwar auch reverse engineeren, aber wenigstens bekommt der Bösewicht dann diese Pickel und Aussatz.

Beim Insider2004 bezweifliche ich stark, das er überhaupt irgendwelche Software schreibt, die a)schützenswert ist bzw. b)in die Hände anderer gelangt: Denn so trollt nur ein .... Troll.

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1251036)

Denn so trollt nur ein .... Troll.

...den man besser nicht füttert.

[Furtbichler]

Zitat:

Zitat von Phoenix (Beitrag 1251037)

...den man besser nicht füttert.

Guter Tipp. Schwer umzusetzen. Ich übe.