Welche Progammiersprache wird denn heutzutage in der Schule im Fach Informatik verwendet?
-
Noch meine Anmerkung, warum Smalltalk wichtig und gut ist, auch wenn es sich in der Praxis nicht so weit verbreitet hat wie Java/C++/C# etc.
Smalltalk ist schlicht und ergreifend der Ursprung der objektorientierten Programmierung und der grafischen Benutzeroberflächen.
Dabei muss man natürlich den Einfluss von LISP und Simula 67 anerkennen. Aber das waren Exoten. Erst Smalltalk-80 hat allgemein großes Interesse an OOP geweckt und dazu geführt, dass Leute wie Cox, Hejlsberg oder Stroustrup mit Objective-C, C mit Klassen/C++, ObjectPascal anfingen, ältere prozedurale Sprachen um hybride OOP-Konstrukte zu erweitern.
Gosling/Joy et al. haben sich bei Java auch an Smalltalk orientiert (und Objective-C) und haben von Smalltalk z.B. auch das Bytecode-Konzept übernommen (der allerdings auch im Ur-ETH-Pascal schon genutzt wurde, später im UCSD-Pascal). Oder eben Garbage-Collection.
Auch im Bereich der Design Patterns und der agilen Methoden war Smalltalk massgeblicher Einflussfaktor (MVC gab es Mitte der 70er in Smalltalk), Smalltalk Leute wie Kent Beck haben XP und Patterns, Unit-Tests, etc. im Mainstream propagiert).
Alan Kay ist mit dem DynaBook, Smalltalk und der GUI einer der wichtigsten Visionäre der Informatik und hat zurecht Turing Award und Kyoto-Preis bekommen.
Dass Smalltalk sich nicht in der Praxis etablieren konnte, hat eigentlich fast nur historische Gründe, es war seiner Zeit einfach 10-15 Jahre vorraus und hatte eine zu seltsame Syntax, um Leute von prozeduralen, statischen Mainstreamsprachen wie C/Pascal wegzulocken.
Dabei ist die einfache, klare, flexible und logische Syntax wirklich ein Highlight der Sprache. Und die 100% prozentige Objektorientierung auch.
Smalltalk war übrigens (wie Logo) für Kinder und Lehrzwecke gedacht und wurde bei Xerox Parc an vielen Schülern ausprobiert. Einige dieser 70er Jahre Smalltalk-Kids sind Anfang der 80er zu Apple um am Mac zu arbeiten. Auch Alan Kay ging später (Mitte 80er -Mitte 90er) zu Apple Research (z.B. Newton Message Pad).
Dass Smalltalk nicht populärer wurde, lag neben den HW-Anforderungen auch am Preis für Smalltalk Entwicklungssysteme. Noch Anfang/Mitte der 90er wollte ParcPlace so ca. 5000 DM für ein Smalltalk Paket. Nichts für Hobbyuser oder Freelancer...
Wer mal mit einem Smalltalk spielen will, soll sich Squeak anschauen. Wird von Kay/Ingalls etc. betreut und geht über die Apple/Disney-Linie noch auf das original Smalltalk von Xerox Parc zurück.
Squeak war auch als Grundsystem für das "One Laptop per Child" Projekt im Gespräch.
-
Tachyon schrieb:
Fedaykin schrieb:
...alles was bisher so kam...
Was bringt es so tief ins Detail zu gehen? Pointer? Wozu?
Grundlagen der Programmierung und die grundlegenden Konstrukte wie Variablen, Bedingungen und Schleifen braucht man nicht nur als Programmierer.
Viele Leute die ein z.B. informatikfremdes Studium wissenschaftliches Studium anfangen kommen z.B. mit Matlab in Verbindung. Da ist etwas Grundwissen durchaus nützlich. Pointer oder sonst welches Zeugs, das Anfänger typischerweise verwirrt braucht man nicht.
Leute die mit CAD Anwendungen arbeiten können Grundkenntnisse ebenfalls gebrauchen, da CAD Anwendungen häufig mit Skriptsprachen erweitert oder automatisiert werden können. Auch da bedarf es keiner komplizierten oder hardwarenahen Konstrukte. Ähnliches gilt für Officeprogramme und Makros.
Weitere Beispiele gibt es inzwischen für alles Mögliche.
Wozu mit OOP rumhampeln? Wozu mit Pointern rumhampeln? Bringt nichts. Das Grundwissen über Grundkonstrukte hingegen sehr wohl. Und das ist auch durchaus etwas, das allgemeinbildende Schulen lehren können.
Das ist einer der wenigen Posts die mich davon überzeugen könne, das zumindest die Prozedurale Programmierung im Schulwesen Sinn macht. Dann bleibt die Frage offen warum dann heutzutage soviel mit OOP Sprachen gelehrt wird? Naja die Prozeduralen Sachen sind dabei ja gleich. Dummerweise wird man bei Sprachen wie Java und C# gleich in die OOP gezwungen und schaut sich da ggf zuviel sachen ab, die man aus gegeben Anlass noch gar nicht wirklich nutzen soll.
Ich denke fü solche Zwecke lässt sich sogar was einheitliches/Schültertaugliches finden oder Entwickeln. Der Java Hamster hat dort ja perfekte Ansätze.
-
ohhahahaha schrieb:
Das heißt man setzt praktisch auf den Digitaltechnik-Unterricht in Physik auf.
was für ein Ding? Sowas ist mir weder auf Real noch Gym nie begegnet, nichtmal als Wahlfach
Also ich habe 2002 meinen Abschluss gemacht und wir hatten im Physikunterricht an einem staatlichen allgemeinen Gymnasium Grundlagen zur Digitaltechnik und sogar so ein paar Versuchsbretter um ein paar einfache Schaltungen aufzubauen. Das müsste in der 10. Klasse gewesen sein, vielleicht auch in der 9..
Darauf aufbauend könnte man den Schülern etwas Grundwissen über Computer vermitteln, das meiner Erfahrung nach sogar vielen erfahrenen Softwareentwicklern fehlt, obwohl genau das eigentlich die Grundlage ist und auch das allgemeine technische Verständnis der Schüler verbessert.
-
Technik schrieb:
Darauf aufbauend könnte man den Schülern etwas Grundwissen über Computer vermitteln, das meiner Erfahrung nach sogar vielen erfahrenen Softwareentwicklern fehlt, obwohl genau das eigentlich die Grundlage ist und auch das allgemeine technische Verständnis der Schüler verbessert.
Was ist das? Der erfahrende Softwareentwicklern braucht dieses Wissen nicht, warum sollen wir unsere Schüler damit quällen?
-
Weil die Schule keine berufliche Vorbereitung auf den Beruf Softwareentwickler sein sollte. Warum sollte man primär Dinge lehren, die Softwareentwickler brauchen? Das Verständnis von technischen Geräten ist meiner Meinung nach viel wichtiger. Programmieren sollte man da auch, alleine schon um das gelernte auch in der Praxis anzuwenden, aber zumindest ein bisschen Zeit sollte man auf die technischen Grundlagen verlegen. OOP und ähnliche Konzepte sind zu speziell auf ein Berufsbild ausgelegt, auch wenn es die meisten Leute hier im Forum als "Allgemeinwissen" sehen könnten, weil sie sich in ihrem Beruf täglich damit beschäftigen.
-
Grandios, einmal nachgefragt und total widersprochen.
-
Huch? Habe ich da was übersehen? Ich habe mir meine Beiträge noch ein paar mal angeschaut und kann keine Widersprüche erkennen. Vielleicht haben wir uns da irgendwo missverstanden.
-
Wie wäre es mit Assembler... Auf nem 8080?
Iwie ohne Mnemonic! Da hat man dann techniche Grundlagen und "Programmierung"
-
Beim Thema technische Grundlagen sollte man wohl erklären was Grundlagen sind. Es ist nicht verkehrt zumindest zu wissen was im PC der Ram/Prozessor etc ist, was Serielle, Paralelle Datenübertragung ist, wozu eine Graka gut ist etc. Es wäre nicht ganz verkehrt zu wissen wie Speicher aufgebaut ist, und wie er Adressiert wird. Warum an mittlerweile auf 64 Bit Systeme umsteigt etc. Funktionsweise HD/DvD etc. Nichts detailiertes halt. In einer Welt in der ein PC's eine Zentrale rolle Spielen, wäre so ein Wissen nicht verkehrt.
Bei uns im Studium hatten wir ein Fach "Microprozessorarchitektur". Dort gings dann schon richtig in Details. Dort wurde uns wirklich näher gebracht wie ein Prozessor aufgebaut ist. Wir hätten Prinzipiell einen simplen 8 Bit Prozessor basteln können. Dazu kamen details wie Pipelining, wie funktionieren Caches etc.... nichts was jetzt für mich absolut relevant wäre. Aber ein Blick über den Tellerand schadet nichts. Zusätzlich haben wir dort auch mal Assembler programmiert.
-
Ich stell mir die Gesichter der Schüler vor, wenn sie in einer algemeinbildenden Schule plötzlich Assembler programmieren müssten
Das wär dann doch wohl etwas übers Ziel hinausgeschossen.Ich bin nach der Diskussion auf den Schluss gekommen, dass es kein "Rezept" gibt, was man zum Thema Programmierung unterrichten sollte. Es gibt mehrere Ansätze, die Sinn machen. Es hat alles seine Vor- und Nachteile. Was ich am Wichtigsten fände, sind Computergrundkenntnisse: Aufbau, Betriebssysteme, grundsätzliche Funktionsweisen von Hard- und Software, Fehlerbehebung,... Wer sich hier vertiefen will, sollte die Möglichkeit dazu haben. Wer in einer Computerklasse arbeitet kann auch tiefer in die Materie einsteigen.
-
Fedaykin schrieb:
Bei uns im Studium hatten wir ein Fach "Microprozessorarchitektur". Dort gings dann schon richtig in Details. Dort wurde uns wirklich näher gebracht wie ein Prozessor aufgebaut ist. Wir hätten Prinzipiell einen simplen 8 Bit Prozessor basteln können. Dazu kamen details wie Pipelining, wie funktionieren Caches etc.... nichts was jetzt für mich absolut relevant wäre. Aber ein Blick über den Tellerand schadet nichts. Zusätzlich haben wir dort auch mal Assembler programmiert.
Ich vermute das ist üblich in den Grundstudiumsvorlesungen (bzw. Bachelor) zu "Technische Informatik" (neben den Betriebssystem-Themen).
Wir haben im TI Praktikum mit TTL Schaltungen angefangen und Abschlussprüfung waren kleinere 6809 Assemblerroutinen auf einem Einplatinen-Dings (keine Hilfsmittel, Zeitlimit, ...)
Aber was mir am meisten gebracht hat, war die microprogrammierbare 4-Bit CPU, die der Praktikumsleiter gebaut hatte. Ziel war es, auf der 12MHz 4-Bit CPU einen 1MHz 6502 in Microcode zu emulieren. Alle Praktikumsgruppen bekamen einige 6502 Opcodes zugeteilt und ein Limit an Microcode-Zeilen. Ziel war eine möglichst optimierte Emulation. Durch die 4-Bit war man gezwungen, alle 8Bit Ops des 6502 sequentiell zu zerlegen. Die Zugriffe auf 6502 Register waren aufwendige RAM Zugriffe der Micromaschine. Es war nicht leicht, das Limit zu unterbieten - man musste auf möglichst viel Parallelität im horizontalen Microcode achten.
Das Ding war mit TTLs, GALs und PALs realisiert (heute würde sicher ein CPLD reichen) - allerdings nur einmal, wir Studis haben mit der Software-Emulation der Micromaschine getestet.
Keine Ahnung, ob es der Praktikumsleiter wirklich geschafft hat, das irgendwann mal in einen C64 einzustöpseln (war sein Ziel). Heutzutage ist ein kompletter C64 im FPGA ja ein Klacks, selbst ein Amiga500 mit Custom Chips und MC68k passt in einen fetten FPGA...
Fedaykin schrieb:
Dazu kamen details wie Pipelining, wie funktionieren Caches etc.... nichts was jetzt für mich absolut relevant wäre. Aber ein Blick über den Tellerand schadet nichts.
Pipelining, ILP, Branchprediction, Register Renaming, Reorder Buffer, Caching etc. ist auch für Softwareentwickler sehr relevant, wenn man HPC Code entwickeln muss. Ohne die TI-Grundlagen und Rechnerarchitektur-Vorlesungen im Hauptstudium würde ich gar nicht verstehen, was Intels Vtune alles ausspuckt, oder wozu man PTLsim nutzen kann (oder AMDs Codeanalyzer...).
OK, für >95% aller Software ist diese Art der Performance-Optimierung völlig egal. Sonst hätten ja Java und .Net-Sprachen oder gar die vielen Skriptsprachen gar keine Anwendungsfelder.