Hi, ich werde demnächst mein Studium der Elektrotechnik anfangen. Da ich
schon einige erweiterte Kenntnisse habe und bereits in einigen Projekten
mitwirken konnte und dies auch in Zukunft noch gerne möchte hätte ich
eine Frage: Ist es heuzutage noch lohnenswert in Assembler zu
programmieren bzw gibt es für später noch Zukunftschancen für
Assemblerprogrammierer?
Sicherlich werden hier und da immer wieder solche benötigt, aber ich
meine für einen normalen Anwendungsprogrammierer? Da in letzter Zeit
Rechen- und Speicherkapazität immer günstiger wurden und sicherlich auch
werden denke ich dass es weiterhin mehr auf schnelles, übersichtliches
Programmieren drauf ankommt.
Bisher habe ich meistens, bis au eine Ausnahmen, AVR-RISC Controller in
Assembler und sonstige, meist Windows bzw Windows CE anwendungen in C++
/ C# programmiert.
Ein weiteres Problem sehe ich in der schweren Portierbarkeit von
Assemblerprogrammen
Grüße und Danke
Nur wenn du Assembler mal benutzt hast, weisst du, wie der Prozessor
funktioniert, und kannst, fsalls das mal nötig sein soll, das maximale
aus ihm rauzsholen.
Natürlich wirst du das aus Beqeumlichkeitsgründen nur tun, wenn es nötig
ist, also beschränkt sich der reale Einsatz von Assembler/Maschinencode
auf zeitkritische Projekte und kleinere Programmbereiche, und manche
Leute brauchen es auch in ihrem Berufsleben nie (Warmduscher).
Ausser du willst/musst einen Compiler für dieses Prozessor schreiben,
dann geht es ohne die Kenntnisse der Maschine sowieso nicht.
Wer kein Assembler lernen will, weil ihm das zu viel Aufwand ist, sollte
doch bitteschön Biologie studieren, denn er hat sich im Fach geirrt.
Flo schrieb:
> Ist es heuzutage noch lohnenswert in Assembler zu> programmieren
Ja. Je nach Problem.
> bzw gibt es für später noch Zukunftschancen für> Assemblerprogrammierer?
Wenn du "Assemblerprogrammierer" als Berufsbezeichnung siehst, nein. Der
gemeine E-Techniker macht etwas mehr als nur Assemlberprogrammierung ;)
> Sicherlich werden hier und da immer wieder solche benötigt, aber ich> meine für einen normalen Anwendungsprogrammierer?
Anwendungsprogrammierer? Wo kommen die denn nu her?
> Da in letzter Zeit> Rechen- und Speicherkapazität immer günstiger wurden und sicherlich auch> werden denke ich dass es weiterhin mehr auf schnelles, übersichtliches> Programmieren drauf ankommt.
In der Anwendungsprogrammierung setzt man eben andere Maßstäbe.
> Ein weiteres Problem sehe ich in der schweren Portierbarkeit von> Assemblerprogrammen
Bezüglich was?
Man sollte generell erst das Problem, und dann die Lösung diskutieren.
Nicht Lösungen ohne Problem!
Hi,
nix für ungut, aber fang besser erst mal mit dem Studium an und mach ein
paar Praktika. Dann siehst was heutzutage so gemacht wird.
Assembler programmiert heute keiner mehr (außer vielleicht bei besonders
zeitkritischen Sachen). State-of-the-art ist im Embedded Bereich C.
Grüße...
Der Begriff Assemblerprogrammierer ist Schrott. Mit nur Assembler hat
man ganz kurze Hosen, es lohnt sich eigentlich gar nicht. Etwas mehr
solle es dann schon sein.
Flo schrieb:
> Hi, ich werde demnächst mein Studium der Elektrotechnik anfangen. Da ich> schon einige erweiterte Kenntnisse habe und bereits in einigen Projekten> mitwirken konnte und dies auch in Zukunft noch gerne möchte hätte ich> eine Frage: Ist es heuzutage noch lohnenswert in Assembler zu> programmieren bzw gibt es für später noch Zukunftschancen für> Assemblerprogrammierer?
Unwahrscheinlich. Es ist aber nicht schlecht, Assembler schon mal
programmiert zu haben. Das steigert das Verständnis über die Funktion
von Prozessoren und Controllern ungemein und vielleicht kann man es auch
mal in einigen Projekten anwenden.
Wie man hier im Forum immer wieder feststellt, ist es auch für reine C
Programmierer recht nützlich, wenn man das Ergebnis des Compilers
immerhin lesen und verstehen kann.
Ich denke, Assembler hat durchaus seine Lebensberechtigung. In C oder
einer anderen Sprache sind manche Sachen nur schwer programmierbar. Wenn
ich z.B. an meinen BasicBeetle denke, der wäre bei weitem nicht so
leistungsfähig und so umfangreich, wenn der in C geschrieben worden
wäre. C und auch andere Sprachen, nutzen leider oft 'Umwege', was man in
Assembler erheblich sparsamer und schneller ausführbar hin bekommt.
MaWin schrieb:
> Nur wenn du Assembler mal benutzt hast, weisst du, wie der Prozessor> funktioniert, und kannst, fsalls das mal nötig sein soll, das maximale> aus ihm rauzsholen.>> Natürlich wirst du das aus Beqeumlichkeitsgründen nur tun, wenn es nötig> ist
Mit Bequemlichkeit hat das eher wenig zu tun. Ein Projekt mit einem
Umfang von zehntausenden Zeilen Code und mehr in Assembler durchzuziehen
wäre reichlich weltfremd.
Also meiner Meinung nach ist es selbstverständlich, das man den
Assemblercode des Prozessors mit dem man gerade arbeitet, kennt und auch
versteht.
Jedoch ist ist es schon sehr weltfremd ein Projekt heute noch in reinem
Assembler zu realisieren. Das ist was für Bastler aber nicht für
Profis...
Das Verständniss von Prozessoren auf Assemblerebene finde ich schon
ziemlich wichtig. Es hat mir die letzten 20 Jahre viele Vorteile
gebracht, auch wenn ich ausser für private Bastelprojekte nur noch
'Hochsprachen' verwende.
Wenn Du sehr schnell und günstig einige überschaubare Funktionen
realisieren möchtest, ist ein 8-Bit-Mikrocontroller häufig besser
geeignet als ein 16-Bit- oder 32-Bit-Mikrocontroller.
Wenn die Applikation zeitkritisch ist und zudem noch sehr stabil laufen
muß, bietet Assembler oft Vorteile gegenüber Hochsprachen.
Kleine Regler, Zeitrelais, Lampensteuerungen, Motorsteuerungen,
Datensplitter etc. werden deshalb oft in Assembler programmiert und
bieten so Vorteile gegenüber Wettbewerbsprodukten.
Assembler dient mir heute noch haeufig, wenn ich Erbsen zaehlen muss. Da
die Hochsprachen aber heute so einfach Assembler Sequenzen einbinden
koennen, sei es als assembliertes Objekt oder direkt im Code, bietet es
sich einfach an beides zu mischen.
Komplexe aber z.B. zeitlich unkritische Dinge in einer hoeheren
Abstraktionsebene loesen und fuer die wirklich kritischen Dinge, wo man
die absolute Kontrolle behalten will oder muss, Assembler Routinen
einbinden.
Ich würde auch sagen, C ist die dominierende Sprache, weils einfach
"schneller" zu programmieren geht und besser lesbar ist.
Assembler ist wichtig,
- wenn funktionalitäten sehr schnell abgebildet werden sollen (wenn man
Erbsen zählen muss, um mich meinem Vorgänger anzuschliessen),
- wenn man den code schrittweise nach fehlern durchsieht, um zu
verstehen, was der Core da wirklich macht (hinter den C instructions)
- wenn man effizient C programmieren will, ist etwas asm Wissen
hilfreich, wenn man weis, was der Compiler ungefähr wie umsetzt
- für die Taktgenaue Abarbeitung einer Routine / Funktionalität, da man
nur dann wirklich die volle Kontrolle über den Core hat
Und noch was zu C:
Keinesfalls vor Pointern zurückschrecken, wenn man sie einmal verstanden
hat, sind sie ein super Werkzeug!
VG,
/th.
> Ist es heuzutage noch lohnenswert in Assembler zu> programmieren bzw gibt es für später noch Zukunftschancen für> Assemblerprogrammierer?
Nur Assembler ist zu wenig. Diverse Assembler-Dialekte und einen Stapel
Hochsprachen kommt eher hin.
Nur ein Stapel Hochsprachen tut es auch.
Nur diverse Assembler-Dialekte schränkt stark ein.
Wenn Du Elektrotechnik studieren willst, wirst Du zwangsläufig Assembler
programieren müssen. Das hat weniger damit zu tun, daß man es später im
Beruf noch massiv braucht. Viel wichtiger ist, daß man durch Assembler
den Controller und die hardwarenahe Funktionsweise kennenlernen muß
(Programmiermodell, Adressierungsarten usw.) Diese Kenntnisse sind auch
für Hochsprachen im embedded Bereich sehr wichtig (Debugging). Mit
anderen Worten wird Assembler genutzt, um dem Studenten hardwarenahes
Denken beizubringen. Im späteren Berufsleben ist Assembler außer in
zeitkritischen Routinen fast völlig verschwunden wegen schlechter
Wartbarkeit, Wiederverwendbarkeit und den strikten Bezug auf nur eine
Zielhardware. Im Bereich DSP hingegen sind manche Funktionen
(Parallelität bei Harvard-Architekturen) immer noch Assembler
vorbehalten.
Übrigens...
neben Assembler programmiere ich in den Sprachen
- C
- C++
- Basic
- Pascal
- Perl
- Java
- Delphi
- (HTML)
... und das, obwohl mein Schwerpunkt eindeutig im Bereich der
Hardwareentwicklung liegt.
Das sind aber alles nur Mittel zum Zweck: Meine eigentliche Aufgabe
besteht darin, Projekte unter knappen Zeit- und Kostenvorgaben zu
realisieren. Die Erstellung von Programmen verschlingt daher nur einen
Bruchteil meiner Arbeitszeit.
Jedenfalls hat ein Russen-DOS auf eine Diskette gepasst, wo MS 3-4
gebraucht hat.
Die Summe aller Übel bleibt immer gleich:
Entweder man programmiert in Assember ewig und hat ein schnelles
Programm oder schnell in einer Hochsprache und hat eine langsameres,
sppeicherhungrigeres Programm was evtl. weniger Faselfehler aber dafür
evtl. Compiler oder Interpreter-Fehler haben könnte.
Heute haben wir Java und sind schon bei Version ....
>neben Assembler programmiere ich in den Sprachen>- C>- C++>- Basic>- Pascal>- Perl>- Java>- Delphi>- (HTML)
Du bist ja ein Held!
Kannst ja alles - also nichts richtig!
Ich nehme an, du hast dich konkret über ihn informiert, bevor du ihm so
etwas vorwirfst. Denn so ungewöhnlich ist es nicht, im Laufe der Zeit
mit vielen Sprachen zu tun zu haben, oft gleichzeitig.
Zumal die bis auf HTML allesamt aus der gleichen Sprachgruppe stammen,
sich strukturell stark ähneln (nur die Objektorientierung differenziert
noch etwas). Davon abweichend wären beispielsweise Sprachen wie Prolog
oder LISP.
Ob man vorteilhaft in Assembler oder einer Hochsprache programmiert,
hängt tatsächlich vom Anwendungsfall ab. Bei harten Echtzeit-Anwendungen
kommt man oft nicht um Assembler herum.
Beispiel: Es sollen mit einem DSP 8 Kanäle mit IIR-Filtern 4. Ordnung
bei einer Abtastrate von 2 MHz gefiltert werden. Zielprozessor ist ein
SHARC, z.B. ein ADSP-21363 mit 333MHz Core-Clock (3 ns Taktzyklus).
Das ganze Framework wird in C geschrieben, einschließlich der
Konfiguration der DMA-Kanäle für die Kommunikation mit den ADC- und
DAC-Bausteinen.
Je nach Struktur der Biquads braucht ein Filter 4. Ordnung 8, 10 oder 12
Taktzyklen, also bei 8 Kanälen und fs=2 MHz bis zu 192 Mio. Zyklen pro
Sekunde, beinahe 60% der verfügbaren Rechenleistung. Das Ergebnis ist
nur mit Assembler-Programmierung zu erzielen.
Spätestens, wenn man SIMD-Instruktionen des SHARC verwendet ist es mit C
vorbei. Man kommt dann zwar mit der Hälfte der Zyklen aus, aber nicht
mehr ohne Assembler.
Was für einen DSP bei 2 MHz gilt, gilt für einen Mikrocontroller bei
entsprechend längeren Abtastperioden.
Dennoch schreibt man Code nur dann in Assembler, wenn es unvermeidlich
ist, denn - unabhängig von der Portierbarkeit - kostet es ungleich viel
mehr Zeit, in Assembler zu kodieren im Vergleich zu C. C und Assembler
lassen sich bei Beachtung der Call/Return-Regeln mischen, bei anderen
Hochsprachen ist es nicht ganz so einfach.
Noch ein Tipp: Auch wenn man in C programmiert, sollte man gelegentlich
den Assembler-Code ansehen, um zu verstehen, was der Compiler mit dem
Quellcode gemacht hat. Beim Debuggen (Single Stepping) lernt man auch
verstehen, wie eine CPU - egal welche - funktioniert. Viele
Programmierer, auch solche im Embedded-Bereich, haben noch nie etwas von
Registern gehört!
Soviel wollte ich gar nicht schreiben, aber es gibt keine binäre
Antwort.
Danke für die Aufmerksamkeit!
Andreas Bayer
@ gast
Da ich nach Deiner Interpretation sehr viele "Helden" kenne, vermute ich
eher, daß Du die Anforderungen in manchen Berufen etwas unterschätzt.
Schau Dich mal bei den Leuten um, die in einer höheren Liga als Du
spielen.
>Viele Programmierer, auch solche im Embedded-Bereich, haben noch nie etwas >von
Registern gehört!
Vielleicht haben sie auch eine Akkumulatormaschine? ;-)
Ich glaube, jeder Embedded-Programmierer hat schon mal was von
Register-/ Akkumaschine, Harvard-/von Neumann-Architektur,
Mnemonischen/Algebraischen Assembler gehört.
>Viele Programmierer, auch solche im Embedded-Bereich, haben noch nie etwas >von
Registern gehört!
Ja ne is klar. Ist das "nur" eine Hypothese oder empirisch untermauert?
Wer im Embedded-Ozean taucht, der kennt sich auch mit Registern aus.
Ganz sicher!
Ansonsten ist es kein low-level-Programmierer. Sondern maximal ein
Codiersklave auf Anwendungsebene.
Informiert im Bereich der Elektrotechnik bin ich, soweit ich das
beurteilen kann zu genüge. Ich habe eine Ausbildung als Eöektroniker für
Geräte und Systeme erfolgreich abgeschlossen und nun ein Studium mit dem
Schwerpunkt Informationstechnik angeboten bekommen.
Da ich neben der Ausbildung und auch schon davor in mehreren Projekten
(auch kommerziel) mitarbeiten durfte und entweder µC-, Windows Ce- oder
Windowsprogramme schrieb, kann ich schon von mir behaupten, dass ich mir
ein gutes Grundlagenwissen aneignen konnte.
Programmiert habe ich die Controller (AVR) in Assembler, die Windows Ce
Anwendungen in C# und die Windowsanwendungen meist in C++ bzw auch C#.
Andere Programmiersprachen sehe ich für mich als keine Alternative,
außer eben JAVA.
Die Frage ist nur, ob es für die Zukunft lohnenswert ist Projekt noch in
Assembler realisieren zu können, da Ressourcen heutzutage für einiges
weniger an Geld als früher zu bekommen sind.
Sicherlich hat ein Programmierer zu Wissen wie ein System bzw Prozessor
arbeitet.
Unter Portierbarkeit verstehe ich z.B. dass ein in C++ geschriebenes
Programm m.H. des richtigen Compilers auf den meisten Umgebungen zum
laufen gebracht werden kann. Was bei Assembler nicht unbedingt der Fall
ist.
Gerade heutzutage, so kommt es mir vor, als Technikfortschritte nur von
geringer Dauer bis zum nächsten Fortschritt sind, ist es nicht unebdingt
sinnvoll ein komplettes System von A-Z auswendigzukönnen, sorndern es
soweit zu beherrschen, dass man die vorgegeben tasks realisieren kann.
Anstoß gegeben hat mir u.a. folgendes:
[ZITAT] Unter dem Aspekt der Geschwindigkeitsoptimierung kann der
Einsatz von Assemblercode auch bei verfügbaren hochoptimierten Compilern
noch seine Berechtigung haben, muss aber differenziert betrachtet und
für die spezifische Anwendung abgewogen werden. Bei komplexer
Technologie wie Intel Itanium und verschiedenen DSPs kann ein Compiler
u. U. durchaus besseren Code erzeugen als ein durchschnittlicher
Assemblerprogrammierer, da das Ablaufverhalten solcher Architekturen mit
komplexen mehrstufigen intelligenten Optimierungen (z. B.: Out-of-Order
Excecution, Pipeline-Stalls, …) hochgradig nichtlinear ist.
[/ZITAT]
In welcher "Liga" ich spiele weiß nur ich.
Die tollen Freiberufler (ich bin auch einer...) müssen immer ALLES
können, damit sie Aufträge bekommen. Da wird dann was
zusammengeschustert und gut.
Aber als Profi kann man nicht alles RICHTIG können. Mann kann zwei, drei
Sachen RICHTIG gut. Den Rest kann man wie der Durchschnitt. Man bekommt
es hin, aber gut ist was anderes. Wird ganz gut bezahlt und fertig.
Ein Profi fängt da an, wo solche Leute die Segeln streichen. Und da
kannst Du auch ein paar Euros mehr die Stunde bekommen.
Um es deutlich zu sagen: Ich mache das Geschäft schon über eine
Generation. Durch die Zeitarbeitsfirmen wird es immer schlimmer. Die
Leute können alles, damit sie unter kommen. Aber RICHTIG können sie
leider (fast) nichts. Früher gab es in jeder Firma noch den ein oder
anderen Profi - leider sterben die aus, da Sie von dummen Chefs nicht
mehr unterstützt werden.
Zum Thema:
Lern Assembler, Du wirst es es nur zu 1% deiner Arbeitszeit verwenden,
aber das unterscheidet Dich dann vom Durchschnitt!
>Lern Assembler, Du wirst es es nur zu 1% deiner Arbeitszeit verwenden,
Um Assembler wird er wohl bei einem Studium nicht herumkommen, zumindest
nicht im Bereich Nachrichtentechik.
Flo schrieb:
...
> [ZITAT] Unter dem Aspekt der Geschwindigkeitsoptimierung kann der> Einsatz von Assemblercode auch bei verfügbaren hochoptimierten Compilern> noch seine Berechtigung haben, muss aber differenziert betrachtet und> für die spezifische Anwendung abgewogen werden. Bei komplexer> Technologie wie Intel Itanium und verschiedenen DSPs kann ein Compiler> u. U. durchaus besseren Code erzeugen als ein durchschnittlicher> Assemblerprogrammierer, da das Ablaufverhalten solcher Architekturen mit> komplexen mehrstufigen intelligenten Optimierungen (z. B.: Out-of-Order> Excecution, Pipeline-Stalls, …) hochgradig nichtlinear ist.> [/ZITAT]
Man benenne mir den DSP, der in C effizienter (nicht bequemer!) zu
programmieren ist als in Asm!
Und: Ich habe Embedded-Programmierer kennengelernt, die nichts von
Registern wussten. Software von NI oder ähnlichen High-Level-Tools
machen's möglich.
Auch Fahrkarten-Automaten gehören in die Kategorie "Embedded"; sie
laufen oft unter WinXX, weil's bequem ist.
Gruß,
Andreas Bayer
Nur mal als Einwurf: Ein wirklich interessantes Forschungsgebiet ist das
der languages & compilers. Dort kannst du mit guten Maschinen- und
Assembler-Kenntnissen sehr viel anfangen.
Vorteil: Es können nicht viele Leute; heutzutage fast nur noch die
Freaks, die sich zB dem reverse engineering verschrieben haben. Oder
eben die embedded / real-time Profis. Das ist auch eher eine Minderheit.
Wichtig ist für jeden(!) Programmierer, die Abstraktion von der Maschine
zur Hochsprache zu verstehen. Das ist grundlegend und reicht für das
Gros vollkommen aus.
G. Ast schrieb:
> Also meiner Meinung nach ist es selbstverständlich, das man den> Assemblercode des Prozessors mit dem man gerade arbeitet, kennt und auch> versteht.
Das sollte eigentlich selbstverständlich sein, denn nur so lernt man den
Prozessor und sein Innenleben richtig kennen und nutzen.
> Jedoch ist ist es schon sehr weltfremd ein Projekt heute noch in reinem> Assembler zu realisieren. Das ist was für Bastler aber nicht für> Profis...
Sorry, ich würde mich selbst als fortgeschrittenen Bastler bezeichnen,
programmiere seit ca. 20 Jahren in verschiedenen Assembler-Dialekten und
behaupte mal, dass ich es halbwegs kann. Trotzdem bin ich aktuell dabei,
mich in C einzuarbeiten, um aktuelle Prozessoren richtig nutzen zu
können. Verschiedene Libs wie SD-Card, FAT oder USB sind fast nur noch
in C verfügbar. Also habe ich die Wahl, auf die genannten Features zu
verzichten oder halt über den eigenen Tellerrand hinaus zu schauen.
Das hat aber m.E. nichts mit Bastler oder Profi zu tun.
Die Zeit wandelt sich auch: früher begann man mit Assembler und kam dann
zur Hochsprache; heutzutage beginnt mit Java (sogar noch
plattformunabhängig) und hört dann irgendwann dass es noch eine
Maschinensprache gibt.
Viele Programmierer verkommen, sie werden Anwender von
WYSIWYG-Drag-Drop-Click-Software...
Andreas Bayer schrieb:
> Flo schrieb:> ...>> [ZITAT] Unter dem Aspekt der Geschwindigkeitsoptimierung kann der>> Einsatz von Assemblercode auch bei verfügbaren hochoptimierten Compilern>> noch seine Berechtigung haben, muss aber differenziert betrachtet und>> für die spezifische Anwendung abgewogen werden. Bei komplexer>> Technologie wie Intel Itanium und verschiedenen DSPs kann ein Compiler>> u. U. durchaus besseren Code erzeugen als ein durchschnittlicher>> Assemblerprogrammierer, da das Ablaufverhalten solcher Architekturen mit>> komplexen mehrstufigen intelligenten Optimierungen (z. B.: Out-of-Order>> Excecution, Pipeline-Stalls, …) hochgradig nichtlinear ist.>> [/ZITAT]>> Man benenne mir den DSP, der in C effizienter (nicht bequemer!) zu> programmieren ist als in Asm!
Wie ich schon zu Anfang schrieb, erst das Problem betrachten, dann die
Lösung. Ein Intel Itanium ist nicht wirklich ein DSP. Ein DSP mit einer
Out-of-Order Execution wäre eher unnütz.
Wie du schon gesagt hast, es gibt keine binäre Antwort auf die Frage
"Assembler" ja oder nein. Gäbe es etwas wie universelle Werkzeuge, hätte
man in der Küche nicht so viele verschiedene Messer. Da stellt es auch
niemand in Frage, wenn man fürs Steak ein anderes Messer als fürs Brot
verwendet.
Pofet schrieb:
> Viele Programmierer verkommen, sie werden Anwender von> WYSIWYG-Drag-Drop-Click-Software...
Erkläre mal, warum es ein "Verkommen" darstellt, wenn man für eine
moderne Anwendung mit graphischer Oberfläche ein Tool verwendet, das
technisch aus der gleichen Generation stammt wie die Anwendung, die man
entwickelt.
Das "Zusammenklicken von Oberflächen" hat ja grade in RAD Umgebungen den
Vorteil, dass man schneller zum Kern der Anwendung und damit zur
Funktionalität kommt. Auf Kosten der Resourcen. Aber was ist billiger,
eine Programmierer-/Ingenieurs-/Informatiker-Stunde oder 1MB RAM und
0,1s verlängerte Startzeit?
Wenn du allerdings Drag-Drop-Click Tools für Embedded meinst, das ist
wieder ein anderer Schuh. Dort spielen die Resourcen eine größere
Rolle...
Hallo,
ich programmiere alles in ASM, ganz einfach weil es mir Spass macht.
Natürlich dauert alles ein bisschen länger, aber die Zeit habe ich, da
ich nur in meiner Freizeit programmiere.
Meiner Meinung nach würde sich in bestimmten Anwendungen auch ASM in
Kommerziellen Geräten lohnen. Ein gutes ASM Programm ist immer kürzer
und schneller als ein gleichwertiges Programm in einer Hochsprache. Auch
zu bedenken ist das nicht nur der Preis des (grösseren und schnelleren)
MC eine Rolle spielt sondern auch die Platine die u.U. für höhere
Frequenzen ausgelegt sein muss.
Kann sein dass ich mich irre, ich glaube jedenfalls das wenn die
Stückzahlen stimmen die längere Entwiklungszeit in kauf genommen werden
kann.
Bestes Beispiel: Mein neuer LCD TV. Wenn ich da durch das
Einstellungsmenü zappe, schläft mir das Gesicht ein.
Zum Glück muss ich nicht beruflich programmieren. Mir würde es in der
Seele wehtun wenn ich einen M32 mit einer Hochsprache programmieren
müsste, und dabei wüsste das in ASM ein Tiny2313 reichen würde. (Naja,
ist vielleicht ein bisschen krass :-))
In erster Linie meine ich den low-level-Bereich. Dort ist
Maschinen-Verständnis zwingend notwendig.
Ansonsten klar: Für GUIs gibt es schöne Builder, das spart Zeit und ist
zudem noch qualitativ hochwertig.
Aber mal im Ernst:
Jeder (fast) Informatik-LK-Schüler könnte das machen, was ein Großteil
von einfachen Codiersklaven (viele sogar mit M.Sc. oder Diplom)
tagtäglich werkelt.
Da bin ich gerne embedded-Entwickler, das kann zumindest nicht jeder
Schüler.
Pofet schrieb:
> Aber mal im Ernst:> Jeder (fast) Informatik-LK-Schüler könnte das machen, was ein Großteil> von einfachen Codiersklaven (viele sogar mit M.Sc. oder Diplom)> tagtäglich werkelt.
Das ist je nach dem so eine Sache. Die (ernsthaften) Anwendungen, die
mit den entsprechenden Frameworks und Tools entwickelt werden (nur als
Beispiel: .net Framework und Visual Studio), sind eher größere Business
Lösungen.
Diese Lösungen leben mehr von einer sinnvollen Architektur,
entsprechenden Datenmodellen, deren Abbildung auf Datenbanken,
Anpassbarkeit an entsprechende Aufgabenstellungen. Im groben Sinne also
von einem guten Objektmodell und dessen Beherrschung.
Diese "Planungssache" kann ziemlich umfangreich werden und erfordert
Erfahrung. Wenn man allerdings über die Planungsphase hinaus ist, wird
programmiert. Und sobald man eine "Anleitung" in Form einer
Klassenhierarchie o.Ä. hat, ist Programmieren "nur" noch "abschreiben"
und hat nicht mehr allzuviel mit dem Schöpfungsprozess zu tun.
Wenn man in einer Softwarefirma arbeitet, muss man schaun, dass man
beides tun darf, ansonsten wird der Job schnell öde.
