Ist RemObjects die Zukunft von Delphi?

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