Spätestens wenn man die Frage damit beantwortet, dass z.B. die Datenpuffer von BufferedImages seit Java7 nicht mehr als „gestohlen“ markiert werden können, weil „setStolen()“ fehlt, sollte man sich noch nach anderen Stellen umsehen… (das ist btw. auch ein gutes Beispiel dafür, warum man möglichst nur Klassen innerhalb von „java.“ und „javax.“ verwenden sollte ;))
Spaß beiseite… Ich denke mal, dass es nicht so sehr darauf ankommt, was sich im Einzelnen an einer Klasse geändert hat, sondern mehr darauf, welche Mechanismen warum und evtl. noch wie geändert wurden. Deswegen ists wohl meist auch wichtig, dass man sich mit ein wenig Erfahrung in den geforderten Frameworks mitbringt, denn man kann ja nicht jede Klasse aller Frameworks kennen.
Ich nenn mal ein Beispiel. Ich musste/durfte auch mal mit Java 1.3 programmieren (damals noch mit . geschrieben). NICHT weil ich schon so lange Java kenne, sondern weil Java-Code zu nativen Code (Bitcode) kompiliert werden sollte. Etwas „Wesentliches“, was ist es da noch nicht gab, das war Auto-(Un)-Boxing. D. h., solcher Code ist schwer lesbar.
Dann werf ich noch Generics in den Raum, man sollte doch bitteschön wissen, wann es solche Sprachkonzepte (syntaktischen Mittel)/Features gab!
Auch solche Sachen, was hat sich in den Collections geändert, wieso ArrayList zwingen notwendig? Gut, da wären wir schon bei Java 1.2.
Findet ihr nicht, man sollte sogar etwas über die Entstehung der Programmiersprache wissen, welche Zuflüsse es gegeben hat usw.?
Im Gegensatz zu der obigen Frage nach Änderungen, anhand deren Beantwortung auf den aktuellen Wissensstand geschlossen werden kann, ist dein Beispiel ehertheoretischer Natur. Dürfte in der Wirtschaft exakt keinen Interessieren, wann wer mit welcher Version vor 10 oder 20 Jahren programmiert hat (außer es wird ein Cobol Entwickler gesucht). Die Firmen interessiert der RoI, sprich was muss investiert werden um den Kandidaten auf das Entwicklerteam einzuschießen. Und wenn der Kandidat quasi die aktuellen Java Guidelines inhaliert hat und am besten am aktuell genutzten Framework mitentwickelt hat…super. Ob er weiß, was in Java 0.0.1beta stand… who cares?
[quote=“CyborgBeta, post:22, topic:19201”]
Findet ihr nicht, man sollte sogar etwas über die Entstehung der Programmiersprache wissen, welche Zuflüsse es gegeben hat usw.?
[/quote]Nö, finde ich gar nicht. Wenn man mit einer Maschine arbeitet, muss man nur wissen, wie sie funktioniert, nicht aber warum. Oder sollte es deiner Meinung nach so werden, dass jeder Maschinenführer Physik studiert haben sollte?
wenn ich 1 + 1 in den Taschenrechner eintippe ( ), so will ich ein Ergebnis haben, ich will nicht wissen wie der Taschenrechner funktioniert und das anstellt.
Wenn ich ein Java programm schreibe will ich eine Applikation sehen, nicht wissen wie das nun die JVM anstellt, dass genau das erscheint, worum ich sie gebeten habe
Wie gesagt, die Details muss man nicht kennen, aber die prinzipielle Arbeitsweise sollte man verstanden haben. Ein wichtiger Grund dafür sind „Leaky Abstractions“. Z.B. ist Stackoverflow voll mit Fragen der Art, warum 0.1 + 0.9 in der Programmiersprache seiner Wahl (oder auch auf dem Taschenrechner) nicht exakt 1.0 liefert - egal wie gut man die unterliegenden „Eingeweide“ zu verstecken versucht, an manchen Stellen scheinen sie eben trotzdem durch.
Das kommt darauf an, ob er die Maschine nur benutzt oder auch wartet. Es gibt viele simple Programmierjobs, bei denen nur irgendwelches Zeug gemappt wird, da brauche ich kein tieferes Wissen. Wenn ich jetzt aber komplexe Algorithmen entwickle und dabei noch Performance und Speicher im Blick behalten soll, dann muss ich wissen was untendrunter passiert. Es kommt halt immer auf die Komplexität der Tätigkeiten an
und in den meisten Fällen braucht man dazu dann ein gewisses Verständnis von der Materie. Aber ich denke da scheiden sich die Geister zwischen „coding monkey“ und Software-Architekt.
Das ist doch interessant?! Damals hieß die Sprache übrigens noch „Oak“. Ein Beispiel:
The four integer types have widths of 8, 16, 32, and 64 bits, and are signed unless prefixed by the unsigned modifier. (Side note: unsigned isn’t implemented yet; it might never be.)
Wie Recht sie hatten
Man kann das auf unterschiedliche Weisen sehen. Und ich hatte mir schon verschiedene Vergleiche hierfür überlegt.
Der erste Vergleich mag nun etwas methaphorisch-abstrakt wirken, aber ich hatte es gelegentlich verglichen mit der Arbeit eines Bildhauers. Am Ende sehen gibt ein Ergebnis (die Skulptur bzw. das Programm), und es interessiert niemanden mehr, wie es entstanden ist. Tatsächlich sehe ich die Aufgabe eines Programmierers aber, darauf übertragen, nicht im Erstellen der Skulptur, sondern in der Auswahl (oder ggf. Herstellung) und vor allem der Verwendung von Hammer und Meißel.
Ein Programm, das hingedengelt wurde, so dass es zwar („gerade so“) läuft und („gerade so“) macht, was es soll, ist nicht so werthaltig, wie eine vernünftig entwickelte Software, modular, ohne Leaky Abstractions, mit wiederverwendbaren Komponenten.
Ein anderer Vergleich ist: Programmieren ist wie Singen. Prinzipiell „kann“ das fast jeder. Aber nur ganz, ganz wenige sollten sich auf eine Bühne stellen und das auch öffentlich machen. (D.h.: Was manche Leute auf GitHub stellen, lädt zum Fremdschämen ein…)
(das ist btw. auch ein gutes Beispiel dafür, warum man möglichst nur Klassen innerhalb von „java.“ und „javax.“ verwenden sollte ;))
), so will ich ein Ergebnis haben, ich will nicht wissen wie der Taschenrechner funktioniert und das anstellt.