IDE oder einfacher Editor zum Einstieg

E

_ebm_

Aktives Mitglied
Thread Starter
Dabei seit
19.01.2008
Beiträge
2.079
Reaktionspunkte
204
Ich schreibe diesen Beitrag nicht aus Eigennützigkeit, bin schliesslich selbst seit Jahren Softwareentwickler und bin meine Wege Schon gegangen. Da aber in dem Thread Xcode HowTo die Frage auftauchte, ob man als Anfänger ein Integrated Developer Environment (IDE) verwenden sollte oder mit einem guten Editor samt Shell besser bedient wäre, greife ich das Thema hier nochmal auf.

Pro IDE:
* Easy to use. Alles ist integriert und es werden einem viele Schritte abgenommen

Contra IDE:
* Man ist auf die Plattform festgelegt und lernt nicht, wo die IDE aufhört und die Tools der Programmiersprache anfangen.

Pro Shell:
* Keine überladenen GUIs.

Contra Shell:
* Die Lernkurve ist steiler, da man muss die Tools lernen.

Ich bin für den Anfänger eher ein Freund für die puristische Programmierung mit Shell und Editor. Der Vorteil liegt darin, dass man nicht auf eine Plattform festgelegt ist. Beispiel GNU Compiler Collection: Die ist auf jedem Betriebssystem lauffähig, auf dem es die GNU Utils gibt.

Ein C-Programm lässt sich entweder direkt mit gcc oder auch mit make übersetzen. Besteht da ein Projekt aus mehreren Übersetzungseinheiten, reicht ein kleines Makefile:

Code:
$ ls
Makefile foo.c  bar.c
$ cat Makefile
foobar: foo.o bar.o
$ make foobar
gcc -c foo.c
gcc -c bar.c
gcc foo.o bar.o -o foobar
#

Beispiel Java: Plattformübergreifende Programmierung...
 
Contra IDE:
* Man ist auf die Plattform festgelegt und lernt nicht, wo die IDE aufhört und die Tools der Programmiersprache anfangen.

Genau das Gegenteil ist der Fall!

Wenn jemand zum Beispiel C++ lernen will, dann kann er in Xcode "Build & Go" drücken, und in VisualStudio war es -- wenn ich mich richtig erinnere "Run". Ich denke mal, für Eclipse gilt ähnliches.

Ich -- Dipl.-Inform., einige Jahre Windows Entwickler (1) -- habe keinen
blassen Schimmer, wie man unter Windows C++ auf der Kommandozeile baut. Geht, aber interessiert mich nicht, und hab ich auch noch nie gebraucht.

Ich habe auch an der Uni Modula-2 mit einer IDE gelernt -- und zwar als einziger im Semester mit einem Mac und System sieben. Es sollte uns Programmieren beigebracht werden, und eben genau nicht der (u.U. platformabhängige) Umgang mit Werkzeugen. Meine Mac IDE hat mir erlaubt, dass zu tun.

Oberon kam dann mit seiner eigenen IDE, die war auf jedem OS gleich.

Ich stimme Dir zu, als Profi sollte man seine Werkzeuge kennen, zum Beispiel auch Command Line gdb.

Aber als Anfänger ist das alles nicht wichtig, und gerade die schnellen Erfolge motivieren am Anfang. Die Kommandozeile motzt bei jedem Vertipper, und macht der Frust m.E. noch größer.

Ich habe es in einem anderen Thread geschrieben: Profis auf dem Mac sollten sich mit gcc und gdb in der Kommandozeile auskennen. Anfänger müssen das m.E. nicht.

Alex

1) Software, an der ich massgeblich beteiligt war stand in der 90er Jahren regelmäßig in den Top 10 Non-Games der GfK
 
Ja ich hab in meiner ganzen SE-Vergangenheit nicht eine Zeile Code speziell für Windows geschrieben. Ich hab damals mit TurboPascal (DOS) angefangen und bin schnell bei Linux gelandet (c, c++, java, python, ...). Da gab es eh lange keine passenden IDEs und ich hab vi und Emacs verwendet.

Der Vorteil liegt hier darin, dass ich *meinen* Quelltext nehmen kann, zu einem anderen System trage, wo gcc o.ä. verfügbar ist und nur noch make eingebe und (bis auf plattformspezifische Anpassungen) kompiliert es durch. Entwickelst du mit VS oder Borland, werden plattformspezifische Bibliotheken eingebunden, die dir beim Portieren fehlen. Und wenn du diese Dreingaben als selbstverständlich und zur Programmiersprache gehörig annimmst, bekommst du auf anderen Systemen Probleme...

Genau in diesem "selbstverständlich" sehe ich die Gefahr für Einsteiger...
 
Entschuldige, Deine Argumentation hat den zentralen Fehler, dass Du zu viele Annahmen machst.
Entwickelst du mit VS oder Borland, werden plattformspezifische Bibliotheken eingebunden, die dir beim Portieren fehlen.
Hier ist der eigentliche Punkt: Du redest von "IDE" und meinst Borland für Windows.
Sagt mir mal, wie mich das verwenden einer Modula-2 IDE verdorben hat. Welche Platformspezifischen Bibilotheken bindet eine Java, Lisp, Prolog oder Fortran IDE ein?

_ebm_;3942375Und wenn du diese Dreingaben als selbstverständlich und zur Programmiersprache gehörig annimmst schrieb:
Wenn Du Linux Libraries als selbstverständlich annimmst gilt das natürlich nicht. Richtig? ;)
Und aus den Mac Foren kenne ich genug Fragen: "Warum gibt es denn libx nicht? Warum geht das nicht wie bei Linux?"

zu einem anderen System trage, wo gcc o.ä. verfügbar
Aber zum Beispiel auf klassichem Mac OS gab es keinen gcc.
Weisst Du, wie man C++ Code mit MPW (eine Kommandozeilenumgebung unter dem alten Mac OS) zum laufen bringt? Ich bin sicher Du brauchst sehr viel weniger Zeit um es mit Metrowerks CodeWarrior (eine alte IDE) zum laufen zu bringen.

(bis auf plattformspezifische Anpassungen)
Das in Klammern zu setzen finde ich aber sehr optimistisch. Und wie gesagt, es setzt auch das make Tool vorraus.

Du solltest vielleicht Deine Frage anders formulieren ;)

Alex
 
Entschuldige, Deine Argumentation hat den zentralen Fehler, dass Du zu viele Annahmen machst.

Hm ich glaub da haben wir gänzlich unterschiedliche Meinungen. Das liegt vielleicht an der Perspektive.

Hier ist der eigentliche Punkt: Du redest von "IDE" und meinst Borland für Windows.
Sagt mir mal, wie mich das verwenden einer Modula-2 IDE verdorben hat. Welche Platformspezifischen Bibilotheken bindet eine Java, Lisp, Prolog oder Fortran IDE ein?
Ich meine aber auch die MFC aus VS, SWT aus Eclipse oder die Swing-Erweiterungen von NetBeans

Prolog hat eine gute IDE? Wusste ich nicht. Ich hab mich damals zu Uni-Zeiten mit vi "abgemüht". Mehr als 100 Relationen hatte ich aber nie definiert.

Wenn Du Linux Libraries als selbstverständlich annimmst gilt das natürlich nicht. Richtig?
Und aus den Mac Foren kenne ich genug Fragen: "Warum gibt es denn libx nicht? Warum geht das nicht wie bei Linux?"

Richtig, es gibt unterschiede zwischen den Unices. Ich hab schon portabel für Solaris, Linux und AIX programmiert. Aber mir geht es ja nicht um Specialities für die Systeme sondern um den geneigten Anfänger! Der wird sich selten aktiv um Bibliotheken kümmern. Allerdings kann es ihm passieren, dass er durch die Menüs der IDE geistert und hier nen häkchen macht und dort etwas einfügt und schon läuft sein Programm nicht mehr überall. Programmiert ein Student unter MacOS mit Xcode, sein Prof will aber ein Lauffähiges System unter Solaris, so kann in Probleme laufen.

Aber zum Beispiel auf klassichem Mac OS gab es keinen gcc.
Weisst Du, wie man C++ Code mit MPW (eine Kommandozeilenumgebung unter dem alten Mac OS) zum laufen bringt? Ich bin sicher Du brauchst sehr viel weniger Zeit um es mit Metrowerks CodeWarrior (eine alte IDE) zum laufen zu bringen.

Das war vor meiner Zeit Und sollte ein armer Anfänger in diese Verlegenheit kommen, tut er mir leid.

Das in Klammern zu setzen finde ich aber sehr optimistisch. Und wie gesagt, es setzt auch das make Tool vorraus.

Du solltest vielleicht Deine Frage anders formulieren ;)

Alex

DAS war mir klar, dass du das schreibst :D Und ich schlage nochmal mit dem Anfänger zurück. Portabel zu programmieren ist nicht einfach. Meine Programme waren nur so von #ifdef ... #endif gespickt. Mir geht es aber immernoch um den Anfänger. Das wird ihn nur dann tangieren, wenn er mit Systemspezialitäten konfrontiert wird. Und da läuft er mit einschlägigen IDEs eher in die Falle als mit dem Stroustrup oder Kerninghan arbeitet (Ich meine damit, sich an den Sprachstandard hält, nicht das Buch auswendig lernt).

*)
 
Und da läuft er mit einschlägigen IDEs eher in die Falle als mit dem Stroustrup oder Kerninghan arbeitet (Ich meine damit, sich an den Sprachstandard hält, nicht das Buch auswendig lernt).

Aber man kann sich doch auch mit IDE an den Standard halten... ;)

Andere Frage: Hälst Du aus den von Dir genannten Gründen C nicht ohnehin für eine Sprache, die für Anfänger vollkommen untauglich ist?

Im übrigen mussten wir uns an der Uni C dann selber beibringen, ob wir das in Kommandozeile oder IDE gemacht haben war vollkommen egal.
Das Ergebnisse mussten unter HP/UX und Solaris ubersetz- und ausführbar sein.

Da die meisten zu der Zeit keine HP oder Sun Workstation zu Hause hatten (Selbst ich nicht, ich hatte eine Silicon Graphics Iris Indigo EDIT: und A/UX :hehehe: ) wurde dann ohnehin zu Hause auf z.B. Windows entwickelt, und dann im Rechnerpool ausprobiert.

Das hat natürlich Platformabhängigkeiten gar nicht aufkommen lassen.

Fazit vielleicht: Es geht nicht um die Werkzeuge, es geht darum, wie die Materie vermittelt wird.

Wenn ich im Gegensatz zu meinem Studium, das vollkommen Platformagnostisch (1) war, an den Prof aus dem "Anfängerfragen" Thread denke, wird mir übel.

Alex

1) In einer Zeit, in der noch nicht mal alle Informatikstudenten einen Computer zu Hause hatten waren die HP und Sun Stations einfach das, worauf alle Zugriff hatten. Dadurch waren sie für unsere Profs der "Standard"
 
@_ebm_: ich glaube was die Diskussion etwas schwierig macht, ist offenbar Dein tiefes Mistrauen gegenüber dem von IDEs erzeugten Projekten - so wie jedem Webentwickler schlecht wird, wenn er den HTML-Code sieht, den Frontpage und Co ausspucken.
Während bei Frontpage dieses Mistrauen sicherlich berechtigt ist, würde ich dies bei moderen IDEs nicht unsterstellen.
Weder VS, noch Eclipse, noch Netbeans knallen Dein Projekt gleich mit Abhängigkeiten voll, die Du gar nicht willst.
Aber es ist ja klar, dass, wenn Du den jeweiligen GUI-Builder nutzt, auf jeden Fall Abhängigkeiten wie z.B. von SWT bekommst.
Wenn Du aber von so einfachen Beispielen mit 'ner foo.c und bar.c redest, dann redest Du vermutlich auch noch nicht von großen GUI-Anwendungen. Und so ein einfaches Konsolenprogramm wird auch von einer IDE nicht mit Swing-Abhängigkeiten belastet.

Ich bin der klaren Auffassung, dass der Einstieg mit einer IDE leichter ist, schon alleine aufgrund der genannten Möglichkeit einfach auf "Run" zu klicken.
Und gerade wenn es um Abhängigkeiten von Libraries geht, finde ich auch immer noch IDEs besser. Da muss ich einmal angeben, welche lib ich brauche und gut, ich muss mir nicht überlegen welchen Kommandozeilen-Befehl ich dafür brauche.

Ich hab z.B. oo-programmieren mit BlueJ gelernt, das hat zwar erstmal nichts mit "richtigem" programmieren zu tun, aber gerade dadurch, dass mir alles komplizierte abgenommen wurde, konnte ich mich voll drauf konzentrieren objektorientierte Konzepte zu lernen und das anhand praktischer Beispiele.
Das war für mich die perfekte Mischung zwischen Lerhbuch lesen und Beispiel durchprogrammieren, die mich sehr schnell hat OOP und dann auch Java lernen lassen.
Die ersten Schritte und das erste Programm in Eclipse waren dann ein Katzensprung.
Den javac-Befehl habe ich seitdem nur in einer einzigen Vorlesung mal benutzt, aber ansonsten hab ich mir die Mühe erspart.
 
Aber man kann sich doch auch mit IDE an den Standard halten...

Hm, an welchen Standard hält sich Borland? Oder das VS? ;) Ich habe nichts dagegen, wenn mir eine IDE hilft, größere Projekte zu managen. Aber wenn ich gerade dabei bin, eine Sprache zu lernen und dann von einer IDE schon einen Projektrumpf vorgeschmissen bekomme, finde ich nicht tauglich. Leider machen das die großen C++-IDE alle.

Andere Frage: Hälst Du aus den von Dir genannten Gründen C nicht ohnehin für eine Sprache, die für Anfänger vollkommen untauglich ist?

Die Frage ist schwer zu beantworten. Die Sprache ist antiquiert. Man muss sich mit Speicherverwaltung herumschlagen und verstehen, was Pointer und Referenzen sind. Das dürfte für die meisten Anfänger eine Überforderung sein. Ausserdem ist es schwer (nicht unmöglich!), mit C objektorientiert zu programmieren. Darum finde ich es auch nicht falsch, dass die meisten Unis inzwischen von Modula auf Java umgestiegen sind. Kein Speichermanagement, alle komplexen Strukturen werden eh per Referenz übergeben... Das machtes dem Einsteiger leicht.

Im übrigen mussten wir uns an der Uni C dann selber beibringen, ob wir das in Kommandozeile oder IDE gemacht haben war vollkommen egal.
Das Ergebnisse mussten unter HP/UX und Solaris ubersetz- und ausführbar sein.

(Selbst ich nicht, ich hatte eine Silicon Graphics Iris Indigo EDIT: und A/UX :hehehe: ) wurde dann ohnehin zu Hause auf z.B. Windows entwickelt, und dann im Rechnerpool ausprobiert.

Da die meisten zu der Zeit keine HP oder Sun Workstation zu Hause hatten
Das hat natürlich Platformabhängigkeiten gar nicht aufkommen lassen.

Ja so war es bei mir auch. Wir hatten damals im Compilerbau einen SQL-Compiler in C geschrieben (3. Semester, Grundstudium). Dazu gab es einen 14-Tage Crashkurs C. Es wurde eh Pascal vorausgesetzt. Man sollte also schon wissen, was Pointer sind. Ich hatte damals eh schon lange mit Linux programmiert und kannte den gcc (damals noch 2.95). Ausprobiert hab ich dann von Zuhause aus per Shell auf ner Workstation an der Uni. Es kann sein, dass ich daher meine Affinität zu Shelltools habe. Ich bediene Make inzwischen im Schlaf. Ganz abgesehen davon, dass ich mir auch schon mein eigenes Linux zusammengefrickelt hatte.


Fazit vielleicht: Es geht nicht um die Werkzeuge, es geht darum, wie die Materie vermittelt wird.

Wenn ich im Gegensatz zu meinem Studium, das vollkommen Platformagnostisch (1) war, an den Prof aus dem "Anfängerfragen" Thread denke, wird mir übel.

Dem kann ich einfach nur noch zustimmen :) Es gibt überall schwarze Schafe. Wichtig ist eben wirklich, was am ende herauskommt


@_ebm_: ich glaube was die Diskussion etwas schwierig macht, ist offenbar Dein tiefes Mistrauen gegenüber dem von IDEs erzeugten Projekten - so wie jedem Webentwickler schlecht wird, wenn er den HTML-Code sieht, den Frontpage und Co ausspucken.
Während bei Frontpage dieses Mistrauen sicherlich berechtigt ist, würde ich dies bei moderen IDEs nicht unsterstellen.
Weder VS, noch Eclipse, noch Netbeans knallen Dein Projekt gleich mit Abhängigkeiten voll, die Du gar nicht willst.
Aber es ist ja klar, dass, wenn Du den jeweiligen GUI-Builder nutzt, auf jeden Fall Abhängigkeiten wie z.B. von SWT bekommst.
Wenn Du aber von so einfachen Beispielen mit 'ner foo.c und bar.c redest, dann redest Du vermutlich auch noch nicht von großen GUI-Anwendungen. Und so ein einfaches Konsolenprogramm wird auch von einer IDE nicht mit Swing-Abhängigkeiten belastet.

Naja, ich hab oben schon angedeutet, woher meine Erfahrungen kommen. Es geht mir ja nicht nur um die Abhängigkeiten in der GUI. Oftmals wird schon eine Standardbibliothek der IDE eingebunden, die dir das Leben als Profi leichter macht. Du lernst also mit dieser Bibliothek. Ich verweise da nur an den verhängnissvollen "Anfängerfragen"-Fred. IDEs sind wirklich sehr hilfreich. Ich würde mich nicht mehr zutrauen, unser Projekt auf Arbeit ohne Eclipse weiter zu entwickeln. Da wäre ich nur noch dabei, die Typos aus dem Code zu frickeln.

In dem Athemzug will ich auch erwähnen, das Bibliotheken gerad bei C++ sehr wichtig sind. Ohne die STL oder Boost hätte ich keine Lust mehr ...

Ich bin der klaren Auffassung, dass der Einstieg mit einer IDE leichter ist, schon alleine aufgrund der genannten Möglichkeit einfach auf "Run" zu klicken.
Und gerade wenn es um Abhängigkeiten von Libraries geht, finde ich auch immer noch IDEs besser. Da muss ich einmal angeben, welche lib ich brauche und gut, ich muss mir nicht überlegen welchen Kommandozeilen-Befehl ich dafür brauche.
Wenn es dir nur um den Knopf "Compile"/"Run"/"Debug" geht. Naja, das ist schon schön bequem und man kann sich auf seinen Code konzentrieren. Du musst aber als Anfänger auch lernen, die IDE zu bedienen, einzustellen, was du wo brauchst. Da können bebensogut die vielen Schalter verwirren. Auf der Konsole javac <klasse>.java aufzurufen, halte ich nicht für übertrieben. Das geht recht einfach. Klar, wenn man Obj-C oder C++ programmiert, wird das schon tricky, das werden aber die wenigsten Anfänger. Die Barriere ist viel zu gross.

Ich hab z.B. oo-programmieren mit BlueJ gelernt, das hat zwar erstmal nichts mit "richtigem" programmieren zu tun, aber gerade dadurch, dass mir alles komplizierte abgenommen wurde, konnte ich mich voll drauf konzentrieren objektorientierte Konzepte zu lernen und das anhand praktischer Beispiele.
Das war für mich die perfekte Mischung zwischen Lerhbuch lesen und Beispiel durchprogrammieren, die mich sehr schnell hat OOP und dann auch Java lernen lassen.
Die ersten Schritte und das erste Programm in Eclipse waren dann ein Katzensprung.
Den javac-Befehl habe ich seitdem nur in einer einzigen Vorlesung mal benutzt, aber ansonsten hab ich mir die Mühe erspart.

BlueJ sagt mir garnichts. OO ist für mich auch eher ein Paradigma als eine art Sprache. Ich lerne, was Klassen sind, was Objekte und was Instanzen. Ich mache mir Gedanken um Schnittstellen, Inherritance, Polymorphismus,... Mit welcher Sprache ich das mache, ist dabei recht egal.

Wenn ich nebenbei mal einen Test schreibe, um zu sehen, ob etwas so geht, wie ich es mir vorstelle, nutze ich übrigens keine IDE. Bis ich die gestartet und eingerichtet hab, ist der Test schon fast vollständig implementiert.

Ich will die Bequemlichkeiten einer IDE nicht schmälern. Für mich lenkt die Funktionsvielfalt aber unter gewissen Gesichtpunkten vom Problem ab. Papier und Bleistift ist eben manchmal doch besser als ne Schreibmaschine ;)

Gruss Carsten
 
Hm, an welchen Standard hält sich Borland? Oder das VS? ;)
An welchen sollten Sie sich halten? Ich kennen keinen Standard für IDEs.

Aber es ist ganz und gar möglich, sogar in Borland C, IEEE konformen Code zu schreiben und zu übersetzen.

Aber wenn ich gerade dabei bin, eine Sprache zu lernen und dann von einer IDE schon einen Projektrumpf vorgeschmissen bekomme, finde ich nicht tauglich. Leider machen das die großen C++-IDE alle.
Und was ist am Xcode Projektrumpf falsch?

Ausprobiert hab ich dann von Zuhause aus per Shell auf ner Workstation an der Uni. Es kann sein, dass ich daher meine Affinität zu Shelltools habe
Ich finde immer, man muss sich selbst und seine Schüler nicht unnötig quälen.
Nochmal: Eine IDE erlaubt es mir, mich auf die AUFGABE, und nicht auf die WERKZEUGE zu konzentrieren.

Oftmals wird schon eine Standardbibliothek der IDE eingebunden, die dir das Leben als Profi leichter macht. Du lernst also mit dieser Bibliothek. Ich verweise da nur an den verhängnissvollen "Anfängerfragen"-Fred.
Du nimmst aber alle IDEs in Sippenhaft. Das finde ich unzulässig.

Auf der Konsole javac <klasse>.java aufzurufen, halte ich nicht für übertrieben. Das geht recht einfach.
Du warst doch der, der unnötigen Ballast vermeiden wollte? javac IST für Anfänger unnötiger Ballast!

Ich lerne, was Klassen sind, was Objekte und was Instanzen. Ich mache mir Gedanken um Schnittstellen, Inherritance, Polymorphismus,... Mit welcher Sprache ich das mache, ist dabei recht egal.
Und eine _gute_ IDE hilft Dir dabei, Dich genau darauf zu konzentrieren.

Bis ich die gestartet und eingerichtet hab, ist der Test schon fast vollständig implementiert.
OK, Xcode läuft bei mir den ganzen Tag, das muss ich nicht starten. Und wir können ja mal messen, ob Du schneller "int main (int argc, const char ** argv) schreibst, oder ich das Xcode Projecttemplate auf hab ;)

Ich will die Bequemlichkeiten einer IDE nicht schmälern. Für mich lenkt die Funktionsvielfalt aber unter gewissen Gesichtpunkten vom Problem ab.
Ich will die Mächtigkeit einer Shell nicht schmälern. Für mich lenkt die Komplexität aber unter gewissen Gesichtpunkten vom Problem ab. :p

Alex
 
Beides hat seine Vor- und Nachteile. Ich bin mir des Effektes schon bewusst, dass wenn ich ein Projekt in Xcode erzeugt hab, das Gerüst steht und ich mich gleich um die Aufgabe und die Lösung des enthaltenen Problems kümmern kann.

Anfänger kämpfen noch mit ganz anderen Problemen. Sie müssen lernen, was eine Methodensignatur ist, wie Parameter aussehen und was ein Rückgabetyp ist. Ich hab es leider schon erlebt, dass ein Student nicht wusste, was der Hauptontrollfluss und ein Einsprungspunkt ist. Mit dem Zwang, wirklich beim Anfang anzufangen - sprich sie legen die Datei mit der Main-Methode an und arbeiten sich so durch das Problem - ist manchmal lehrreicher als eine IDE die einem sowas schon als Template hinlegt.

Wie ich schrieb, ich nutze gerade wegen der vielen Helferlein IDEs. Sie erleichtern mir vieles und ich kann dich mit der Shell bestimmt nicht darin schlagen, ein neues Projekt in Xcode anzulegen. Einem Anfänger wird IMHO aber zu viel abgenommen - sowohl Entscheidungen als auch Arbeitsschritte.

Aber ich glaube, mein Blick ist da zu akademisch. Entferne ich mich davon, könntest du recht haben ;)

Gruss Carsten
 
Einem Anfänger wird IMHO aber zu viel abgenommen - sowohl Entscheidungen als auch Arbeitsschritte.

Aber ich glaube, mein Blick ist da zu akademisch. Entferne ich mich davon, könntest du recht haben ;)

Ich glaube, Dein Blickwinkel ist da zu praktisch, oder besser: werkzeuglastig, und ausserdem durch schlechte Erfahrungen mit der Borland IDE geprägt.

Nach dem C64 habe ich auf dem Mac programmiert, und da gab es für Anfänger nur IDEs: erst Lightspeed Pascal dann Lightspeed C, Symantec C und schliesslich CodeWarrior.

Mit A/UX, Irix und dem Macintosh Programmers Workshop (MPW) kam ich erst nach langen Jahren "IDE Entwicklung" in Berührung.

So, nach Deiner These müsste ich ja einen Schaden davon getragen haben :D

Aber es ist natürlich auch so, dass ich damals in einer echten Exotenrolle war, damit verglichen ist der Mac heute vollkommen Mainstream. Und das es "gotoxy" auf dem Mac nicht gab, das habe ich schon in der Schule gelernt.
EDIT: Und als Exot lief ich nie Gefahr, irgendetwas für selbstverständlich zu halten.
EDIT 2: Ausserdem war die Rechnerwelt in der 80ern ohnehin deutlich hetrogener. Ich bin damit gross geworden, das es verschiedene, inkompatible System gab. Die Windows Dominanz kam erst später

Und mich natürlich dadurch unbeliebt gemacht, dass immer über die Textausgabe der Schul PCs gemotzt habe. Zu Hause hatte ich einen Rechner mit GUI :hehehe:

Alex
 
Zuletzt bearbeitet:
Ich glaube, Dein Blickwinkel ist da zu praktisch, oder besser: werkzeuglastig, und ausserdem durch schlechte Erfahrungen mit der Borland IDE geprägt.[\QUOTE]

mag sein...

Nach dem C64 habe ich auf dem Mac programmiert, und da gab es für Anfänger nur IDEs: erst Lightspeed Pascal dann Lightspeed C, Symantec C und schliesslich CodeWarrior.

Mit A/UX, Irix und dem Macintosh Programmers Workshop (MPW) kam ich erst nach langen Jahren "IDE Entwicklung" in Berührung.

So, nach Deiner These müsste ich ja einen Schaden davon getragen haben :D

Aber es ist natürlich auch so, dass ich damals in einer echten Exotenrolle war, damit verglichen ist der Mac heute vollkommen Mainstream. Und das es "gotoxy" auf dem Mac nicht gab, das habe ich schon in der Schule gelernt.
EDIT: Und als Exot lief ich nie Gefahr, irgendetwas für selbstverständlich zu halten.
EDIT 2: Ausserdem war die Rechnerwelt in der 80ern ohnehin deutlich hetrogener. Ich bin damit gross geworden, das es verschiedene, inkompatible System gab. Die Windows Dominanz kam erst später

Und mich natürlich dadurch unbeliebt gemacht, dass immer über die Textausgabe der Schul PCs gemotzt habe. Zu Hause hatte ich einen Rechner mit GUI :hehehe:

Alex

Dafür hattest du nur mit Exoten zutun :p Ne ich hatte meine ersten Berührungen noch mit einem KC87 von Robotron (Ich oute mich mal als Ossi) Da hat man nen Monokrom Fernseher und nen Kassettenrekorder angeschlossen und sich gefreut, was für Geräusche aus dem Rekorder kamen, wenn man die Software als Musik abspielte. Programmiersprache war damals Basic ;)

Beim Abi waren es dann altersschwache 286er mit Dos und TurboPascal. An der Uni AIX, Solaris, Linux. Mit Windows hatte ich nur daheim beim Spielen Kontakt. Apple kam auch erst viel später. Nun sitz ich hier, ich armer Thor Nein es macht spass. Aber meine alt geliebte Konsole lass ich mir nich nehmen *fg*
 
@_ebm_: ich glaube wir reden hier auch einfach von einer anderen Art programmieren zu lernen.

Ich habe es so gelernt, dass ich erstmal die Konzepte beigebracht bekommen habe und das dann halt teilweise auch direkt im Code. Aber wenn wir dann z.B. in der ersten OOP-Vorlesung mit Java rumgespielt haben, dann sind wir direkt in halbfertige Codebeispiele eingestiegen, damit wir direkt mit Klassen und Objekten hantieren können. Dabei hat uns noch gar nicht interessiert, warum das Programm auf der Konsole startet, wenn man auf "Run" klickt.
Das mit Kontrollfluss und Einstiegspunkt kam dann hinterher, als wir gelernt hatten wie man programmiert und wir angefangen haben auch Software zu bauen.

Du verfolgst da scheinbar eher den Ansatz gleich Programme zu schreiben. Dabei ist dann der erste Schritt natürlich auch zu verstehen wie und warum das Programm überhaupt ein Programm ist. Und da ist es dann sicherlich auch nicht verkehrt zu verstehen, dass javac das was man gerade gebastelt hat übersetzt und java dann das macht, was man in der main geschrieben hat.

Das sind rein vom Ablauf her zwei völlig unterschiedliche Ansätze und keiner von beiden ist richtig oder falsch und auch nicht besser oder schlechter.
Ich würde ersteren einfach mal als moderner ansehen (das meine ich aber wertfrei), eben weil gerade durch die IDEs, die man heutzutage hat (und mein Beispiel BlueJ ist eine IDE, die speziell darauf abzielt Anfängern OOP nahezubringen) man die leichte Zugänglichkeit dazu hat, dass man sich erstmal auf's programmieren lernen beschränken kann, bevor man sich um Compiler und Einstiegspunkte Gedanken machen muss.
 
  • Gefällt mir
Reaktionen: below
Nachtrag:

Wo ich jetzt schon mehrfach BlueJ erwähnt habe, habe ich selber mal auf deren Website geschaut, um mal zu gucken, wohin sich das entwickelt hat - schließlich hab ich das auch seit Jahren nicht gesehen.
Ich finde zu unserer Diskussion passt sehr gut der Abschnitt Why BlueJ?

Ich zitiere mal ein Stück daraus, der genau auf das abzielt was ich in meinem vorigen Post sagte:
4. Problems with Java (and BlueJ's answers)

Java is a reasonably clean language, but by no means free of problems for introductory teaching. For teachers, it is important to know those problems and to have a way to deal with them. Two of the problems most often reported in the literature (for example in [1] and [4]) are:

problems with the main function
problems with text I/O
The main function: The main function has to be written with the signature

public static void main (String[] args)

This causes several problems. Firstly, several concepts are used here which cannot be explained at this stage (static functions, arrays, void return types). So teachers have to use some hand-waiving ("just believe me and write it like this") and students feel frustrated. Secondly, this has nothing to do with object-orientation! The main function does not logically belong to any object. Thus, students start off with seeing an exception rather than a good example of object-orientation.

I/O: {Lass ich mal aus}

/edit:
Der Abschnitt gefällt mir auch noch sehr gut:
5. Real object-oriented teaching

Many Java text books claim to use an "objects first" approach. We very much agree with this idea. In reality, most of the books then go on to explain some low level instructions first and get to objects and classes in chapter four. The reason is an intrinsic problem with Java: if you explain classes first, then you still need a way to execute the class's operations to see a result. And to do this you have to write some driver code. To write this code, you need to know some Java instructions.

In BlueJ, no driver code is needed. Operations can be invoked interactively, so teachers are free to use a real objects-first approach for the first time. Students can be given a class of which they can create objects. They can use those objects. Then they can open them and read, modify or add operations. This is really "objects first" with the introduction of lower level constructs after methods (as a means to implement those methods).
 
Das ist so ein bißchen das Henne/Ei Problem. Das eine geht nicht ohne das andere. Was eine IDE alles vereinfacht und wie mächtig die sein können merkt man erst wenn man eigene makefiles/ant-files von Hand im Terminal geklöppelt hat. Ebenso sind gewisse Dinge wie Kontrollstrukturen, OO-Design zwar grundlegend wichtig. Trotzdem muß ich erstmal wissen wie man ein Hello-World schreibt und Ein/Ausgaben machen kann. Auch skalare Datentypen ( und warum die dann doch wieder besser durch Objekte gekapset werden) sollte man zunächst begreifen.

Also geht nie wirklich das eine ohne das andere. Ein Stück weit muß man damit leben das man Dinge zunächst zu akzeptieren hat und später verstehen wird. Ganz ohne dem geht es, egal welchen Weg man einschlägt nicht.

Ein bißchen bin ich froh, das ich damals simples aber strukturiertes Basic gelernt hab auf einem Rechner der mit seinen 7KB RAM eh nur Textbildschirme mit Grafikzeichen kannte und wo es durchaus noch schnell möglich war auch Assembler zu lernen und nachzuverfolgen wie diese Computer dies dann schrittweise ausführten.

Diese Einfachheit fehlt heute und manchmal denke ich man sollte den Leuten Lern-VMs mit abstrahierten einfachen Maschinen zur Verfügung stellen. Sowas wie die Ruby-Shell scheint mir zum grundsätzlichen lernen wie Rechner funktionieren und wie man programmiert am ehesten geeignet.

Wenn man dann den Weg über einfache Datenstrukturen (Stack,Queue,Liste,Baum) hin zu gekapselten Datenstrukturen, hin zu Objekten zieht und analog den Entwurf vom imperativen Algorithmus über funktionales programmieren hin zu OO-Programmierung und OO-Design und dabei schrittweise IDEs verkompliziert dann vollzieht man diesen Weg nach. Nur wer hat die Zeit dazu dies alles so ausführlich zu lernen?

Ein bißchen so ist es in der Mathematik doch auch. Analysis I kann man noch gut vertehen und lernen. Analysis II und III nimmt man aber erstmal zur Kenntnis ( und das war mir schon zu komplex muß ich gestehen) und versteht es erst später. Selbst gestandene Mathematiker geben zu das das Verständnis für all dies erst Jahre später kommt. Wenn man zu den fürchterlichen "warum-typen" gehört die nur lernen indem sie gleich verstehen ( ich gehöre dazu - ich kann mir wenig merken ich muß es erleben und vollständig begreifen), dann hat man ab bestimmten Komplexitätsgraden Probleme, denn da muß der Stoff zunächst erstmal schlicht gelernt werden. Da hilft dann nur ein abstrahieren in Lern-VMs ( zurück zu den good old times) und Schrittweises aufbauen aller Grundlagen. Wie gesagt ein bißchen bin ich froh das ich nich in die jetzige Komplexität hineingeboren bin, sondern seit Anfang der 80er als junger Schüler alles miterleben und wachsen sehen konnte.
 
wegus: naja, ich sehe das nicht als reines Henne-Ei-Problem - sondern ich sehe die Diskussion gerade einfach auf der Ebene wie man Leuten etwas beibringt, denn wir reden hier ja davon was für Anfänger gut ist.
Ohne Euch jetzt als alt bezeichnen zu wollen, behaupte ich aber mal, dass Ihr die Sache einfach anderes seht, eben weil Ihr programmieren schon in den 80ern gelernt habt, da sah die Welt noch anders aus.
Ich hab immerhin auch noch im ersten Semester Grundlagen imperativer und deklarativer Sprachen gelernt und mit Scheme und Prolog gearbeitet.
Die jetzigen Erstsemester lernen total nach dem Objects-First-Ansatz. Klar lernen die auch ein paar Grundlagen, aber die steigen eben mit Hilfe von BlueJ direkt bei Objekten ein. Da werden eben die Grundlagen und älteren Sprachen nur noch wie in einer Art Geschichtskurs behandelt, damit man weiß wie man zur OOP gekommen ist.
Fairerweise muss ich aber auch erwähnen, dass ich Wirtschaftsinformatiker bin, deshalb sind für uns diese Sachen auch nicht mehr so wichtig, ich glaube die Informatiker mit denen wir die OOP Vorlesung zusammen hören, die haben auch immer noch Vorlesungen in denen sie imperative und deklarative Sprachen ausführlich lernen.

Worauf ich eigentlich hinaus wollte: ich finde den Objets-First-Ansatz zum lernen sehr gut. Insbesondere als Antwort auf die im Forum häufig gestellte Frage wie ein Anfänger programmieren lernen soll (und aus dieser Frage ist ja dieser Thread entstanden) - denn dafür braucht man keine universitäre Ausbildung und muss deshalb auch nicht wissen was der Unterschied zwischen imperativ und deklarativ ist.
Aber der Objects-First-Ansatz läuft nun mal nur anständig mit Hilfe von IDEs.
 
@_ebm_: ich glaube wir reden hier auch einfach von einer anderen Art programmieren zu lernen.

Ganz so einfach sehe ich das nicht. jemanden einfach hinzusetzen "Hier ist ein Buch, Programmiere mir mal was" funktioniert nicht. Das hat bei uns an der Uni auch nie so stattgefunden. Erst wurden Grundlagen vermittelt, sprich Datentypen, Speichergrößen, mathematische Funktionen vs. Funktionen in der strukturierten Programmierung. An die Wege in der Schule kann ich mich schon garnicht mehr erinnern. Ich glaube übrigens schon, dass man einem intelligenten Menschen sagen kann, was ein Einsprungspunkt ist. ("Hier startet das Programm und damit der Startpunkt gefunden wird, muss er genau so aussehen, was die einzelnen Bezeichner bedeuten, lernt ihr später") Es geht auch nicht anders. Wie wegus schreibt, es ist ein rundes Problem und irgendwo muss man anfangen.

Da in der einleitenden Theorie Arrays vermittelt wurden, sollte String[] argv kein Problem sein. Allein das static in der Signatur ist für einen Java-Neuling ungewöhnlich. Das Verständnis kommt erst, wenn man lernt, wie die VM mit statischen Methoden und Feldern umgeht. Das ist aber im Speziellen eine eigenschaft von Java und nicht der OOP im allgemeinen.

Nachdem was du über BlueJ gepostet hast, eignet sich die Sprache gut für das schulische Lernen, um Jugendliche an das Thema heranzuführen. Im Uni-Alltag würde ich soetwas nicht sehen wollen, da mir von zu vielen wesentlichen und in allen Programmiersprachen vorhandenen Konzepten abstrahiert wird.

Du merkst aber, das ist inzwischen zu einem eher didaktischen als pragmatischen Problem geworden. Was muss man lernen, um programmieren zu können? Wo fängt die Praxis an, wo hört die Theorie auf? Es geht ja nicht nur darum, in einem Programm 1+2 berechnen zu wollen. Es soll ja auf effektive Art und Weise ein Problem gelöst werden.
 
Was dagegen ? schrieb:
Ohne Euch jetzt als alt bezeichnen zu wollen, behaupte ich aber mal, dass Ihr die Sache einfach anderes seht, eben weil Ihr programmieren schon in den 80ern gelernt habt, da sah die Welt noch anders aus.

Well, es ist in der Tat so! Mit den daraus resultierenden Vor und Nachteilen. genau wie Du es schreibst.

Was dagegen ? schrieb:
Grundlagen imperativer und deklarativer Sprachen gelernt und mit Scheme und Prolog gearbeitet.
Die jetzigen Erstsemester lernen total nach dem Objects-First-Ansatz. Klar lernen die auch ein paar Grundlagen, aber die steigen eben mit Hilfe von BlueJ direkt bei Objekten ein. Da werden eben die Grundlagen und älteren Sprachen nur noch wie in einer Art Geschichtskurs behandelt, damit man weiß wie man zur OOP gekommen ist.

Das scheint mir IMHO auch der einzig sinnvolle/gangbare Weg! Man merkt aber eben schon ob die Leute da auch begriffen haben warum man bestimmte Dinge so macht ( sprich ob sie die "Geschichte" kennen).

Leider ist das eben auch bei vielen großen Softwareprojekten zu spüren, wo man bei vielen Dingen einfach merkt das da gilt "denn sie wissen nicht was sie tun"!

Ich geb ja zu ich bin in einer kuriosen IT-Zeit groß geworden. Als Student hab ich in einem Technikmuseum in Kassel den Rechner stehen sehen an dem ich als Schüler mal programmieren gelernt hab. Ich glaube auch das daraus ein sehr eigener Blickwinkel entstanden ist, den ich heute gern so manchem vermitteln würde und ich merke "das ist gar nicht mehr so leicht", vor allem ist gar nicht mehr die Zeit da all diese Schritte nachzuvollziehen.

Nötig wäre es denke ich durchaus. Das was ältere Programmierer meist zuviel an Ressourcen bedenken ("das sind ja Megabytes an Daten!" - "na und wen stören heut Megabyte") das beachten Youngsters zu wenig, sie haben kaum ein tieferes Verständnis für sowas und dann dauern eben Listen von "Kunden die im letzten Jahr Produkt X gekauft haben und bisher keinen Kontakt mehr mit dem CustomerService hatten" eben etwas länger, tauschen einmal den ganzen DB-Chache durch, als es ggf. so manch anderer gelöst hätte. Das alte Paradigma was heute zu lange dauert, wird morgen schon durch Hardware schnell genug sein, gilt ja auch nicht mehr wirklich in dem Tempo!


_ebm_ schrieb:
Ich glaube übrigens schon, dass man einem intelligenten Menschen sagen kann, was ein Einsprungspunkt ist.

Man kann Bewerber gut aus der Ruhe bringen in dem man sie fragt was ein Interrupt ist und wenn man ihnen einen Schraubendreher und einen PC gäbe ob sie in einem alten PC wohl einen finden könnten und wie sowas eigentlich aussähe :) Wer Microcontroller programmieren gelernt hat der löst das, der Rest kommt übel ins Schwimmen! :D
 
Aber meine alt geliebte Konsole lass ich mir nich nehmen
Nochmal böse nachgefragt: Was glaubst Du denn, welchen Schaden hab ich durch meine IDE Benutzung :p ?

Ohne Euch jetzt als alt bezeichnen zu wollen, behaupte ich aber mal, dass Ihr die Sache einfach anderes seht, eben weil Ihr programmieren schon in den 80ern gelernt habt, da sah die Welt noch anders aus.
Aber Du siehst, die Alten Säcke sind sich auch uneins über "IDE vs. Konsole" ;)

Was muss man lernen, um programmieren zu können? Wo fängt die Praxis an, wo hört die Theorie auf? Es geht ja nicht nur darum, in einem Programm 1+2 berechnen zu wollen. Es soll ja auf effektive Art und Weise ein Problem gelöst werden.
Richtig, und deshalb ist Deine Frage, "IDE oder einfacher Editor" falsch gestellt. Es geht um etwas ganz anderes.

Alex
 
Worauf ich eigentlich hinaus wollte: ich finde den Objets-First-Ansatz zum lernen sehr gut. Insbesondere als Antwort auf die im Forum häufig gestellte Frage wie ein Anfänger programmieren lernen soll (und aus dieser Frage ist ja dieser Thread entstanden) - denn dafür braucht man keine universitäre Ausbildung und muss deshalb auch nicht wissen was der Unterschied zwischen imperativ und deklarativ ist.
Aber der Objects-First-Ansatz läuft nun mal nur anständig mit Hilfe von IDEs.

Es mag etwas intuitiver sein, objektorientiert zu programmieren. Die lernkurve finde ich aber deutlich höher. Man muss nicht nur begreifen, was ein Typ und eine Methode sind, man schlägt sich auch mit Klassen, Objekten, Schnittstellen, Vererbung, Instanzen und Referenzen herum. Was bedeutet jetzt "static" in diesem Zusammenhang? Wie geht diese Sprache damit um, die ich gerade am Wickel hab (z.B. Unterschied Java <-> C++)

Mir gefällt der Object-First-Ansatz garnicht, da er zu Oberflächlichkeit und Missverständnissen führen kann. Könntest du basierend auf deinem Wissen mit C objektorientiert programmieren? Glaub mir, das geht! Das hat nur wenig mit der Syntax einer Sprache zutun. Die hilft dir nur dabei!
 
Zurück
Oben Unten