ich finde es ja toll, das man immer mehr programmieren kann und die hilfen immer besser werden. vielleicht wären aber auch alle daran gut beraten, auch mal die software-dokumentation in andere sprachen zu übersetzen. das würde vielen windows-verwöhnten hobby-programmieren ein wesentliches stück weiterhelfen.
p.s. ihr könnt euch jetzt auf mich stürzen und mir sagen, dass ich erst englisch lernen soll. mir geht es nun mal so, dass ich mit deutsch besser weiterkomme als mit englisch.
Nun, du kannst gerne Dokumentation ins deutsche zu übersetzen. Bei Programmen von Windows-Hobbyprogrammierern, die nichtmal technische Dokumentation auf englisch *lesen* können, besteht die Gefahr, dass es sich um Shareware oder Freeware handeln wird. Das wiederum bedeutet, dass die Programme üblicherweise als i386-Binaries verfügbar sind, was z.B. Nutzern von GNU/Linux auf Macs nichts bringt.
Software sollte alleine aus praktischen Gründen schon frei sein, wobei ich darauf hinweisen möchte, dass ich nicht aus praktischen Gründen einzig und allein Freie Software einsetze.
ich lese aus deinem beitrag folgendes heraus: wer keine technische englische dokumentation lesen kann, soll nicht programmieren weil eh nichts für die allgemeinheit (zumindest für mac-user) brauchbares rauskommt. das ist falsch. du gehst sogar weiter und bezeichnest das als gefahr. eine grobe fehleinschätzung. du verweigerst aus egoistischen motiven einer minderheit (ist nunmal so, nichts für ungut ingo und udo) die möglichkeit für die community etwas brauchbares zu erstellen. ein anderer punkt ist die dokumentation. übersetzung ist arbeit und dafür muss sich jemand finden. ich bin kein guter übersetzer und versuche mich an etwas anderem (newbierouter.de). das ist mein beitrag den ich geleistet habe und es hat schon dem einen oder anderen geholfen. wenn also udo und ingo als hobbyprogrammierer etwas sinniges herstellen wollen sollte man ihnen nichts grundsätzlich verweigern. ich hoffe es findet sich jemand der für die beiden übersetzt.
Naja, ich hatte es eigentlich so gemeint, dass wir keine Share- und Freeware gebrauchen, weil sie nicht frei ist und üblicherweise daher diverse *Minderheiten* (wenn du schon anfängst davon zu reden, bin ich gerne bereit auch auf die gleiche Weise zu argumentieren) wie Leute, die GNU/Linux auf PPC, m86k, etc. einsetzen, es noch schwieriger haben als es jetzt schon der Fall ist.
Wenn Autoren ihre Programme unter eine freie Lizenz stellen, ist es vollkommen egal, ob sie englisch können oder nicht (wobei natürlich englische Kommentare im Code vorzuziehen wären...).
In der Windowswelt ist Free- und Shareware nunmal verbreitet und immer wenn unfreie Software programmiert wird, ist das schlecht für die OpenSource-Bewegung und natürlich erst Recht für die Free Software-Bewegung.
Wenn jemandem das Übersetzen nicht liegt, macht ja nichts. Ich finde es super, dass du dich überhaupt engagierst, das machen ja leider nur wenige.
Von Johann Lermer am Fr, 3. November 2000 um 08:52 #
Hi,
dies soll bitte nicht als Kritik, sondern als Anregung verstanden werden. Ich weiß sehr gut, daß die meiste Dokumentation nur in englisch verfügbar ist, allerdings gibt es schon recht viele deutsche Übersetzungen sowohl bei KDE als auch z.B. beim deutschen Manpage Projekt. Und genug deutsche Bücher übers Programmieren gibt's auch.
Wer jetzt trotzdem noch nicht genug Lesematerial zusammenbekommt, um damit als Programmierer loslegen zu können, der sollte sich wirklich ernsthaft fragen, ob er/sie nicht erst mal anstelle der Programmierkenntnisse die Englischkenntnisse auffrischen sollte. Denn es ist nun mal so: in unser heutigen Berufswelt ist - zumindest in den technischen Berufen - englisch eine zwingende Voraussetzung. Ihr solltet also nicht an der fehlenden deutschen Dokumentation kritisieren, sondern dies als Anlaß nehmen, mal vernünftig Englisch zu lernen. Ich habe vor Jahren auch so angefangen, mit den Amiga Developer Manuals. Anfangs ist es immer schwierig, aber mit der Zeit wird's schon!
das denke ich auch... wer wirklich software erstellen will die für die allgemeinheit von nutzen ist muss eh englisch lernen. allerdings kann man auch sagen, dass ich deutsche dokumentation meistens trotzdem lieber lese, weil ich bei englischen dokumentationen teilweise doch noch raten muss, was dies und das bedeuten soll (einzelne wörter) oder halt nachschlagen. ausserdem fällt es mir im deutschen weitaus leichter gewissen spitzfindigkeiten und humoristische zeilen zu erkennen :) dann aber wiederum denke ich mir, dass man die arbeitszeit doch lieber in neue gute dokumentation stecken sollte als in übersetzungen. aber wenn jemand gerne übersetzt kann er so auch einen guten beitrag leisten. z.b. freue ich mich schon auf die deutsche übersetzung des kde buches, das werde ich mir dann eventuell auch kaufen.
Shareware oder Freeware wird es fuer KDE wohl kaum geben da Qt gluecklicherweise unter GPL und LGPL lizensiert ist. Die ueber USD $1000 fuer eine Qt Professional Lizenz sind wohl fuer die meisten Sharewareautoren zu viel. Also keine Sharewareplage fuer KDE User!
...es gibt jetzt schon dt. Bücher zu Qt1.4x/KDE1.1.x die sich mit dem Programmieren beschäftigen. ZB. aus dem Franzis-Verlag (finde ich nicht so prickelnd) und ein gutes aus dem Addison-Wesley-Verlag.
Kann es sein, daß bei denen die hier am lautesten jammern kein wirkliches Interesse am Programmieren besteht? ...sonst wären die Bücher bestimmt bekannt! Um KDE-Proggies zu erstellen muß man C++ können. Fangt damit an... es gibt gute dt. Bücher. ...bis die Durchgearbeitet sind, ist ein dt. KDE2-programmierBuch erschienen....
Wer etwas über die zur Zeit erhältlichen deutschsprachige Bücher zur KDE/Qt-Programmierung erfahren möchte: ich habe ein paar Rezensionen zusammengetragen unter
http://members.tripod.de/dcmonline/linux.html
... btw: gerade das Buch aus dem Franzis-Verlag von Uwe Thiem finde ich ganz hervorragend. Ich finde, das liest sich flüssig und zeigt sehr schnell, wie man einen Einstieg findet ...
Von Frank Arnold am Fr, 3. November 2000 um 00:25 #
Kdevelop ist durchaus nicht die schlechteste IDE, allerdings ist der wahnsinnige Drang zu verspüren ein zweites VisualC++ nach Linux bringen zu wollen.
So schön das für einige Windows-Fanatiker auch sein mag, es zeugt nicht gerade von besonderem Ideenreichtum. Es wäre schön wenn irgendwann die Entwickler mit dem alten Zopf VisualC brechen würden und eine bessere IDE von Grundauf designen würden. Als wirklich positives Beispiel möchte ich nur einmal den DDD "Data Display Debugger" (auch aus Deutschen Landen) hervorheben. Es gibt nichts vergleichbares (zudem OpenSource) auf der Windows-Plattform.
Versteht das nicht falsch, ich findes es toll was die Leute quasi in ihrer Freizeit auf die Beine stellen! Mir fehlt es manchmal nur an etwas mehr "Idealismus", nach dem Motto "...so würde ich mir eine perfekte IDE vorstellen...", anstatt "...wie kriegen wir das genauso wie bei XYZ hin..."
Ich kenne Visual C++ kein bisschen und muss sagen, dass mir KDevelop gefällt, auch wenn ich es nicht benutze. Man muss nicht immer um jeden Preis anders sein, als die anderen.
Von Frank Arnold am Fr, 3. November 2000 um 00:25 #
Kdevelop ist durchaus nicht die schlechteste IDE, allerdings ist der wahnsinnige Drang zu verspüren ein zweites VisualC++ nach Linux bringen zu wollen.
So schön das für einige Windows-Fanatiker auch sein mag, es zeugt nicht gerade von besonderem Ideenreichtum. Es wäre schön wenn irgendwann die Entwickler mit dem alten Zopf VisualC brechen würden und eine bessere IDE von Grundauf designen würden. Als wirklich positives Beispiel möchte ich nur einmal den DDD "Data Display Debugger" (auch aus Deutschen Landen) hervorheben. Es gibt nichts vergleichbares (zudem OpenSource) auf der Windows-Plattform.
Versteht das nicht falsch, ich findes es toll was die Leute quasi in ihrer Freizeit auf die Beine stellen! Mir fehlt es manchmal nur an etwas mehr "Idealismus", nach dem Motto "...so würde ich mir eine perfekte IDE vorstellen...", anstatt "...wie kriegen wir das genauso wie bei XYZ hin..."
Ich stimme Dir vollkommen zu, daß Visual C++ nicht der Weisheit letzter Schluß an IDE ist (viel zu unübersichtlich etc.). Programmiere auch deshalb nicht mit Kdevelop, sondern mit Xemacs.
Nur, was Du am DDD so toll findest, bleibt mir verborgen. Ich finde das ein furchtbar unübersichtliches Teil, das alles mögliche nicht anzeigt (Dereferenzierte Iteratoren) und bei dem ich, wenn ich drei verschaltete Zeiger anzeigen will, einen 25"-Bildschirm brauche.
Von Frank Arnold am Fr, 3. November 2000 um 10:53 #
Ich finde die Idee am DDD sehr innovativ, Debugsymbole in einer art grafischem Flussdiagramm darzustellen (zu können). Sicherlich bekommt man Probleme bei Zeigerlisten, aber mal ganz ehrlich - wer will sich denn einen Binärbaum oder eine doppelt verkettete Liste mit allen Nodes + den Datenpointern auf einmal ansehen?
Das Problem bei allen neuen Sachen ist, daß sie nicht zu verschieden vom bisherigen sein dürfen.
Beispiel Programmiersprachen: Scheme ist weder OO noch prozedural und kaum einer benutzt es. In C++ dagegen kann man prozedural anfangen und wenn man mehr kennt irgendwann auf OO erweitern. Langsam und Schritt für Schritt. Stroustrup hat das absichtlich so gemacht; er wollte nicht die 1000ste akademische Sprache entwerfen die zwar viel Lob erntet, aber in realen Projekten kaum benutzt wird.
Der DDD gefällt mir persönlich auch nicht (Geschacksache). Und ja, ich will den Baum als ganzes sehen. Ich hab' mir sogar extra eine Routine geschrieben, mit der ich den gesamten Baum per ASCII-Grafik in's Logfile zeichnen kann (meine Bäume haben selten mehr als 20 Knoten). Die Listen geb' ich sowieso alle aus.
Das Konzept ist ja auch nicht so verkehrt, aber ich arbeite gerade in einem Projekt mit einem Entscheidungsbaum aus mehreren hunderttausend Knoten, die aber alle über mehrere Ebenen hinweg aus einer Basisklasse abgeleitet sind. Dieser Baum wird komplett rekursiv aufgebaut. Glaube mir, da mit DDD zu debuggen, ist die Hölle!
Nun meckert doch nicht so viel ! KDevelop ist ein geniales open source Produkt ! Könnt Ihr Euch eigentlich vorstellen, was für ein Aufwandt da drin steckt ? Ich bin froh, daß es sowas gibt - egal ob MV++ angelehnt oder nicht.
ich bin ja auch dafür, dass kdevelop eine wirklich gute sache ist. kommentare von anonymous (siehe oben) kann ich leider nicht verstehen. wenn man nicht so gut technisches englisch kann: heißt das dann, das man dann nur shareware programmiert??? kläart mich doch mal bitte auf.
> wenn man nicht so gut technisches englisch kann: > heißt das dann, das man dann nur shareware > programmiert???
Diese Schlussfolgerung ist sicher Unfug.
Allerdings ist es schon sehr hilfreich, technische Dokumente mit Verständnis lesen zu können. Ansonsten kannst Du weder mit RFCs, W3C-Recommendations, ... etwas anfangen. Das bedeutet, dass Du immer auf im Zweifel ver- altete Sekundärliteratur angewiesen bist, sofern sie überhaupt existiert.
Und ganz ehrlich: Entwicklung im OpenSource- Umfeld ist eine internationale Angelegenheit und Dokumente, die sich an Entwickler richten werden selten übersetzt. Wenn mich nicht alles täuscht, sind die letzten Änderungen an den man-pages-de (zumindest auf dem offiziellen Server) schon vor sehr langer Zeit gemacht worden. Oder wie viele Info-Pages gibt es schon auf deutsch?
Es ist ja schon erfreulich, dass es zumindest im GNOME- und KDE- Umfeld Übersetzungen der Anwenderdokus gibt - aber für Entwickler...
ich vermute er meint, dass wer kein englisch spricht eher dazu neigt seinen sourcecode verschlossen zu halten, weil ihn ja eh kaum einer verstehen würde. ausserdem ist es schwierig in einer internationalen community zu arbeiten, wenn man sich mit den anderen nicht gut verständigen kann...
Von Frank Arnold am Fr, 3. November 2000 um 17:10 #
Dann freuen wir uns jetzt alle von dir zu erfahren, wie man heute gutes Software-Engeneering betreibt, ohne für die Implementierung auf objektorientierte Sprachen wie C++ zurückzugreifen:
Dazu möchte ich sagen das mit Freepascal ein OO Pascal zur verfügung steht . Ebenso ist VB scheise aber OO(sollte es zumindest , oder?).Die reihe würde also in sachen nicht OO nicht stimmen. Auch mit Phyton kann man "große" Programme schreiben. Wie definiert ihr eigentlich größe ? Zeilenzahl , Programmiererzahl , Komplexität?
> Was könnte er meinen ? Wahrscheinlich hackt er jetzt in JAVA.
> Wie definiert ihr eigentlich größe ? Zeilenzahl, Programmierzahl, Komplexität? Und wie definierst Du Komplexität? Wer z. B. keine Ahnung von Mathe hat, wird sicherlich bei einen CAD-Proggie verzweifeln, dafür in anderen Bereichen nicht unbedingt schlecht sein. Groß ist für alle Progs > 100k LOC (wenn sie nicht aus 99999 '//' bestehen ;)
>> Was könnte er meinen ? > hackt er jetzt in JAVA.
Ja richtig, wenn man sich als Software-Engineering-Experte outet und meint, man können mit C++ keine großen Projekte schreiben, dann ist der Übergang zu Java ja wenigstens konsequent. Weil die größten Projekte ja immer in Java, gleich nach VB geschrieben sind.
Von Christoph Hellwig am So, 5. November 2000 um 11:40 #
> Dann freuen wir uns jetzt alle von dir zu > erfahren, wie man heute gutes > Software-Engeneering betreibt, ohne für die > Implementierung auf objektorientierte > Sprachen wie C++ zurückzugreifen:
Hmm. Ein großteil der Wirklich hochwertigen Software wird auch heute noch in C geschrieben ...
Und was Objektorientierung angeht: Man kann auch in C durchaus OO schreiben. (Schau dir einfach mal Linux an: die ersten Objekte werden die ziemlich bal begegnen).
> Ein großteil der .... in C geschrieben. Jetzt kommt der Spruch: Ein großteil der Lohnabrechnungen sind immer noch in COBOL geschrieben und laufen seit 30 Jahren blah blah blah etc. etc. pp.
Die Sprache 'C' ist jedenfalls auf dem 'absteigenden Ast': Vgl. hierzu z. B. iX November/2000 S. 12.
> Man kann auch in C durchaus OO schreiben. Sabalott! I tell you news: Mensch kann auch in ASSEMBLER dem OO-Paradigma folgen. Echt, ohne Schmarrn!
So what?
Nur weil bestimmte Dinge technisch möglich sind, sollte sie noch lange nicht verwirklicht werden ...
Von Christoph Hellwig am So, 5. November 2000 um 17:45 #
Du weist schon, was ich mit guter Software meinte.
Und in C kann man eigentlich sehr gut bestimmte OO-Paradigmen (hauptseachlich abstrakte basisklassen) benutzen. Diese eine die ich genannt habe is sogar die basis des ganzen UNIX/Linux kernel konzepts.
Und dass ich nicht alles in C schreiben will ist auch klar. Aber dort wo Performance wichtig ist, ist C immer noch erste Wahl.
OO in assembler halte ich für schwierig, da einige der Grundabstraktionen fehlen. Aber ich bin offen es von dir eklaert zu kriegen (mov $(SYMBOL_NAME(classX) eax, so dass ist jetzt das Objekt ...)
Die Erklärung ist trivial: Da praktisch alle Hochsprachen letztendlich in Maschinencode enden und für fast alle Maschinensprachen entsprechende Assemblersprachen gibt und daher in guter Näherung als äquivalent angesehen werden können, wird es für Deinen OO-Code in C/C++/whatever einen äquivalenten Code in asm geben. (ich sage nichts darüber aus, wie 'praktizierbar' dies ist) Die Umkehrung gilt nicht: In ASM sind Dinge möglich, die in Hochsprachen so nicht möglich sind.
Mosh
PS handcodierte asm schlägt C allemal und dass FORTRAN C bei nat-wiss. Berechnungen überlegen ist, haben wir hier schon des öfteren erläutert.
Von Christoph Hellwig am So, 5. November 2000 um 18:47 #
> Da praktisch alle Hochsprachen letztendlich > in Maschinencode enden und für fast alle > Maschinensprachen entsprechende > Assemblersprachen gibt und daher in guter > Näherung als äquivalent angesehen werden > können, wird es für Deinen OO-Code in > C/C++/whatever einen äquivalenten Code in > asm geben.
Nein. Der Code ist dann nichtmehr OO. OO ist (wie fast jedes Element von Hochsprachen) einfach eine Abstraktion, die beim uebersetzen in niedrigere Ebenen (asm, binaercode) verloren geht.
> Die Umkehrung gilt nicht: > In ASM sind Dinge möglich, die in > Hochsprachen so nicht möglich sind.
Ja. (auch wenn ich jetzt den Zusammenhang nicht ganz sehe).
Von Frank Arnold am Mo, 6. November 2000 um 00:24 #
@Christoph Hellwig Seit wann kann man in C abstrakte Basisklassen erzeugen? Vtables gibt es erst in C++. Polyphormismus ist in C nicht möglich. Kapselung und Abstraktion - Fehlanzeige! Sorry, aber C kann in keinem Punkt den OOP Richtlinien Rechnung tragen. Das wird eigentlich auch von keinem Software-Designer in Frage gestellt (übrigends auch ein Punkt warum es C++ überhaupt gibt)... Das Betriebssysteme wie Linux zum grössten Teil in C geschrieben werden hat andere Gründe. Einer sind die Einschränkungen im priviligierten Kernel-Mode, hier gibt es z.B. keine C-Laufzeitbibliothek...
Sei mir nicht böse, aber wenn mir jemand sowas beim Einstellungsgespräch erzählen würde... :-/
Von Christoph Hellwig am Mo, 6. November 2000 um 12:17 #
@Frank Arnold
> Seit wann kann man in C abstrakte > Basisklassen erzeugen?
Seit die structs eingeführt wurden - also seit ca 30 Jahren ...
> Vtables gibt es erst in C++.
Das formal Feature (und wieso erst seit C++ - Einige Sprachen hatten das schon 20 Jahre früher ...) ja. Aber du kannst exact das in C auch machen.
Schau dir einfach mal 'struct file_lock' in linux/fs.h an. Dort hast du eine Klasse, die einige Variablen hat, sowie drei virtuelle Methoden (Funktions-Pointer). Von dieser Art gibt es Unmengen im Linux Kernel - ich habe aber diese gewählt, weil sie anders als die meisten die methoden nicht in einer eigenen Subklasse hat.
> Polyphormismus ist in C nicht möglich.
Nö - na und. Das habe ich auch nicht behauptet ...
> Kapselung und Abstraktion - Fehlanzeige!
Ähmm. Klar kannst du das in C. Beispiel: die Benutzung der struct file_operations in Linux. Dahinter kann sich alles mögliche verbergen (datei, device, socket, pipe, ...)
> Sorry, aber C kann in keinem Punkt den OOP Richtlinien Rechnung tragen.
Auch Sorry, aber das habe ich nicht behauptet. Ich habe nicht behauptet, dass C eine OO-Sprache sei, und schon garnicht, dass es irgendwelchen Richtlinien genügt. Ich habe nur gesagt, dass man auch in C auf Objekt-Orientierte Weise programmieren kann.
> Das wird eigentlich auch von keinem Software-Designer
Was ist bitte ein Software-Designer?
> Das Betriebssysteme wie Linux zum grössten Teil in C geschrieben > werden hat andere Gründe.
Als was?
> Einer sind die Einschränkungen im priviligierten Kernel-Mode, > hier gibt es z.B. keine C-Laufzeitbibliothek...
Tolles Argument. Dann nehm halt ne libc in den Kernel, das geht recht problemlos (wir recht ähnlich bei Netware Praktiziert, das die nlm dort alle im Ring 0 laufen).
Die Problematik ist eigentlich das C++ Zu viele Nachteile hat, und die Vorteile im Kernel-Mode praktisch bicht brigen. Trotzdem gab es Kernel wie Chorus oder Fiasco, die in C++ geschrieben wurden. Sonderlich erfolgreIch sind sie aber nicht ... Und ja, es gib auch NT und Linux treiber in C++ (auch wenn letzere Bekämpft werden ...)
> Sei mir nicht böse, aber wenn mir jemand sowas beim > Einstellungsgespräch erzählen würde... :-/
Man gut, dass ich schon nen recht interresanten Job habe ;)
Von Frank Arnold am Mo, 6. November 2000 um 20:30 #
@Christoph Hellwig Du versuchst objektorientierte Merkmale von C++ auf C umzusetzen und sprichst von OOP-Merkmalen die es nicht in prozedurorientierten Sprachen gibt!? Ich kann Dich ja verstehen, das Du C besser als C++ findest (ich habe selbst einige Jahre gebraucht den Schritt zu C++ zu gehen), allerdings musst Du doch auch ehrlich eingestehen können das einiges (OOP)mit C schlecht geht. Was genau, kannst Du ja selber z.B. in "K&R, Programmieren in C" oder z.B. "Herglotz, C++ Einsteigerseminar" nachlesen. Dort findest Du auch die Antworten auf Deine Fragen über Laufzeitbindung, virtuelle Methoden und abstrakte Basisklassen bei objektorientierten Programmiersprachen (wie C++).
Von Christoph Hellwig am Mo, 6. November 2000 um 20:47 #
@Frank Arnold
> Du versuchst objektorientierte Merkmale von > C++ auf C umzusetzen und sprichst von > OOP-Merkmalen die es nicht in > prozedurorientierten Sprachen gibt!?
Ja. Bestimmte sachen kann man auch in C machen, bestimmte nicht.
> Ich kann Dich ja verstehen, das Du C besser > als C++ findest
Es geht nicht um mögen. Es geht darum, daß C++ in bestimmten bereichen (Kernel, etc ...) einfach fehl am Platze ist.
> allerdings musst Du doch auch ehrlich > eingestehen können das einiges (OOP)mit C > schlecht geht.
Ja, gerne ;)
Ich habe nichts von gut gesagt, und in C++ siehts bestimmt auch schöner aus ;)
> Deine Fragen
Meine Fragen? Ich habe keine Fragen gestellt, ich habe Aussagen gemacht und Beispiele gebracht.
Christoph
P.S. und ich habe durchaus schon einige Bücher über Programmiersprachen gelsen ...
Ich ärgere mich gerade mit 1.2 rum. Irgendwie kriege ich das mit dem Debuggen nicht gebacken. Ich arbeite mit QT und die erzeugten Makefiles sorgen auch für die -g3 Compileroption, aber scheinbar hat der entstehende Code keine Debugsymbole. Gibt es da eine Trick ?
Ach, ja, Ich hoffe dass der Debugger sich in 1.3 inegriert und dass im Debugger Codeänderungen möglich sind.
Von Bodo Schulz am So, 5. November 2000 um 07:59 #
@hjb nicht schlecht, aber dann müsste das programm auch da mal stehen bleiben! :-) Tut es bei mir jedenfalls nicht. Etwas anderes tut mir viel mehr weh, als der debugger ... ich hab nirgends in der doku einen hinweis gefunden, wie ich eine fremde library einbauen kann! Da will ich schon mal was für postgres-sql machen und muß meine Makefiles wieder selber schreiben, weil Kdevelop keine lib , die ich ihm mitgebe, akzepiert, oder nicht findet.
Das eigentliche Thema verfehlt aber englisch ist immer mein Thema. Für den normalen Anwender sollte alles in deutsch sein den Programmierer englisch ist schon fast ein englischer Dialekt. Wer programmiert sollte englisch können den Linux ist international. PS. Ich habe ein altes englisches Auto mit Manual, z.B. das Wort "fit" hat viele Bedeutungen.
Mal kurz ne Frage an die Profis unter euch: Weis jemand ob es 3270-Emulationen unter Linux gibt??????? Und wenn ja wie richte ich die ein? Wäre für ne Antwort dankbar...
keine richtig gute, hab schonmal drueber nachgedacht, die x3270 umzuschreiben,mir fehlt aber leider die zeit, vielleicht fang ich naechstes fruehjahr mal damit an.
vielleicht wären aber auch alle daran gut beraten, auch mal die software-dokumentation in andere sprachen zu übersetzen.
das würde vielen windows-verwöhnten hobby-programmieren ein wesentliches stück weiterhelfen.
mir geht es nun mal so, dass ich mit deutsch besser weiterkomme als mit englisch.
Finde es auch nicht richtig, nur weil es andere können, Englisch zu lernen und aufs programieren zu verzichten.
auf diese antwort habe ich gewartet.
Nun, du kannst gerne Dokumentation ins deutsche zu übersetzen. Bei Programmen von Windows-Hobbyprogrammierern, die nichtmal technische Dokumentation auf englisch *lesen* können, besteht die Gefahr, dass es sich um Shareware oder Freeware handeln wird. Das wiederum bedeutet, dass die Programme üblicherweise als i386-Binaries verfügbar sind, was z.B. Nutzern von GNU/Linux auf Macs nichts bringt.
Software sollte alleine aus praktischen Gründen schon frei sein, wobei ich darauf hinweisen möchte, dass ich nicht aus praktischen Gründen einzig und allein Freie Software einsetze.
ich lese aus deinem beitrag folgendes heraus: wer keine technische englische dokumentation lesen kann, soll nicht programmieren weil eh nichts für die allgemeinheit (zumindest für mac-user) brauchbares rauskommt. das ist falsch. du gehst sogar weiter und bezeichnest das als gefahr. eine grobe fehleinschätzung. du verweigerst aus egoistischen motiven einer minderheit (ist nunmal so, nichts für ungut ingo und udo) die möglichkeit für die community etwas brauchbares zu erstellen. ein anderer punkt ist die dokumentation. übersetzung ist arbeit und dafür muss sich jemand finden. ich bin kein guter übersetzer und versuche mich an etwas anderem (newbierouter.de). das ist mein beitrag den ich geleistet habe und es hat schon dem einen oder anderen geholfen. wenn also udo und ingo als hobbyprogrammierer etwas sinniges herstellen wollen sollte man ihnen nichts grundsätzlich verweigern. ich hoffe es findet sich jemand der für die beiden übersetzt.
karsten
Naja, ich hatte es eigentlich so gemeint, dass wir keine Share- und Freeware gebrauchen, weil sie nicht frei ist und üblicherweise daher diverse *Minderheiten* (wenn du schon anfängst davon zu reden, bin ich gerne bereit auch auf die gleiche Weise zu argumentieren) wie Leute, die GNU/Linux auf PPC, m86k, etc. einsetzen, es noch schwieriger haben als es jetzt schon der Fall ist.
Wenn Autoren ihre Programme unter eine freie Lizenz stellen, ist es vollkommen egal, ob sie englisch können oder nicht (wobei natürlich englische Kommentare im Code vorzuziehen wären...).
In der Windowswelt ist Free- und Shareware nunmal verbreitet und immer wenn unfreie Software programmiert wird, ist das schlecht für die OpenSource-Bewegung und natürlich erst Recht für die Free Software-Bewegung.
Wenn jemandem das Übersetzen nicht liegt, macht ja nichts. Ich finde es super, dass du dich überhaupt engagierst, das machen ja leider nur wenige.
dies soll bitte nicht als Kritik, sondern als Anregung verstanden werden. Ich weiß sehr gut, daß die meiste Dokumentation nur in englisch verfügbar ist, allerdings gibt es schon recht viele deutsche Übersetzungen sowohl bei KDE als auch z.B. beim deutschen Manpage Projekt. Und genug deutsche Bücher übers Programmieren gibt's auch.
Wer jetzt trotzdem noch nicht genug Lesematerial zusammenbekommt, um damit als Programmierer loslegen zu können, der sollte sich wirklich ernsthaft fragen, ob er/sie nicht erst mal anstelle der Programmierkenntnisse die Englischkenntnisse auffrischen sollte. Denn es ist nun mal so: in unser heutigen Berufswelt ist - zumindest in den technischen Berufen - englisch eine zwingende Voraussetzung. Ihr solltet also nicht an der fehlenden deutschen Dokumentation kritisieren, sondern dies als Anlaß nehmen, mal vernünftig Englisch zu lernen. Ich habe vor Jahren auch so angefangen, mit den Amiga Developer Manuals. Anfangs ist es immer schwierig, aber mit der Zeit wird's schon!
wer wirklich software erstellen will die für die allgemeinheit von nutzen ist muss eh englisch lernen.
allerdings kann man auch sagen, dass ich deutsche dokumentation meistens trotzdem lieber lese, weil ich bei englischen dokumentationen teilweise doch noch raten muss, was dies und das bedeuten soll (einzelne wörter) oder halt nachschlagen.
ausserdem fällt es mir im deutschen weitaus leichter gewissen spitzfindigkeiten und humoristische zeilen zu erkennen :)
dann aber wiederum denke ich mir, dass man die arbeitszeit doch lieber in neue gute dokumentation stecken sollte als in übersetzungen. aber wenn jemand gerne übersetzt kann er so auch einen guten beitrag leisten. z.b. freue ich mich schon auf die deutsche übersetzung des kde buches, das werde ich mir dann eventuell auch kaufen.
...es gibt jetzt schon dt. Bücher zu Qt1.4x/KDE1.1.x die sich mit dem Programmieren beschäftigen. ZB. aus dem Franzis-Verlag (finde ich nicht so prickelnd) und ein gutes aus dem Addison-Wesley-Verlag.
Kann es sein, daß bei denen die hier am lautesten jammern kein wirkliches Interesse am Programmieren besteht? ...sonst wären die Bücher bestimmt bekannt!
Um KDE-Proggies zu erstellen muß man C++ können. Fangt damit an... es gibt gute dt. Bücher. ...bis die Durchgearbeitet sind, ist ein dt. KDE2-programmierBuch erschienen....
http://members.tripod.de/dcmonline/linux.html
... btw: gerade das Buch aus dem Franzis-Verlag von Uwe Thiem finde ich ganz hervorragend. Ich finde, das liest sich flüssig und zeigt sehr schnell, wie man einen Einstieg findet ...
Gruß, Daniel
So schön das für einige Windows-Fanatiker auch sein mag, es zeugt nicht gerade von besonderem Ideenreichtum.
Es wäre schön wenn irgendwann die Entwickler mit dem alten Zopf VisualC brechen würden und eine bessere IDE von Grundauf designen würden.
Als wirklich positives Beispiel möchte ich nur einmal den DDD "Data Display Debugger" (auch aus Deutschen Landen) hervorheben. Es gibt nichts vergleichbares (zudem OpenSource) auf der Windows-Plattform.
Versteht das nicht falsch, ich findes es toll was die Leute quasi in ihrer Freizeit auf die Beine stellen! Mir fehlt es manchmal nur an etwas mehr "Idealismus", nach dem Motto "...so würde ich mir eine perfekte IDE vorstellen...", anstatt "...wie kriegen wir das genauso wie bei XYZ hin..."
So schön das für einige Windows-Fanatiker auch sein mag, es zeugt nicht gerade von besonderem Ideenreichtum.
Es wäre schön wenn irgendwann die Entwickler mit dem alten Zopf VisualC brechen würden und eine bessere IDE von Grundauf designen würden.
Als wirklich positives Beispiel möchte ich nur einmal den DDD "Data Display Debugger" (auch aus Deutschen Landen) hervorheben. Es gibt nichts vergleichbares (zudem OpenSource) auf der Windows-Plattform.
Versteht das nicht falsch, ich findes es toll was die Leute quasi in ihrer Freizeit auf die Beine stellen! Mir fehlt es manchmal nur an etwas mehr "Idealismus", nach dem Motto "...so würde ich mir eine perfekte IDE vorstellen...", anstatt "...wie kriegen wir das genauso wie bei XYZ hin..."
Nur, was Du am DDD so toll findest, bleibt mir verborgen. Ich finde das ein furchtbar unübersichtliches Teil, das alles mögliche nicht anzeigt (Dereferenzierte Iteratoren) und bei dem ich, wenn ich drei verschaltete Zeiger anzeigen will, einen 25"-Bildschirm brauche.
Gruß
Christoph
Sicherlich bekommt man Probleme bei Zeigerlisten, aber mal ganz ehrlich - wer will sich denn einen Binärbaum oder eine doppelt verkettete Liste mit allen Nodes + den Datenpointern auf einmal ansehen?
Beispiel Programmiersprachen:
Scheme ist weder OO noch prozedural und kaum einer benutzt es.
In C++ dagegen kann man prozedural anfangen und wenn man mehr kennt irgendwann auf OO erweitern. Langsam und Schritt für Schritt.
Stroustrup hat das absichtlich so gemacht; er wollte nicht die 1000ste akademische Sprache entwerfen die zwar viel Lob erntet, aber in realen Projekten kaum benutzt wird.
Der DDD gefällt mir persönlich auch nicht (Geschacksache). Und ja, ich will den Baum als ganzes sehen. Ich hab' mir sogar extra eine Routine geschrieben, mit der ich den gesamten Baum per ASCII-Grafik in's Logfile zeichnen kann (meine Bäume haben selten mehr als 20 Knoten).
Die Listen geb' ich sowieso alle aus.
Das Konzept ist ja auch nicht so verkehrt, aber ich arbeite gerade in einem Projekt mit einem Entscheidungsbaum aus mehreren hunderttausend Knoten, die aber alle über mehrere Ebenen hinweg aus einer Basisklasse abgeleitet sind. Dieser Baum wird komplett rekursiv aufgebaut. Glaube mir, da mit DDD zu debuggen, ist die Hölle!
Christoph
KDevelop ist ein geniales open source Produkt !
Könnt Ihr Euch eigentlich vorstellen, was für ein Aufwandt da drin steckt ? Ich bin froh, daß es sowas gibt - egal ob MV++ angelehnt oder nicht.
ciao
Erdie
Ein KDevelop Nutzer
kommentare von anonymous (siehe oben) kann ich leider nicht verstehen.
wenn man nicht so gut technisches englisch kann: heißt das dann, das man dann nur shareware programmiert??? kläart mich doch mal bitte auf.
> heißt das dann, das man dann nur shareware
> programmiert???
Diese Schlussfolgerung ist sicher Unfug.
Allerdings ist es schon sehr hilfreich,
technische Dokumente mit Verständnis lesen
zu können. Ansonsten kannst Du weder mit RFCs,
W3C-Recommendations, ... etwas anfangen. Das
bedeutet, dass Du immer auf im Zweifel ver-
altete Sekundärliteratur angewiesen bist,
sofern sie überhaupt existiert.
Und ganz ehrlich: Entwicklung im OpenSource-
Umfeld ist eine internationale Angelegenheit
und Dokumente, die sich an Entwickler richten
werden selten übersetzt. Wenn mich nicht
alles täuscht, sind die letzten Änderungen
an den man-pages-de (zumindest auf dem
offiziellen Server) schon vor sehr langer
Zeit gemacht worden. Oder wie viele Info-Pages
gibt es schon auf deutsch?
Es ist ja schon erfreulich, dass es zumindest
im GNOME- und KDE- Umfeld Übersetzungen der
Anwenderdokus gibt - aber für Entwickler...
ausserdem ist es schwierig in einer internationalen community zu arbeiten, wenn man sich mit den anderen nicht gut verständigen kann...
C++ Scheisse zugeschnitten ist.
Und wer damit grosse Programme schreibt
hat sowieso kaum was von gutem Software Engineering verstanden.
Auch mit Phyton kann man "große" Programme schreiben.
Wie definiert ihr eigentlich größe ? Zeilenzahl , Programmiererzahl , Komplexität?
Wahrscheinlich hackt er jetzt in JAVA.
> Wie definiert ihr eigentlich größe ? Zeilenzahl, Programmierzahl, Komplexität?
Und wie definierst Du Komplexität?
Wer z. B. keine Ahnung von Mathe hat, wird sicherlich bei einen CAD-Proggie verzweifeln,
dafür in anderen Bereichen nicht unbedingt schlecht sein.
Groß ist für alle Progs > 100k LOC
(wenn sie nicht aus 99999 '//' bestehen ;)
Mosh
> hackt er jetzt in JAVA.
Ja richtig, wenn man sich als Software-Engineering-Experte outet und meint, man können mit C++ keine großen Projekte schreiben, dann ist der Übergang zu Java ja wenigstens konsequent. Weil die größten Projekte ja immer in Java, gleich nach VB geschrieben sind.
> erfahren, wie man heute gutes
> Software-Engeneering betreibt, ohne für die
> Implementierung auf objektorientierte
> Sprachen wie C++ zurückzugreifen:
Hmm. Ein großteil der Wirklich hochwertigen Software wird auch heute noch in C geschrieben ...
Und was Objektorientierung angeht: Man kann auch in C durchaus OO schreiben. (Schau dir einfach mal Linux an: die ersten Objekte werden die ziemlich bal begegnen).
Christoph
Jetzt kommt der Spruch:
Ein großteil der Lohnabrechnungen sind immer noch in COBOL geschrieben und laufen seit 30 Jahren blah blah blah etc. etc. pp.
Die Sprache 'C' ist jedenfalls auf dem 'absteigenden Ast':
Vgl. hierzu z. B. iX November/2000 S. 12.
> Man kann auch in C durchaus OO schreiben.
Sabalott!
I tell you news:
Mensch kann auch in ASSEMBLER dem OO-Paradigma folgen.
Echt, ohne Schmarrn!
So what?
Nur weil bestimmte Dinge technisch möglich sind, sollte sie noch lange nicht verwirklicht werden ...
Mosh
Und in C kann man eigentlich sehr gut bestimmte OO-Paradigmen (hauptseachlich abstrakte basisklassen) benutzen. Diese eine die ich genannt habe is sogar die basis des ganzen UNIX/Linux kernel konzepts.
Und dass ich nicht alles in C schreiben will ist auch klar. Aber dort wo Performance wichtig ist, ist C immer noch erste Wahl.
OO in assembler halte ich für schwierig, da einige der Grundabstraktionen fehlen. Aber ich bin offen es von dir eklaert zu kriegen
(mov $(SYMBOL_NAME(classX) eax, so dass ist jetzt das Objekt ...)
Christoph
Da praktisch alle Hochsprachen letztendlich in Maschinencode enden und für fast alle Maschinensprachen entsprechende Assemblersprachen gibt und daher in guter Näherung als äquivalent angesehen werden können,
wird es für Deinen OO-Code in C/C++/whatever einen äquivalenten Code in asm geben.
(ich sage nichts darüber aus, wie 'praktizierbar' dies ist)
Die Umkehrung gilt nicht:
In ASM sind Dinge möglich, die in Hochsprachen so nicht möglich sind.
Mosh
PS
handcodierte asm schlägt C allemal und dass
FORTRAN C bei nat-wiss. Berechnungen überlegen ist, haben wir hier schon des öfteren erläutert.
> in Maschinencode enden und für fast alle
> Maschinensprachen entsprechende
> Assemblersprachen gibt und daher in guter
> Näherung als äquivalent angesehen werden
> können, wird es für Deinen OO-Code in
> C/C++/whatever einen äquivalenten Code in
> asm geben.
Nein. Der Code ist dann nichtmehr OO. OO ist (wie fast jedes Element von Hochsprachen) einfach eine Abstraktion, die beim uebersetzen in niedrigere Ebenen (asm, binaercode) verloren geht.
> Die Umkehrung gilt nicht:
> In ASM sind Dinge möglich, die in
> Hochsprachen so nicht möglich sind.
Ja. (auch wenn ich jetzt den Zusammenhang nicht ganz sehe).
Christoph
Seit wann kann man in C abstrakte Basisklassen erzeugen?
Vtables gibt es erst in C++. Polyphormismus ist in C nicht möglich. Kapselung und Abstraktion - Fehlanzeige! Sorry, aber C kann in keinem Punkt den OOP Richtlinien Rechnung tragen. Das wird eigentlich auch von keinem Software-Designer in Frage gestellt (übrigends auch ein Punkt warum es C++ überhaupt gibt)...
Das Betriebssysteme wie Linux zum grössten Teil in C geschrieben werden hat andere Gründe. Einer sind die Einschränkungen im priviligierten Kernel-Mode, hier gibt es z.B. keine C-Laufzeitbibliothek...
Sei mir nicht böse, aber wenn mir jemand sowas beim Einstellungsgespräch erzählen würde... :-/
> Seit wann kann man in C abstrakte
> Basisklassen erzeugen?
Seit die structs eingeführt wurden - also seit ca 30 Jahren ...
> Vtables gibt es erst in C++.
Das formal Feature (und wieso erst seit C++ - Einige Sprachen hatten
das schon 20 Jahre früher ...) ja. Aber du kannst exact das in C auch machen.
Schau dir einfach mal 'struct file_lock' in linux/fs.h an.
Dort hast du eine Klasse, die einige Variablen hat, sowie drei
virtuelle Methoden (Funktions-Pointer). Von dieser Art gibt es
Unmengen im Linux Kernel - ich habe aber diese gewählt, weil sie
anders als die meisten die methoden nicht in einer eigenen
Subklasse hat.
> Polyphormismus ist in C nicht möglich.
Nö - na und. Das habe ich auch nicht behauptet ...
> Kapselung und Abstraktion - Fehlanzeige!
Ähmm. Klar kannst du das in C. Beispiel: die Benutzung der
struct file_operations in Linux. Dahinter kann sich alles mögliche
verbergen (datei, device, socket, pipe, ...)
> Sorry, aber C kann in keinem Punkt den OOP Richtlinien Rechnung tragen.
Auch Sorry, aber das habe ich nicht behauptet. Ich habe nicht behauptet,
dass C eine OO-Sprache sei, und schon garnicht, dass es irgendwelchen
Richtlinien genügt.
Ich habe nur gesagt, dass man auch in C auf Objekt-Orientierte Weise
programmieren kann.
> Das wird eigentlich auch von keinem Software-Designer
Was ist bitte ein Software-Designer?
> Das Betriebssysteme wie Linux zum grössten Teil in C geschrieben
> werden hat andere Gründe.
Als was?
> Einer sind die Einschränkungen im priviligierten Kernel-Mode,
> hier gibt es z.B. keine C-Laufzeitbibliothek...
Tolles Argument. Dann nehm halt ne libc in den Kernel,
das geht recht problemlos (wir recht ähnlich bei Netware Praktiziert,
das die nlm dort alle im Ring 0 laufen).
Die Problematik ist eigentlich das C++ Zu viele Nachteile hat, und
die Vorteile im Kernel-Mode praktisch bicht brigen. Trotzdem
gab es Kernel wie Chorus oder Fiasco, die in C++ geschrieben wurden.
Sonderlich erfolgreIch sind sie aber nicht ...
Und ja, es gib auch NT und Linux treiber in C++ (auch wenn letzere
Bekämpft werden ...)
> Sei mir nicht böse, aber wenn mir jemand sowas beim
> Einstellungsgespräch erzählen würde... :-/
Man gut, dass ich schon nen recht interresanten Job habe ;)
Christoph
Du versuchst objektorientierte Merkmale von C++ auf C umzusetzen und sprichst von OOP-Merkmalen die es nicht in prozedurorientierten Sprachen gibt!?
Ich kann Dich ja verstehen, das Du C besser als C++ findest (ich habe selbst einige Jahre gebraucht den Schritt zu C++ zu gehen), allerdings musst Du doch auch ehrlich eingestehen können das einiges (OOP)mit C schlecht geht. Was genau, kannst Du ja selber z.B. in "K&R, Programmieren in C" oder z.B. "Herglotz, C++ Einsteigerseminar" nachlesen.
Dort findest Du auch die Antworten auf Deine Fragen über Laufzeitbindung, virtuelle Methoden und abstrakte Basisklassen bei objektorientierten Programmiersprachen (wie C++).
> Du versuchst objektorientierte Merkmale von
> C++ auf C umzusetzen und sprichst von
> OOP-Merkmalen die es nicht in
> prozedurorientierten Sprachen gibt!?
Ja. Bestimmte sachen kann man auch in C machen, bestimmte nicht.
> Ich kann Dich ja verstehen, das Du C besser
> als C++ findest
Es geht nicht um mögen. Es geht darum, daß C++ in bestimmten bereichen (Kernel, etc ...) einfach fehl am Platze ist.
> allerdings musst Du doch auch ehrlich
> eingestehen können das einiges (OOP)mit C
> schlecht geht.
Ja, gerne ;)
Ich habe nichts von gut gesagt, und in C++ siehts bestimmt auch schöner aus ;)
> Deine Fragen
Meine Fragen? Ich habe keine Fragen gestellt, ich habe Aussagen gemacht und Beispiele gebracht.
Christoph
P.S. und ich habe durchaus schon einige Bücher über Programmiersprachen gelsen ...
Genausowenig wie Scheme rein funktional.
Nebenbei erwähnt,
Christoph Hellwig hopsert bei CALDERA rum
(für die, die es noch nicht gewusst haben)
Aber dass soll nichts heissen ;)
Mosh
....zwanzigster :o)
die erzeugten Makefiles sorgen auch für die -g3 Compileroption, aber scheinbar hat der entstehende Code keine Debugsymbole.
Gibt es da eine Trick ?
Ach, ja, Ich hoffe dass der Debugger sich in 1.3 inegriert und dass im Debugger Codeänderungen möglich sind.
Servus, jochen
nicht schlecht, aber dann müsste das programm auch da mal stehen bleiben! :-)
Tut es bei mir jedenfalls nicht.
Etwas anderes tut mir viel mehr weh, als der debugger ...
ich hab nirgends in der doku einen hinweis gefunden, wie ich eine fremde library einbauen kann!
Da will ich schon mal was für postgres-sql machen und muß meine Makefiles wieder selber schreiben, weil Kdevelop keine lib , die ich ihm mitgebe, akzepiert, oder nicht findet.
in diesem sinne ... quält die debugger!
Bodo
Für den normalen Anwender sollte alles in deutsch sein den Programmierer englisch ist schon fast ein englischer Dialekt.
Wer programmiert sollte englisch können den Linux ist international.
PS. Ich habe ein altes englisches Auto mit Manual, z.B. das Wort "fit" hat viele Bedeutungen.
Gruß Newbie :-)
isi