Zu Fuß, mit dem Moped oder im Porsche?

  • Das ist ja eine schöne Umfrage und ich bin auch 'mal auf die Ergebnisse gespannt.


    Allerdings gefällt mir die Assoziation mit der Bewegungsart überhaupt nicht. Es gibt Situationen, da ist die eine oder andere Sprache aus unterschiedlichen Gründen im Vorteil (z.B. platzsparend, ist heute selten ein Argument, aber warum muss ein Programm zur Ausgabe von "Hello World" mehrere KB groß sein ?)
    Dazu fehlen mir in dieser Aufzählung Programmiersprachen, die weniger Dummheiten wie die drei zur Auswahl stehenden erlauben (wie PASCAL und Nachfahren, ADA und Nachfahren).
    Ich weiß, diese Sprachen werden meistens nicht für die Entwicklung von SW auf Microcontrollern genutzt :D Aber bei manchen uC-basierten Systemen wäre mir ein hoher Qualitätsstandard doch wesentlich lieber, als Porsche-Programmierung mit den bekannten C-Problemen: was hat ein Pointer mit einer Zahl zu tun ? Eigentlich nichts, aber man kann es einfach durcheinander bringen :whistling:

  • Allerdings gefällt mir die Assoziation mit der Bewegungsart überhaupt nicht.

    Wieso passt doch recht gut, zum Einkaufem am Samstag nimmste lieber das Moped weil du leichter nen Parkplatz bekommst, für die Fußgängerzone am besten die Füße und für ne lange Autobahnfahrt den Porsche :thumbup:

  • Haben die, die abgestimmt haben eigentlich auch eine Erklärung warum sie diese Sprache benutzen? Ich bin mit C angefangen wegen der Flexibilität und der teilweisen einfachen Erlernbarkeit.


    Leider wird in der Berufsfachschule viel zu wenig mit der "C" Programmierung gemacht, stattdesen wird auf Step 7 gesetzt. ;(


    Lg, Franky

  • Ich bin mit java groß geworden, da war die einarbeitungszeit für c einfach die geringste. Wobei ich denke das jeder microcontroller auch mal mit assambler programmieren sollte. Erst durch solch eine hartwarenahe programmierung lernt man den chip erst richtig kennen, das erleichtert dann auch den umgang mit höheren programmiersprachen.

  • ...Leider wird in der Berufsfachschule viel zu wenig mit der "C" Programmierung gemacht, stattdesen wird auf Step 7 gesetzt. ;(
    ..

    Da haben wir doch bereits die Thematik der Auswahlkriterien: Step7 ist (in den Dialekten KOP/FUP/AWL) eben die Sprache der Wahl, wenn man über SPS (in Deutschland) spricht. Lässt sich (neben dem alten Dialekt namens Step 5) auf ca. 90% aller SPS'en nutzen und hilft daher dem, der es erlernt hat, ungemein. Dürfte aber sicher nicht bei allen Berufszweigen an der BFS gelehrt werden.


    Für die, die es nicht wissen: Eine SPS ist eine speicherprogrammierbare Steuerung und wird in der Steuerung von großen und kleinen Industrieanlagen eingesetzt.

  • Ich weiß, diese Sprachen werden meistens nicht für die Entwicklung von SW auf Microcontrollern genutzt :D Aber bei manchen uC-basierten Systemen wäre mir ein hoher Qualitätsstandard doch wesentlich lieber, als Porsche-Programmierung mit den bekannten C-Problemen: was hat ein Pointer mit einer Zahl zu tun ? Eigentlich nichts, aber man kann es einfach durcheinander bringen :whistling:

    Ein Pointer ist eine Adresse ist eine Zahl...!?
    Es gab mal einen schönen Vergleich von Programmiersprachen. Das ging ungefähr so:
    C: Shoot yourself in the foot.
    PASCAL: The compiler won't let you shoot yourself in the foot.
    Außerdem kann man ja C++ nehmen, da fängt der Compiler auch einiges ab.
    Und in C darf man viele Sachen machen, muss es aber nicht.
    Davon abgesehen programmiere ich µC in C.
    Zuerst gelernt habe ich Pascal (Schule) bzw. TurboPascal (Selbststudium) auf dem PC. Wenn es dann mal etwas schneller und 32bittig werden sollte, wurden Assembler-Routinen integriert. Als ich dann aus der PC-DOS-Umgebung auf Windows umgestiegen bin, habe ich auch C gelernt (ebenfalls Selbststudium). Dabei ist es dann auch bei den µC geblieben. Assembler ist ja ganz nett, aber die Wartbarkeit des Codes ist doch eher suboptimal.
    Mit Basic konnte ich mich schon auf dem 64er nicht anfreunden und auch heute gefällt mir Visual Basic nicht, auch nicht 'for Applications'.
    Was mir an C gegenüber Pascal aber überhaupt nicht gefällt ist, dass man keine Funktionen schachteln kann. Also eine Funktion in eine Funktion schreiben, die dann auch nur in der äußeren Funktion lokal definiert ist.
    Und mehrfach verschachtelte Kommentare vermisse ich auch (zum auskommentieren von teilweise auskommentiertem Code).

  • Bisher programmiere ich meine µC überwiegend in Basic, ganz einfach weil ich aus der Basic-Ecke komme. Habe in der Ausbildung VB gelernt und auch schon Jahre zuvor zog sich Basic wie ein Faden durch mein Leben: Basic auf dem TI, Basic auf dem C128D, QB, VB, VBA, BASCOM, ...


    Ein paar meiner µC laufen mit einem in C geschriebenen Programm, allerdings ist da der Code von mir meistens nur angepasst worden, da ich C nicht wirklich gut beherrsche. Aktuell lerne ich aber fleißig C++ (http://www.amazon.de/Die-Progr…ung-Special/dp/382731660X) und will in Zukunft nicht nur, aber auch meine µC damit quälen.


    Abgestimmt habe ich dennoch für Basic, da im Moment ganz klar der Schwepunkt darauf liegt.


    PS: Finde es traurig, dass man von manchen Geeks als Basic-Entwickler total vorverurteilt wird. Ich habe in VB und VBA schon Projekte realisiert die gutes Geld gekostet haben und sich hinter Lösungen in C++, Java oder was auch immer nicht verstecken brauchen. Ich denke ein guter Entwickler beherrscht mehrere Sprachen und nimmt für das vorliegende Problem das geeigneteste Werkzeug. Deswegen arbeite ich ja auch daran meinen Horizont in Richtung C++ und später Java zu erweitern.

  • Etwas (ganz ganz wenig) C beim Studium gelernt. Dann für die Diplomarbeit Assembler gelernt. Für die Arbeit musste ich dann noch einiges in C lernen.
    Privat nutze ich nur Assembler. Gefällt mir einfach besser. Ich weiß immer genau was passiert und wie lange etwas dauert! Und da ich bisher meistens zeitkritische Sachen gemacht habe, passt da assembler eh mehr als C.

  • Ein Pointer ist eine Adresse ist eine Zahl...!?

    Eben nicht !
    Denn was erhalte ich denn, wenn ich (Pointer + Adresse + Zahl) addiere ?
    Wieso muss ich als SW-Entwickler wissen, wie groß Daten sind ?
    Wer stellt denn sicher, dass der Pointer auch wirklich einer ist und nicht in's Nirgendwo zeigt ?
    Dies sind Aufgaben, die ein Compiler vollautomatisch machen kann (und sollte). Die zugehörige Laufzeitumgebung erledigt dann (hoffentlich) den Rest der Überwachung.
    Nur in sehr wenigen (und sehr maschinennahen) Aufgaben kann es
    notwendig werden, dass ich solche "Rechentechniken" benötige. Dann wird
    mir die Programmiersprache vielleicht (wie in Pascal, Delphi oder ADA)
    entsprechende explizite Ausnahmen (die ich dem Compiler ansagen muss)
    erlauben.

    Es gab mal einen schönen Vergleich von Programmiersprachen. Das ging ungefähr so:
    C: Shoot yourself in the foot.
    PASCAL: The compiler won't let you shoot yourself in the foot.
    Außerdem kann man ja C++ nehmen, da fängt der Compiler auch einiges ab.
    Und in C darf man viele Sachen machen, muss es aber nicht.

    Danke für dieses schöne Beispiel. Da kenn ich die Pointe (bzgl. C++) allerdings etwas anders:
    Bei C++ weiß ich nämlich noch nicht einmal, in welchen Fuß ich geschossen habe.


    Das Ergebnis der Umfrage ist auf jeden Fall sehr interessant.

  • Eben nicht !
    Denn was erhalte ich denn, wenn ich (Pointer + Adresse + Zahl) addiere ?

    Wieder eine Adresse=Pointer... Ob das was sinnvolles ist, ist was anderes.

    Wieso muss ich als SW-Entwickler wissen, wie groß Daten sind ?

    Musst du nicht, wenn du keine Pointer benutzt. Wenn du es aber machst, solltest du wissen, WAS du machst. Die Programmiersprache zwingt dich nicht dazu, Zeiger zu verwenden.

    Wer stellt denn sicher, dass der Pointer auch wirklich einer ist und nicht in's Nirgendwo zeigt ?

    Dass der Pointer ein Pointer ist? Die Definition. Dass der auf was sinnvolles zeigt? Der Programmierer. Ich gebe aber zu, dass ich die Zeigerbehandlung in Turbo-Pascal eingängiger fand.

    Zumindest in Turbo-Pascal kann ich auch mit Zeigern rechnen und totalen Unsinn treiben, ohne dass der Compiler was merkt. Ich kann nämlich syntaktisch völlig korrekt riesigen Unsinn bauen.
    Mit maschinennaher Programmierung kann man verschiedene Aufgaben enorm beschleunigen. Dass das keiner mehr ordentlich macht, sieht man an aktuellen Programmen, die immer langsamer werden. Wenn ich dabei von einer Hochsprache unterstützt werde, finde ich das sehr angenehm. Man muss dann nicht gleich zu Assembler übergehen. Da lässt sich dann nämlich Code nicht mehr auf andere Plattformen übertragen. Das andere Extrem ist dann interpretiertes Java. Total Plattformunabhängig aber schneckenlangsam. Macht aber ja nichts, weil die heutigen Rechner schnell genug sind. Haa haa haa, bis auf meinen...


    Aber jeder sollte mit der Programmiersprache programmieren, die ihm (oder ihr) am besten gefällt.

  • Die Kombination von assembler+hochsprache hat für mich zwei vorteile:


    Mit assembler kann ich schlanken code bauen und komme an alles direkt dran,was die Hardware bietet: Ich kann interne Konfigurationsregister des Prozessors beeinflussen,komme an alle Speicherbereiche dran,u.s.w.


    Dafür isses tausendmal komfortabler, einen sinus mit Variable:=sin(andere_variable) zu ebrechnen,als einen ellenlangen assembler-code zu schreiben,und das rad jedesmal neu zu erfinden
    Oder auch string-behandlung: bevor ich mir einen abbreche, um einen binärwert in eine textlesbare zahl (zur bildschirmausgabe,oder tastatureingaben) zu wandeln,lass' ich das die hochsprache machen - read(ln) und write(ln) (bzw die entspr. funktionen bei µcs mit angebundener display+tastatur) tun das automatisch,in assembler würde ich mir da einen abbrechen :whistling:
    da gilt "warum in assembler was programmieren,was die pascal-entwickler für mich schon programmiert und in einem komfortablen befehl abgelegt haben?"


    Dagegen da,wo ich flexibel sein will/muss,oder speicher+rechenzeit sparen will/muss, ist assembler unschlagbar :thumbup:

  • Bei der Flexibilität ist man aber mit einer Hochsprache besser aufgehoben. Was Rechenzeit und Speicherverbrauch angeht, hast du mit Assembler natürlich recht. Aber so richtig Spaß macht zumindest mir der Umgang mit den verschiedenen Adressierungsmodi der verschiedenen Befehle nicht.

  • Ein großteil verwendet wahrscheinlich Bascom (Basic) auch deswegen weil es 1-2 Tage braucht, um ein paar LEDs leuchten zu lassen :) .


    Dazu gibts ja auch die 4kb demo kostenlos. Wenn man dann eben sein Moped tunen will gehts halt weiter.

    -So fresh wie die Créme-


    FSK 6 Es gibt kein richtiges Mädchen
    FSK12 Der Held bekommt das Mädchen
    FSK16 Der Böse bekommt das Mädchen
    FSK 18 Alle bekommen das Mädchen

  • Ein großteil verwendet wahrscheinlich Bascom (Basic) auch deswegen weil es 1-2 Tage braucht, um ein paar LEDs leuchten zu lassen :) .

    In Bascom braucht man 1-2 Tage, um eine LED zum leuchten zu bringen? Ist das so kompliziert? (Oder so langsam?)
    Ok, mit WinAVR muss man sich erstmal in das ganze make-Gedöns einarbeiten. Bei einer kommerziellen Entwicklungsumgebung sieht das natürlich ganz anders aus. Aber wenn man nicht der komplette Neuling im programmieren ist, sollte das auch recht schnell gehen.
    Na ja, ich verwende im Wesentlichen die C-Entwicklungsumgebung von Renesas, da kann die Demo-Version bis zu 64kB Code erzeugen :P.

  • Dafür isses tausendmal komfortabler, einen sinus mit Variable:=sin(andere_variable) zu ebrechnen,als einen ellenlangen assembler-code zu schreiben,und das rad jedesmal neu zu erfinden
    Oder auch string-behandlung: bevor ich mir einen abbreche, um einen binärwert in eine textlesbare zahl (zur bildschirmausgabe,oder tastatureingaben) zu wandeln,lass' ich das die hochsprache machen - read(ln) und write(ln) (bzw die entspr. funktionen bei µcs mit angebundener display+tastatur) tun das automatisch,in assembler würde ich mir da einen abbrechen :whistling:
    da gilt "warum in assembler was programmieren,was die pascal-entwickler für mich schon programmiert und in einem komfortablen befehl abgelegt haben?"

    Naja, aber auch bei asm musst Du nicht jedesmal das Rad neu erfinden oder Dir einen abbrechen, da gibt's ja auch Bibliotheken - habe mir einiges im Netz zusammengesucht, teilweise überarbeitet, auch eigenes, alles in nem lib-Ordner abgelegt... da sind auch Mathe-Sachen dabei, LCD ansteuern, Datenkonvertierung (also 8-Bit-Zahl in 3 Stellen auf dem Display ausgeben etc.), RC-5-Empfang, usw.


    und da macht's ja dann auch nicht (weder vom Komfort noch von der Herangehensweise) den großen Unterschied, ob ich nun Variable:=sin(andere_variable) schreibe, oder den Wert in ein Register lege, "rcall SUB_Sinus" aufrufe und das Ergebnis aus nem anderen Register abhole...


    Klar, irgendwann werde ich mir auch mal C draufschaffen, aber momentan finde ich asm noch einfacher...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!