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.
ob dus brauchen wirst oder nicht, ums lernen und verstehen kommst du sowiso nicht herum...
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.