Java verkehrt herum lernen.

[_ebm_]

Darf man Probleme nicht andersrum versuchen anzupacken?

Hast Du mal versucht, ein Pferd verkehrt herum aufzusatteln?

Natürlich darfst Du fragen stellen. Das verbietet Dir hier niemand. Aber gestatte uns ob Deiner Unbelehrbarkeit uns zu wundern...

 

[Pingu]

Ich glaube Du verwechselst da arg einige Dinge. Du vergleichst nämlich Interpreter-Sprachen mit Compiler-Sprachen.

-> Basic, Ruby, Cobol, Python, … sind alles Interpreter-Sprachen und auf Deinem Dir eigenen Wege erlernbar
-> C, Objective C, C#, Java, … sind alles Compiler-Sprachen und auf Deinem Dir eigenen Wege _nicht_ erlernbar

Bei Compiler-Sprachen ist der Compiler der Rührstab zum Kuchen backen. Jetzt gibt es aber keinen Rührstab, der den Kuchen alles auf magische Art wieder in seine Zutaten zurück verwandelt. Der Decompiler holt praktisch nur die chemischen Komponenten der Zutaten wieder zurück, aber nie die Zutaten. Ein Decompiler ist für den versierten Entwickler ein Werkzeug, um Fehler zu analysieren und in der originalen Quelle zu beheben. Ein Decompiler ist kein Werkzeug welches zum Entwickeln gedacht ist. Ehrlich gesagt, wer sauber entwickelt, braucht wahrscheinlich nie einen Decompiler.

 

[Diskordia]

Ich verarsche niemanden. Wie kommst du darauf?

Naja so wie du die "modernen" Informatik kritisierst, klingt das nicht wirklich ernst und seriös.

Ja stimmt ich bin auch kein Deutscher.

Na und? Ich auch nicht.

Muss man ein Profi sein wenn man in euer Forum kommt?

Nein, aber wenn man den falschen Ton erwischt kommt das halt zurück

Gruss Diskordia

 

[dannycool]

Ehrlich gesagt, wer sauber entwickelt, braucht wahrscheinlich nie einen Decompiler.

Schön wärs... wir fallen regelmäßig über Compilerfehler und da ist das manchmal hilfreich um herauszufinden, was der Compiler denkt was er tut. Meine Assembler-Jahre liegen schon lang zurück und den Disassembler-Output von jeder beliebigen Plattform zu verstehen ist gar nicht so leicht.

Aber das ist es eben, das hat mit Entwickeln wenig zu tun, für die Entwicklung selbst ist ein Decompiler deutlich weniger nützlich. Bei Java lässt man sich vielleicht leicht dazu verleiten einen Decompiler für besser zu halten als er ist, weil man viele VM-Codesequenzen gut in Java-Code übersetzen kann und Symbole oft noch in Originalbezeichnung vorliegen, das sieht dann auch gern täuschend echt aus, ist es aber nicht. Gerade neuere Sprachfeatures werden ohnehin völlig falsch rückübersetzt weil da viel syntaktischer Zucker dabei ist.

Ich seh aber nicht grundsätzlich ein Problem darin, Java durch Analyse von existierendem Code zu lernen. Es gibt genug Open-Source-Projekte die in Java geschrieben sind. Nur mit dem Decompiler würde ich es bleiben lassen.

 

[wegus]

TE! TO!
sagt mal was bedeutet das?
Ist wohl auf mich gemuenzt.

ThreadErsteller, ThreadOwner und ja das bist hier Du

Wer keine Ahnung von Java hat, weiss auch nicht was Java ist und wie es funktioniert.
Eine Sprache lernen ist schoen und gut. Fuer manche benoetigt man 10 Jahre. Fuer japanisch das ganze Leben. Fuer Java vielleicht weniger. Dennoch ist es eine Sprache.

Ich hab gedacht ich probier es mal auf die alte Tour. Dass sich die Daten aber nicht rueckgaengig machen lassen, ist doch nicht meine Schuld. Und es reizt niemand von euch Informatikern es doch machbar werden zu lassen.
Beginnend am eigenen Programm, was man kennt.
Ach herrjeh. Ich bin auch womoeglich 50 Jahre zu spaet auf die Welt gekommen.

Informatik autodidaktisch gelernt. Mathe keine Kenntnisse.
Und ich sehe auch dass ich mich auch hier in die Reihe stellen muss, soll, sollte und nicht mehr eigen denken darf. Nur noch in Modulen denken soll.

Oder bin ich auch damit im Irrtum?

Ja, sogar mit einer ganzen Menge von Annahmen! Da fehlt es an sehr Vielem. Zunächst sind Programmiersprachen eingeschränkte, formale Sprachen. Sie unterliegen viel strikteren Regeln als das angeführte Japanisch und sind auch weniger Leistungsfähig ( dafür sind sie eineindeutig).


Der Satz mit dem

Dass sich die Daten aber nicht rueckgaengig machen lassen, ist doch nicht meine Schuld. Und es reizt niemand von euch Informatikern es doch machbar werden zu lassen.

Zeigt das hier ein tiefgreifendes Mißverständnis über das Arbeiten von Compilern vorliegt. Hier ist schon die Annahme allein ein Anreiz können Isomorphismen schaffen wo keine sind ein Hinweis darauf, das Basiswissen fehlt. Jede Folgerung auf diesem Wissensstand wird fehlschlagen, wie die illusorische Aufforderung zeigt.

Ich hab gedacht ich probier es mal auf die alte Tour.
Beginnend am eigenen Programm, was man kennt.

Grundsätzlich nicht schlecht! Aber eine Sprache, auch eine Formale, besteht aus mehr als dem Lernen von Vokabeln. Es gibt Lösungsstrategien, Konventionen, etablierte Verfahren etc. die einem Zeit und Fehler ersparen. Die wollen/müssen auch gelernt werden. Die gab es aber zu Zeiten von BASIC für DOS oder Turbo-Pascal einfach noch nicht! Wenn ich jetzt ein Programm aus dem Pleistozän der Programmierung nehme und das selbe Ding genauso abhandeln will wie damals in Turbo-Pascal...nun dann müßte ich heute wieder Turbo-Pasal als Sprache wählen und gut. Wenn es Java sein soll, wenn es Objective-C sein soll oder wenn es C# sein soll, dann will das Vokabular gelernt werden, die Methodik und die zuarbeitenden Frameworks verstanden werden und erst dann kann ich den Lösungsansatz von damals in einen Lösungsansatz von heute übertragen und diesen neuen Ansatz dann in ein neues Programm überführen. Wenn Du so willst ist das genau Gegenteil von Decompilieren nötig. Der Sourcecode ( nicht das Decompilat) muß re-abstrahiert und die Methoden dahinter verstanden werden ( und nicht nur die Vokabeln).

Es geht eben nicht durch Disassemblierung. Überspitzt gesagt wird man den Unterschied zwischen Trabant 601 und Porsche 911 nicht finden wenn man beide KFZ in deren Elementarteilchen zerlegt und dann die Hadronen sortiert! Es ist eher umgekehrt, ich brauche die Baupläne, die Informationen zu den Antriebs- und Materialkonzepten etc. ich muß den Überbau verstehen. Das beide Autos aus Atomen sind weiß ich ohne es nachzuprüfen, daher bringt auch ein zerlegen nichts.

 

[Diskordia]

Ehrlich gesagt, wer sauber entwickelt, braucht wahrscheinlich nie einen Decompiler.

Manchmal ist es nicht verkehrt einen Decompiler zu benutzen, aber dann geht es eher darum genau festzustellen was jetzt nun das framework xyz genau macht und dann weiss man auch was man tut.

Gruss Diskordia

 

[_ebm_]

Ich kam in meiner 12-jährigen Java-Erfahrung noch nie in die Verlegenheit, fremde Bibliotheken decompilieren zu müssen um einen Bug nachzuvollziehen. Zumeist liegen die Libs in Quelltext vor und wenn nicht, disqualifizieren sie sich für die Nutzung. Außerdem haben gute Libs einen vernünftigen Debug-Schalter. Schlußendlich gibt es noch den Debugger.

Und: Versteht man nicht, was der javac mit dem eigenen Quelltext tut, sollte man sich nochmal ein gutes Java-Buch greifen

Gruß Carsten

PS. Den Decompiler hab ich bisher nur einmal eingesetzt und zwar um ein fremdes System zu "reverse-engeneeren". Das war aber schmutzig und diente nicht dazu, es zu verändern und anzupassen sondern nur um Grundlegende Funktionen innerhalb zu verstehen.

 

[Diskordia]

Naja manchmal liegt die Entscheidung eine Lib zu benutzen nicht in der Eigenen Hand, wenn man dann bei einer riesigen Lib wie DevExpress die Source nicht hat und was exotisches machen muss bleibt einem nichts anderes übrig als den decompiler anzuschnallen.
Aber ansonsten stimme ich dir da zu.

 

[_ebm_]

Du scheinst das aus gleichem Grund gemacht zu haben wie ich Passt schö