andr_gin schrieb:
10% der Arbeit gehen dabei drauf, ein Programm zu schreiben und 90% der Arbeit bei der Wartung,
...
Wenn ich eine Klammer mehr habe, kann ich für die selbe Übersichtlichkeit eine Anweisung weniger schachteln und d.h. eine Zeile mehr.
Seh ich sogar noch strenger. Häufig werden drei bis vier Zeilen kontrollierter Code pro Tag, als sehr gutes Ergebnis angesehen.
Das allerdings direkt an den Klammern oder "end if"s festzumachen, halte ich für Unsinn.
Für Anfänger ist es sicher von Vorteil, wenn der Code dadurch "intuitiv" besser zu verstehen ist.
Für "gute Programmierer" macht das keinen Unterschied.
Du musst ja davon ausgehen, dass die Entwickler sich (spätestens nach einiger Zeit) mit ihrer Umgebung auskennen. (Anfänger natürlich erstmal nicht)
Der Block muss ein Terminierungszeichen besitzen, so ist das System nunmal gemacht. (rekursiver Parser ...)
Ob das ein "}" oder ein "end" ist, macht nicht wirklich was aus.
Was Einrückungen angeht, sehe ich lediglich einen Unterschied zu Sprachen, bei denen sie Einfluss auf den Code haben.
Wenn das nicht vorliegt kann man jeden Code automatisiert formatieren.
(Häufig hängen solche Tools direkt am Versionssystem, so dass beim Einchecken die vorgegebene Formatierung erzeugt wird.)
andr_gin schrieb:
Wenn man akzeptiert, dass man dann Unmengen an Sicherheitslücken durch Buffer Overflows, Speicherlecks etc. hat, dann ist das aber schlecht.
Du hast meine Aussage irgendwie falsch interpretiert.
Wenn C den größten Erfolg verspricht, sind doch genau diese Dinge betrachtet worden.
Erfolgversprechend heißt doch nicht "das finde ich persönlich am coolsten" sondern
"ist nach betrachtung der relevanten faktoren als beste Wahl hervorgetreten".
andr_gin schrieb:
Wenn man sich mit diversen Industriesteuerungen beschäftigt, dann ist das wieder eine komplett andere Welt. Da werden oft noch mit Genuss Programmiersprachen verwendet, die noch nicht einmal Schleifen haben.
Wieso ist das eine andere Welt? Wenn Du das von der privaten "Amateurentwicklung" trennen willst, ok. Dann stimmen auch sicher die Aussagen, dass "}" statt "end" weniger lesbar ist.
Aber jeder von uns kommt tagtäglich mit einer großen Zahl solcher Embedded-Software in Kontakt, eine Zahl die weit höher ist, als die der "gewöhnlichen PC-Software".
Nur weil man sich als private Entwickler oder Anfänger nicht mit sowas beschäftigt, kann man es doch nicht für solche Betrachtungen ignorieren. (Oder die Aussagen gelten eben nur für "Anfänger" und "Laien".)
andr_gin schrieb:
95% der Software, die entwickelt wird, ist Individualsoftware ... aber die reine Rechenzeit der CPU spielt hier absolut keine Rolle.
Mir ist nicht ganz klar, was Du mit diesem Abschnitt sagen willst. Du scheinst immer nur an PC-Hardware mit Ressourcenverteilung wie bei Arbeitsplatzrechnern zu denken.
In der Industrieautomation ist genau das nicht vorhanden. Ein Arbeitsplatzrechner braucht reserven, weil man die genaue Last nicht vorhersagen kann.
Ein Embedded-System wird bis unters Dach ausgelastet. Ist es das nicht, wird die Hardware reduziert. Du kannst Dir bei der großen Stückzahl keine unbenötigten Reserven leisten.
Wenn die Software nur 4K verbaucht, baut man keinen 8K Chip ein etc. (es sei den die Platine kommt als Standard mit 8K und ist deshalb wider billiger, etc.)
Tatsächlich verzichten die meisten dieser Systeme sogar auf ein unterlagertes Betriebsystem.
"Weil wir es nicht brauchen". Du hast 4 Millisekunden um den Airbag auszulösen,
das willst Du nicht durch .NET schicken nur weil da "lesbarerer" Code entsteht.
andr_gin schrieb:
Schlechten Code kann man überall schreiben, aber guten Code eben nicht und genau darum geht es und wenn man keine Exceptions hat, dann wird der Code nie sauber werden.
Sorry, aber das ist Unsinn. Die Aussage widerspricht sich ja selbst.
Wenn es so wäre, könnte man ja gar keine sauberen Routinen fürs Exceptionhandling schreiben.
andr_gin schrieb:
...und wenn sich etwas aufhängt, dann meistens mit einer Segmentation Violation irgendwo und nicht mit einem schönen Stack Trace, wo man das Problem nachvollziehen kann.
Das klingt auch wieder alles sehr nach "PC-Entwicklung mit .NET". Tatsächlich gibt es weit heftigere Fehler, als Segfaults. Aber darum geht es doch hier gar nicht.
andr_gin schrieb:
Support ist sicher bei VB.NET 10 mal besser ...
Ich habe doch auch gar nichts anderes gesagt.
Du führst ganz schön viele Punkte auf, die doch eigentlich mit dem winzigen Thema aus dem letzten Post nichts zu tun haben.
Ich hab doch überhaupt nichts gegen Dein VB.NET. Ich sage nur dass Deine Argumente bezüglich "Lesbarkeit" und "end if" statt "}" etc, nicht wirklich relevant sind, weil es weit wichtigere Argumente gibt, die vorher zu einer Entscheidung führen.
andr_gin schrieb:
Argumente wie "haben wir immer schon gemacht" zählen bei mir nicht. Wenn eine neue Lösung besser ist, dann wird sie gemacht.
Das ist das gleiche Mißverständniss, wie bei "Erfolgsaussichten von C".
Du versuchst das Argument "haben wir schon immer so gemacht", losgelöst zu sehen.
Natürlich entscheidet man sich nicht gegen die "bessere Lösung" mit diesem Argument.
Aber es kann dafür sorgen, dass eine von mehrere Varianten zur besseren Lösung wird.
Routine ist eines der wertvollsten Werkzeuge bei kommerzieller Softwareentwicklung.
(Das die Entwicklung dadurch nicht besonders "spannend" wird ist klar. Und natürlich auch gewollt.)
IceMatrix schrieb:
Das ist eben der Grund, warum C nichts für Anfänger ist. Wenn man diese Sprache programmieren will, dann sollte man schon wissen, was man tut.
Alles hat Vor- und Nachteile.
Gleiches Mißverständnis wie oben. Wenn all diese Argumente gegen C sprechen, wird es sicher nicht die "erfolgversprechendste Sprache" sein, die man für das Projekt verwenden kann. Dazu kommt, dass all diese Punkte gar nicht das Thema sind.
Ich habe mich dazu geäußert das "Lesbarkeit" usw. bei Professioneller Entwicklung kaum ein Argument zur Wahl der Umgebung ist, in der man das jeweilige Projekt umsetzt.
Dieser VB.Net vs C kram klingt ja fast nach nem Konsolenthread.
-- -- muckelzwerg
) und nimmt viel Routinearbeit ab: wie Getter und Setter oder Constructors automatisch zu erzeugen. Auch die Befehlsvervollständigung ist ganz hilfreich, gerade wenn man mal die API-Docs nicht geöffnet hat und nicht weiß, wie genau eine Methode nun heißt und welche Parameter in welcher Reihenfolge sie verlangt.
