Mit welcher Sprache anfangen?

ten

DEvent schrieb:

das stimmt natürlich.
ich hatte mal eine java-klasse gebastelt, die automatisch eine netzwerkverbindung aufmacht und sich anmeldet. kurz vor ende der objektlebenszeit musste noch was über's netz geschickt werden. eigentlich eine aufgabe für einen destruktor. ich hab' dann einfach 'finalize()' überschrieben (in einen try/catch block mit super.finalize(), wie sich das gehört) und das klappte problemlos. der einzige nachteil ist, dass man es nicht ganz exakt zeitlich steuern kann (genau jetzt musst du dich abmelden).

Auf die Idee eine Methode disconnect() zu definieren bist du nicht gekommen?

nö, das wollte ich nicht.
das objekt sollte alles selbständig machen (es hat dafür auch einen eigenen thread), verbindung aufbauen, daten in eine queue schieben...und wenn es fertig ist, sich abmelden und tschüss.

Artchi

DEvent! tntnet meinte sowas:

void foo()
{
    fstream f("test.txt");
} // f wird autom. close() aufrufen

void foo()
{
   try{
    FileInputStream f = new FileInputStream("test.txt");
    f.close();   // muß ich selber dran denken...
   }catch(FileNotFoundException e)
   {}
}

Wenn ich in Java nicht close() aufrufe, wird f dann geschlossen, wenn der GC Lust und Laune hat. Das im fstream-Dtor einmal auch close() stehen muß, ist klar. Aber es steht nur einmal vom fstream-Entwickler, aber nicht vom Anwender. Das ist der springende Punkt.

Simon2

DEvent schrieb:

Ihr mit eueren Destructoren...

Naja, sie geben einem eben eine synchronisierbare automatische Möglichkeit des Aufräumens. In Java gibt's das halt nicht (automatisch schon, synchronisierbar nicht). Wie wichtig dieses Mittel für eine Sprache ist, muß jeder selbst entscheiden (für mich ist es kein KO-Kriterium) ....

DEvent schrieb:

Daß Java-Programmierer ihre liebe Not damit haben, sich das new abzugewöhnen, ist meine persönliche Erfahrung. Das wollte ich hier einfach mal einwerfen. Ich glaube nicht, daß das unbedingt einen Flame-war auslösen muß.

Das ist ja auch nachvollziehbar, alle Objekte in Java werden mit new erstellt, und ist auch für die Sprache Java o.k.

Hat auch niemand etwas Anderes behauptet. Es geht mehr um die "Kommunikationskultur" hier im Forum ... wenn man weiß, dass jemand von Java herkommt, kann man gezielter Tipps geben ... und bisweilen legt eine in C++ unübliche Verwendung von new es nahe, dass das auf den Fragesteller zutrifft.
(alles noch vollkommen OK)
Wenn man (ich) dann das aber anspricht (z.B. um zielgerechter antworten zu können), gibt es Leute hier, die das gleich zum Anlass für einen Flame-war nehmen.
(Nicht OK)

Nach meiner letzten (vollkommen neutralen) Bemerkung in so einer Situation hatte ich auch über eine Woche lang hier einen Stalker an den Hacken wie ein LKW einen kläffenden Hund.....

Das darf man IMO gerne mal beklagen.

DEvent schrieb:

inzwischen unterscheide ich zwischen Leuten, die schnell was auf die Beine stellen wollen/müssen und solchen, die sich lieber gründlich mit einem Thema beschäftigen wollen. Ersteren rate ich eher zu Java, letzteren zu C++. (allerdings sage ich Ersteren auch, dass sie das, was sie an Anfang sparen hinterher doppelt "nachzahlen" müssen).

Also das ist ja Blödsinn hoch 3. Auch in C++ kann man "mal schnell was auf die Beine stellen" und dann hinterher Designfehler ausbügeln. Hast du vor 10 Jahren auch Leuten geraten in Assembler zu programmieren, weil man in Asm ja so viel effezientere Programme schreiben kann?

Was hat denn ASM jetzt damit zu tun ? ASM und C++ unterscheiden sich durch grundsätzlich andere Abstraktionsstufen ... C++ und Java nicht.
Und von "effizienten Programmen" habe ich IIRC auch nichts geschrieben... ich verstehe den Vergleich und deswegen Deine Aussage hier nicht.

Nach meiner Erfahrung kommt man als Anfänger mit Java "schneller zum Schuß" als in C++ - nicht mehr und nicht weniger. Kann sein, dass Andere abweichende Erfahrungen gemacht haben, das ändert aber genausowenig an meinen wie der Umstand, dass der Grund dafür nur zum geringeren Teil an der Sprache selbst liegt.
(Es wäre übrigens guter Stil, auf Pauschalaussagen wie "Blödsinn hoch 3" zu verzichten. Die bringen nichts ein und sollen nur ein Thema mit einem "Dicke-Eier-Faktor" versehen, der der Diskussion nie weiterhilft).

Gruß,

Simon2.

tntnet

@Artchi: Genau das meinte ich. Und das Java-Beispiel ist ein gutes Beispiel dafür, was man da falsch machen kann. Korrekterweise gehört der Aufruf von close grundsätzlich in einen finally-Block, da man mit der Datei in der Regel was machen möchte, was wiederum eine Exception werfen könnte (wobei das aufgrund der Methodensignatur in der Java-Variante nicht erlaubt wäre, d.h. bei der Verarbeitung darf kein Fehler auftreten - könnte man ja auch mal diskutieren ). Etwa so:

void foo()
{
   try{
    FileInputStream f = new FileInputStream("test.txt");
    try {
      // mach was mit der Datei, sonst macht das öffnen keinen Sinn
    }
    finally {
      f.close();   // muß ich selber dran denken...
    }
   }catch(FileNotFoundException e)
   {}
}

Da wird noch deutlicher, daß die Verantwortung, die Resource aufzuräumen beim Anwender der Klasse statt bei der Klasse selbst liegt, wie das bei C++ der Fall ist. Ich finde, die C++-Lösung eleganter:

void foo()
{
    fstream f("test.txt");
    // mach was mit der Datei, sonst macht das öffnen keinen Sinn
} // f wird autom. close() aufrufen

Und danke Simon2 für den Hinweis auf die Kommunikationskultur. Da kann ich Dir nur zustimmen.

Tntnet

Artchi

Die Kommunikationskultur hier im Forum beruht darauf, das C++ grundsätzlich bullshit ist. Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten. Ohne nennenswerte Begründung... einfach nur "C++ ist eh doof, aber XY ist besser dafür geeignet.". Jüngstes Beispiel von heute:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-171250.html
Theoretisch kann man jeden Tag sowas hier als Beispiel aufführen.

Du kannst hier im Forum praktisch nicht einmal pro C++ sein, ohne das jemand aus einem _anderen_ Lager kommt, und C++ für bullshit erklärt.

Selbst wenn man in Sprache XY etwas nicht für ganz optimal hält, ist C++ sowieso bullshit. Das ist so, als ob ich an einem Mercedes den Kühlergrill nicht so toll finden würde, und mir ein Benzfahrer darauf hin sagt "Dein BMW ist der letzte Dreck!". Was ist das für eine Diskussion?

Und in Sprache XY ist es ja by-design so gewollt, und deshalb gut und richtig. Aber was bei C++ by-design ist, ist eh bullshit, weil im C++ Komitee eh nur Assis sitzen, die 1998 eh alles falsch entschieden haben.

Und Dtors sind auch bullshit. Auch Stackobjekte die sich alleine aufräumen können sind auch bullshit.

ten

Artchi schrieb:

Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten.

was auch gerechtfertigt ist.
für newbies ist c++ ein ziemlicher hammer.
wer noch nie programmiert hat, der hat mit c++ mehr frust als spass.
und selbst erfahrene programmierer kann c++ an den rand der verzweiflung bringen.
(ich erinnere dich nur mal an dein problem mit den wchar_t/unicode-streams)

Artchi

ten schrieb:

Artchi schrieb:

Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten.

was auch gerechtfertigt ist.
für newbies ist c++ ein ziemlicher hammer.
wer noch nie programmiert hat, der hat mit c++ mehr frust als spass.

Das Thema hatten wir schon mal diskutiert. Meinung einiger C++ler (Simon2, tntnet u.a.) ist, das dieser Frust vermeidbar wäre, würde man die Einsteiger zu Anfang (!) nicht mit char*-Strings, dynamische Plain-Arrais und sonstigen Pointer-Geschichten belästigen. Denn wie wir wissen, gibt es für eine einfache Nutzung und vorallem Erlernung der Sprache eine String-Klasse, Vectoren, Referencen, Stackobjekte und ab C++2009 auch definitiv Sharedpointer.
Gut, werden wieder einige sagen, das sind keine Build-In-Core-Features. Aber gut... jedes mal die selber Leier.

Ich halte es aber auch für ein elitäres "Gehabe", wenn man sagt, das C++ nur für erfahrene Programmierer ist. Genau das gleiche wie bei Windows vs. Linux. Ich habe schon so manchem jungen Kollegen/in, die nur Java oder VB programmiert haben, die string-Klasse u.ä. von C++ gezeigt. Meiste Reaktion: "Das ist ja praktisch wie in Java?!" Klar, um so weiter man vordringt, um so mehr gibts, was nicht wie Java ist. Aber für die tägliche Arbeit (Strings, Datencontainer, eigene Klassen usw.) kann man es einfach "haben".

Hier gilt der Spruch: "Warum einfach, wenn es auch kompiliziert geht?" Die meiste C++ Einsteiger-Literatur geht danach. Kenne nur ein gutes deutschen C++-Buch, welches den einfachen C++-Weg geht.

ten schrieb:

und selbst erfahrene programmierer kann c++ an den rand der verzweiflung bringen.

Kann ich von mir nicht behaupten.

(ich erinnere dich nur mal an dein problem mit den wchar_t/unicode-streams)

Ehm... du meinst als ich einen wstring in einen filestream rausschreiben wollte? Du kannst den Thread ruhig hier nochmal verlinken... ich war da jedenfalls nicht verzweifelt. Ich war lediglich verwundert. Sowas fällt aber unter "Unwissenheit", die einem in jeder Sprache passieren kann.
Die Lösung des "Problems" ist einfach nur eine fehlende Implementierung, die man durch eine einfache gewünschte austauschen kann. Dabei liegt die Betonung auf "kann", was sagt, das C++ einem hier bewusst by-design eine Option per Facet (codecvt) überlässt:

http://www.kharchi.de/codecvt.png

Jetzt wo ich mich damit beschätigt habe, weiß ich für die Zukunft bescheid. Dieses Thema wird aber leider stiefmütterlich in der C++ Literatur behandelt. DAS ist etwas was man den Buchautoren ankreiden muß, aber nicht C++.

Simon2

ten schrieb:

Artchi schrieb:

Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten.

was auch gerechtfertigt ist.
für newbies ist c++ ein ziemlicher hammer.
wer noch nie programmiert hat, der hat mit c++ mehr frust als spass.

Hi,

das finde ich auch übertrieben.
Es ist nach meiner Erfahrung eben nur so, dass "Mal-eben-nebenbei-Einsteiger" oftmals auf "Clickibunti-Programme" stehen. Das ist doch der typische Newbie-Thread: "Habe noch nie was programmiert, will aber mal eben ein MMORPG mit eingebautem Chat schreiben".
Den Leuten rate ich zu java, weil Java für diesen Ansatz viel mehr bietet (nicht die Sprache, sondern das "Produkt" !).
Ich will jetzt gar nicht den "Chat-Programmierer" schlechtreden - immerhin sind Internet und Spiele üblicherweise die ersten (und lange auch einzigen) Kontaktflächen zum PC.

Aber: Es gibt Leute, die bleiben bei "eben-mal-nebenbei" .... und es gibt andere, die sich zunehmend für das Grundsätzliche interessieren und die mehr Energie und Mühe reinstecken wollen. Die sind immer noch Einsteiger, aber mit denen kann man auch über Programmstruktur, Ressourcen, Multithreading, .... reden und bleibt nicht auf dem Level von "Wie bekomme ich diese WinAPI-Funktion so hin, dass sie tut, was ich will ?". Denen würde ich C++ empfehlen, weil es (als Sprache) viele Konzepte anbietet, um sich damit auseinanderzusetzen.

Für Erstere sind ein anderes Beispiel "Sprachumsteiger" in unserer Firma, die jahr(zehnt)elang COBOL programmiert haben und nun binnen kürzester Frist in einem OO-Projekt lauffähigen Code abliefern müssen. Die werden von Java (wieder: das "Produkt" !) stärker an die Hand genommen. (Wichtig dabei: Die "Tester" sind in einer anderen Abteilung :p )

Lange Rede, kurzer Sinn: Einsteigern würde ich Java oder C++ empfehlen .... je nach Ausrichtung.

Gruß,

Simon2.

P.S.: Bitte beachten, dass ich nirgendwo geschrieben habe, Java-Programmierer seien alles "Clickibunti"-Programmierer oder Einsteiger oder sonstwie schlechter als andere Menschen.

Artchi

Simon2! Der Disclaimer ist genial!

Simon2

Artchi schrieb:

Simon2! Der Disclaimer ist genial!

Ja, man muß langsam aber sicher catch-Blöcke einführen

Gruß,

Simon2.

DEvent

Was hat denn ASM jetzt damit zu tun ? ASM und C++ unterscheiden sich durch grundsätzlich andere Abstraktionsstufen ... C++ und Java nicht.
Und von "effizienten Programmen" habe ich IIRC auch nichts geschrieben... ich verstehe den Vergleich und deswegen Deine Aussage hier nicht.

Nach meiner Erfahrung kommt man als Anfänger mit Java "schneller zum Schuß" als in C++ - nicht mehr und nicht weniger. Kann sein, dass Andere abweichende Erfahrungen gemacht haben, das ändert aber genausowenig an meinen wie der Umstand, dass der Grund dafür nur zum geringeren Teil an der Sprache selbst liegt.
(Es wäre übrigens guter Stil, auf Pauschalaussagen wie "Blödsinn hoch 3" zu verzichten. Die bringen nichts ein und sollen nur ein Thema mit einem "Dicke-Eier-Faktor" versehen, der der Diskussion nie weiterhilft).

Das bezog sich auf dein:

(allerdings sage ich Ersteren auch, dass sie das, was sie an Anfang sparen hinterher doppelt "nachzahlen" müssen).

Deswegen der Vergleich Asm zu C++, weil dein "Hinweis" in den Klammern ist wie ein Asm-Programmierer zu C++ sagen würde, "C++ ist kannst du schneller programmieren als in Asm, aber was du bei C++ einsparst musst du hinterher doppelt "nachzahlen"

Simon2

DEvent schrieb:

...
Deswegen der Vergleich Asm zu C++, weil dein "Hinweis" in den Klammern ist wie ein Asm-Programmierer zu C++ sagen würde, "C++ ist kannst du schneller programmieren als in Asm, aber was du bei C++ einsparst musst du hinterher doppelt "nachzahlen"

Aha !!

Jetzt verstehe ich Dein Argument. Danke.

Allerdings sehe ich das inhaltlich immer noch anders: C++ hat einen deutlich höhere "Design- und Compile-Hürde" als Java (und erst Recht als ASM). Diese Hürde ist allerdings nicht Schikane, sondern hat oft zur Folge, dass einige Inkonsistenzen schon zur Entwicklungszeit auffallen, die ohne diese Hürde erst in der Testphase auffallen. Wenn dort andere Leute als die Entwickler sitzen (wie es bei größeren Unternehmen häufig der Fall ist), vergrößert sich höchstwahrscheinlich dadurch der Gesamtaufwand gegenüber der "Compilezeit-auffall-Variante".
Das ist an sich nichts Schlechtes, sondern kann sich im Schnitt immer noch rechnen ... man darf diesen Aufwand nur nicht unter den Tisch fallen lassen, wenn man sich ein realistisches Bild von den verschiedenen Sprachen machen will (Die Werbeaussage "Mit Java kommen Sie schneller zu lauffähigem Code" verschweigt das nämlich gerne).

Das ist jetzt nicht nur meine Privatmeinung, sondern wurde von unserem Java-Dozenten unbd Berater (extern) so geäußert.

Um damit Deine ursprüngliche Frage zu beantworten:

... Hast du vor 10 Jahren auch Leuten geraten in Assembler zu programmieren, weil man in Asm ja so viel effezientere Programme schreiben kann? ...

Nein.
Und heute tue ich das auch nicht.
Und in diesem Thread und Anderen kannst Du nachlesen, dass ich durchaus der Meinung bin, dass "mit der Technik mithalten" auch bedeutet, seine Programmierparadigmen mitzuwechseln.

Gruß,

Simon2.

Simon2.0 wurde in VBScript geschrieben.

DEvent

Diese Hürde ist allerdings nicht Schikane, sondern hat oft zur Folge, dass einige Inkonsistenzen schon zur Entwicklungszeit auffallen, die ohne diese Hürde erst in der Testphase auffallen. Wenn dort andere Leute als die Entwickler sitzen (wie es bei größeren Unternehmen häufig der Fall ist), vergrößert sich höchstwahrscheinlich dadurch der Gesamtaufwand gegenüber der "Compilezeit-auffall-Variante".

Finde ich nicht. Grade in C++ wird der Code allein durch die vielen Möglichkeiten der Sprache unübersichtlich. Man muss schon sehr lange mit C++ programmieren, damit man die Übersicht behält und erkennt, wann ein Sprachfeature notwendig oder nützlich ist, oder wann ein Feature sinnlos oder gar schädlich ist. Das ist wie mit Asm, benutzte ich jetzt Bitshift oder Multiplikation, muss der Speicherblock eine Potenz von 2 haben oder nicht... usw.

In Java ist gegen C++ recht übersichtlich was Sprachfeatures betrifft. Dadurch kann man sich mehr auf den Design konzetrieren und erkennt Designfehler schneller.

In OOA kann man auch recht flott Designfehler erkennen, weil die ganzen unwichtigen Teile entfallen und man sich nur auf das Design konzentrieren kann. Das verhält sich ähnlich in Java.

Naja aber das ist wieder OT, sorry :p

Also ich finde, wenn man eine Sprache braucht, dann sollte man sich anschauen für welche Problemstellungen die Sprache Design wurde und welche Programmierparadigmen sich die Sprache bedient.

Diese 2 Dinge und wie viele Annehmlichkeiten eine Sprache bietet um seine Ziele zu erreichen sind IMHO wichtig an einer Sprache. Der Rest ist ziemlich unwichtig.

Es ist eigentlich egal mit welcher Sprache man anfängt. Hauptsache man ist sich bewust welche Paradigmen man sich in der Sprache seiner Wahl bedient.

Wenn man LISP gelernt hat, fallen einen dann andere Paradigmen, wie OOP oder Regelbasiertes-P. dann schwerer.

Simon2

DEvent schrieb:

...Finde ich nicht...

Macht nichts.

Ich denke, insgesamt hat dieser Thread dem Fragesteller eine Menge geboten und unsere "Differenzen" sind derartig marginal, dass ich sie problemlos unter "persönliche Vorlieben" verbuchen kann.

So, jetzt muß ich weg, Schlagzeug spielen.

Schönen Tag noch,

Simon2.

tntnet

[url]http://thedailywtf.com/Articles/Trust_Me,_I'm_A_Doctor.aspx[/url]
(irgendwie funktionieren die url-tags hier nicht , aber egal - ich lasse sie mal stehen.)

Das Problem ist, daß jeder meint, Programmierer zu sein, nur weil er ein paar Grundzüge kann. Niemand denkt, er sei Arzt, nur weil er jede Arzt-Serie im Fernsehen schaut.

C++ ist ein Werkzeug für Profis. Auch Anfänger können vieles damit machen, so wie auch ein Normalsterblicher nach einer kleinen Einführung auch leben retten kann. Allerdings erschliessen sich die Möglichkeiten nur für den, der bereit ist, auch was zu lernen.

Tntnet