Hi,
OK, Python ist meiner Meinung nach etwas weniger grauenvoll als die
anderen genannten. So richtig kann ich das mangels wirklicher
Erfahrung aber nicht beurteilen.
ich finde Python mehr als ordentlich. Eine Sprache, anhand der man wunderbar lernen kann, wie man _richtig_ programmiert.
Aber meine Polemik von oben ist sowieso nicht kommentierungswürdig,
eigentlich. *g*
*g* :-)
Ich habe mich schon öfter gefragt, wie ich Java empfunden hätte, wäre
ich damals nicht so auf C++ fixiert gewesen, obwohl ich es selbst
kaum konnte. Ich fand an Java alles schlimm, weil ich vorher Pascal
und Assembler gewohnt war, und daher dann auch das Pointer-Konzept
und das eigene Aufräumen im Destruktor von C++ etc. ganz toll fand.
Ich behaupte, dass es egal ist, womit man vorher bereits Erfahrung hatte. Für Java braucht man erst mal eine Unmenge Energie, um _überhaupt_ etwas erreichen zu können. Nun ja, andererseits reduziert das die Menge der "'sch mach des so und's funzt"-DAUs.
Sowas selbst machen zu müssen, erinnert mich jetzt, rückblickend an
Selbstgeißelung. :-)
Ja ... :-)
Einige meiner Kommilitonen haben C++ und Java zur gleichen Zeit
gelernt, und waren von Java begeistert, während sie C++ gehasst
haben. Bei mir war es umgekehrt. Erst viel später wurden mir die
Vorteile von Java klar.
Ich finde - in hinreichender Unkenntnis - C++ etwas zu kryptisch, gerade was die Symbolik angeht. Bei Java sind die Sprachkonstrukte sehr viel klarer.
Ich könnte mit meiner Einschätzung völlig falsch liegen...
Nicht, wenn Du sie als subjektiv bezeichnest. Immerhin reden wir von hochkomplexen Dingen, die zwangsläufig unterschiedliche Einstiege seitens der Einsteiger bedingen.
Zustimmung. Wobei natürlich die Frage gestellt werden darf, woher die IDE denn die Doku kennen soll. Die meisten werden aus dem Quellcode erzeugt ... :-)
Ja, genau. Da für viele Quellen aber bereits Javadoc existiert, wäre
es wünschenswert, wenn aus diesem wieder eine für die IDE lesbare
Dokumentation im eigenen Format generiert werden könnte.
Ich bin mir fast sicher, dass das irgend wer schon mal gemacht haben mag. Meiner Ansicht nach ist das aber ein Umweg, den man eher vermeiden sollte - wobei ich nicht glaube, dass Du das anders siehst :-)
Später, wenn sich das Format etabliert hätte, wäre es natürlich
wünschenswert, wenn es gleich zusammen mit der (Closed-Source-)Software
ausgeliefert werden würde.
Das müsste strukturell standardisiert werden, was erfahrungsgemäß nur mit einer gewissen Abhängigkeit geht, welche de facto nicht existiert: Bisher geht's ja wunderbar ohne. Ich hege also Zweifel, dass sich derartiges etablieren lässt. Eher könnte man die Entwickler dazu bringen, die Klassenstrukturen in Form von leeren Rümpfen auszuliefern (was sich ja beispielsweise per UML wunderbar generieren lässt), welche neben den (eh bekannten) Signaturen nur ihre Dokumentation besitzen.
In Visual Studio ist das sehr viel schöner gelöst.
Dort reicht ein Druck auf F1, und schon ist man bei der Doku.
Auch von Dingen, die bei der Auslieferung von VS noch nicht bekannt waren?
Soweit ich weiß, ja. Leg mich aber nicht drauf fest.
Okay, hätte mich auch eher am Rande interessiert (bzw. etwas mehr, wie es denn dann gelöst wäre).
Aber wofür gibt es denn die Manifest-Datei?
Für rein ignorative Zwecke. Nach meiner Beobachtung :-)
Vielleicht sollte ich dafür ein Eclipse-Plugin entwickeln... ;)
Halt mich bitte auf dem Laufenden! :-)
[Doku im externen Browser vermeiden]
Ja: Quellcode suchen! ;-)
Ich wußte, daß du das sagen würdest! ;-)
Es gibt die Theorie, nach der man nur dann Fragen stellen soll, wenn man die Antwort bereits kennt. Insofern also: Herzlichen Glückwunsch :-)
Bei uns klappt das (meistens), weil wir gewöhnlich nur Projekte verwenden, deren Quellcode uns zur Verfügung steht; sei es nun wegen Open Source oder durch Einkauf. Trotzdem habe ich schon oft genug überlegt, ob ich jetzt wirklich wieder ein externes Projekt auschecken möchte oder es mir doch antue, die Doku im Netz zu suchen. Schön ist es nicht.
Du meinst, weil das dann bei einem Full (Re)build wieder alles
mitkompiliert werden muß?
Auch, aber öfter deshalb, weil man eben nicht für _alle_ externen Pakete mehr als nur das JAR-File eingerichtet hat. Oft packt man nur in die project.xml die Abhängigkeit rein, lässt Maven rödeln und gut is' (quasi). Es ist schließlich nicht so, dass es nur zwei, drei Dutzend Pakete gäbe ...
(Ich wüßte
jetzt spontan nicht mal, ob man einzelne Projekte aus dem Build-
Vorgang ausschließen kann, und trotzdem noch die Quellen zur
Dokumentation verwenden kann.)
Das kommt auf den Build-Vorgang an. Bei uns gibt es da nicht mal den Ansatz eines Konfliktes.
Oder dauert es dir einfach zu lange, das Projekt auszuchecken, wenn
du nur schnell was nachschauen magst?
Es muss erst mal gesucht werden.
Ich hoffe, dass es nicht daran liegt, dass unsere Projekte komplizierter sind, sondern daran, dass Du einfach besser bist
Natürlich liegt es einzig und alleine daran! ;-)
*g* ;-)
Cheatah
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes