Mit Tachyonen und Gold-Chip gegen Handystrahlen...

[Gerhard Hoffmann]

On Sun, 04 Jan 2009 20:35:18 +0100, "Horst-D.Winzler" <horst.d.winzler@web.de> wrote:

Hast du eine Quelle? Obwohl, die Sprüche sind sowas von treffend, das es
eigentlich egal ist, von wem sie letztendlich stammen ;-)

Mein TET-Prof. in einer Vorlesung. Ist aber schon ziemlich lange her.


Der Spruch, nichts komplizierter zu machen als unbedingt nötig
wird auch immer wieder Einstein zugeschrieben.

War aber als "Occam's razor" bekannt.
"Entia non sunt complicanda praeter neccesitatem"
(William of Ockham, irgendwann im Mittelalter)

Gruß, Gerhard

 

[Horst-D.Winzler]

Gerhard Hoffmann schrieb:

On Sun, 04 Jan 2009 20:35:18 +0100, "Horst-D.Winzler" <horst.d.winzler@web.de> wrote:


Hast du eine Quelle? Obwohl, die Sprüche sind sowas von treffend, das es
eigentlich egal ist, von wem sie letztendlich stammen ;-)

Mein TET-Prof. in einer Vorlesung. Ist aber schon ziemlich lange her.


Der Spruch, nichts komplizierter zu machen als unbedingt nötig
wird auch immer wieder Einstein zugeschrieben.

War aber als "Occam's razor" bekannt.
"Entia non sunt complicanda praeter neccesitatem"
(William of Ockham, irgendwann im Mittelalter)

Gruß, Gerhard

Der Mann hatte ein bewegtes Leben. Langweilig war das sicher nicht ;-)

Keep it simple.

http://www.wotug.org/parallel/www/occam/occam-bio.


Hier ist es sehr ausfühlich behandelt.

http://de.wikipedia.org/wiki/Wilhelm_von_Ockham

Ob noch jemand ein Zitat findet, das noch älter ist? ;-)
--
mfg hdw

 

[Stefan Reuther]

Falk Willberg wrote:

Gerrit Heitsch schrieb:
Genau sowas gehoert in den Kommentar im Source, nirgendwo anders.

Und das bitte in einer Sprache, für die es Wörterbücher im WEB gibt.

Aus gegebenem Anlaß[0]: Kennt jemand ein solches für Finnisch?

http://kaannos.com/

Viel interessanter ist Wortstammanalyse für finnisch, die haben ja
schlappe 15 Fälle, mit denen sie auch noch Bedeutung ausdrücken Aber
auch das gibt's im Netz.

http://www2.lingsoft.fi/cgi-bin/fintwol

/* Alustetaan PIO SPI:n tarvitsemiin tiloihin */

Alustetaan = "alustaa" V PRES PSS PE4 = initialize
tarvitsemiin = "tarvita" DV-MA ILL PL = required
tiloihin = "tila" N ILL PL = state, mode

Mit Grammatik auffüllen (ILL = Illativ => 'into', PL = Plural), fertig:
"Initialize PIO SPI into required modes".


Stefan (nein, kann kein Finnisch, hat aber mal ein finnisches
Sprachansagesystem gebastelt

 

[Stefan Reuther]

Dirk Ruth wrote:

Stefan Reutherschrieb:
Dirk Ruth wrote:
ASCII-Art ist eher ein workaround für dieses Problem. Ein so
eingefügtes Diagramm oder Grafik will hinterher keiner mehr ändern,
wenn man nicht irgendwo die originalen Quellen dafür hinterlegt hat.

Wieso "originale Quellen"? ASCII-Art ist Klartext und kann mit jedem
Editor geändert werden. Sogar Word. Bequemer ist natürlich
http://www.jave.de/>. Der akzeptiert natürlich auch Cut&Paste von Word.

Missverständnis.
Wenn du in Excel eine Messreihe und daraus ein Diagramm erstellt hast,
dass dann wieder als Bild abgespeichert und in ASCII umgewandelt wird,
dann mußt du das Excel-Original nochmal irgendwo hinterlegen. Ändern
sich da mal ein paar Werte, muss die Grafik und das ASCII neu erzeugt
werden, weil du das mit den Punkten und Strichen usw. händisch nicht
so hinbekommst, wie ASCII-Art.

Warum sollte ich so einen Unfug machen? Natürlich hebe ich mir bei sowas
die Originaldaten auf, völlig egal, ob das nun eine Excel-Datei oder
eine Gnuplot-Eingabedatei ist. Schon, weil Word bei eingebetteten
Diagrammen gerne mal Mist macht. Aber es ging doch um Grafiken und
Skizzen, also Dinge, die man der Dokumentation wegen extra erstellt. Zum
Beispiel so ein schickes Blockdiagramm
.------------------.-----.
| Anwendung | |
+------------------+ |
| Library | |
+------------------+ |
| Kernel | |
+------------------' |
| Master Control Program |
`------------------------'
Mit sowas bin ich in ASCII-Art dreimal schneller als mit der
Word-Malfunktion (malfunction? .

Mal ebenso ein paar mathematische Formeln einzufügen wird da echt
zur Qual.

Formeln, so mit ASCII-Art-Wurzelzeichen und so, baue ich nicht.
Vielleicht noch sowas

riesen * langer * ausdruck
sqrt ( ---------------------------- )
( noch + ein ) ^ ausdruck

aber das kann man ja auch in jeder Festbreitenschriftart lesen.

Mathematische oder physikalische Hindergründe oder Herleitungen halte
ich für recht wichtig bei der Code-Entwicklung. Schon allein um die
Präzision bei Rechenoperationen abschätzen zu können, ist es
unentbehrlich. Sowas will ich nicht in einem externen Dokument. Wenn
ich dann Summenformeln oder Integrale in Courier New in die Kommentare
schreiben muss, dann mach das keinen Spass.

Herleitungen müssen nicht unbedingt vollständig im Quelltext stehen. Da
reicht mir sowas:
/* This is the solution to
sqrt(a - sa*x) + sqrt(b - sb*x) = d
obtained with Mathematica.
[d = sqrt(d2), Anm.d.Posters] */
return ((a - b - d2)*sa - (a - b + d2)*sb + 2*sqrt(d2*(b*sa*sa
- (a+b-d2)*sa*sb + a*sb*sb)))
/
((sa-sb)*(sa-sb));
Wer nachrechnen will, darf das gerne tun, aber so genau muss es nun auch
nicht im Quelltext stehen.


Stefan

 

[Axel Schwenke]

Dirk Ruth <d.ruth@itecnet.de> wrote:

Gerrit Heitschschrieb:
Dirk Ruth wrote:


Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

Weil es dann kein reiner Text mehr waere und das will man wirklich
nicht. Waere so, als wenn du deinen Source in MS-Word schreibst und dann
auch nur damit wieder lesen kannst.

Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.). Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.

Herzlichen Glühstrumpf!

Von Details abgesehen hast du gerade "Literate Programming"
wiedererfunden:

http://de.wikipedia.org/wiki/Literate_programming


XL

 

[Alexander Schreiber]

Rainer Buchty <buchty@atbode100.lrr.in.tum.de> wrote:

In article <gjresn.9k.1@stefan.msgid.phost.de>,
Stefan Reuther <stefan.news@arcor.de> writes:

|> Mit sowas bin ich in ASCII-Art dreimal schneller als mit der
|> Word-Malfunktion (malfunction? .

An der Stelle möchte ich eine Lanze für xfig brechen... Wenn es um
"normale" Grafiken ohne Firlefanz (d.h. keine Schlagschatten, Farbverlaufs-
füllung, Transparenzen) geht, gibt es m.E. kaum etwas besseres.

Und das Format läßt sich in andere gängige Vektor- und Bitmaptformate
wandeln, ja, sogar der Austausch mit der Microsoftwelt (WMF, EMF) ist
per fig2dev und ps2edit möglich, so man das will.

ACK. Fuer alles, was irgendwie als vektorartige Grafik gemacht werden kann,
ist xfig _das_ Mittel der Wahl hier. Zumal die Grafiken in sehr viele
verschiedene Formate, darunter auch PDF, exportiert werden koennen.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

 

[Alexander Schreiber]

Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:

Gerrit Heitsch schrieb:
...
Genau sowas gehoert in den Kommentar im Source, nirgendwo anders.

Und das bitte in einer Sprache, für die es Wörterbücher im WEB gibt.

Aus gegebenem Anlaß[0]: Kennt jemand ein solches für Finnisch?

Falk
[0]/* Alustetaan PIO SPI:n tarvitsemiin tiloihin */

http://translate.google.com/ kann mittlerweile relativ viele Sprachen,
natuerlich in variabler Qualitaet. Zu Deinem Text meint es:
"PIO formatiert ist SPI in den Räumlichkeiten der Nachfrage" - hoffentlich
erhellt der Kontext diese Maschinenuebersetzung etwas ;-)

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

 

[Rainer Buchty]

In article <gjresn.9k.1@stefan.msgid.phost.de>,
Stefan Reuther <stefan.news@arcor.de> writes:

|> Mit sowas bin ich in ASCII-Art dreimal schneller als mit der
|> Word-Malfunktion (malfunction? .

An der Stelle möchte ich eine Lanze für xfig brechen... Wenn es um
"normale" Grafiken ohne Firlefanz (d.h. keine Schlagschatten, Farbverlaufs-
füllung, Transparenzen) geht, gibt es m.E. kaum etwas besseres.

Und das Format läßt sich in andere gängige Vektor- und Bitmaptformate
wandeln, ja, sogar der Austausch mit der Microsoftwelt (WMF, EMF) ist
per fig2dev und ps2edit möglich, so man das will.

Rainer

 

[Dirk Ruth]

Gerrit Heitschschrieb:
"

Dirk Ruth wrote:
Falk Willbergschrieb:
"
Dirk Ruth schrieb:
...
Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.) . Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.
Klar, dann kann man nur noch mit dem OS eines einzigen Herstellers
programmieren.


Warum? Wenn die Info in eigens dafür vorgesehene Tags eingebettet ist.

Aha... und welcher Compiler baut das XML erstmal nach Text um damit er
damit was anfangen kann? Garantiert nur bestimmte Hersteller und dann
noch mit inkompatiblen Tags womit du beim Programmieren auf einen
bestimmten Editor festgelegt bist. Danke, muss nicht sein.

Ich glaube du denkst da zu kompliziert.
Aber sicher habe ich mich nur einfach falsch ausgedrückt.

Ich stelle mir z.B. in etwa sowas vor:
Basis-Datei ist ein XML-File. In diesem existieren verschiedene Tags,
sowohl vorgegebene, als auch selbst definierbare. Der Editor zeigt nun
alle die Tags an, die ausgewählt worden, dass sie ebend angezeigt
werden sollen (natürlich nicht die Tags, sondern was dazwischen
steht). Möchte ich irgend etwas einfügen, z.B. ein GIF o.ä. (die
hattest Du ja zugelassen), dann wird dort ein neuer Tag mit dem GIF
eingefügt. Das geschieht für mich als Anwender völlig transparent,
ohne das ich mich um die Verwaltung des Dokuments kümmern muss.

Nun zu den verschiedenen Sichten:
Möchte ich kompilieren, dann sage ich einfach "speichern unter *.c",
oder drücke ein Button oder was auch immer und ein Script schreibt
alles, was z.B. zwischen den Tags <Code> ...</Code> steht in eine
plain C-Datei, die wie eine normale C-Datei aussieht.
Möchte ich eine Doku, dann entsprechend alles was zwischen <Doku>
....</Doku> steht.

Für sowas simples brauche ich doch um Himmels willen keine neue Super
Entwicklungsumgebung. Jedes poplige 20-Zeilen Script oder Makro kann
das machen. Es braucht nur einen netten Editor, der mir die Tags
verwaltet, komfortabel anlegt und anzeigt. Copy und Paste für Bilder
usw. wäre natürlich schön.
Der MS-Explorer macht es z.B. nicht schön. Der zeigt nur ein
Plus-Zeichen, mit dem man einen Baum aufklappen kann.

Ich möchte mit dem Editor selbst kar nicht mal Zeichen können müssen.
MS würde sowas sicher per OLE oder was auch immer realsieren, das man
keine externe Anwendung starten muss, aber das muss ich nicht
unbedingt haben. Es geht mir einzig um eine direkte Zuordnung einer
Code-Zeile zu einem umfangreicheren Kommentar, der eben mehr als ein
reiner Textkommentar sein kann.


Sowas ähnliches macht man im Internet wohl schon seit 20 Jahren. Man
nennt das HTML-File. Da werden dann Bilder, Text, Animationen zu einem
Meta-Dokument zusammen gefügt.


Vielleicht gibt es sowas mal für den Firefox als Extension.

Der Ansatz ist ja eher, dass es eine Source-Datei gibt, auf die
mehrere Sichten existieren können.
Zusammengehörende Informationen über möglichst kurze Wege zu
vernetzen, halte ich für das Ordnungssystem mit der höchsten
Effizienz. Die einlaufen Informationen zu dem Zeitpunkt zu vernetzen,
zu dem sie bearbeitet und angewendet werden steigert die Effizienz
nochmals und sorgt für den geringsten Informatonsverlust.
Also nichts da mit Dokumentation aus dem Nichts nach Fertigstellung
des Projekts erstellen.

Kannst du gerne per externer Datei machen, aber der Source muss reiner
Text bleiben.

Ähm ist er doch?

Ich schreibe seit Jahren Software mit vi, die Abhängigkeiten prüft make,
kompilieren tue ich mit gcc.


Habe ich früher auch mal so gemacht.
Heute verwende ich lieber eine Entwicklungsumgebung, mit der ich
sowohl programmieren, compilieren, die Versionen verwalten, debuggen,
simulieren, in der Online-Hilfe suchen, GUI-Entwickeln, flashen usw.
kann und das über mehrere Einzelprojekte.

Damit bist du aber auf einen Editor festgelegt. Schoen, wenn der dir
gefaellt. Aber was machst du wenn das nicht der Fall ist?

Vergiss nicht, was machst du wenn du in 10 Jahren nochmal an den Source
ranwillst aber das XML von damals keiner mehr versteht? Alles was hier
_immer_ lesbar sein soll (Source, Texte, usw...) lagert hier als
Textfile, PDF, HTML, GIF, JPEG oder PNG. Alle anderen Formate haben sich
als zu kurzlebig oder zu proprietaer erwiesen, besonders wenn man hin
und wieder mal die Platform gewechselt hat.

Ich bin kein XML-Experte, war jetzt nur ein Vorschlag.
Der Vorteil von XML ist nach meinem letzten Wissensstand aber, das es
dazu eine Definitionsdatei gibt, die ebend sicher stellt, dass es nach
10 Jahren noch lesbar ist.


Dirk

 

[Michael Eggert]

Thomas 'Tom' Malkus <tom@isnix.de> wrote:

Moin!

Aber die Büros sehen so aus wie die Ausstellung bei IKEA.

Jau, denn auch bei IKEA wären die Billardkugeln am Tisch festgeklebt:
http://picasaweb.google.com/zurich.office.images/ZurichOfficePhotos#5174254532920134562
http://picasaweb.google.com/zurich.office.images/ZurichOfficePhotos#5174254631704382386



Also, so ein ganz klein wenig gestellt schauts doch aus...

Gruß,
Michael.

 

[Dirk Ruth]

Alexander Schreiberschrieb:
"

Dirk Ruth <d.ruth@itecnet.de> wrote:
Stefan Reutherschrieb:
"
Dirk Ruth wrote:
Axel Schwenkeschrieb:
2. High-Level Dokumentation. Funktionsprinzipien, Konfigurations-
parameter, Dateiformate, Hintergrundinfos.

Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.

Warum nicht?

Für einfache Blockdiagramme kenne ich nichts unkomplizierteres. Zum
Beispiel Datenstrukturen dokumentiere ich gerne mal so im Quelltext.
Und in den High-Level-Dokumentationen findest du auch gerne mal ASCII-
Art. Geht einfach schneller und einfacher als mit der Word-Malfunktion.

Word ist für nichts anderes geeignet, als gelegendlich mal einen Brief
zu schreiben, der aber auch nicht zu lang sein darf.
Ich glaube, da sind wir uns auch einig.

Allerdings.

ASCII-Art ist eher ein workaround für dieses Problem. Ein so
eingefügtes Diagramm oder Grafik will hinterher keiner mehr ändern,
wenn man nicht irgendwo die originalen Quellen dafür hinterlegt hat.
Hinzu kommt, dass die Auflösung sehr begrenzt ist und alle Entwickler
die gleichen Schriftparameter eingestellt haben müssen, damit es in
etwa auch gleich aussieht.

Zum Programmieren nimmt man Schriftarten mit fester Breit, Problem
geloest. Proportionalschriften machen bei ASCII-Format nun wirklich
keinen Sinn.

Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.

Mal ebenso ein paar mathematische Formeln
einzufügen wird da echt zur Qual.

Schreibs halt im LaTeX-Format, das ist relativ gut lesbar. BTDT ;-)

Ja das machst Du. Sonst aber wahrscheinlich keiner weiter auf dieser
Welt. In einem Ein-Mann-Team ist das auch völlig egal. Wenn aber 25
Entwickler an einem Projekt arbeiten, kann man aber erstmal die 25
Leute auf eine 6wöchige LaTex-Schulung schicken. Damit sind dann schon
mal 3 Mannjahre weg.
Teamarbeit funktioniert nur, wenn es Standards gibt. LaTex im
Quellcode ist kein Standard.

Ein guter Standard fehlt leider. XML könnte diese Lücke schließen.

Hier hängt die Entwicklung der Entwicklungsumgebungen m.E. den
Anforderungen weit hinterher

Man liest sich,
Aber gern.

Dirk

 

[Dirk Ruth]

Joergschrieb:
"

Dirk Ruth wrote:
Stefan Reutherschrieb:
"
Dirk Ruth wrote:
Axel Schwenkeschrieb:
2. High-Level Dokumentation. Funktionsprinzipien, Konfigurations-
parameter, Dateiformate, Hintergrundinfos.
Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Warum nicht?

Für einfache Blockdiagramme kenne ich nichts unkomplizierteres. Zum
Beispiel Datenstrukturen dokumentiere ich gerne mal so im Quelltext.
Und in den High-Level-Dokumentationen findest du auch gerne mal ASCII-
Art. Geht einfach schneller und einfacher als mit der Word-Malfunktion.

Word ist für nichts anderes geeignet, als gelegendlich mal einen Brief
zu schreiben, der aber auch nicht zu lang sein darf.
Ich glaube, da sind wir uns auch einig.


Aehm, damit hatte ich schon 1990 fette Doku geschrieben, mit
Schaltbildauszuegen drin (damals per HPGL Import Funktion), Graphiken,
Bildern und so weiter. Und das tue ich auch jetzt noch, ausser dass es
nun unter Windows ist.

Das tut mir leid Jörg. ;-)

Meine Erfahrungen sind damit eher nicht so gut. Ich versuche Word
immer möglichst aus dem Weg zu gehen. Wir vertragen uns leider nicht
besonders. Die neue Oberfläche macht das auch nicht gerade einfacher.

Dirk

 

[Joerg]

Michael Eggert wrote:

Thomas 'Tom' Malkus <tom@isnix.de> wrote:

Moin!

Aber die Büros sehen so aus wie die Ausstellung bei IKEA.

Jau, denn auch bei IKEA wären die Billardkugeln am Tisch festgeklebt:
http://picasaweb.google.com/zurich.office.images/ZurichOfficePhotos#5174254532920134562
http://picasaweb.google.com/zurich.office.images/ZurichOfficePhotos#5174254631704382386



Also, so ein ganz klein wenig gestellt schauts doch aus...

<angeber_modus>

In diesem Ingenieurbuero hier ist nix gestellt. Unten steht ein 7ft Pool
Table. Und zwar nicht mit diesen blauen Designer-Kugeln drueber, sondern
wie sich das gehoert mit grosser rechteckiger Tiffany-Lampe.

</angeber_modus>

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

 

[Dirk Ruth]

Stefan Reutherschrieb:
"

Dirk Ruth wrote:
Stefan Reutherschrieb:
Dirk Ruth wrote:
ASCII-Art ist eher ein workaround für dieses Problem. Ein so
eingefügtes Diagramm oder Grafik will hinterher keiner mehr ändern,
wenn man nicht irgendwo die originalen Quellen dafür hinterlegt hat.

Wieso "originale Quellen"? ASCII-Art ist Klartext und kann mit jedem
Editor geändert werden. Sogar Word. Bequemer ist natürlich
http://www.jave.de/>. Der akzeptiert natürlich auch Cut&Paste von Word.

Missverständnis.
Wenn du in Excel eine Messreihe und daraus ein Diagramm erstellt hast,
dass dann wieder als Bild abgespeichert und in ASCII umgewandelt wird,
dann mußt du das Excel-Original nochmal irgendwo hinterlegen. Ändern
sich da mal ein paar Werte, muss die Grafik und das ASCII neu erzeugt
werden, weil du das mit den Punkten und Strichen usw. händisch nicht
so hinbekommst, wie ASCII-Art.

Warum sollte ich so einen Unfug machen? Natürlich hebe ich mir bei sowas
die Originaldaten auf, völlig egal, ob das nun eine Excel-Datei oder
eine Gnuplot-Eingabedatei ist. Schon, weil Word bei eingebetteten
Diagrammen gerne mal Mist macht. Aber es ging doch um Grafiken und
Skizzen, also Dinge, die man der Dokumentation wegen extra erstellt. Zum
Beispiel so ein schickes Blockdiagramm
.------------------.-----.
| Anwendung | |
+------------------+ |
| Library | |
+------------------+ |
| Kernel | |
+------------------' |
| Master Control Program |
`------------------------'
Mit sowas bin ich in ASCII-Art dreimal schneller als mit der
Word-Malfunktion (malfunction? .

Word stand wie gesagt nicht zur Debatte.
Jetzt stell dir einfach mal eine Diagramm vor, indem 5
Temperaturkurven eingezeichnet sind. Alle Kurven liegen eng
beieinander und schneiden sich zum Teil. Es sind verschiedene
Referenzpunkte oder Stützstellen eingezeichnet. Bestimmten
Kurvenpunkten sind Kürzeln mit hoch- und tiefgestellten Indizes usw.
gekennzeichnet.

Das kommt jetzt mit ASCII einfach nicht so richtig gut rüber.

Mal ebenso ein paar mathematische Formeln einzufügen wird da echt
zur Qual.

Formeln, so mit ASCII-Art-Wurzelzeichen und so, baue ich nicht.
Vielleicht noch sowas

riesen * langer * ausdruck
sqrt ( ---------------------------- )
( noch + ein ) ^ ausdruck

aber das kann man ja auch in jeder Festbreitenschriftart lesen.

Mathematische oder physikalische Hindergründe oder Herleitungen halte
ich für recht wichtig bei der Code-Entwicklung. Schon allein um die
Präzision bei Rechenoperationen abschätzen zu können, ist es
unentbehrlich. Sowas will ich nicht in einem externen Dokument. Wenn
ich dann Summenformeln oder Integrale in Courier New in die Kommentare
schreiben muss, dann mach das keinen Spass.

Herleitungen müssen nicht unbedingt vollständig im Quelltext stehen. Da
reicht mir sowas:
/* This is the solution to
sqrt(a - sa*x) + sqrt(b - sb*x) = d
obtained with Mathematica.
[d = sqrt(d2), Anm.d.Posters] */
return ((a - b - d2)*sa - (a - b + d2)*sb + 2*sqrt(d2*(b*sa*sa
- (a+b-d2)*sa*sb + a*sb*sb)))
/
((sa-sb)*(sa-sb));
Wer nachrechnen will, darf das gerne tun, aber so genau muss es nun auch
nicht im Quelltext stehen.

Nein das reicht mir nicht als Dokumentation (auch nicht als
Kommentar). Ich bin da leider etwas anspruchsvoller. Wenn ich sowas
als Doku vorgelegt bekommen würde, dann bekäme ich Bauchschmerzen.
Würde mich auch nicht trauen, sowas einem Kunden als Doku hinzulegen.
Selbst wenn sich ein Kollege neu in den Code einarbeiten muss und der
die Hintergründe noch nicht kennt, braucht ewig, um damit warm zu
werden.
Das menschliche Gehirn versteht komplizierte Sachverhalte viel
schneller, wenn sie optisch gut aufbereitet sind.
Es hat irgendwie seinen Grund, warum mathematische Ausdrücke,
chemische Formeln usw. in einer bestimmten Form dargestellt werden.
Ich will effektiv arbeiten, denn Zeit ist Geld. Dinge die sich
automatisieren lassen will ich als Mensch nicht machen, dann das kann
ein Automat viel besser und vor allem kostengünstiger.


Dirk

 

[Henning Paul]

Rainer Buchty wrote:

In article <gjresn.9k.1@stefan.msgid.phost.de>,
Stefan Reuther <stefan.news@arcor.de> writes:

|> Mit sowas bin ich in ASCII-Art dreimal schneller als mit der
|> Word-Malfunktion (malfunction? .

An der Stelle möchte ich eine Lanze für xfig brechen... Wenn es um
"normale" Grafiken ohne Firlefanz (d.h. keine Schlagschatten,
Farbverlaufs- füllung, Transparenzen) geht, gibt es m.E. kaum etwas
besseres.

Ja, hab' ich für meine Diplomarbeit auch verwendet - obwohl ich nie ganz
glücklich damit war. Mittlerweile habe ich mich auf Corel Draw (in der
VMware) + psfrag eingeschwungen, eben weil Lot fällen, Linien
halbieren, Kreis vierteln etc. mit xfig immer ein wenig umständlich
war.

Gruß
Henning

 

[Albrecht Mehl]

Thomas 'Tom' Malkus schrieb:

Im Moment versuche ich gerade aus mit LaTex erstelltem Handbuch eine
Windows HTML Hilfe zu bauen. Will noch nicht so richtig...

Ein Blick auf

http://www.dante.de/faq/de-tex-faq/html/tools.html#17

lohnat wohl.

A. Mehl
--
Albrecht Mehl |eBriefe an:mehl bei freundePUNKTtu-darmstadtPUNKTde
Schorlemmerstr. 33 |Tel. (06151) 37 39 92
D-64291 Darmstadt, Germany|sehenswert - ungefähr 'Wir einsam im All'
http://www.phrenopolis.com/perspective/solarsystem/index.html

 

[Wiebus]

Hallo Heiko.

Nur leider ist es schwer bis unmöglich, erstklassige Leute zu bekommen.

Was erwartest Du? Die Anzahl der Begabten ist Konstant. Du kannst die
Ausbildung verbessern, aber wenn Du alle Begabten gut ausgebildet
hast, hast Du eine Art "Sättigung" erreicht.
Mehr kommt dann nicht mehr.....

Aber vieleicht ist es ja auch nicht ganz so dramatisch:

Siehe: Deutschlandfunk 02.12.2008 ˇ 14:35 Uhr
Ekkehart Schlicht im Gespräch mit Sandra Pfister

Nachzulesen http://www.dradio.de/dlf/sendungen/campus/885071/

Irgendwie finde ich, das der Mann recht hat.
Vieleicht solltet Ihr euch Überlegen, ob nicht auch gute Facharbeiter
oder Techniker brauchbar sind?

Und zweitklassige Leute sind
ein Risiko, das kleine Firmen nicht tragen können. Da machen wir lieber
Überstunden ;-) Letztlich sind wir also auf Absolventen angewiesen und haben

Absolventen? Das meint Ihr nur. s.O. das Interview.

damit auch sehr gute Erfahrungen. Die ach so erfahrenen älteren Semester
bewerben sich auf unsere Stellenausschreibungen gar nicht erst.

Weil viele ältere (wie ich) ihre "Erfahrung" auch als Ballast
kennengelernt haben. Ich hab einfach nicht die Chuzpe, meinen
geistigen und körperlichen Verfall mit dem Euphemismus "Reife"
zu Umschreiben.

Möglicherweise könnten kleinere Umstrukturierungen es euch erlauben,
auch noch gut mit drittklassigen- viertklassigen klarzukommen.
Einfach mal viel kleinere Klappe beim Formulieren der Anzeige....
viele wären auch schon mit einer Bezahlung auf Facharbeiterniveau oder
darunter zufrieden. Hauptsache ein Job....

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

 

[Thomas Schaerer]

Gerhard Hoffmann <dk4xp@hoffmann-hochfrequenz.de> wrote:

Der Spruch, nichts komplizierter zu machen als unbedingt n?tig
wird auch immer wieder Einstein zugeschrieben.

War aber als "Occam's razor" bekannt.
"Entia non sunt complicanda praeter neccesitatem"
(William of Ockham, irgendwann im Mittelalter)

Und von wem ist das:

"Warum einfach, wenn's komplizierter besser geht?"

Gruss
Thomas
--
Mein ELKO-Buch ueber Opamp, OTA und Instrumentation-Amplifier:
http://www.elektronik-kompendium.de/shop/buecher/operationsverstaerker-und-instrumentationsverstaerker
(Aendere "akz" durch "isi" in der Mailadresse fuer Reply!)

 

[Dirk Ruth]

Axel Schwenkeschrieb:
"

Dirk Ruth <d.ruth@itecnet.de> wrote:
Gerrit Heitschschrieb:
Dirk Ruth wrote:


Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

Weil es dann kein reiner Text mehr waere und das will man wirklich
nicht. Waere so, als wenn du deinen Source in MS-Word schreibst und dann
auch nur damit wieder lesen kannst.

Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.). Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.

Herzlichen Glühstrumpf!

Von Details abgesehen hast du gerade "Literate Programming"
wiedererfunden:

http://de.wikipedia.org/wiki/Literate_programming

Dann gibt es das also schon seit 1981 - sehr interessant.
Scheinbar bin ich also mit meinen Wünschen doch nicht so ganz allein.


Könnte ja jetzt die ketzerische Frage stelllen, wie Tex heute nach
fast 30 Jahren immer noch funktionieren kann und compilierbar ist,
wenn es doch mit so einem abstrusen Konzept entwickelt wurde.

Dirk

 

[horst-d.winzler]

Thomas Schaerer schrieb:

Gerhard Hoffmann <dk4xp@hoffmann-hochfrequenz.de> wrote:

Der Spruch, nichts komplizierter zu machen als unbedingt n?tig
wird auch immer wieder Einstein zugeschrieben.

War aber als "Occam's razor" bekannt.
"Entia non sunt complicanda praeter neccesitatem"
(William of Ockham, irgendwann im Mittelalter)

Und von wem ist das:

"Warum einfach, wenn's komplizierter besser geht?"

Kann sich nur um die Weisheit eines Verwaltungsjuristen handeln ;-)
--
mfg hdw