Code Wiederverwertbarkeit
-
Mythos Wiederverwertbarkeit
-
!rr!rr_. schrieb:
zum anderen dürfte ein Teil des problems aber auch in der in Programmiererkreisen extrem verbreiteten do-it-yourself- und "das Rad immer wieder neu erfinden"-Mentalität liegen.
"Mist ... der Editor hat einen grünen Cursor, meine Lieblingsfarbe ist aber orange. Macht nix, mach ich mir eben meinen eigenen Editor. Gibt ja erst x-hundert verschiedene."
Die Existenz von x-tausend Programmiersprachen (4000? 7000? mehr?) und von hunderten, parallel gepflegten *n*x-Distos ist auch nicht gerade geeignet, diesen Verdacht zu entkräften.
Meine ersten beiden C++ Lehrbücher enthielten beide Beispielcode für eine eigene String-Klasse. Eines legt die Stringlänge auf 80 fest. Im andern Buch wird einige Kapitel weiter vorn die STL String-Klasse erklärt, und weiter hinten eine eigene implementiert.
Ein unbedarfter Leser sollte aber im Gegenteil besser davon abgebracht werden, ausgereifte vorhandene Klassen re-implementieren zu wollen, um eben nicht die "das Rad immer wieder neu erfinden"-Mentalität zu wecken.
- die Programmiertechnik ist wahrscheinlich noch zu jung.
In der Mathematik - die ist bekanntlich tausende Jahre älter - würde niemand auf die Idee kommen, Fermats letzten Satz neu zu beweisen, nur, weil er für sein eigenes Theorem eine Schlußfolgerung aus Fermats letztem Satz benötigt. Vorhandene Theoreme werden ganz natürlich wiederverwertet.
In der Mathematik wird man auch bekannte Theoreme nochmal beweisen und zwar zu Übungszwecken genauso ist es wenn man einen String oder eine Liste implementiert.
Außerdem wird das "das Rad immer wieder neu erfinden" auch beim Programmieren immer weniger, je mehr Erfahrung man hat. Da aber hier im Forum meist viele Anfänger sind, kommt es dir so viel vor.
-
Hängt davon ab, welche Sprache man nutzt und welche Patterns eingesetzt werden. Du wirst aber nie mit einer Codebasis die Bedürfnisse aller Nutzer befriedigen können. Wenn man aber z.B. Templates, Policy-Klassen, Strategie-Pattern u.ä. im Design berücksichtigt, kann ein Nutzer zumindest die Codebasis erweitern. Wenn eine Erweitererung/Verhaltensänderung ohne Fork (Copy & Paste) der Codebasis möglich ist, ist schon sehr viel gewonnen.
Ich habe erst letztens aus unserem Inhouse-Framework eine GUI-Klasse durch Copy&Paste für unser Projekt anpassen müssen. Weil die Klasse nicht anders anpassbar war. Ich werde aber die von mir kopierte Klasse an das Framework-Team zurück geben, so das sie diese in die nächste Framework-Version übernehmen können. Dann bin ich wieder bei der "Wiederverwendung"!
Das alle das Rad neu erfinden wollen, hat wahrscheinlich was mit dem Forscherdrang zu tun. Aber man sollte vielleicht auch den wirtschaftlichen Aspekt betrachten, wo man so viel wiederverwenden sollte, wie nur möglich. Ich programmiere ja auch nicht einfach ein neues Betriebssystem, weil ich die meisten Betriebssystem sche*** finde. Wirtschaftlich gesehen macht es Sinn, sie einfach zu benutzen.
-
Bei uns gibt es auch Code, der von mehreren aus dem Team verwendet werden kann. Das sind aber eher allgemeinere Funktionalitäten... Da darüber hinaus vieles Spezialanwendungen sind, deren Code man selten oder garnicht recyclen kann, kommt man nicht umhin das meiste selbst zu programmieren.
-
-
!rr!rr_. schrieb:
Außerdem gibt es in der Mathematik inzwischen nur noch eine weltweit benutzte Notation.
Das stimmt doch schon bei Schulstoff nicht mehr. Man denke nur an die unterschiedlichen Summennotationen, i vs. j als imaginäre Einheit u.ä. Je spezieller es dann wird, umso lustiger wird's dann auch mit der Notation. Ich habe eher den Eindruck, dass die Mathematik auch ziemlich unkontrolliert gewachsen ist (im Sinne von: irgendwann hatte keiner mehr einen Überblick über das ganze Gebilde) und man sich deshalb mit der Wiederverwendbarkeit zwischen den Subdisziplinen etwas schwer tut.
-
Walli schrieb:
i vs. j als imaginäre Einheit u.ä.
In der Mathematik ist das "i" Standard.
In der Elektrotechnik / Elektronik und der Physik wird "j" benutzt weil "i" ja schon dem Strom vorbehalten ist.
-
Ja, da haben wir es doch. Nicht einmal die E-Techniker und die Mathematiker schreiben solche Basics gleich, und da postuliert doch tatsächlich jemand, es gäbe eine 'weltweit benutzte Notation' in der Mathematik. Im Endeffekt frickelt sich bei Kollisionen oder aus Bequemlichkeit jeder die Notation nach seinen Bedürfnissen, was ja auch kein Problem ist, wenn man es vorher anständig definiert oder in jenem Zweig der Mathematik dies und das nun einmal so üblich ist. Aber von _einer_ Notation kann man wohl kaum sprechen. Ohne Erklärung wüsste ich in einer fremden mathematischen Disziplin nicht, was (a,b) heißen soll. Ist das ein Tupel oder ein Skalarprodukt (und wenn ja, welches)? Oder ist es vielleicht noch etwas ganz anderes?
-
Walli schrieb:
Nicht einmal die E-Techniker und die Mathematiker schreiben solche Basics gleich, und da postuliert doch tatsächlich jemand, es gäbe eine 'weltweit benutzte Notation' in der Mathematik.
ja, genau - was erlauben ... !
Die Notationsunterschiede in der mathematik (i vs j ...) sind in den allermeisten Fällen entweder marginal oder vollkommen isomorph (und leicht ineinander umzuformen), in der Regel beides.
Das läßt dann oft schon durch einfaches Suchen-Ersetzen umformen. Man versuche im Gegensatz dazu mal eine Umformung eines ruby Programms nach Scheme ...
Walli schrieb:
Ohne Erklärung wüsste ich in einer fremden mathematischen Disziplin nicht, was (a,b) heißen soll.
Das hängt vom Kontext ab, klar oder? Es gibt aber niemanden, der
%&_a^b
für
gcd(a,b)
schreibt, oder gewöhnliche Formeln im 17er-System und Implikationen mit 3-wertiger Logik schreibt. Und das ist der Punkt.
-
Frag mal nen Analytiker und nen Algebraiker, was ne lineare Funktion ist...
-
Walli schrieb:
Ja, da haben wir es doch. Nicht einmal die E-Techniker und die Mathematiker schreiben solche Basics gleich
Unterschiedliche Communities benutzen unterschiedliche Sprachen.
Nur weil beides irgendwie was mit Mathematik zu tun hat, bedeutet es nicht, dass die selbe Sprache verwendet wird.Wenn sich 2 Mathematiker unterhalten werden die sich ohne Probleme verstehen. Wenn sich 2 E-Techniker unterhalten ebenfalls.
-
mein Analytiker hat gerade keine Sprechstunde
Egal, die beiden werden sich schon verständigen können. Im Zweifelsfall einfach "Homomorphismus" statt "linear" sagen.
-
!rr!rr_. schrieb:
Egal, die beiden werden sich schon verständigen können.
Programmierer werden sich auch irgendwie verständigen können.
-
es geht hier um Verständigung zwecks Wiederverwertbarkeit.
Ein ruby Programmierer wird eine Menge Arbeit investieren müssen, damit eine Schemerin die ruby-Klassen in ihrem Scheme-Programm wiederverwerten kann.
(wobei ruby und scheme hier nur stellvertretend für zwei von 5000+ Programmiersprachen mit weiteren 5000*4999/2-1 = 12497499 Kombinationsmöglichkeiten stehen.)
Einen Mathematiker A kostet es dagegen nur ein Fingerschnippen, das Theorem von Mathematiker B - selbst wenn es hundert oder auch 3000 Jahre alt ist - in seinem Text zu benutzen.
die seit Jahrtausenden andauernde Evolution an mathematischen Notationen ist nunmal ein Vorsprung an Notations-Rafinesse, den die erst ein paar Jahrzehnte alte Informatik so schnell nicht einholen wird.
-
Entropie....;)
Naja, Algorithmen z.B. sind doch recht grundlegend, und wiederverwertbar.
bestimmte Programmiertechniken haben sich bewährt und sind wiederverwertbar.
Es gib eine lange Tradition von Assembleroptimierten Programmen, nur in welchem Algorithums Buch oder welcher Internetseite tauchen diese Erfahrungen/Bibliotheken auf?
Assemblerdidaktik war schon immer irgendwie schlecht, zu allem übel hat man es auch recht oft mit recht ineffizienten und so unleserlichen Asm-Code zu tun.
Was hier fehlt, ist eine Standardisierung, wie sie die Mathematik erfahren hat.Man könnte per Gesetz vorschreiben, dass Hersteller wie Intel Prozessoren nur mit anständig beigepackter Entwicklungsumgebung verkaufen dürfen. Aber wäre der Compiler dann wirklich noch so gut?
Hintergrund: In vielen Musikproduktionen hört man bis zum Abwinken die Werksounds von elektronischen Musikinstrumenten. Musiker sind auch bequem, und setzen mit großer Vorliebe Fertigsounds ein. Und gerade gut gemachte Fertigfunktionen kann man gut editieren, helfen verstehen.Jetzt kommt aber auch noch die Entwicklungsbehindernde Patentregelung dazu. Viele gute Unterprogramme sind patentiert, so mancher Buchcode blöde lizensiert.
Wege zu finden, die dem Wildwuchs der Sprachen entgegenwirken, wäre eine wichtige wirtschaftliche und soziale Basis. Ich denke, das Standardisierung, Einfachheit, Effizienz und Transparenz gute Orientierungspunkte sind. Aber die Standardisierung sollte auch nicht so sein, das man sehr lange braucht, um davon zu profitieren. Zum Beispiel: Bis man C++ Fortgeschrittener ist, hat man längst Assembler gelernt und kann sich den C++ Compiler incl Funktionen selber schreiben.
...Jetzt kommen aber noch die Betriebsysteme mit ihren Eigenheiten und undokumentierten Funktionen. Es wäre an der Zeit, Windows in Open Source umzuwandeln, sämtliche Funktionen gut dokumentiert und wiederverwertbar zur Verfügung zu stellen.
Aber bis das geschehen ist, hat man sich wieder 50 neue Direcx Verionen heruntergeladen, verlangen die neuesten Grafikkarten die neuesten Directx Versionen usw...
Und man bräuchte eigentlich auch eine Hardwarestandardisierung...Mathematische Erkenntnisse sind weniger (Geld-) marktorientiert als Programmierung, könnte man meinen, so dass letztlich auch die Standardisierung, die Didaktik und die Wiederverwertbarkeit oder die Transparenz deutlich besser sind.
Man sieht das Problem aber auch bei der Hardware selber: Mainboards wären normalerweise gut wiederverwertbar, aber finde mal eine standartisierte, auswechselbare Grafik für dein 5 oder mehr Jahre altes Mainboard.
Wenn man für Linux Konsoleprogramme schreibt, hat man eine recht gute Basis für wiederverwertbaren Code, gute Hardwareanbindung, dokumentierte Funktionen und gute, standardisierte Schnittstellen. Was Linux braucht, sind gut ausgearbeitete, standardisierte Pfade durch den Code und Tool - Dschungel
Linux Programmierer müssen sich unbedingt das Prinzip "weniger ist mehr" und den Segen der Open Source Entwicklung vor Augen führen, denn ein Wildwuchs schlecht dokumentierter Open Source Programme ist kaum noch Open Source, hat nicht mehr viel mit Transparenz oder gar Effizienz zu tun.
