Erste Schritte Anfänger Verständnisfrage zum Compiler

[ChippoS]

Hallo
ich bin nicht nur Anfänger = ich fange gerade erst mit Java an, ich bin dazu ein Anfänger ohne Vorkenntnisse und alt, sehr alt. Mir muss also bitte etwas mehr Geduld als gar einem Anfänger entgegengebracht werden.
Meine erste Verständnisfrage lautet:
Ist ein Compiler nicht eigentlich ein Decompiler?
Soweit mein bisher angeeignetes Wissen in all seiner Spärlichkeit reicht, glaube ich, dass ein PC ursprünglich Bits (bzw Bytes) verarbeitet. Daher ist z.B. schon ein Editor (für mich) ein Programm, dass Bits/Maschinensprache in eine (Text-)Form "übersetzt"; selbst die Eingabeaufforderung ist für mich ein aus Bits/ Maschinensprache "übersetztes Programm". Daher würde ich diese Programme, die von Bits in (mir fehlt das passende Wort, daher bitte dem Sinn nach gehen) Programmsprache übersetzen als Compiler ansehen.
Während ein Übersetzer aus einer (höheren) Computersprache in Maschinensprache demnach doch dann ein Decompiler wäre.
An welchem Punkt habe ich einen Knoten im Hirn? Wer kann mir bitte helfen?

 

[mihe7]

Der Punkt ist einfach, ob nach oder von Maschinensprache übersetzt wird.

Text ist, auch wenn er binär kodiert ist, kein Bestandteil der Maschinensprache, sondern einfach Daten.

 

[kneitzel]

Also erst einmal eine sehr interessante Fragestellung. Deine Sichtweise finde ich schon recht interessant.

Hier greift aber die Definition.
Compiler wird in der Regel etwas genannt, das eine höher wertige Sprache in eine niedrig wertigere Sprache übersetzt.
Beispiele wären sowas wie Java -> Bytecode oder Bytecode -> Maschinencode, c -> Assembler, Assembler -> Maschinencode

Wenn es von einem unteren Level in ein höheres Level geht, dann spricht man in der Regel von einem Decompiler. Also wenn aus ByteCode wieder Java Code gemacht wird.

Compiler – Wikipedia

de.wikipedia.org

Ein Compiler (auch Kompilierer; von englisch compile ‚zusammentragen‘ bzw. lateinisch compilare ‚aufhäufen‘) ist ein Computerprogramm, das Quellcodes einer bestimmten Programmiersprache in eine Form übersetzt, die von einem Computer (direkter) ausgeführt werden kann.

Edit: Höher wertig / niedriger wertig ist bei Sprachen so evtl. schlecht formuliert. Damit ist die Nähe zur Maschinensprache gemeint. Also dass ein Rechner direkt mit möglichst wenig weiterer Verarbeitung, etwas ausführen kann.

 

[Robert Zenz]

Ist ein Compiler nicht eigentlich ein Decompiler?

Ja und Nein. Im Sinne von das sie beide etwas von einem Zustand in den anderen uebersetzen, Ja. In jedem restlichen Sinne, Nein.

Ein "Compiler" wird immer dazu verwendet um Quelltext in einen ausfuehrbaren Zustand zu versetzen (also quasi Human zu Maschine). Ein "Decompiler" tut immer genau das umgekehrte, nimmt also etwas das Maschinenausfuehrbar ist und erzeugt daraus lesbaren Quelltext. Natuerlich kann man den Maschinencode auch direkt lesen, aber kaum jemand hat die Zeit dafuer.

Soweit mein bisher angeeignetes Wissen in all seiner Spärlichkeit reicht, glaube ich, dass ein PC ursprünglich Bits (bzw Bytes) verarbeitet.

"Urspruenglich" muss aus dem Satz raus, aber ja, ein PC verarbeitet immer einzelne Bits, welche zusammen Bytes und so weiter ergeben.

Daher ist z.B. schon ein Editor (für mich) ein Programm, dass Bits/Maschinensprache in eine (Text-)Form "übersetzt"; selbst die Eingabeaufforderung ist für mich ein aus Bits/ Maschinensprache "übersetztes Programm". Daher würde ich diese Programme, die von Bits in (mir fehlt das passende Wort, daher bitte dem Sinn nach gehen) Programmsprache übersetzen als Compiler ansehen.

Du vermischt hier Konzepte, naemlich die direkte Interaktion (Button auf der Oberflaeche), und das "vorbereiten" eines Programms welches quasi selbststaendig ablaeuft. Natuerlich, jeder Tastendruck auf deiner Tastatur fuehrt dazu dass die CPU Instruktionen ausfuehrt, aber meistens sind diese bereits als Maschinencode vorhanden, also bereits kompiliert (oder direkt in Assembler geschrieben, wobei wenn man nicht gerade Assembler in einem Hex-Editor tippt, kompiliert man sogar das vorher) und werden nur noch abgearbeitet. Wohingegen das kompilieren eines Programms dieses lediglich in ausfuehrbarer Form erzeugt.

Wie bereits weiter oben, und von @kneitzel gesagt, kompilieren ist ein recht spezifischer Begriff, naemlich Quelltext nach Maschinencode, Ausfuehrung ist dabei nicht enthalten. Der Unterschied hier ist das Quelltext zuerst kompiliert, und dann erst ausgefuehrt wird, also du musst zwischen "Compiletime" und "Runtime" unterscheiden, das sind auch zwei Begriffe die dir immer wieder unterkommen (weniger in Java aber mehr in C oder C++, um ehrlich zu sein).

 

[kneitzel]

Daher ist z.B. schon ein Editor (für mich) ein Programm, dass Bits/Maschinensprache in eine (Text-)Form "übersetzt"

Zu dem Punkt kann man noch ausführen: Hier handelt es nicht um einen Compiler. Es geht hier um Fragen des Encoding und der Darstellung.

Es wird also nichts übersetzt. Im Text hast Du das Zeichen A und die Datei ist im ASCII Format.

ASCII-Tabelle

ASCII-Tabelle

www.torsten-horn.de

Du hast also in der Datei einfach nur eine Zahl: 65, bzw 0x41 in Hexadezimal oder eben 0000 0100 0000 0001 in Binärform.
Wobei das so auch falsch ist. Streng genommen hast Du auf einer rotierenden Scheibe irgendwelche Magnetfelder (oder irgend eine andere Speicherform)

Und da wird nichts übersetzt. Hier wird maximal interpretiert. Nach ASCII Tabelle wird dieser Wert interpretiert als A. Das muss aber noch irgendwie angezeigt werden ... aber da kommt dann sehr viel rein: Schriftart, Schriftgröße, Farbe, ... Aber das dient nur der Anzeige. Der Wert an sich bleibt gleich (*). Das erkennst Du, wenn du es dann wieder speicherst.

(*) Streng genommen bleibt der Wert nicht gleich. Denn intern arbeitet das Programm nicht mit ASCII Werten sondern statt dessen wird da ein UTF-16 Zeichen draus. Also würde das ASCII Zeichen 0x41 in das 0x0041 umgewandelt.

 

[ChippoS]

Oh, ach so... es ist also eher eine (einfache) Frage der DEFINITION. Mit anderen Worten: die willkürliche Definition eines Compilers ist die, dass aus einer höheren Sprache in eine niedrige übersetzt wird. So dass compilieren eben einfach von oben (in Bezug auf Programmiersprachen) nach unten ist.
Hab ich verstanden (obwohl es für mich anders herum einfacher wäre)
Und Dank auch für die weiteren Bemerkungen, denen ich folgen konnte. Durch diese Details begreife ich immer mehr und auch wenn es mir in der Ausgangsfrage nur um das Verständnis ging, habe ich jetzt noch mehr Informationen erhalten, die ich gut ge-brauchen kann. Um eine Sprache zu lernen, sollte man halt sprachlich korrekt verbalisieren Diese Detailgenauigkeit kann nur bei Verständnis erfolgen und dieses wiederum nur durch Genauigkeit.
Besten Dank! Ich habe (viel) dazu gelernt 😊

 

[White_Fox]

Vielleicht wäre folgender Gedenkengang für dich noch nützlich:

Programmiersprachen sind ja - wie Robert Zenz schon angemerkt hat - dafür gemacht, Informationen und Anweisungen so darzustellen, daß sie von Menschen benutzt und verstanden und verstanden werden und die Informationen für den Computer trotzdem irgendwie mitenthalten.

Im Grunde heißt das, daß im Quellcode Informationen sind, die der Computer nicht verwerten soll und kann. Ein typisches Beispiel sind die Bezeichnungen von Variablen. Während diese Namen für die Lesbarkeit des Quellcodes für Menschen äußerst wichtig ist (tatsächlich steht und fällt mit der Benamsung vieles), immerhin soll man am Namen ja erkennen können was der Wert der Variable zu bedeuten hat, wird der Name vom Compiler rausgeworfen und durch eine schnöde Speicheradresse ersetzt (sofern die Variable überhaupt in den Speicher geladen wird, aber das ist eine andere Geschichte).

Jetzt jage das Kompilat, also das was der Compiler als ausführbaren Maschinencode erzeugt hat, mal gedanklich durch einen Decompiler.
Der sieht zwar, das eine Adresse für Speicher reserviert wurde, aber daraus ist absolut kein Variablenname abzuleiten. Der Decompiler muß sich an dieser Stelle irgendetwas ausdenken.

Das Ganze ist in der Realität noch weitaus komplizierter, aber was ich deutlich machen wollte: decompilieren ist zwar die Umkehrung vom compilieren, aber das eine ist trotzdem nicht das direkte Gegenteil vom anderen im Sinne von "einfach anders herum". So willkührlich sind die Definitionen gar nicht, und Unterteilungen von Hochsprachen über maschinennahe Sprachen bis direkt zur Maschinensprache haben da schon ihre Berechtigung.

 

[ChippoS]

Sehr nützlich; dieser Gedankengang. Denn er erklärt mir das, was bisher offen geblieben war. Eine Übersetzung ist nur dann eine vollendete Übersetzung, wenn sie die inhaltlichen Aspekte berücksichtigt und quasi verständlich mit übersetzt. Von unten nach oben baue ich quasi mehr Informationen auf bzw füge sie zu "Größerem" zusammen und da ich dann von oben nach unten gewissermaßen mehr inhaltliche Informationen habe, die herunter gebrochen werden, ist es eben ein andersartiges Übersetzen. (Ich schreibe das kursiv, weil ich weiß, dass ich die richtigen Termini -noch- nicht kenne, trotzdem aber schon wenigstens den "Sinn" ausdrücken möchte) Ist das so korrekt aufgenommen von mir?

 

[White_Fox]

Noch eine Anmerkung, du hast ja anderswo geschrieben das du Java lernen willst: Mach es dir nicht zu kompliziert.

Die wichtigste Daseinsberechtigung von Hochsprachen ist, viele Nebendetails von dir fernzuhalten. Wie ein Compiler arbeitet, gehört da m.M.n. auch dazu.

Wenn du neugierig bist und es wissen willst - nur zu, ich will dich keineswegs aufhalten. Nur programmieren lernst du davon halt nicht, und gerade solche Dinge wie die Funktionsweise von Compilern sind sehr anspruchsvoll, da kannst du dich beliebig tief reinknien und wirst nicht fertig damit.

Edit:

Ist das so korrekt aufgenommen von mir?

Es ist zumindest nicht völlig verkehrt. Der Begriff 'kompilieren' bedeutet soviel wie 'zusammensammeln'. Der Compiler sammelt die Informationen zusammen, die er für das Programm benötigt. Dazu gehört zwar auch das Übersetzen von deinem Programmcode in Maschinensprache, allerdings optimiert der Compiler deinen Programmcode auch. Wenn er feststellt daß du zwar eine Variable deklarierst, diese aber nirgendwo nutzt, kann er sie z.B. wegwerfen, genauso wie unnötige Funktionsaufrufe. Und wenn du andere Bibliotheken benutzt, sammelt der Compiler diese Informationen auch ein und verwurstet die im Kompilat.

 

[ChippoS]

Vielleicht ist das der wichtigste Hinweis: es an manchen Stellen gut sein zu lassen. Schließlich ist es oft so, dass, wenn eine Frage beantwortet wurde, sich neue auftun. Um das Ziel aber nicht zu verlieren, lasse ich es dann hier so be-stehen. Denn auch das muss man/ich lernen. An welcher Stelle sind die Infos ausreichend genug, um (gut) weiter machen zu können?! Hier sind die Antworten mehr als gut und hilfreich gewesen!
Ich bedanke mich herzlichst für ALLE Antworten, die ich erhalten habe und für die Geduld mit mir

 

[White_Fox]

Hast du so etwas wie ein Tutorial? Einen roten Faden? Woher weißt du, was du als nächstes lernen solltest?

(Edit: nur um dich vielleicht etwas in die Richtung zu schubsen, in die du eigentlich zu wollen scheinst...)

 

[ChippoS]

Ich habe angefangen im Internet nach Tutorials zu suchen und bin recht schnell bei einigen gelandet, die sofort "eingestiegen" sind. Und dort hätte ich sicher weiter machen können. Wie das Telefon wirklich funktioniert weiß ich nämlich bis heute auch nicht im Detail; kann es aber trotzdem problemlos nutzen. Allerdings bereitet das Telefon auch wenig Schwierigkeiten in der Nutzung als solches. Ich aber hatte den Eindruck, dass bei der Programmierung durch ganz leichte Fehler -ein vergessenes Semikolon, ein Buchstabe groß statt klein geschrieben usw. sehr schnell auch große Probleme auftreten können. So bin ich -das beziehe ich nur auf mich- zu der Überzeugung gelangt, dass das Schwierigste bei der Programmierung vielleicht nicht unbedingt das Programmieren ist, sondern die Fehler im (eigenen) Programm zu finden. Diese finde ich aber nur, wenn ich verstehe. Wenn ich Zusammenhänge, Details, Verknüpfungen, Definitionen und Vorgaben -bis zu einem gewissen Grad- verstehe. Daher bin ich dann bei
www. gailer-net.de Java Tutorial gelandet.
Zusätzlich habe ich "Java ist auch eine Insel" (Chr. Ullenboom) und "Java -Programmieren lernen für Einsteiger" (M.Bonacina) als Haupthilfen und vier weitere Tutorials, die in meiner Internetsammlung stehen.
Was mir aber fehlte, so blöd sich das anhört, war die "gesprochene Sprache". Deshalb meine Suche nach einem geeigneten Forum. Ich lese die Beiträge hier und auch wenn ich inhaltlich nicht im geringsten folgen kann, bekomme ich ein "Gefühl" für die Sprache, so wie sie von Euch (den Profis) in Zusammenhang mit der "Muttersprache" genutzt wird. Diese "Verknüpfung" kann ich in keinem Tutorial erfahren, aber für mich ist sie ein wichtiger Bestandteil, um sie selbst innerlich zu integrieren. So wie man eine Fremdsprache eben auch gut in dem Land lernt, in dem sie gesprochen wird ;-)
Also: Ja, ich habe einen Faden (bin gerade erst bei den Variablen), aber lasse mir ausgiebig Zeit, die Grundlagen zu verinnerlichen. Eine gute Basis erspart m.E. manch Problem, das ohne diese entstehen könnte. Eine falsche Vokabel in einer Fremdsprache führt eventuell zu einem Lacher, aber eine falsche Vokabel in Java lässt eventuell das ganze Programm nicht laufen...Daher meine Ausschweifungen. Ich bereite mich einfach jetzt schon auf meine Fehlersuche vor. Denn ganz sicher werde ich solche machen!

 

[Barista]

Ich aber hatte den Eindruck, dass bei der Programmierung durch ganz leichte Fehler -ein vergessenes Semikolon, ein Buchstabe groß statt klein geschrieben usw. sehr schnell auch große Probleme auftreten können. So bin ich -das beziehe ich nur auf mich- zu der Überzeugung gelangt, dass das Schwierigste bei der Programmierung vielleicht nicht unbedingt das Programmieren ist, sondern die Fehler im (eigenen) Programm zu finden. Diese finde ich aber nur, wenn ich verstehe. Wenn ich Zusammenhänge, Details, Verknüpfungen, Definitionen und Vorgaben -bis zu einem gewissen Grad- verstehe.

Bei Flüchtigkeitsfehlern hilft nur Geduld und auch die IDE.
Mit Grundlagen hat das nicht viel zu tun.

Eine falsche Vokabel in einer Fremdsprache führt eventuell zu einem Lacher, aber eine falsche Vokabel in Java lässt eventuell das ganze Programm nicht laufen.

Viele Tippfehler findet bereits der Compiler.

Ich glaube nicht, dass eine Fremdsprache und eine turingvollständige Codierung vergleichbar sind.

Beim Programmieren geht es wenig um das Finden von Flüchtigkeitsfehlern.

Wichtiger sind Fehler auf höherer Ebene, aus Projekten bekannt als "daran hat niemand gedacht".

Nach meiner Meinung bringt irgendwelches Pauken (Auswendiglernen) wenig.

Allerdings habe ich gerade in meiner Java-Anfangszeit viele Sachen gelesen (Garbage Collection, Objekte, Vererbung, JDK-APIs usw.).

Das habe ich aber nicht als Auswendiglernen empfunden, sondern als interessant.

Um Java (oder eine andere Programmiersprache) zu lernen, benötigt man vor allem Übung.

Also such Dir eine interessante Aufgabe und arbeite daran, dann kommt das Lernen von allein.

 

[ChippoS]

Verständnis erlangen und bzw. oder "Auswendiglernen" sind für mich unterschiedliche Arten. Mag sein, dass für Dich diese Vergleiche mit einer Fremdsprache nicht hilfreich gar entfremdet sind. Aber auch wenn ich keine Ahnung vom Programmieren habe, weiß ich ziemlich sicher wie ICH lerne und dass es da sehr große Unterschiede bei verschiedenen Menschen gibt. Auch wenn ich also mit "Auswendiglernen" genauso wenig anfangen kann wie scheinbar Du, so weiß ich, dass andere Menschen damit sehr gut zurecht kommen. Und m.E. benötigt man, in diesem Fall ICH nicht nur Übung, die ich sehr wichtig finde, sondern mehr.
Ich lese die Bücher, mache dementsprechend auch die Übungen (und wiederhole diese dauernd), ich halte mich an das Tutorial, ebenfalls mit Übungen, ich bin dem Forum aus o.g. Gründen beigetreten und ich schaue mir immer wieder einmal "Quelltexte" an , um immer mehr davon l e s e n zu können. Im Moment sind das eben fast nur Vokabeln. Aber so fängt es an...
Ich habe mir eine 10-15 Jahre Aufgabe vorgenommen und den ersten Schritt getan. Also: ja, ich habe ein langfristiges, mittelfristige und kurzfristige Ziele
Dass ein Compiler bereits Tipp-Fehler findet, erfährt man wohl nur, wenn man solche macht und den Compiler nutzt. Dazu möchte ICH aber auch schon vorher wissen, was der Compiler eigentlich macht. Denn seine Hauptaufgabe ist wohl nicht, Tippfehler zu finden.
Und ich arbeite noch gar nicht mit der IDE (hoffentlich ist das eine wahre Aussage, denn so ganz bin ich da noch nicht hingelangt und durchgestiegen?!?) Ich schreibe im Editor und gehe dann zur Eingabeaufforderung. (Vielleicht beinhaltet das auch schon eine IDE also bitte nicht steinigen falls ich da völlig falsch liege)
Ich sage es noch einmal: ich bin Anfänger ohne Vorkenntnisse. Was Dir also selbstverständlich ist, sich von selbst versteht, muss ich noch lernen. Und wenn Deine Erfahrung ist, dass nur die Fehler auf höherer Ebene wichtig sind, dann bedanke ich mich für diese Information, die mir sehr wichtig erscheint. Aber um auf höhere Ebenen zu kommen, muss ich die unteren erst absolvieren und da sind für MICH Tippfehler manchmal auch noch "unbedachte Handlungen, die zu Fehlern führen". Und diese Unterscheidung muss ICH noch lernen, das ist für mich eine Grundlage. Später werde ich das sicher auch als lächerlich, zum Lächeln, empfinden, aber die ersten Schritte sind immer etwas lächerlich, wenn man Marathonläufer geworden ist oder? Vielleicht bin ich zu vorsichtig, will mich zu sehr absichern, da gebe ich Dir durchaus recht. Und ein Schubs nach vorn tut da gelegentlich seine gute Wirkung.
Daher: ja, ich mache nun weiter und lasse den Compiler und die dazu gemachten Aussagen so stehen. 😊

Edit: Was ich in meiner komplizierten Art sagen wollte, lässt sich kurz so zusammenfassen:
Vergisst Du ein Semikolon, so ist das ein Tippfehler.
Setze ICH kein Semikolon, so ist das (noch) Dummheit -nicht Wissen.

 

[White_Fox]

Ob der Vergleich zwischen einer Programmiersprache und Fremd/Muttersprache hinkt sei mal dahingestellt. Meiner Meinung ist der Vergleich nicht möglich, aber eigentlich finde ich diese Frage auch nicht so wichtig.

Ich kenne dieTutorials, die du da bearbeitest, nicht. Ich würde dir aber davon abraten, das Buch "Java ist auch eine Insel" allzu ernsthaft zum Lernen zu benutzen. Das Buch ist ein reines Nachschlagewerk und in weiten Teilen einfach nur eine Übersetzung der offiziellen Javadokumentation, auch wenn der Autor immer wieder so tut als würde er dir was beibringen wollen. Ich finde aber daß es kaum jemandem nützen wird, alle möglichen Stringmethoden intensiv zu üben und bis in tiefe Details auswendig zu lernen, um sich danach durch 1.200 weitere Seiten ebenso tief in andere Themen einzuarbeiten. Man braucht eigentlich nie alles davon und schon gar nicht auf einmal, aber was wird davon im Kopf hängengeblieben sein, wenn man nach den 1.200 weiteren Seiten wirklich mal etwas davon braucht?
Dafür ist das Buch ziemlich dick und sich da durchzuquälen eher demotivierend.

Daher: Wenn du soweit bist daß du mit if(), switch(), while(), do while() und for() etwas anfangen kannst und verstanden hast, kann ich dir das Buch "Java von Kopf bis Fuß" - O'Reily sehr empfehlen. Und wenn du das durch hast, kannst du gleich mit "Entwurfsmuster von Kopf bis Fuß" weitermachen.
Beide Bücher legen sehr viel Wert auf Verständnis und vermitteln dieses meiner Meinung nach auch wirklich gut. Danach kannst du dir m.M.n. ernsthaft ein eigenes Projekt überlegen und hast genug Wissen, um es anzufangen.
Nicht daß das Lernen danach aufhören würde, aber irgendwann muß es ja mal losgehen.

Und - das kann ich dir aus eigener Erfahrung sagen - mit nichts lernt man intensiver, interessanter und nachhaltiger als mit einem eigenen kleinen Softwareprojekt.

 

[Jw456]

Hallo du scheint nicht mit einer IDE zu arbeiten.
Eine IDE ist eine sinnvolle Entwicklungs Umgebung die einen Editor enthält der auch genau für die Programmiersprache abgestimmt ist. In ihr ist auch gleich der Compiler und Debugger für Fehler suche enthalten.

Auch Wort Vervollständigung und Methoden vorschlage sind gute hilfen auch für den Anfang.
Ich persönlich möchte eine Ide nicht mehr missen.

Ich würde auch als Anfänger empfehlen eine Ide zu benutzen.

Auch die meisten Anfänger Bücher tutorials arbeiten damit. Benutze am besten die gleiche wie im Buch.

Vielleicht InteliJ, Netbeens, auch Eclipse wird gerne benutzt.

PS auch solche Sachen wie Semikolon oder klammer falsch zeigt dir der Editor der IDE an. Er hilft dir auch bei der Strukturierung des Codes. Auch bei nicht definierten Variablen nicht benutzen... Es gibt noch viele weitere Sachen wir für der Editor der IDE hilft.

 

[ChippoS]

Vielen herzlichen Dank für all die Hinweise und Tipps! Ich werde jedem einzelnen in meinem Tempo nachgehen und ausprobieren Und nun widme ich mich erst einmal wieder den Variablen und den Arrays .. .mit anderen Worten: es sind sicherlich neue Fragen zu befürchten

 

[temi]

kann ich dir das Buch "Java von Kopf bis Fuß" - O'Reily sehr empfehlen. Und wenn du das durch hast, kannst du gleich mit "Entwurfsmuster von Kopf bis Fuß" weitermachen.

Würde ich auch in dieser Reihenfolge vorschlagen, allerdings muss man mit dieser Art von Buch zurecht kommen. Vielleicht vorher mal die Leseprobe anschauen.

 

[Barista]

Vielen herzlichen Dank für all die Hinweise und Tipps!

Beim Lesen Deiner Postings habe ich den Eindruck, dass Dir Prosa mehr lliegt als Code.
Meinst Du wirklich, dass Java etwas für Dich ist?
Aber versuchen kann man es mal.

 

[Mart]

Beim Lesen Deiner Postings habe ich den Eindruck, dass Dir Prosa mehr lliegt als Code.

musst dir mal @kneitzel seinen spruch durchlesen

 

[kneitzel]

Also auch Entwickler können durchaus ein gewissen Umgang mit Text beherrschen. Das sind keine Dinge, die sich widersprechen.

 

[mihe7]

Mir kam zu Ohren, dass manche Entwickler sogar ganze Bücher geschrieben haben

 

[White_Fox]

...fängt ja schon mit der Abschlußarbeit an...

 

[mihe7]

...fängt ja schon mit der Abschlußarbeit an...

Ja, da kommt auch einiges an Text zusammen.

 

[kneitzel]

...fängt ja schon mit der Abschlußarbeit an...

Dafür gibt es doch - wie wir hier schon erfahren haben - Agenturen, die das für einen machen ....

 

[M.L.]

Grundsätzlich ist die "Maschinensprache" eine relativ grosse Menge an Anweisungen, Strom durch irgendwelches Material fliessen zu lassen ( mathematisch durch 0 und 1 abgebildet). Sinn und Zweck dieser Anweisungen sind dem elektronischen Endgerät allerdings egal. Wobei der Java Compiler durchaus grobe Fehler vermeiden kann (im Ggs. zu z.B. Programmiersprachen wie C/ C++, die den Code i.V. mit dem Endgerät wirklich _alles_ machen lassen). Der "gesprochenen Sprache" kommt "Visual Basic (.NET) " übrigens etwas näher als das kryptische C# (oder Java)

 

[Mart]

z.B. Programmiersprachen wie C/ C++, die den Code i.V. mit dem Endgerät wirklich _alles_ machen lassen

normalerweise sollte sich der Kernel dazwischen stellen dass das nicht passiert

 

[White_Fox]

Nur wenn es einen Kernel gibt.

 

[Mart]

deswegen "normalerweise"

 

[ChippoS]

Upsala...bin überrascht, welche Entwicklung die Diskussion genommen hat. Besonders überrascht mich die Frage, ob ich mich denn nicht lieber der "Prosa widmen" sollte, aber versuchen könne "man" es ja mit Java...
Da muss "man" ja nun kein (Sprach-)Wissenschaftler sein, um herauszulesen, welche Daten und Informationen in diesem Text offensichtlich und als Subtext vermittelt werden
Dann gebe ich das mal auf meine Art zurück @Barista : Wenn ein (Java) Programmierer bestenfalls einen gewissen Umgang mit Text beherrscht, werde ich sicher keiner! Dann habe ich nämlich Programmierer überschätzt.
@Mart : Leider weiß ich nicht, welchen Spruch Du meinst...dazu brauche ich mehr Angaben, sonst würde ich ihn mir durchlesen.

 

[kneitzel]

Bitte lass Dich durch so Aussagen nicht verwirren. Hier tummeln sich halt einige Leute und die sind von der Art und Weise teilweise hoch unterschiedlich. Aussagen, die Dich nicht weiter bringen, kannst Du also getrost ignorieren.

 

[mihe7]

Leider weiß ich nicht, welchen Spruch Du meinst...dazu brauche ich mehr Angaben, sonst würde ich ihn mir durchlesen.

In @kneitzel s Signatur: "Clean code is simple and direct. Clean code reads like well-written prose..." von Grady Booch, Pionier der OOP und einer der "drei Amigos", die die UML entworfen haben.