From: ry53@rz.uni-karlsruhe.de (Angela Schmidt)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: SAS/C Compiler, Stacksize errechnen
Date: 25 Jan 1993 12:54:09 GMT
Organization: Nessyhoehle@I501.NessyNet.de
Distribution: world
Reply-To: Angela@rz.uni-karlsruhe.de
NNTP-Posting-Host: tp70.rz.uni-karlsruhe.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


In article <2hgls*D40@oberon.nbg.sub.org>, hartmut@oberon.nbg.sub.org (hartmut Goebel) writes:
> In article <1993Jan22.101610.11843@mpifr-bonn.mpg.de>, Michael van Elst writes:
> Und zum x-ten Mal: Warum soll der Programmierer etwas amchen, was der
> Compiler einfacher, schneller und sicherer kann?
> 
> Und warum wollt ihr Fehler, die schon beim Compilerien zu finden
> sind, erst im Testlauf finden (wenn berhaupt - beim Testen findet
> man ja bekanntlich auch nicht alle Fehler).
> 
> Und warum wollt Ihr Fehler immer erst auftreten lassen, anstelle sie
> von vorneherein zu vermeiden? Schadensvermeidung ist immer billiger
> als Schadensbkmpfung. Oder fahrt Ihr Auto nach dem Motto wie ihr
> programmiert: erst mal starten, wenn kracht ist halt ein Fehler drin?

Ein Auto kann man schlecht selber reparieren, selbstgeschriebene
Programme hingegen schon. Von den Kosten einmal ganz abgesehen.
Dein Vergleich hinkt also... Warum startest Du ein neues Programm? 
Schliesslich knnte es abstrzen - hast Du daran schon einmal gedacht?
La' es lieber bleiben, dann bist Du sicher, da Dein Rechner nicht
crasht und da Du keine wertvollen Daten verlierst. Hmmm - vielleicht
solltest Du - um Schaden zu vermeiden - mit dem Programmieren
aufhren...?

Nun aber zu Deiner Frage:
Sieh' es einfach mal so: Mir ist die Geschwindigkeit und die Krze
meines Programmes einfach _viel_ wichtiger als die paar Vorteile, die
mir Oberon gbe. Feldberschreitungen und hnliches kommen so selten
vor, da ich keine Lust habe, mir fr die paar Flle, die ich notfalls
mit Mungwall debuggen kann, eine runtime-library and den Hals hngen
zu lassen. Ich brauche auch keine Garbage-Collection, denn allein
_ich_ wei, wann ich etwas allociert habe und wann ich es wieder loswerden
will. Und wenn ich mein Public-Mem einem anderen Task vererbe, kann
ich sicher sein, da mein Compiler es nicht besser gewut hat.

Aber vielleicht haben Oberon-Programmierer ja eine so schlechten
Programmierstil, da sie ohne diese Features nicht mehr auskommen
knnen. Wenn so jemand mal auf C umsteigt, dann kann ich mir gut
vorstellen, da am Anfang nichts Gutes dabei herauskommt...

Wenn ich auf meine letzten paar Jahre C-Erfahren zurckblicke,
mu ich feststellen, da die _wenigsten_ Bugs aus Fehlern bestanden,
die ein Compiler gefunden htte. Ok, es waren durchaus Fehler dabei,
die ein Compiler htte vermeiden knnen - meist lag es dann aber
an der _Implementierung_ des Compilers und nicht an der Sprache
"C". DICE steckt halt noch etwas in den Kinderschuhen und hat an
einigen Stellen noch so seine Macken. Das mu man halt akzeptieren,
dafr hat man einen preiswerten Compiler. Ob Dein Oberon sooo viel
besser ist, kann ich leider nicht beurteilen. Auch Dein Oberon wird
noch seine Schwchen haben - oder denkst Du, es sei bugfrei, nur weil
es in Oberon geschrieben ist?

Um es kurz zu sagen: ich _will_ mich auf einer tieferen Ebene
bewegen, weil ich die Kontrolle ber mein Programm selber haben
will (ja, ich traue nicht mal meinem Comliper - nur mir selbst :-) und
weil ich von der hheren Geschwindigkeit, dem kleineren Code und
hnlichem profitieren will. Was spricht dagegen? Warum meckerst
Du stndig an "C" herum? Benutz doch Dein Oberon und schreibe
die besten, sichersten und tollsten Programme, die es je gab. Die
Ehre wird Dir voll gebhren - schlielich sind ja alle C-Programme
sooooo frchterlich schlecht und groe Projekte (wie auch das OS)
lassen sich in C so gut wie gar nicht schreiben. Unix wurde ja
auch in Oberon geschrieben...

> Kann mir daruaf vielleicht endlich  aml einer eine Antwort geben? Vor
> Stellungnamen dazu scheint Ihr Euch zu drcken.

War das genug Stellungnahme?

> (Remember: C ist mit Syntax verzuckerte Assembler)

Dann ist Oberon mit Syntax verzuckertes C. (Und somit auch nur mit
Syntax verzuckerter Assembler.)

> Das habe ich nie behauptet. Aber Oberon erleichter das Erstellen von
> fehlerfreien Programmen, weil der Compiler und das Run-Time-System
> viel mehr Fehler finden, als in anderen Sprachen wie z.B. (das ja
> nicht mal ein Laufzeitsystem hat!).
  ^^^^^^^^^

Was heit hier "nicht mal". Kannst Du Dir nicht vorstellen, da
es Progammierer gibt, die diesen Kse gar nicht wollen? Ich
behaupte, da zum Beispiel die pattern.library inclusive der Fehler,
die mein Compiler _und_ das Run-Time-System flschlicherweise nicht
gemeldet haben, maximal soviel Fehler pro KB Code hat, wie ein
Programm hnlicher Gre und Komplexitt von Dir. Bei der
pattern.library wren das bis jetzt knapp 1 Bug / 10 KB. Mehr
Fehler sind selbst ein Jahr nach der Verffentlichung nicht
bekanntgeworden.

> Es gibt auch eine Studie, die Modula-2 und C vergleicht, was die
> Verwendbarkeit fr mittlere und groe Projekte angeht. Lest mal nach:
> in ACM SIGPLAN Notices, Vol. 27, No. 4, April 1992 p.17ff.
> Ich brauche nicht zu erwhnen, da Modula-2 die Nase vorne hat. Und
> das, obwohl mit C noch recht freundlich umgegangen wird.

Kommt immer auf den Autor an. Sicherlich kann man auch Modula
furchtbar niedermachen. Ich wrde auch einem Anfnger kein "C"
empfehlen - die sollen mal ruhig BASIC oder Wirth nehmen - das
ist viel besser fr sie. _Mir_ aber traue ich "C" durchaus zu...


     V v
  @/@@=\   Und hr' bitte auf, uns Oberon einreden zu wollen,
    00 &=-      Angela 
oOoO_/` \\_
    \ /&\   Angela Schmidt cand. inf. (Nessy@IRC) | Amiga //
  |>O<|         EMail: Angela@rz.uni-karlsruhe.de | 1000 // 
   / \_/\/\/v,  Weekend: +49 731 712316 (9am-9pm) |  \\ // since 
  /___________\ Weekdays: 721 6904263 (10am-11pm) |   \X/ 1986 
Newsgroups: de.comp.sys.amiga.misc