Java oder welche Sprache?

[Anderer Basher]

Dass der Code für die Speicherverwaltung komplett wegfällt, das ganze recht schnell ist und ich da absolut keinen Fehler mehr machen kann halte ich für wesentlich wichtiger für die "Schönheit".

Richtig. Genau darum gehts. Und genau das ist in Java nicht der Fall. Ich muss manuell irgendwas closen.

Der Rest wird fast immer von irgendwelchen Libraries übernommen, da muss ich auch kaum etwas per Hand schreiben.

kaum != gar nichts
Wo du etwas per Hand schreiben musst, können Fehler passieren. Immer.

C oder C++

Boah ey, Junge. Du hast echt nichts verstanden. Du bist der Realität gegenüber so ignorant, dass du dir einredest, C++ sei immer noch eine Erweiterung von C. Es ist mehr als das. Die Sprachen haben sich auseinanderentwickelt. In C musst du alles manuell aufräumen, also immer schön die Finger still halten, was das betrifft.

mehr Code selber schreibt und kaum Libs benutzt muss man sich öfter selbst um irgendwelche Resourcen kümmern.

So 'n Blödsinn. Wenn du eine OS-API wrappst, schreibst du dir eine kleine Klasse, die im Destruktor ein close(handle) oder etwas vergleichbares macht, das wars dann auch schon. Dieses Konzept lässt sich auf jede beliebige Resource übertragen. Der Aufwand ist minimal.

Eine Datenbankverbindung habe ich auch schon lange nicht mehr per Hand zugemacht und wenn ich eine Datei benutze mache ich die nach dem Schreib- oder Lesevorgang meistens gleich wieder zu

Das macht alles RAII für mich.

Wie gesagt, wenn sogar eher "Low-Level"-Sprachen wie D oder Go auf GC setzen kann das wohl nicht die falsche Richtung sein für Sprachen, mit denen man auf einer etwas höheren Ebene entwickelt.

Tausende Fliegen können nicht irren, schon klar. Warum verweigerst du dich eigentlich der Realität und behauptest, man müsse so extrem viel mit Resourcen hantieren? In C++ ist der vom Java-Basher erwähnte unique_ptr die Lösung für die meisten Fälle. Meist sind Besitzverhältnisse so klar, dass man nicht lange darüber nachdenken muss, wo und wann irgendwas freigegeben werden muss.

Was der Java-Basher nicht weiß: Man kann mit unique_ptr auch jede beliebige Art von Resource verwalten, indem man einen sog. "Deleter" angibt, also eine Funktion, die bei Freigabe aufgerufen werden soll.

Über Schönheit kann man sich natürlich streiten, aber für mich ist C++ die hässlichste Sprache, die ich bisher benutzt habe. Fortran (immerhin in einer modernen Form) war auch dabei Man kann damit leben, aber ich bin doch ganz froh, wenn ich was anderes benutzen kann...

Weil du kein modernes C++ kennst. Modernes C++ besteht nicht aus irgendwelchen Zeigerfrickeleien, Resource-Frickeleien oder ähnliches, wie ich sie immer wieder von naiven Programmierern hören muss. Es gibt da so ein schönes Sprichwort, es fängt an mit: Wenn man keine Ahnung hat, ...

Doch, das ist ein Problem, wenn man keine Refcounts hat Die JVM verzichtet ja auch Refcounting und das hat ja auch gute Gründe.

Richtig, Refcounts haben ihre Probleme. Aber 1) sind Besitzverhältnisse in 99,9% der Fälle so klar, dass ein GC die langsame, inperformante und unnötige Wahl ist und 2) Wird selbst der GC irgendwann feststellen, dass ein Objekt nicht mehr gebraucht wird und kann dann eine entsprechende Freigabemethode aufrufen.

Dann muss man aber auch wissen, dass der komplette Code, der irgendwie vom Destruktor aufgerufen wird sich an die Regeln hält.

Nicht unbedingt. Es hat sich in C++ die Konvention durchgesetzt, in Destruktoren nichts zu werfen. Wenn man über einen solchen Fehler informiert werden möchte, ruft man explizit eine .close() Methode auf, die etwas wirft oder ein Fehlerflag setzt.

Oder ich packe es auch wieder in try-catch ein, aber schön ist das dann auch nicht mehr...

Das ist dann aber immer noch nur ein einziges mal, nämlich genau dann, wenn ich den Destruktor implementiere. Besser, als bei jeder Verwendung der Klasse einen try-catch Block um das close zu brauchen. Absolut lächerlich.

 

[escalate]

Genau aus den Gründen die Du aufgeführt hast, ist das auch gut so!

-- für Operator-Overloading

Fehlende Möglichkeiten, Infix-Operatoren zu definieren führt dazu, dass man hin und wieder unleserlichen Code schreiben muss (nicht nur kann).

BigInteger y = a2.multiply(x.pow(2)).add(a1.multiply(x)).add(a0);

Ist schon sehr hübsch, aber ich schreibe lieber:

y = a2 * x ** 2 + a1 * x + a0

Normalerweise lag der eigentliche Reiz an Java in einer gewissen wohl-Definiertheit, der leider immer mehr und mehr aufgeweicht wird.

Vielleicht wäre es wirklich besser, einen Schlussstrich zu ziehen und nur noch Kleinigkeiten zu verbessern. Wer das nicht will kann sich ja bei anderen Sprachen umsehen. Gibt doch genügend Auswahl...

 

[Java-Basher]

Dass der Code für die Speicherverwaltung komplett wegfällt, das ganze recht schnell ist und ich da absolut keinen Fehler mehr machen kann halte ich für wesentlich wichtiger für die "Schönheit".

Die Speicherverwaltung fällt mit Destruktoren genau so weg. Aber sie sind halt darüber hinaus wesentlich mächtiger als der GC. (Siehe manuelles close())

Über Schönheit kann man sich natürlich streiten, aber für mich ist C++ die hässlichste Sprache, die ich bisher benutzt habe.

Aber auch wenn man über Schönheit streiten kann, sollte man schon Gründe dafür nennen. Manuelle Speicherverwaltung lasse ich jedenfalls nicht gelten, denn dazu wirst du schlicht und ergreifend nicht gezwungen.

Dann muss man aber auch wissen, dass der komplette Code, der irgendwie vom Destruktor aufgerufen wird sich an die Regeln hält.

Stimmt, aber der Destruktor besteht meinstens aus einem delete oder einer Funktion einer C-API, da hält sich der Aufwand in Grenzen.

 

[escalate]

Boah ey, Junge. Du hast echt nichts verstanden. Du bist der Realität gegenüber so ignorant, dass du dir einredest, C++ sei immer noch eine Erweiterung von C.

Interessant, dass du meinst meine Gedanken lesen zu können aber da ist wohl etwas schiefgelaufen...

Weil du kein modernes C++ kennst.

Da hat dein Gedankenlese-Modul schon wieder übelst versagt...

Tausende Fliegen können nicht irren, schon klar.

Wenn die Fliegen schon einen C++-Compiler geschrieben haben würde ich sie zumindest ernstnehmen

Lies dir mal durch, was ein Erfinder einer modernen Programmiersprache zu dem Thema GC zu sagen hat und dann sagst du mir mal, was du davon nicht glaubst.

Nicht unbedingt. Es hat sich in C++ die Konvention durchgesetzt, in Destruktoren nichts zu werfen.

Wenn man sich auf Konventionen verlässt können Fehler passieren.

 

[Anderer Basher]

Interessant, dass du meinst meine Gedanken lesen zu können aber da ist wohl etwas schiefgelaufen...

Ich nur langsam angepisst von den Programmierern anderer Sprache, die mich mit C'lern in eine Schublade stecken. Entschuldige den Ton.

Lies dir mal durch, was ein Erfinder einer modernen Programmiersprache zu dem Thema GC zu sagen hat und dann sagst du mir mal, was du davon nicht glaubst.

Werde bitte etwas konkreter.

Wenn man sich auf Konventionen verlässt können Fehler passieren.

Richtig, aber 1) Verwende ich schlechten Code nicht und 2) habe ich meinen letzten Destruktor vor geschätzt 'nem Monat geschrieben.

P.S.: Ich finde ist interessant, dass du lediglich zu dem irrelevanten Mist, der lediglich meine persönliche Meinung widerspiegelst, Stellung beziehst, aber meine sachlichen Argumente vollkommen ignorierst.

 

[fastjack]

Ihr könnt übrigens auch buchstabenweise zitieren

Naja, auf jeden Fall können Fliegen und deren Maden an einem Tag 140 Kilogramm totes Elefantenfleisch in Brei umwandeln (hab ich gerade in N24 gesehen). Aber ne Fliege die nen c++ Compiler schreibt, neeee.

@Java-Basher Du merkst ab das Du hier in einem Java-Forum bist oder nicht gelle?

 

[Java-Basher]

@Java-Basher Du merkst ab das Du hier in einem Java-Forum bist oder nicht gelle?

Äh.. was?

 

[escalate]

Mich würde einfach mal deine Meinung (oder die vom anderen Basher) zu diesem Link hier interessieren:

Garbage Collection - D Programming Language

Würdest du dem Erfinder von D (oder auch denen von Go) empfehlen, den GC standardmäßig wegzulassen?

Richtig. Genau darum gehts. Und genau das ist in Java nicht der Fall. Ich muss manuell irgendwas closen.

Der zitierte Teil von mir bezieht sich auf die Speicherverwaltung. Und da muss ich nichts manuell closen, also was soll ich mit der Antwort anfangen?

So 'n Blödsinn. Wenn du eine OS-API wrappst, schreibst du dir eine kleine Klasse, die im Destruktor ein close(handle) oder etwas vergleichbares macht, das wars dann auch schon. Dieses Konzept lässt sich auf jede beliebige Resource übertragen. Der Aufwand ist minimal.

Da kann ich nur auf das nächste Zitat verweisen:

kaum != gar nichts
Wo du etwas per Hand schreiben musst, können Fehler passieren. Immer.

Es ist wie bei Konventionen: es können Fehler passieren, im Normalfall aber eher nicht. Wie gesagt, ich habe schon länger nichts mehr manuell aufräumen müssen und im Normalfall macht das eine Lib im Hintergrund. Der vertraue ich auch, dass sie das richtig macht.
Im "schlimmsten" Fall muss ich an sinnvoller Stelle ein obj.dispose() aufrufen und das ist jetzt auch nicht besonders fehleranfällig.

Warum verweigerst du dich eigentlich der Realität und behauptest, man müsse so extrem viel mit Resourcen hantieren?

Extrem viel? Wer sagt denn das? Ich muss quasi überhaupt nicht mit Resourcen hantieren und bei C++ darf man sich (je nach Anwendung) zusätzlich noch ein bisschen mit Speicherverwaltung beschäftigen...

Besser, als bei jeder Verwendung der Klasse einen try-catch Block um das close zu brauchen. Absolut lächerlich.

Dazu zwingt einen keiner, man kann den Code anders organisieren.

 

[MasterK]

Und wo ist die Unlogik ein Interface zu haben welches sich "AutoCloseable" nennt? Ich finde der Interfacename trifft es schon ziemlich gut.

Es geht überhaupt nicht um den namen, sondern um die art und weise an sich. Was mach ich denn, wenn ich eine bibliothek benutze, welche mir eine final klasse ohne AutoCloseable zur verfügung stellt?
Es ist eben ein nachträglich rangepapptes feature welches nicht mal allgemeingültig funktioniert.

Was mache ich, wenn da irgendwas schiefgeht? Exceptions werfen im Destruktor soll ja keine so gute Idee sein...

Die gegenfrage wurde ja schon gestellt: was machst du in seinem solchen fall? Ein try-catch-finally block um den try-catch block?

Eine Sprache, die nicht hinter ihren Objekten saubermacht, ist schlicht und ergreifend inkontinent. Aber wenn du ständiges Windelwechseln für "elegant" hältst...

Holen wir jetzt den fäkalhumor raus? Man kanns auch anders ausdrücken: in C++ darf ich selbst entscheiden, wann ich sch****.

Letztendlich ist die ganze diskussion bzgl GC in c++ und java eh schwachsinn. Wenn man c++ nutzt, dann ja gerade auch wegen der möglichkeit, das löschen von objekten absolut eindeutig definieren zu können. So wie der GC eben ein feature von java ist, ist eben RAII ein feature von c++. Sie haben beide ihre berechtigung und sind beide mächtige werkzeuge. Letztendlich gibt es bzgl GC nur eines zu sagen: wenn ich in C++ garbage collection haben will, dann KANN ich das auch. Ja, es gibt auch GC bibliotheken für c++. Aber garantiert aufgerufene desktruktoren in java kann ich nicht haben.

Und um das ganze noch abzurunden: In welcher sprache ist eigentlich die HotSpot VM geschrieben?

 

[Noctarius]

Dass du als Mod ein solches Anti-Argument bringst, finde ich unter aller Sau. Zumal du ja offenbar selbst für Operator-Überladung bist. Ich könnte genauso eine Methode schreiben, die .add() heißt und in Wirklichkeit eine Email an den Chef mit dem Inhalt "**** dich" sendet, oder beim nächsten Lieferdienst Pizza bestellt. Wie wäre es mit einer Variable namens socket, die eigentlich ein Thread ist?

C++ stellt einem hier ein wichtiges Mittel zur Verfügung, seinen Code ausdrucksstärker zu machen. Jedes Sprachmittel kann missbraucht werden, aber darum geht es nicht. Kein guter Programmierer würde so einen operator + schreiben, deshalb ist das Argument unbrauchbar.

Äh? Ich habe lediglich gesagt, dass es aus diesem Grund nicht integriert wird. Das war die offizielle SUN Aussage - habe ich an irgendeiner Stelle gesagt, dass ich diese Ansicht teile?

Vielleicht erst lesen, dann denken, dann abreagieren, dann von C++ auf Java schalten und erst danach antworten...

Leute wie du sind es die unserem tatsächlich mal sachlichem C++-Freund Sätze erzwingen wie "ich will nicht flamen oder trollen" ... Junge Junge... Und schon sind wir wieder im Kindergarten.

 

[Landei]

Holen wir jetzt den fäkalhumor raus? Man kanns auch anders ausdrücken: in C++ darf ich selbst entscheiden, wann ich sch****.

Da kommen wir zum Punkt: Wieso glaubst du, dass du die beste Methode und den besten Zeitpunkt besser bestimmen kannst als ein moderner, ausgereifter GC? Die Praxis zeigt, dass der GC seinen Job extrem gut (und natürlich 100% fehlerfrei) macht, auf jeden Fall besser als der durchschnittliche C++-Programmierer. Die Anwendungen, wo extremes Finetuning und absolute Kontrolle notwendig sind, sind eine Nische, für die Java sowieso nicht gedacht ist. Die breite Masse der Anwendungsprogramme braucht so etwas schlicht und ergreifend nicht.

Ich habe das Gefühl, manche Programmierer denken, sie "verlieren die Kontrolle", wenn ihnen der Compiler, GC, die IDE oder sonstwer Arbeit abnimmt, aber genau das Gegenteil ist der Fall, sie gewinnen zusätzliche Kontrolle. Meditiere ein wenig darüber, dann wirst du vielleicht auch erleuchtet.

 

[Java-Basher]

Mich würde einfach mal deine Meinung (oder die vom anderen Basher) zu diesem Link hier interessieren:

Reference counting is a common solution to solve explicit memory allocation problems. [...]

Ich habe shared_ptr noch nie gebraucht. (Denn üblicherweise hat ein Objekt auch einen klaren Scope.)

Destructors are used to deallocate resources acquired by an object. For most classes, this resource is allocated memory. With garbage collection, most destructors then become empty and can be discarded entirely.

Destruktoren werden wegoptimiert. Das sind keine Funktionsaufrufe. Folgende Programmausschnitte erzeugen identischen Code:

int main()
{
  std::unique_ptr<int>(new int);
}
// ----
int main()
{
  int *i = new int;
  if (i)
    delete i;
}

All those destructors freeing memory can become significant when objects are allocated on the stack. For each one, some mechanism must be established so that if an exception happens, the destructors all get called in each frame to release any memory they hold. If the destructors become irrelevant, then there's no need to set up special stack frames to handle exceptions, and the code runs faster.

Kann ich leider wenig zu sagen. Müsste man mal testen.

All the code necessary to manage memory can add up to quite a bit. The larger a program is, the less in the cache it is, the more paging it does, and the slower it runs.

Na ja. Destruktoren machen vielleicht 2% Code aus. Ich denke der Nachteil hält sich hier stark in Grenzen.

Garbage collection kicks in only when memory gets tight. When memory is not tight, the program runs at full speed and does not spend any time freeing memory.

Na gut. Das kann man in C++ natürlich auch erreichen, aber man muss es selbst machen.

Was mich aber an der gesamten Argumention stört ist, dass so getan wird als würde ein GC gar keine Zeit verbrauchen. Alles was die Destruktoren machen, muss der GC schließlich auch machen. Und zwar in doppelter Hinsicht: Er muss die Objekte verfolgen und freigeben.

Weiterhin habe ich ja auch nicht viel gegen einen GC an sich (zumindest außerhalb von C++), was mich wirklich stört ist, dass es keine Destruktoren gibt.

Interessant ist auch wie D das regelt. In D gibt es Destruktoren, trotz Müllsammler:

The destructor is expected to release any resources held by the object.

The program can explicitly inform the garbage collector that an object is no longer referred to (with the delete expression), and then the garbage collector calls the destructor immediately, and adds the object's memory to the free storage. The destructor is guaranteed to never be called twice.

Und weiter:

However, if they:

are allocated as local symbols in a function
are allocated using new
use new with no arguments (constructor arguments are allowed)
have the scope storage class

then they are allocated on the stack. This is more efficient than doing an allocate/free cycle on the instance.
[...]
If the class has a destructor, then that destructor is guaranteed to be run when the class object goes out of scope, even if the scope is exited via an exception.

Was ja zumindest brauchbar klingt. Schade, dass Java so etwas nicht hat. (Auch wenn ich Müllsammlung eher als Bibliotheksfeature anbieten würde.)

 

[Noctarius]

The destructor is expected to release any resources held by the object.

The program can explicitly inform the garbage collector that an object is no longer referred to (with the delete expression), and then the garbage collector calls the destructor immediately, and adds the object's memory to the free storage. The destructor is guaranteed to never be called twice.

Das wäre meiner Ansicht nach auch (wie schon oben irgendwo von mir erwähnt) ein interessantes Feature für einen GC. Es gibt Fälle wo es einfach Sinn machen würde, z.B. nach der Initialisierung einer Anwendung wo Tonnen an Daten geladen wurden nur um sie weiter zuverarbeiten (z.B. XML).

 

[MasterK]

Wieso glaubst du, dass du die beste Methode und den besten Zeitpunkt besser bestimmen kannst als ein moderner, ausgereifter GC? Die Praxis zeigt, dass der GC seinen Job extrem gut (und natürlich 100% fehlerfrei) macht, auf jeden Fall besser als der durchschnittliche C++-Programmierer.

Hm, du willst es einfach nicht verstehen. Also 1) bin ich nicht nur ein durchschnittlicher C++ Programmierer
2) Es geht nicht zwingend darum, den "besten" zeitpunkt zu bestimmen. Denn dieser wird entweder durch die sprache definiert (wenn das objekt den scope verlässt) oder ist relativ egal. Ich weiss nicht, ob du jemals _richtig_ mit C++ entwickelt hast oder nicht. Aber wenn, dann weiss man, dass man ohne GC, aber mit RAII eben etwas anders entwickelt. Was durchaus seine vorteile haben kann, wenn man einen destruktor hat, welcher garantiert dann aufgerufen wird wenn ein objekt zB aus einem container entfernt wird. Meiner meinung nach sollten leute, die von modernen C++ nicht wirklich ahnung haben bei solch einer diskussion am besten auch einfach die klappe halten. Wenn der java weg das einzig wahre wäre, dann bräuchte man nicht so eine krücke "try-with-resources".

Nur weil es keinen GC gibt heisst das nicht, dass man auch nur ein einziges mal den speicher selbst freigeben muss. Man sieht es zugegebenermaßen aber sehr häufig, sogar code in dem leute mit malloc rumhantieren obwohl idR absolut unnötig. Aber fehlendes know-how ist kein fehler der sprache.

 

[Landei]

Hm, du willst es einfach nicht verstehen. Also 1) bin ich nicht nur ein durchschnittlicher C++ Programmierer

Bleibt ja nur noch unterdurchschnittlicher. Ein überdurchschnittlicher Entwickler würde wissen, wie nützlich Abstraktionen sein können.

2) Es geht nicht zwingend darum, den "besten" zeitpunkt zu bestimmen. Denn dieser wird entweder durch die sprache definiert (wenn das objekt den scope verlässt) oder ist relativ egal.

Es gibt aber günstigere und weniger günstigere Zeitpunkte, den Speicher freizugeben. Und du hast wenig Chancen, einen günstigen (etwa wenn der Prozessor auf trödelnde IO wartet) zu erwischen. Aber das kann den Unterschied zwischen einer ruckeligen und flüssigen Applikation ausmachen.

Ich weiss nicht, ob du jemals _richtig_ mit C++ entwickelt hast oder nicht. Aber wenn, dann weiss man, dass man ohne GC, aber mit RAII eben etwas anders entwickelt. Was durchaus seine vorteile haben kann, wenn man einen destruktor hat, welcher garantiert dann aufgerufen wird wenn ein objekt zB aus einem container entfernt wird.

Ersetze "anders" durch "low level", dann stimme ich dir zu.

Meiner meinung nach sollten leute, die von modernen C++ nicht wirklich ahnung haben bei solch einer diskussion am besten auch einfach die klappe halten.

Man muss nicht in C++ programmieren können (nebenbei bemerkt kann ich es, neben Delphi, Prolog, Scala, Haskell und einigen anderen) um solche konzeptionellen Schwächen erkennen zu können. Ein Garbage Collector ist geradezu eine Voraussetzung dafür, dass eine Sprache ein gewisses Abstraktionsniveau erreichen kann:

Generally speaking, higher-level programming languages are more likely to have garbage collection as a standard feature. In languages that do not have built in garbage collection, it can often be added through a library, as with the Boehm garbage collector for C and C++. This approach is not without drawbacks, such as changing object creation and destruction mechanisms.

Most functional programming languages, such as ML, Haskell, and APL, have garbage collection built in. Lisp, which introduced functional programming, is especially notable for introducing this mechanism.

Other dynamic languages, such as Ruby (but not Perl 5, or PHP, which use reference counting), also tend to use GC. Object-oriented programming languages such as Smalltalk, Java and ECMAScript usually provide integrated garbage collection. Notable exceptions are C++ and Delphi which have destructors. Objective-C has not traditionally had it, but ObjC 2.0 as implemented by Apple for Mac OS X uses a runtime collector developed in-house, while the GNUstep project uses a Boehm collector.

(Garbage collection (computer science) - Wikipedia, the free encyclopedia)

Was schließen wir daraus? Sind denn die Entwickler aller anderen modernen Sprachen blöd, weil sie den Vorteil von Destruktoren nicht erkennen können?

Ich finde es ehrlich gesagt ziemlich traurig, wenn Entwickler nicht über den Tellerrand "ihrer" Sprache schauen können.

Wenn der java weg das einzig wahre wäre, dann bräuchte man nicht so eine krücke "try-with-resources".

Java ist für Anwendungsprogrammierung gemacht, und das geht um Längen besser als in C++. Wenn wir jetzt anfangen, "Krücken" zu zählen, käme C++ nämlich ziemlich schlecht weg.

Nur weil es keinen GC gibt heisst das nicht, dass man auch nur ein einziges mal den speicher selbst freigeben muss. Man sieht es zugegebenermaßen aber sehr häufig, sogar code in dem leute mit malloc rumhantieren obwohl idR absolut unnötig. Aber fehlendes know-how ist kein fehler der sprache.

Richtig, fehlendes Know-How ist ein Problem von Entwicklern, die auf einem zu tiefen Level herumkrebsen und denken, ihre Pointer-Hacks und ihr Bit-Geschiebe wären große Kunst.

 

[MasterK]

Richtig, fehlendes Know-How ist ein Problem von Entwicklern, die auf einem zu tiefen Level herumkrebsen und denken, ihre Pointer-Hacks und ihr Bit-Geschiebe wären große Kunst.

Weisst du eigentlich, was du da für einen unsinn schreibst? Pointer-hacks und Bit-geschiebe? Nur weil ich das machen KANN wenn ich es wirklich brauche, zwingt mich die sprache doch nicht dazu. Ich habe lediglich die wahl.

Was schließen wir daraus? Sind denn die Entwickler aller anderen modernen Sprachen blöd, weil sie den Vorteil von Destruktoren nicht erkennen können?

Ich finde es ehrlich gesagt ziemlich traurig, wenn Entwickler nicht über den Tellerrand "ihrer" Sprache schauen können.

Ein vorschlag: du liest dir meine vorherigen posts durch und kommst dann zum schluss, dass du mir hier grad etwas vorwirfst das ich nie behauptet habe. Ok?

Apropos "tellerrand":
_Gefühlt_ habe ich die einschätzung, dass sich da java entwickler wesentlich schwerer mit tun. C++ entwickler meckern zwar mehr, schauen aber auch mehr. Zumindest mein ganz persönliches gefühl, dass ich so im laufe der jahre gewonnen habe.

Edit:
Ein punkt bzgl "destruktoren" hätte ich da aber doch noch. Warum gibt es dann konstruktoren? Ich mein, die argumente hier waren, man könne sich doch selbst eine "close" methode oder "finish" oder wie auch immer schreiben. Wozu brauchen wir dann konstruktoren? Schreiben wir doch einfach "init" oder "initialize" oder "prepare", jeder so wie er will? Keine ahnung was landei dagegen hat, aber ich habe ganz gern die möglichkeit, den lebenszyklus eines objekts von erstellen bis löschen klar definiert zu haben. Zumindest die _möglichkeit_ dazu, genau das zu haben. Wurde ja in diesem thread schon erwähnt, dass sich destruktoren und GC nicht ausschliessen müssen.

 

[Java-Basher]

Wenn wir jetzt anfangen, "Krücken" zu zählen, käme C++ nämlich ziemlich schlecht weg.

Dann mal los. Aber um gleich zwei Punkte vorwegzunehmen:
- Fehlender Garbage-Collector: Argument im Zusammenhang des Threads nicht mehr sinnvoll. (C++ kann das halt auch, nur wird es einem nicht aufgezwungen, da nicht in die Sprache integriert. Eine Lösung im Standard wäre vielleicht sogar ganz nett, aber das gehört dann halt auch wieder nicht zur Sprache selbst.)
- Kleine Standardbibliothek. Da hast du meine Zustimmung, aber das gehört halt auch nicht direkt zur Sprache.

Ich bin auf deine Krückensammlung gespannt.

 

[Landei]

Ein punkt bzgl "destruktoren" hätte ich da aber doch noch. Warum gibt es dann konstruktoren? Ich mein, die argumente hier waren, man könne sich doch selbst eine "close" methode oder "finish" oder wie auch immer schreiben. Wozu brauchen wir dann konstruktoren? Schreiben wir doch einfach "init" oder "initialize" oder "prepare", jeder so wie er will? Keine ahnung was landei dagegen hat, aber ich habe ganz gern die möglichkeit, den lebenszyklus eines objekts von erstellen bis löschen klar definiert zu haben. Zumindest die _möglichkeit_ dazu, genau das zu haben. Wurde ja in diesem thread schon erwähnt, dass sich destruktoren und GC nicht ausschliessen müssen.

Es gibt mehrere Unterschiede zwischen Konstruktoren und normalen Methoden, etwa der (explizite oder implizite) Aufruf von Super-Konstruktoren oder initialisierungsspezifische Details (wie das Setzen von final-Variablen). Aber das solltest du eigentlich wissen.

 

[MasterK]

Es gibt mehrere Unterschiede zwischen Konstruktoren und normalen Methoden, etwa der (explizite oder implizite) Aufruf von Super-Konstruktoren oder initialisierungsspezifische Details (wie das Setzen von final-Variablen). Aber das solltest du eigentlich wissen.

Ja eben. Und es gibt mehrere unterschiede zwischen destruktoren und normalen methoden. Warum also destruktoren verteufeln und konstruktoren nicht?

 

[Landei]

Weil niemand wissen kann, welche Daten du in ein Objekt packen willst, aber völlig klar ist, wie diese Daten (und welche) am Ende wieder aufgeräumt werden müssen.

Ein Konstruktor ist eben kein Spiegelbild eines Destruktors, man kann nicht individuelle Speicher für seine Daten anfordern, sondern bekommt diesen für alle Daten geliefert, ob man will oder nicht (natürlich hat man die Wahl, den Speicher sofort zu belegen oder nicht).

 

[MasterK]

Weil niemand wissen kann, welche Daten du in ein Objekt packen willst, aber völlig klar ist, wie diese Daten (und welche) am Ende wieder aufgeräumt werden müssen.

Dafür brauchst du keinen konstruktor. Da kannst du wie fürs "close()" auch einfach ein "init()" nehmen. Dass ein destruktor kein "spiegelbild" eines konstruktors ist ist mir klar. Dir ist aber durchaus klar, dass sich ein destruktor von normalen methoden in solch sinnvoller art und weise unterscheidet, dass destruktoren an sich sinnvoll sind?

 

[Landei]

Dafür brauchst du keinen konstruktor. Da kannst du wie fürs "close()" auch einfach ein "init()" nehmen.

In Java ginge das nicht, weil man keine Möglichkeit hat, Speicher manuell anzufordern. In solch einer Sprache ist es dann aber auch sinnlos, einen Destruktor zu haben, weil jedes Bit Speicher bereits unter Kontrolle der VM ist.

Natürlich ist in C++ ein Destruktor komfortabler als eine close()-Methode, keine Frage, aber ein GC ist eben trotzdem komfortabler als ein Destruktor, und ist alles, was man in der Anwendungsentwicklung braucht. Natürlich gibt es in der Low-Level-Systementwicklung Fälle, wo man keinen GC haben darf, z.B. um selbst einen GC zu implementieren - aber das brauchen wir hier nicht zu diskutieren, dafür ist Java sowieso nicht gemacht.

 

[MasterK]

Und c++ entwickler sind eben der meinung (der meinung bin ich auch), dass ein destruktor und RAII auch oft vorteile hat. Ein paradebeispiel ist ja das try-with-resources in java...

 

[fastjack]

Hallo,
ich möchte gerne Programmieren lernen. Ich habe 4 große Sprachen gefunden, die wohl infrage kommen würden: C, C++, C#, Java. Was denkt ihr, womit ich anfangen sollte? (Und ich frage hier natürlich mit gewisser Absicht in einem Java Forum, also haut ruhig die Vorteile eurer wahrscheinlichen Lieblingssprache raus, von einem Bekannten wurde mir nämlich C++ empfohlen und ich möchte ja etwas zum Gegenhalten haben.)

C, C++, C#, Java? Das ist war hier die Frage.

Allein aus der bisherigen Diskussion kann man eigentlich die Komplexität von c / c++ erkennen, was jetzt um Gottes willen nicht heißen soll daß diese Sprachen schlechter sind. Ich denke ein Anfänger will sich heutzutage nicht mit char* oder Destruktoren, oder... herumschlagen, er will einfach das seine Gehversuche funktionieren. C# wäre mir ehrlich gesagt zu fett / viel / groß. Kurzum nimm Java.

 

[bronks]

Eines vorab: Ich bin kein Fan von Microsoft, C# und .NET, aber von den Entwicklungen in Java bin ich zunehmend immer mehr angepi**t. Aber da bin ich zum Glück nicht alleine.

Der TIOBE-Index wird immer hervorgekramt, um zu zeigen, wie beliebt doch Java ist. An dem Index ist auch eindeutig zu erkennen, daß Java seit Jahren unbeliebter wird. Richtig eingebrochen ist die Linie kurz bevor EE5 in Aussicht gestellt wurde, denn da waren die EE-Entwickler schon richtig gelangweilt.

... Gehversuche funktionieren ... C# wäre mir ehrlich gesagt zu fett / viel / groß. Kurzum nimm Java.

Sorry, aber was ist an C# so fett, viel und groß?

Ja, es stimmt, denn man hat Windows, Visual Studio, IIS und SQL Server inclusive. Alles durchdacht, selbserklärend, getestet und funktionierend.

Und nochmal:
Ja, es stimmt, denn noch hat Sun/Oracle/JCP es nicht geschafft alle guten Ideen aus C#/.NET zu kopieren. Der Grund liegt wohl darin, daß man sich in einer üblen technischen Sackgasse verfahren hat. Dafür versucht man jetzt mit z.B. TryWithRessources eigene wege zu gehen.



EDIT: Reihenfolge der Absätze in Ordnung gebracht.

 

[Firephoenix]

Die Diskussion hier ist mittlerweile auf einem Niveau als würde man in den Baumarkt schreien:
"Welches Werkzeug ist am wichtigsten"
und als Antworten kommen:
Heimwerker: Hammer
Maler: Pinsel
Heimwerker2: Bohrer
Schreiner: Säge
Elektriker: Isolierwerkzeug
Heimerwerker3: Schraubenzieher

und dannach beginnt die Debatte ob man besser in die Wand schraubt oder Nageln soll, natürlich kann man mit der Säge auch keine Löcher in die Wand sägen, außer man modifiziert die Säge entsprechend, damit wird aber der Hammer wieder hinfällig.
Nich zu vergessen, dass man mit dem Hammer auch Nageln kann falls nötig - oder war es schrauben?
Natürlich macht es auch einen riesen Unterschied ob der Pinsel einen Handschutz für die Farbe hat - alle anderen sind ja mittlerweile veraltet und kosten zuviel Zeit weil man sich noch die Finger waschen muss - was man aber auch mit Handschuhen und Malerkittel vermeiden könnte

Und jetzt hauen mit gleich hunderte Leute auf den Kopf die noch nicht damit fertig waren ihre Lieblingsprogrammiersprachen zu verteidigen

 

[fastjack]

Ja, es stimmt, denn man hat Windows, Visual Studio, IIS und SQL Server inclusive.

Wenn Du mal scharf nachdenkst, sind das alles Sachen, die man zum Einstieg eben nicht unbedingt brauchen sollte. Okay ein OS braucht man, aber ich brauche als Anfänger kein VisualStudio (auch kein Eclipse oder IDEA), kein IIS und auch keinen SQL-Server. Was Du brauchst, um die Grundlagen einer Sprache richtig zu lernen ist ein Editor und halt die Sprache, fertig.

edit:

Alles durchdacht, selbserklärend, getestet und funktionierend.

Das habe ich bis jetzt bei keiner Sprache erlebt auch bei keiner IDE, schon gar nicht bei MSSQL-Servern.

 

[nocturne]

@Operator-überladen:
meinHaus += deinHaus ist ein zu einfaches Beispiel(!): ein Haus mehr ist als die Summe seiner Räume (raumliste1 += raumliste2 finde ich 100%ig).

Ob man Operatorüberladen verwendet oder nicht halte ich für Sitouationsabhängig, hoffe ihr stimmt mir zu.

@GC und Smartpointer / Autopointer.
Ich denke hier muss nicht nur die Sitouation unterschieden werden sondern auch die Spezialisierung der Fachkraft.

@auto
Bei groovy gibt es das typenunsichere deklarierren von variablen mit def.
Das finde ich nur gut, wenn
- die IDE anhand der vorherigen codezeilen erkennen kann, welche typen drin sein könnten und probleme markiert.
z.B. um von einem String auf ein DetachedQuery zu kommen benötigt man nur eine variable mit namen sql. Das finde ich praktisch.

 

[bronks]

... Anfänger kein VisualStudio (auch kein Eclipse oder IDEA), kein IIS und auch keinen SQL-Server. Was Du brauchst, um die Grundlagen einer Sprache richtig zu lernen ist ein Editor und halt die Sprache, fertig ...

Editor und Sprache waren irgenwann in den 80er das Mittel. Damals war noch alles einfach und übersichtlich, aber trotzdem hat man damit nicht weniger erreicht, als heute.

Heute will der Benutzer ein Klickibunti, welches sich aus vielen komplizierten Objekten zusammensetzt. Schon dafür braucht man eine vernünftige IDE mit CodeCompletion bzw. IntelliSense, denn Auswendiglernen oder in Büchern herumblättern muß sich heute niemand mehr antun.

Mittlerweile sind wir soweit, daß es für Java sogar brauchbare GuiEditoren gibt. Und plötzlich sind diese sogar beliebt. Mache Leute kritisieren zwar, daß man den generierten Code nicht bzw. mit Einschränkungen editieren kann. Ich meine, daß es eine Frechheit von technischer Krücke ist, daß ein GuiEditor überhaupt JavaCode erzeugt.

Vernünftige GuiEditoren für Java gab es natürlich auch schon vor 10 Jahren, aber da diese etwas gekostet haben passten diese einfach nicht in die Javawelt.

 

[fastjack]

Heute will der Benutzer ein Klickibunti, welches sich aus vielen komplizierten Objekten zusammensetzt. Schon dafür braucht man eine vernünftige IDE mit CodeCompletion bzw. IntelliSense, denn Auswendiglernen oder in Büchern herumblättern muß sich heute niemand mehr antun.

Leider. Durch Klickibunti lernt man aber leider nicht... CodeCompletion + IntelliSense sind natürlich sinnvoll, zum reinen Erlernen würde ich es nicht empfehlen, kurzum, es verblödet. Ich kenne Leute, die keinen deutschen Satz mehr ohne IntelliSense zustande bringen. Andere schreiben nichtmal mehr Klassen- oder Methodennamen richtig, wieso denn auch, die CodeCompletion sucht schon das Passende heraus. Und "denn Auswendiglernen oder in Büchern herumblättern muß sich heute niemand mehr antun", antun? tja, wir haben ja auch schon aufgehört zu denken stattdessen googeln wir

Ich sage immer noch: Um Java zu lernen, reicht ein normaler Editor und das JDK (wie groß nochmal 50-60MB?), fertig.

P.S.: Um GUI geht es in dem Thread gar nicht.

 

[bronks]

Die Diskussion hier ist mittlerweile auf einem Niveau als würde man in den Baumarkt schreien: "Welches Werkzeug ist am wichtigsten" ...

Nene, falsch verstanden. Hier geht es darum, welches Universalwerkzeug unter den üblichen Bedingungen am einfachsten Verwendet werden kann.

So z.B. ein Hammer mit drangeschraubtem Flaschenöffner und Gabel.

Mit einer Zange kann man einen Nagel auch ins Holz schlagen, Flaschen öffenen kann man damit sowieso und eine Gabel macht Diese auch überflüssig. Ist zwar fricklerhaft, aber es funktioniert.

 

[fastjack]

Auch falsch. Hier gehts es darum das jemand programmieren lernen möchte und wissen wollte, mit welcher der Sprachen (c, c++, c#, Java) er am besten anfangen sollte, mehr nicht...

 

[Tomate_Salat]

Ich würde eine von diesen hier empfehlen. z.b. Whitespace.

Naja, auch wenn das hier der x-tausende Thread zu dem Thema ist. Überlege dir, was du später mal machen willst und lerne dafür eine Sprache (vorab: Spieleentwicklung geht mit allen!).

Wenn du z.B. daheim einen Androiden hast, empfielt sich Java, dann kannst du späte mal darauf entwickeln.
Wenn du Plattformunabhängig arbeiten willst, Java oder C++ (afaik soll das mit QT funktionieren. Arbeite nur im Betrieb mit C++ und haben da unser eigenes FW).
...

 

[bronks]

Auch falsch. Hier gehts es darum das jemand programmieren lernen möchte und wissen wollte, mit welcher der Sprachen (c, c++, c#, Java) er am besten anfangen sollte, mehr nicht...

Was? Hast Du die letzten 3 Seiten nicht gelesen? Es geht um Programmiersprachenbashing! Vor allem um C++ vs. Java. Ist doch sowieso alles Kindergarten, wenn man C# als vergleich nimmt.

 

[Evil-Devil]

Wenn Java Generics mit nativen Typen wie C# unterstützen würde, wären sicherlich viele schon glücklich.

 

[s4ke]

Ohne jetzt den ganzen Thread gelesen zu haben:

Meine Entscheidung sich erst mal voll auf Java zu konzentrieren war die richtige. Ich hatte aber für den Einstieg in Java minimale Kenntnisse in C++ mitgebracht (was mir das Konzept der "Referenzen" in Java gleich nähergebracht hat, "Referenzen" weil es ja keine Referenzen im näheren Sinn sind ) was mir unheimlich geholfen hat. Aber für Programmiereinsteiger ist Java das Nonplus-Ultra, weil man sich nicht mit Sprachbestandteilen auseinanderzusetzen hat, die einen am Anfang nur verwirren (später schaut man dafür aber öfters mal neidisch zu anderen Sprachen (C# mit Properties, C++ mit Operatorenüberladung, etc.). Und man lernt das Programmieren besser als mit Sprachen wie Python, die einem die Abläufe hinter hinter der Kulisse ein bischen verschweigen.

Und noch etwas: Android Programmierung macht einfach höllisch Spaß und man muss keine neue Sprache lernen, wenn man bereits Java kann. Es gibt dafür einiges an neuen Konzepten zu lernen .

An was man sich aber bei Java öfters mal gewöhnen muss ist etwas à la:

[Sarkasmus]

Double d = DoubleFactoryFactory.getInstance().createDoubleFactory().createDouble(1.0);

[/Sarkasmus]

sake

 

[schlingel]

Ein Punkt den fastjack gebracht hat kann ich allerdings nur unterstützen: IDEs mit samt ihrer Macht, helfen dem Neuling nicht beim Erlernen des Werkzeugs. Im Gegenteil, das ganze bleibt für ihn - sofern er wirklich ein absoluter Anfänger ist - das Klicken von Knöpfen um bestimmte Dinge zu erreichen ohne zu wissen wie es funktioniert.

Das beste Beispiel dafür sind Daten getriebene Anwendungen die in VS wild zusammengeklicked werden können und per Databinding an eine vom Wizard erstellte Datenbank gebunden werden können. Doch was ist passiert? Wie wird das deployed? etc. sind dann Fragen die derjenige der das Tutorial schritt für schritt befolgt hat, dann nicht beantworten können. (Ich konnte es jedenfalls damals nicht ...)

Sogar Petzold, jeder der halbwegs etwas von Windows versteht sollte der Name ein Begriff sein, hat das Thema beschäftigt weshalb er diesem Thema einen Artikel gewidmet hat.

Ein anderes Buch das diese Thematik anschneidet ist Design For How People Learn. In dem Buch wird auch kurz auf oben angesprochene Problematik eingegangen.

So sehr IDEs auch die Entwicklung beschleunigen, es hilft einem Anfänger viel mehr mit Editor und Kommandozeilencompiler anzufangen!

 

[bronks]

... etc. sind dann Fragen die derjenige der das Tutorial schritt für schritt befolgt hat, dann nicht beantworten können. (Ich konnte es jedenfalls damals nicht ...) ...

So z.B. und auf Java bezogen: JSF + EJB + JPA. Das kann man sich im Texteditor in wenigen Dateien zusammentippen, aber was ist das Ergebnis:

In die GUI wird etwas reingetippt daraufhin wird
- das Datenmodell automatisch aktualisiert
- die Transaktion automatisch begonnen
- die Daten automatisch persistiert
- die Transaktion automatisch commited

Das ist alles so abstrakt. Es funktioniert einfach. Was will man da für Fragen haben und was erwartet man als Antworten. Macht es überhaupt einen Sinn sich mit den darunterliegenden Techniken, wie z.B. JTA, JDBC, Servlet ... ... zu beschäftigen?

 

[schlingel]

Spätestens wenn es nicht mehr "einfach" funktioniert, macht es sehr viel Sinn ;-)

PS: Ich beginne lieber auf Servlet Ebene :-D

 

[bronks]

Spätestens wenn es nicht mehr "einfach" funktioniert ...

Dann ist es verbugter Müll, welcher nirgendwo akzeptiert wird.

 

[schlingel]

Dann ist es verbugter Müll, welcher nirgendwo akzeptiert wird.

Mit der Aussage kann ich absolut nichts anfangen. Du dürftest deutlich mehr Glück mit Frameworks haben als ich. Mir begegnet fast täglich "verbugter Müll", der allerdings überall akzeptiert wird. (Android-Framework, Jackson-JSON-Parser, etc.)

Die perfekte Welt gibt es IMHO nicht. Mir hat technisches Verständnis und tieferes Wissen mehr Zeit gerettet als es mich gekostet hat sie zu erlernen.

Wer das anders sieht, schön, allerdings ist die Annahme das jedes Framework fehlerfrei funktioniert und es nutzlos ist, zu wissen welche Sub-Frameworks im verwendeten Framework verwendet werden und wie diese funktionieren, gefährlich wenn mal Anforderungen geändert werden und man spezielle Anpassungen machen muss.

 

[bronks]

... Du dürftest deutlich mehr Glück mit Frameworks haben als ich ...

Wird wohl so sein oder ich bin in dieser Hinsicht etwas toleranter. Letztes Jahr hatte ich nur 2 Probleme, welche eindeutig auf Bugs zurückzuführen waren. Eines davon habe mit einem einfach Workaround in den Griff bekommen und das andere Problem erforderte härtere Massnahmen. In Summe bis jetzt 1 Arbeitstag Schaden.

Außer o.g. gab es schon ein paar mehr Situationen, wo etwas nicht so funktioniert hat, wie es eigentlich hätte funktionieren sollen, aber dann habe ich es minimal anders umgesetzt ohne mich damit besonders aufzuhalten.

 

[Landei]

Ein Punkt den fastjack gebracht hat kann ich allerdings nur unterstützen: IDEs mit samt ihrer Macht, helfen dem Neuling nicht beim Erlernen des Werkzeugs. Im Gegenteil, das ganze bleibt für ihn - sofern er wirklich ein absoluter Anfänger ist - das Klicken von Knöpfen um bestimmte Dinge zu erreichen ohne zu wissen wie es funktioniert.

Man muss aber schon unterscheiden, ob die IDE etwas wirklich "magisches" tut, oder nur etwas ausführt (Refactorings, Einfügen von Konstruktoren und Standardmethoden), was man sich hinterher problemlos ansehen kann.

 

[schlingel]

Vollkommen richtig. Ich meinte jetzt natürlich so etwas wie Formeditoren, DB-Erzeuger, WS-Erzeuger, etc.

 

[bronks]

Vollkommen richtig. Ich meinte jetzt natürlich so etwas wie Formeditoren, DB-Erzeuger, WS-Erzeuger, etc.

Du meinst also, die Sachen welche man sich hinterher problemlos ansehen kann.

 

[schlingel]

Zum Beispiel, ja.

Was die Logik von DB-Erzeugung angeht, sind wir ja in einem Bereich den man sich nicht "problemlos" ansehen kann, aber das nur so nebenbei ;-)

Im allgemeinen ist es nun einmal so: Wer glaubt eine IDE ist ein simples Werkzeug das so nebenbei gelernt wird, ist schon wieder zu weit weg von der Sicht des Anfängers, der von der immensen Informationsflut - gerade in einem komplexen Gebiet wie dem Programmieren - erschlagen wird. "Problemlos" ist eben auch Definitionssache, ähnliche dem "es ist leicht zu sehen" oder "trivial" in mathematischen Texten.

Ich empfehle - noch einmal - die oben verlinkte Literatur zu lesen um die Argumentationsketten im ganzen zu verstehen.

PS: Ich mag so suggestive Einzeiler nicht. Man weiß nie was da jetzt wirklich gemeint war. Könnte eine interessierte Frage, eine höhnische Anmerkung oder was anderes sein. Das ist eine schlechte Grundlage für eine Debatte.

 

[bronks]

... PS: Ich mag so suggestive Einzeiler nicht. Man weiß nie was da jetzt wirklich gemeint war. Könnte eine interessierte Frage, eine höhnische Anmerkung oder was anderes sein. Das ist eine schlechte Grundlage für eine Debatte ...

Sorry, aber genau der Deine, von mir zitierte, Satz hat irgenwie keine Aussage für mich gehabt. Denn genau die von Dir erwähnten Formeditoren, DB-Erzeuger und WS-Erzeuger erzeugen einen verständlichen Programmcode, den man glücklicherweise nicht manuell Tippen muß.

... Was die Logik von DB-Erzeugung angeht, sind wir ja in einem Bereich den man sich nicht "problemlos" ansehen kann, aber das nur so nebenbei ;-) ...

Beim Speichern von Änderungen im DB-Designer frägt mich meine IDE immer, ob ich den das Script dazu gerne sehen würde. Es gibt keine Geheimnisse und ich habe die volle Kontrolle.

Kann es sein, daß Du einfach nur die falschen Werkzeuge verwendest?

... Im allgemeinen ist es nun einmal so: Wer glaubt eine IDE ist ein simples Werkzeug das so nebenbei gelernt wird, ist schon wieder zu weit weg von der Sicht des Anfängers, der von der immensen Informationsflut - gerade in einem komplexen Gebiet wie dem Programmieren - erschlagen wird. "Problemlos" ist eben auch Definitionssache, ähnliche dem "es ist leicht zu sehen" oder "trivial" in mathematischen Texten ...

Genau das Gegenteil, denn in der IDE klicke ich mir etwas zusammen, sehe mir den erzeugten Code an und denke mir: "Ja logisch, klar, steht doch alles da". Ich verstehe den erzeugten Code, obwohl ich diesem im vi nicht stolperfrei und auf anhieb kompilierbar eingetippt hätte.

... Ich empfehle - noch einmal - die oben verlinkte Literatur zu lesen um die Argumentationsketten im ganzen zu verstehen ...

Das sind Argumente zu einer von vielen Meinungen. Es hat m.E. absolut keinen Sinn zu lernen, wie man Farben herstellt, wenn man Bild malen möchte. Irgendwann kommt der Punkt, wo es interessant wird sich mit dem Mischen von Farben zu beschäftigen, aber am Anfang möchte man einfach nur die Farbe aufs Papier bringen und schöne Formen malen.

 

[schlingel]

Beim Speichern von Änderungen im DB-Designer frägt mich meine IDE immer, ob ich den das Script dazu gerne sehen würde. Es gibt keine Geheimnisse und ich habe die volle Kontrolle.

Das heißt noch lange nicht, das der Anfänger deshalb weiß was eine Datenbank ist, wie diese zu deployen ist, was die verschiedenen Zeilen des SQL-Skripts tun und weshalb das da so steht. WS ist es das gleiche und Forms auch. Wobei bei Forms noch am ehesten Verständnis hergestellt werden kann weil es keinen Technologiesprung gibt (Von WSDL auf Java, von SQL zu Java, etc).

Genau das Gegenteil, denn in der IDE klicke ich mir etwas zusammen, sehe mir den erzeugten Code an und denke mir: "Ja logisch, klar, steht doch alles da".

Meiner Erfahrung nach gibt es nur sehr wenige Ausnahmefälle in der Menge der Anfänger die sich das so überlegen. Für die meisten Normalsterblichen ist die Informationsfülle einfach erschlagend. Klar, ich benutze auch eine IDE und bin sehr zufrieden damit, das heißt aber noch lange nicht, das es deshalb auch für einen Anfänger das beste Werkzeug ist.

Das sind Argumente zu einer von vielen Meinungen.

Wobei genau das die Streitfrage ist. Hier habe ich meine Meinung argumentiert und vor allem mit Erfahrungen eines der bekanntesten Praktiker (jedenfalls in der MS Windows-Welt) und einem leichten Buch zum Thema Lerntheorie untermauert.
Du bist anderer Meinung, weil du gut zurecht kommst mit einer IDE oder weil du andere Erfahrungen gemacht hast. Das ist dein gutes Recht, aber einer der am meisten gemachten Fehler in der Lehre. Deshalb würde ich in solchen Fragen immer auch Erfahrungen von Lehrenden und Fachliteratur zum Thema abrufen.

[...]aber am Anfang möchte man einfach nur die Farbe aufs Papier bringen und schöne Formen malen.

Das ist ein guter Punkt. Aber dann wären andere Tools noch besser geeignet, wie z.B. Lightswitch oder App Inventor, allerdings helfen diese einem Anfänger nicht damit die Materie besser zu verstehen. Und der Lernerfolg wird ja durch die Fähigkeit bestimmt Programme entwickeln und auch warten zu können. Dadurch ist Verständnis ein absolutes Muss-Kriterium.
Es ist hierbei mehr gefragt wie die Tutorials vorgehen anstatt alles auf die Tools zu schieben. Aber siehe auch dazu das verlinkte Buch ;-)

 

[bronks]

Das heißt noch lange nicht, das der Anfänger deshalb weiß was eine Datenbank ist, wie diese zu deployen ist, was die verschiedenen Zeilen des SQL-Skripts tun und weshalb das da so steht ... ... Meiner Erfahrung nach gibt es nur sehr wenige Ausnahmefälle in der Menge der Anfänger die sich das so überlegen. Für die meisten Normalsterblichen ist die Informationsfülle einfach erschlagend ...

Ja. Jetzt verstehe ich, was Du meinst, aber kann es nicht wirklich glauben, daß jemand so anfängt, wenn er damit wirklich etwas erreichen möchte.

Ich habe absolut in die falsche Richtung gedacht, da ich Bildungstechnisch wohl die besten Voraussetzungen für den Start als Programmierer hatte: 2 Jahre Hauptschulinformatik in den Jahren 1988/89 mit gwbasic und dBase.