IDE oder einfacher Editor zum Einstieg

[wegus]

Was muss man lernen, um programmieren zu können?

strukturiertes denken, präzises sprachliches Beschreiben, erfassen von Relationen und deren Abbildung in Algorithmen, dazu Rückgreifen auf bereits validierte Entwurfsmuster und Datenstrukturen. Denken in Abbildungen (algebraische Mathematik) und Näherungsverhalten ( Numerik).

Ob man das eher mit nem Editor oder einer IDE lösen mag muß jeder selbst entscheiden. Kurz gesagt: man muß Denken lernen, Verfahren lernen und dazu ist ein Grundwissen über die verwendeten Geräte und ihre Funktion unabdingbar.

 

[_ebm_]

Nochmal böse nachgefragt: Was glaubst Du denn, welchen Schaden hab ich durch meine IDE Benutzung ?

Ich gebe zu, da habe ich nen Schaden Deiner könnte aber genausogut die Abneigung gegen alles, was bernstein auf grün ist sein

Aber Du siehst, die Alten Säcke sind sich auch uneins über "IDE vs. Konsole"

Absolut!

Richtig, und deshalb ist Deine Frage, "IDE oder einfacher Editor" falsch gestellt. Es geht um etwas ganz anderes.
Alex

Ja, ist sie mglw. Ich befürchte nur, dass der Threadtitel unverständlich wird, wenn ich den Inhalt korrekt charakterisiere

 

[_ebm_]

strukturiertes denken, präzises sprachliches Beschreiben, erfassen von Relationen und deren Abbildung in Algorithmen, dazu Rückgreifen auf bereits validierte Entwurfsmuster und Datenstrukturen. Denken in Abbildungen (algebraische Mathematik) und Näherungsverhalten ( Numerik).

Ob man das eher mit nem Editor oder einer IDE lösen mag muß jeder selbst entscheiden. Kurz gesagt: man muß Denken lernen, Verfahren lernen und dazu ist ein Grundwissen über die verwendeten Geräte und ihre Funktion unabdingbar.

Danke! Genau so sehe ich das auch! Ich kann auch auf einem blatt Papier programmieren! Und da gibt es definitiv keinen "Run"-Knopf

(Nein, ich meine keine Lockstreifen)

 

[wegus]

Was ich mit großer Sorge sehe ist eher die zunehmende Unfähigkeit des exakten Beschreibens. Ein Problem das ich nicht wirklich beschreiben kann ( ich mag es verstanden haben, aber ich kann es nicht kommunizieren) kann ich nicht darlegen und somit nie vollständig mit einer Gruppe lösen.

Ich gebe zu ich habe ein Problem damit wenn die Leute fragen ob man da nicht was proggen kann wenn man gecheckt hat wie das funzt. Das liegt aber weniger an den neuen Begriffen, sprachliches wandelt mit jeder Generation und ich hab da keine Probleme mit. Diese Sprache aber nervt mich, weil ich weiß ich habe es mit einem Gegenüber zu tun dessen sprachliche Fähigkeiten so unausgereift sind, das er mir die nötige Information nicht wird geben können ( sprich es wird sehr sehr anstrengend sie aus ihm herauszubekommen). Da sehe ich ein viel größeres Problem als in der Werkzeugbdebatte.

Wer programmieren will, braucht mehr als den Spaß an formalen Sprachen, die natürlichen Sprachen und deren Mehrdeutigkeiten sollten ihm bewußt sein und er muß damit gern spielen wollen.

 

[_ebm_]

Wegus, du bringst hier gerade einen Aspekt in die Diskussion, der mir auch nicht gefällt. Ich hatte in den letzten Semestern meiner Uni-Tätigkeit die Erstsemestereinführung mit begleitet. Da kam es immer öfter zu Aussagen wie "Wat, nur 3 Fehler pro Seite in einer Klausur, ey Alda ick will proggen". Da hab ich mich regelmäßig gefragt, wie diese Kandidaten die Hochschulreife erreicht haben. Zum Glück blieben die nur selten länger.

Es ist nicht einfach, ein Problem genau zu fassen und dann auch zu beschreiben. Produktspezifikation ist nicht umsonst ein gut bezahlter Job.

 

[wegus]

ich hab da mal eine sehr funktionale Beschreibung gelernt von jemanden der noch Compiler für 64KB RAM Rechner (PDP11) gemacht hat, also aus einer sehr frühen Zeit:

Programmieren heißt zunächst eine Problemmenge X klar zu definieren und einen Lösungsraum Y. Dann gilt es eine Abbildung zwischen beiden so klar zu definieren das man eine Lösungsfunktion f(x)=... findet die das Problem löst.

Dann gilt es die Menge der Probleme (X) korrekt durch Repräsentanzen im Rechner abzubilden. Also jedes reelle x aus X muß eine eineindeutige Darstellung im Rechner finden. Die Abbildung sei g(x). Dann ist es nötig alle Repräsentanzen in eine entsprechende Lösungsmenge zu überführen, die ebenfalls eineindeutige Entsprechungen zu allen Lösungen in der Realität liefert. Dies ist quasi die rechnerinterne Entsprechung von f(x) und sei mit h(x) benannt. Danach ist es logischerweise ebenso wieder nötig die Ergebnisrepräsentanzen in eineindeutig entsprechende Lösungen zu überführen - die sei i(x). Das bringt einen zu der banalen Aussage

f(x)=g(h(i(x))) sei programmieren

oder etwas Länger um das Problem f(x) lösen zu können, muß man zunächst alle möglichen Eingaben exakt beschreiben g(x), eine entsprechung des Algorithmus im Rechner definieren h(x) und diese dann wieder in die Realität überführen sobald berechnet i(x).


Man mag denken das sei Schnee von gestern, aber wenn ich sehe das auch heute in modernen .NET-Anwendungen Leute hergehen und REFA-Stunden ( das sind Stunden mit 100 Minuten) in Float-Werte in DB-Systemen Abbilden und sich dann über Rundungsfehler bei Stundenabrechnungen wundern (*), dann wird eben selbst solch banale Haarspalterei wichtig. Bis man das Begriffen hat kennt man hoffentlich mehrere Editoren und IDEs und kann sich jeweils das passende Werkzeug heraussuchen.


(*) und das steht zu float in der DB-Doku: Ungefähre Zahlendatentypen für numerische Gleitkommadaten. Gleitkommadaten sind ungefähr, d. h. nicht alle Werte im Bereich des Datentyps können exakt dargestellt werden.

 

[below]

Da hab ich mich regelmäßig gefragt, wie diese Kandidaten die Hochschulreife erreicht haben. Zum Glück blieben die nur selten länger.

"Von einer Klasse Schäferhunde schafft einer das Abitur"

Und die Abbrecherraten in Informatik waren schon immer hoch.

Alex

 

[_ebm_]

...aber wenn ich sehe das auch heute in modernen .NET-Anwendungen Leute hergehen und REFA-Stunden ( das sind Stunden mit 100 Minuten) in Float-Werte in DB-Systemen Abbilden und sich dann über Rundungsfehler bei Stundenabrechnungen wundern...

Hoch lebe die Zahlentheorie...

 

[wegus]

"Von einer Klasse Schäferhunde schafft einer das Abitur"

Und die Abbrecherraten in Informatik waren schon immer hoch.

ich gehör ja selber zu den Abbrechern weil IMHO woanders echt Überlast in der Informatik lag ( das gibts heute auch so nicht mehr). In Punkto Programmierung hat man aber IMHo einen Fehler gemacht indem man mit Lehrberufen suggeriert hat man könne das alles so en passant lernen. Dem ist nicht so und es reicht eben nicht aus einfach nur die "Vokabeln" einer formalen Sprache verwenden zu können. Programmieren bedeutet ein weit tiefgreifenderes Verständnis ( ähnlich wie es Juristen entwickeln müssen ) zu haben um zu wissen welches Werkzeug welche Methode wann wo am sinnvollsten greift. Demzufolge sind auch unterschiedliche Tools zu erlernen und das Programmeirwissen nicht innerhalb einer IDE/Editor abzufrühstücken!

Leider ist programmieren heute auch mehr oder weniger nur noch die lästige und häufig unreflektierte Umsetzung von UML-Modellen, also Fließbandarbeit statt Enwticklungsprozeß. Manche beschreiben das als Industrialisierung der Softwareentwicklung ( weg vom Handwerk hin zur Massenware).

 

[was dagegen ?]

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!

Ok, ich kenne jetzt C wirklich überhaupt nicht, außer, dass ich es halbwegs lesen kann, wenn Du mir den Code vor die Nase knallst.
Trotzdem behaupte ich, dass ich Deine Frage mit Ja beantworten kann.
Gerade durch die Art wie ich es gelernt habe, ist für mich eine Klasse eben nicht das Ding was man groß schreiben soll und ein class davor packt und Vererbung auch nicht nur durch ein extends gegeben. Ich habe die Konzepte hinter Kapselung, Polymorphie und wie sie alle heißen, verstanden - zwar am Beispiel einer konkreten Programmiersprache, aber das auch nur, damit ich nicht nur einen Nagel in der Hand halte, sondern ihn irgendwie auch in die Wand bekomme.
Das habe ich zwar mit einem Hammer gelernt, würde es aber jetzt auch mit einer Zange hinkriegen, sofern die denn einigermaßen dafür geeignet ist. Also würde ich wohl auch mit C OO programmieren können

Was wir aber bei unserer Diskussion uns m.E. noch mal in Erinnerung rufen sollten: die Frage entstand nicht ursprünglich daraus wie man einen Softwareentwickler ausbilden soll (und darüber reden wir grad), sondern wie jemand, der in einem Forum nach Programmierung fragt das ganze lernen soll.
Wenn es nämlich um jemanden geht, der damit nicht seinen Lebensunterhalt bestreiten will, sondern sich selbst das ein oder andere Helferlein für seinen Alltag basteln will, dann ist der Weg zu lernen über den wir gerade reden völliger Overkill.
Du machst ja auch keine Schreinerausbildung, weil du dir ein Regal für den Schuppen bauen willst...

 

[wegus]

ber das auch nur, damit ich nicht nur einen Nagel in der Hand halte, sondern ihn irgendwie auch in die Wand bekomme.
Das habe ich zwar mit einem Hammer gelernt, würde es aber jetzt auch mit einer Zange hinkriegen

Dazu paßt der Spruch meines Kollegen "Wer einen Hammer hat für den besteht die Welt immer aus Nägeln" statt die Zange zum hämmern zu nehmen muß man eben auch erstmal schauen ob überhaupt Nägel da sind

sondern wie jemand, der in einem Forum nach Programmierung fragt das ganze lernen soll.

IMHO gibt es je nach Lerntyp da andere Ansätze. Jemand wie ich, der ungern Dinge als gegen hinnimmt und so schlecht auswendig lernt, der also verstehen muß um zu lernen ist am Anfang halt schlecht in IDEs aufgehoben.

Andere die ungern eine horde Dateien hüten wollen, die mit einem Shebang oder einem makfile Probleme haben die sich in einer Shell nicht bewegen können, denen mag es umgekehrt gehen. Eine Standardantwort und eine Standardlösung wird es nicht geben.

 

[_ebm_]

In Punkto Programmierung hat man aber IMHo einen Fehler gemacht indem man mit Lehrberufen suggeriert hat man könne das alles so en passant lernen. Dem ist nicht so und es reicht eben nicht aus einfach nur die "Vokabeln" einer formalen Sprache verwenden zu können. Programmieren bedeutet ein weit tiefgreifenderes Verständnis ( ähnlich wie es Juristen entwickeln müssen ) zu haben um zu wissen welches Werkzeug welche Methode wann wo am sinnvollsten greift.

Grundsätzlich gebe ich dir recht. Um in der Softwareentwicklung vernünftige Ergebnisse liefern zu können, gehört ein tiefgreifendes Verständnis dazu. Daher rührt ja auch meine Einstellung eingangs. Wenn mir Werkzeuge Dinge
verschleiern und ich nicht mal weiss, was da eigentlich im Hintergrund passiert, passiert, entsteht oft Humbug. Allerdings muss man hier auch die Verhältnismässigkeit sehen. In der Lehre an den Schulen werden absolute Grundlagen gelehrt. Zum Leidwesen der Professoren und Assistenten an den Universitäten geht oftmals sogar der immanente Zusammenhang zur Mathematik verloren. Wissen über Logik und Typentheorie sind aber weniger von Bedeutung.

Demzufolge ist programmieren auch mehr oder weniger nur noch die lästige und häufig unreflektierte Umsetzung von UML-Modellen, also Fließbandarbeit statt Enwticklungsprozeß.

Oh da wirst du aber bei den Freunden der MDA auf Wiederstand stossen! Ohne UML und SDL lassen sich heute keine komplexen Probleme mehr beschreiben. Ohne Anwendungsmodelle (SOA/BEPL, CCM,...) bleibt die Präzision auf der Strecke. Sicherlich ist es dann oftmals Fliessbandarbeit. Allerdings werden so Probleme zerkleinert und sind damit leichter zu fassen. Das kommt der Qualität zu gute.

(Ich konnte da eben nicht widerstehen, da ich genau in dieser Branche tätig bin. Wir entwickeln genau so ein Modellierungstool)

 

[wegus]

Oh da wirst du aber bei den Freunden der MDA auf Wiederstand stossen! Ohne UML und SDL lassen sich heute keine komplexen Probleme mehr beschreiben.

durch diese hole Gasse geh ich locker mit Es ändert aber nichts an der Umbewertung die das tatsächliche codieren dadurch erfährt.

 

[_ebm_]

Was wir aber bei unserer Diskussion uns m.E. noch mal in Erinnerung rufen sollten: die Frage entstand nicht ursprünglich daraus wie man einen Softwareentwickler ausbilden soll (und darüber reden wir grad), sondern wie jemand, der in einem Forum nach Programmierung fragt das ganze lernen soll.

Einer, der das nur als Hobby betreiben will, sollte wirklich zu einer IDE greifen, da er so nicht in die Interna einsteigen muss. Da gebe ich dir recht, war aber in diesem Fall auch nie wirklich anderer Meinung.

IMHO gibt es je nach Lerntyp da andere Ansätze. Jemand wie ich, der ungern Dinge als gegen hinnimmt und so schlecht auswendig lernt, der also verstehen muß um zu lernen ist am Anfang halt schlecht in IDEs aufgehoben.

Andere die ungern eine horde Dateien hüten wollen, die mit einem Shebang oder einem makfile Probleme haben die sich in einer Shell nicht bewegen können, denen mag es umgekehrt gehen. Eine Standardantwort und eine Standardlösung wird es nicht geben.

Ich bin auch einer der ersten. Irgendwie hab ich mich immer betrogen gefühlt, wenn irgendein Programm etwas für mich gemacht hat, was ich nicht verstanden hab.

 

[_ebm_]

durch diese hole Gasse geh ich locker mit Es ändert aber nichts an der Umbewertung die das tatsächliche codieren dadurch erfährt.

Ja, die Softwareentwicklung bleibt eben nicht stehen. Die Probleme lassen sich nunmal immer seltener auf einen Blick fassen. Man ist gezwungen, sie zu zerlegen und glaub mir, die Teilprobleme sind immernoch spannend genug, um sich daran zu probieren. Sie sind ja in sich abgeschlossen und du kannst dich auf die Anschlusspunkte zu den anderen Teilproblemen verlassen. Für dich ist die Schnittstelle einfach ein gut dokumentiertes Versprechen (Vertrag: Wenn du das machst, liefer ich dir genau das)

(Denkt euch mal bitte das E im Widerstand da oben weg )

 

[wegus]

@ebm: ich weiß schon was UML ist , ich wollt nur auf die Entwertung hinaus die das für die reinen Codierer bedeutet!

 

[_ebm_]

@ebm: ich weiß schon was UML ist , ich wollt nur auf die Entwertung hinaus die das für die reinen Codierer bedeutet!

Wieso? Die Kompexität seiner Probleme bleibt doch bestehen, nur dass er jetzt nicht mehr ein Softwaresystem betreut, sondern nur einen Teil davon! Er bekommt weiterhin einen Auftrag mit einer Zielvereinbarung und implementiert das, was auf dem Papier steht. In seiner Implementierung kann er sich austoben, wie es ihm beliebt (im Rahmen der Zeit und Möglichkeiten). Er programmiert immernoch in einer Programmiersprache.

Aber ja: Ohne Wissen über Metamodelle kommt man heute kaum noch weiter. Es ist eine neue Ebene. Trotzdem kann man auch mit SDL und UML coden, nur eben auf einer abstrakteren Ebene. Ich empfinde das als eine interessante Herausforderung..

 

[was dagegen ?]

Ich muss wegus da recht geben. Gerade bei uns wurde das sehr stark so gelehrt, da einige unsere Profs sehr stark diesen Standpunkt vertreten.
Dipl-Informatiker werden keine Programmierer, sie werden Softwarearchitekten. Das implementieren kann dann ein gelernter Fachinformatiker oder eben der Inder machen, Outsourcing sei dank.

Klar gilt das nicht uneingeschränkt und sowieso erst in Häuser einer gewissen Größe. Aber es gibt unter den Informatikern schon eine starke Bewegung die das eigentliche codieren immer mehr abwerten zu einer rein handwerklichen Tätigkeit, wo der Programmierer den Passenden Nagel bekommt und ihn nur noch mit seinem Hammer in die vorgegebene Stelle in der Wand einschlägt.

 

[below]

Ich muss wegus da recht geben. Gerade bei uns wurde das sehr stark so gelehrt, da einige unsere Profs sehr stark diesen Standpunkt vertreten.

Ich bin mir nicht sicher. Damals hatte ich den Eindruck, dass wir uns Programmieren an sich eben selbst beibringen sollen.
Das war auch damals nicht echt so das Problem, da mein Semester voll war von Typen wie mir, die ihr Hobby zum Beruf machen wollten.

Problematisch wurde es aber nach dem Abschluss für die, die nicht von sich aus Praktisch gearbeitet haben. Damit kam man zwar durch das Studium, aber in den 90ern wurde auch von einem Dipl Inform erwartet, dass man auch mal ein bischen was wegcodet.

Alex

 

[_ebm_]

Ich muss wegus da recht geben. Gerade bei uns wurde das sehr stark so gelehrt, da einige unsere Profs sehr stark diesen Standpunkt vertreten.
Dipl-Informatiker werden keine Programmierer, sie werden Softwarearchitekten. Das implementieren kann dann ein gelernter Fachinformatiker oder eben der Inder machen, Outsourcing sei dank.

Klar gilt das nicht uneingeschränkt und sowieso erst in Häuser einer gewissen Größe. Aber es gibt unter den Informatikern schon eine starke Bewegung die das eigentliche codieren immer mehr abwerten zu einer rein handwerklichen Tätigkeit, wo der Programmierer den Passenden Nagel bekommt und ihn nur noch mit seinem Hammer in die vorgegebene Stelle in der Wand einschlägt.

Aber wieso fühlt sich der Fachinformatiker dadurch deklassiert? Er hat eben genau das gelernt! Die Lehre an den Universitäten muss sich nunmal an die
Bedürfnisse der Industrie anpassen. Es muss Fachkräfte für den Softwareentwurf geben und dann versierte Techniker, die die Auflagen implementieren. Wenn das wie "hau mal den Nagel hier rein" ankommt, wurde überspezifiziert!

Edit: Danke Alex, Coden sollte der Ingenieur trotzdem noch...