Druckbare Version
Hallo,
Das glaub ich gerne, und so sollte es auch sein. Und ich finde es auch im Hobbybereich recht angenehm, wenn ich ein Programm schreibe, und mich nach einem Jahr sofort wieder drin auskenne. Wiederverwendbarkeit von Code ist auch privat was Feines.Zitat:
Jobmässig bin ich eigentlich schon froh, wenn ich mich in meinen eigenen Programmen nach einem Jahr noch auskenne, ....
grüsse,
Hannes
µC programmiere ich ausschließlich in C.
In die PC-Programmierung arbeite ich mich noch ein, da setze ich dann auf C++ mit QT
Wohl dem, der seinen Code ausführlich dokumentiert.Zitat:
Jobmässig bin ich eigentlich schon froh, wenn ich mich in meinen eigenen Programmen nach einem Jahr noch auskenne, ....
Ein hoch auf Doxygen
Gruß,
askazo
Du sagst es. :DZitat:
Zitat von Ratber
Genau das meinte Ich.
Ein wichtiger Unterschied zwischen den Programmiersprachen ist, wie man Aufgabenstellungen anpackt.
Nehmen wir als Beispiel die Aufgabe, zu ermitteln, ob eine Zahl durch 4 teilbar ist.
In der Schule im Informatikunterricht, als wir uns mit 4 Leuten einen riesigen Kasten mit 64KB RAM, 8-Zoll Disketten, 2 Bildschirmen und 2 Fernschreibern teilten, war die Standardlösung folgende:
If x/4 = int(x/4) then ...
Unser Basic konnte auf keine Bits zugreifen, Modulo kannte die Basicvariante auch nicht, folglich war diese Lösung gut.
Nur dauerte die Berechnung ewig lange, was ja auch ganz klar ist. Zwei Divisionen, eine Integerfunktion und ein Vergleich ... da gruselt es einem ;-)
Heute würde man vielleicht eher so formulieren:
If (x mod 4) = 0 then ...
(Wenn der Rest von x geteilt durch 4 null ergibt, dann ... )
Das Klingt schon besser ... ein Modulo geht fix, also alles Bestens.
In Assembler geht man die Sache einfach ganz anders an. Man schaut einfach, ob die beiden niederwertigsten Bits 0 sind und ist durch mit der Aufgabe. Aufgrund der vielen Systemabhängigen Assemblerschreibweisen schreib ich das mal nach Schnauze ;-)
Load RegisterA, X
Load RegisterB, &B00000011
AND RegisterA, RegisterB
BranchIfZero ->
Keine Division, und in wenigen Taktzyklen abgearbeitet. Um ein Vielfaches schneller und schlanker, also optimal!
Wenn man nun die Assemblertechnik versteht, dann lassen sich solche Lösungen aber ebenso heute auch in Basic hinbekommen, da viele Dialekte auch Bits testen und manipulieren können.
Ebenso könnte ich auch in Assembler die umständliche Variante mit Divisionen realisieren. Es ist halt nur so, das einem beim Erlernen verschiedener Sprachen auch verschiedene Kniffe beigebracht oder bewußt werden und die sind es, die entscheiden, wie schnell und effizient eine Programmiersprache ist.
Obwohl viele Compiler den Code in gewissen Grenzen optimieren können, werden sie das Grundpinzip, nach dem wir eine Aufgabe angehen nicht optimieren, das müssen wir beim Programmentwurf schon selber machen und hier liegt das größte Potenzial bzw. die größten Schwächen.
Gruß MeckPommER
Wenn ich schnell ein paar Ideen umsetzten will nehme ich meistens C/C++, sowohl für µC als auch für den PC. Bei Zeitkritischen dingen Rund ums Thema µC's greife ich dann doch mal eher Assember zurück.
Ein besondere Freude ist es mir immer, wenn Prof's in Klausuren den Code zu irgentwelchen Algorithmen in einer frei gewählten Programmiersprache haben wollen. Dann nehme ich prinzipiell Brainfuck. O:)
Hi MULTIVAC
(Anmerkung, nicht zum Lesen gedacht: Wieso habe ich das Gefühl, dass Dein Nick nicht Deiner Vorliebe für bestimmte Programmiersprachen entspricht, und eher ENIGMA heissen sollte?)
Ein Kommentar, den ich über BF gelesen hatte, ist mir klar: "Selbst erfahrenen C Programmierern versetzt ein solchen Quellcode erstmal einen Schock." Das war bei mir auch so, obwohl ich gar kein erfahrerer Programmierer bin - wenn ich mich überhaupt als Programmierer bezeichnen kann. Aber schade, dass ich BF nicht kann - wär doch mal hübsch, einen Code für den asuro zu schreiben, und hier zu präsentieren:
so nach dem Motto: ein Linienfolgeprogramm besonderer Art.Code:>+++++++++[<++++++++>-]<. >+++++++[<++++>-]<+. +++++++..+++. [-]>++++++++[<++++>-]<. >+++++++++++[<+++++>-]<. >++++++++[<+++>-]<.+++. ------. --------. [-]>++++++++[<++++>-]<+. [-]++++++++++.
Vergnügte Grüße
Der Name Multivac erinnert mich zunächst an viele Geschichten von Asimov ...
Ich dachte zuerst, brainfu*k wäre nur ein Gag und habe mal nachgeguckt ... sagt mal ... öhm ... was für Medikamente muss man gleichzeitig einnehmen, um auf sowas wie BF zu kommen?
Ich bin wirklich froh, das sich BF nirgendwo durchgesetzt hat, wenn ich mir vorstelle, ich würde an 10MB BF Quellcode sitzen *grusel* :)
Gruß MeckPommER
Ja richtig, der Name MULTIVAC stammt aus einer Asimo-Geschichte. Es handelt sich dabei um eine gigantische Rechenmaschine, die sich um das Wohlergehen aller Menschen kümmert, in dem sie der Menschheit in wichtigen Fragen von, für Menschen unvorstellbarer Komplexität und Auswirkungsverkettung(die ja auch zu unserer Zeit entweder lax tuschiert oder aber brutal selbstsüchtig penetriert wird...nur wollen wir uns da jetzt nicht allzu weit aus dem fenster wagen) nicht nur absolut unbestechlich und mit einer galacktischen Brillianz unterstützt, sonder ihr diese auch komplett abnimmt und die Menschheit so wohl situiert dahinleben kann.
Brainfuck ist gegen einige Eingebungen, die sich Programmiersprachen schimpfen glatt noch harmlos. :) Das interessanteste, was ich in diesem Bezug jemals gesehen habe war MALBOLGE. In dieser Programmiersprache ist es erst ein einziges Mal gelungen ein Programm zu "finden" und das auch erst 2 Jahre nach seiner Entstehung. PIET kann cih euch in diesem Bezug auch wärmstens empfehlen.
(Anmerkung, hier mal etwas, was ENIGMA vllt rechtfertigen würde ;) Acuh und übrigens, nettes Hallo world)
Ein WYSIWYG-PRogramm der...ganz anderen Art. Es generiert ein Sierpinski-Dreieck :DCode:
>
+ +
+ +
[ < + +
+ +
+ + + +
> - ] >
+ + + + + + + +
[ >
+ + + +
< - ] >
> + + > > > + >
> > + <
< < < < < < < <
< [ - [ - > + <
] > [ - < + > > > . < < ] > > >
[ [
- > + +
+ + + +
+ + [ > + + + +
< - ] >
. < < [ - > + <
] + > [ - > + +
+ + + + + + + + < < + > ] > . [
- ] > ]
] + < < < [ - [
- > + < ] + > [
- < + > > > - [ - > + < ] + + >
[ - < - > ] < <
< ] < < < < ] + + + + + + + + +
+ . + + + . [ - ] < ] + + + + +
FROhes SCHaffen
MULTIVAC
Brainfuck ist eigentlich gar nicht so schwer, wenn man sich mal 'n gemütliches Stündchen hinsetzt und sich das genauer anguckt.
Nur sieben Befehle, alles andere ist Kommentar. Und wenn man nicht den ganzen Code in einer einzigen Zeile schreibt, sondern das alles schön kommentiert, kann man sogar manchmal noch durchsteigen.
Gut, für die praktische Arbeit nicht ganz so zu empfehlen, aber irgendwie schon lustig.
Für meine ersten Programme auf dem µC habe ich C genommen, jetzt lerne ich mir grade Assembler an. Ist ja eigentlich doch gar nicht so kompliziert, wie es auf den ersten Blick aussieht.
Aber wenn ich das so'n bisschen kann, werd' ich wohl wieder auf C zurückspringen, weil's doch ein Stück einfacher ist.
Basic habe ich nie verwendet, ich find' das irgendwie eklig.
Ich stimme mal für C, weil das doch die favorisierte Sprache für die µC-Entwicklung ist.
AVR Assembler: für Sensorplatinen mit ATTiny26, wegen Platzmangel für den Code (2k) und Performance, siehe zB
http://freenet-homepage.de/uffmann/Ultrasonic2.html
C: für Hauptplatine, siehe z.B.
http://home.arcor.de/uffmann/ARTIST3.htm
http://freenet-homepage.de/uffmann/E....html#Chapter5