Kopfgeldjäger, Schulungen und Carrier, kurz: Nepp und allgemeine Verdummung
Uwe Ohse
die unterqualifizierten Examplare der Sorte Mensch, die mich zu ihren
Kunden oder Mitarbeitern machen möchten.
Da sind zum Beispiel Kopfgeldjäger zu erwähnen. Von den letzten 6
waren 5 noch nicht mal informiert was ich mache [1].
- Netzwerkadministrator für ein größeres TCP/IP basiertes Netzwerk?
Gut, das sollte ich können. Und eigentlich klang das alles auch nicht
schlecht, nur Frankfurt? [2] Und will ich _nur_ Netzwerke betreuen?
(Gut, daß bei mir der Eintönigkeitsfaktor durchaus gewichtig in den
Entscheidungsprozess eingeht muß man nicht wissen)
- Fachmann für das Rebooten von Webservern?
Eigentlich suchte er mehr einen Fachmann für die mausgestützte
Administration einiger Dutzend NT-Webserver, aber das kam halt nicht
'rüber.
Don't worry, der lernt's auch nicht mehr.
- Webdesigner?
Da sind die Leute bei mir natürlich an der richtigen Adresse, meine
Seiten sind wunderbar schlicht und von allen Browsern anzeigbar. Auch
graphischer Unsinn liegt mir fern.
Das sieht man meinen Webseiten auch an.
- NT-Administrator?
Zweiter Chefbeißer für mehrere hundert User. [5]
Ich bin nur leider nur dann fähig die zweite Geige zu spielen wenn
es gut läuft. Es tut mir noch nicht mal leid, aber wenn es Probleme
gibt sind Vorgesetzte nur im Weg.
Im Falle einiger hundert NT-Kisten _kann_ es nicht gut laufen. [3]
Abgesehen davon wasche ich mir jedesmal die Hände wenn ich NT
angefaßt habe. Man weiß ja nie.
- SAP-Berater?
Ich hab' schon mal einen SAP-Rechner und auch schon mal eine
SAP-Anwendung aus 5 Meter Entfernung gesehen. [4]
Das Gespräch war wenigstens ehrlich. "Das macht nichts, das lernt man
schnell.". Den Job des Kopfgeldjägers wohl auch, oder?
- Webserver administrieren?
Ich? Ich kann das wohl lernen.
Aber wieso kam die Frau auf mich? Der Webmaster hier ist eindeutig
jemand ganz anderes, und ich misch' mich auch nicht in seine Sachen
ein.
Novellnetze zu betreuen macht mir auch keinen Spaß, danke. Delphi? Ist
so etwas wie Turbopascal, nicht? Haben Sie zwei Stunden Zeit? Dann
zähle ich Ihnen mal die wichtigsten Gründe auf warum Pascalprojekte
grundsätzlich scheitern. Java? Schon mal angesehen und ... Wie, Java
auf embedded systems? [Klick] Die HTML-RFCs unterhalb meiner Homepage
habe ich nicht geschrieben sondern nur nach HTML übersetzt, steht da auch
ganz klar 'drüber. Und das qualifiziert mich NICHT zur Mitarbeit an der
Qualitätssicherung eines zu entwickelnden kommerziellen DNS-Servers. (ich
hab' mich immer gefragt ob die damit jemals angefangen haben)
Nene. Keine Jobangebote in der nächsten Zeit, bitte.
Erst recht nicht telefonisch Samstag nachmittags zuhause ...
Und bitte überhaupt keine mehr nach dem Schema "Sie sind mir empfohlen
worden weil Sie das und das können", was ich dann in der Regel gerade
mal buchstabieren kann.
Dazu kommen noch Carrier, die einem mittelgroßen regional operierenden
ISP Leitungen aller Art anbieten wollen. Wenig überzeugend ist daß selbst
deren Kundenübertölpelungsspezialisten oft genug nicht informiert sind. So
landen derartige Anfragen oft bei unserem Webmaster (ich bin die letzten
zwei Wochen öfters mal an sein vereinsamtes Telefon herangegangen und hab'
gleich zwei Informationsangebote eher kühl dankend ausgeschlagen).
Würden die ihm Mails schicken könnte ich das ja noch verstehen -
webmaster@wir ist leichter auf unseren Webseiten zu finden als so manche
andere Adresse.
An günstigen Leitungen in die Staaten sind wir auch nicht interessiert,
danke. Falsche Größenordnung.
Uns bei X [bedeutende Konkurrenz, nein, nicht DTAG] anschließen wollen
wir auch nicht. Auch steht nicht zur Debatte uns mit zwei Mbit bei X
anzuschließen und "redundante Upstream sind durch durch Redundanz beim
Upstreamprovider unnötig geworden" [11] ist auch nicht glaubwürdig.
Auf die Bemerkung hin daß das wir zu einem USP 4 Mbit haben folgte dann
das Angebot Kompression auf der 2mbit zu fahren. [12] Die Frage, wie
er denn unsere 34Mbit zum nächsten USP zu ersetzen gedenke, ist leider
nicht beantwortet worden.
Niete im Marketing. Trägt wahrscheinlich Nadelstreifen.
Und dann sind da Schulungen, Seminare und ähnliche Verdummungsunternehmen.
So habe ich zuhause noch das Angebot eines ehemaligen Mitarbeiters liegen,
mich von ihm über irgendwelche wandernden Javaminiaturapplikationen
schulen zu lassen. Vor vier Jahren habe ich ihm noch beibringen dürfen
was ein Pointer ist (damals war er schon C-Profi).
Drei Tage soll die Schulung dauern. Tut mir leid, halte ich garantiert
nicht aus.
Überhaupt ist drei wohl die magische Zahl. Drei Tage Schulung
über Mickysoft internet information sink? Aus dem Kopf aus dem
Programm: Installation NT. Installation MS IIS. Problemlösungen NT mit
MSIE[7]-Mitteln [6]. ASP Programmierung. Incl. Vollständiger Einführung
in die Systemsicherheit [8]. Performancetuning (dem ist der dritte Tag
alleine gewidmet).
Doch, ich bin überzeugt [9]. Drei Tage und knapp 2000 DM sind dafür
sicherlich gut investiert.
Gehen wir mit dem Preis mal etwas herunter. Auf 600 DM für drei Abende
und einen Samstag. Man merkt's schon, hier wird's privater.
Titel: "Einführung in die Datenfernübertragung und das Internet".
Vor drei Jahren wurde das noch mit dem Titel "... und Mailboxen" verkauft.
Immerhin steht heute nicht mehr "ISDN mit 64000 Bytes/Sekunde" auf dem
Faltblatt, und Samstags wird nicht mehr der Umgang mit Crosspoint geübt,
sondern es gibt nun eine "Einführung in das Webdesign mit Frontpage". [10]
Nepp.
Und dann flatterte mir heute, und nun kommen wir zum Auslöser dieses
Postings, ein Angebot ins Haus, an mich adressiert, ein dreitägiges
Seminar "TCP/IP für Kurzentschlossene und Preisbewußte!" zu machen. Zu
wirklich preisgünstigen 1680 DM (ab Freitag, 16:01, sind's 2400 DM).
Nach drei Tagen werde ich also in der Lage sein in unserem Haus oder
bei Kunden in TCP/IP-Fragen mitreden zu können. Jungs, tut mir leid,
ich rede da schon seit drei Jahren mit. [13]
Aber ein paar interessante Punkte hat das schon. Wie designed man
IP-Adressen (Colani?), was ist WindowTCP, worin unterscheiden sich
TCP- und UDP-Ports, und warum sind bei TCP TCP-Frame-Header und
bei UDP nur UDP-Header interessant? Und wer hat die Schreibweise
"Subnet-Maske" erlaubt? Ist Germlish etwas hoffähig geworden?
Und was sind Slidings? (und wird noch jemand anderem beim Wort
"Extranet" komisch?)
Mal ehrlich, wer zahlt 1680 DM wenn noch nicht mal eine Seite Fax
ohne Fehler ist? Ok, Entscheidungsträger.
Kann es wirklich sein daß die Verdummung so weit um sich gegriffen hat?
Muß die Welt mir das an tun?
Gruß, Uwe
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
1) ich verlange ja gar nicht daß irgendjemand weiß was ich _kann_
(ich weiß es auch nicht. "wenig" ist wahrscheinlich ziemlich richtig).
2) was zum Henker soll ich da?
3) einige Hundert egal wie geartete Rechner laufen nicht "gut", sondern
_immer_ schlecht bis sehr schlecht. Das ist hoffentlich kein
Naturgesetz, aber seit etlichen Jahren trifft es jedenfalls zu.
4) dabei kann es auch ruhig bleiben.
5) mehrere Hundert / 2? >= Hundert pro Admin? Kinder.
6) frei übersetzt: Booten und Neuinstallieren.
7) das sind Leute mit wenig Ahnung, die dafür eine Bescheinigung
bekommen haben. In etwa vergleichbar mit frischgebackenen
SuSE-Linuxbesitzern die sich das Handbuch durchgelesen haben:
inkompetent und gefährlich.
8) _ich_ bekomme NT in 5 Minuten sicher, incl. der Zeit für das
Suchen der Zange und das Abschließen der Türe.
In einem kleinen Bruchteil von drei Tagen kann man noch nicht mal die
NT/IIS-Artikel auf Bugtraq lesen, verstehen und die entsprechenden
weniger extremen Maßnahmen angehen.
9) Ja, wirklich. Ich frage mich bloß wozu die ersten beiden Tage
gut sind wenn am Dritten dann doch das System durch Einsatz von
FreeBSD/Linux + (Apache|Boa|choose your own) optimiert wird.
10) was man für eine Verschlechterung halten kann.
11) schade. Schriftlich geben wollte er mir den Satz nicht.
12) "girls in files komprimieren sich wirklich wahnsinnig gut" hat er
leider nicht verstanden.
13) "mitreden können" != "qualifiziert mitreden können".
Stefan Scholl
Umfragen
Kaum zu glauben wieviel Umfragen es gibt. Einige sind echt,
andere enden in Verkaufsangeboten.
Der Typ gestern hat mir es echt nicht geglaubt ... »Nein, aus
Prinzip nicht mehr. ... Nein, zu oft in letzter Zeit. ... Keine
Zeit. <klack/> ... «
Die Verdienen damit Geld, daß ich die Arbeitszeit für dumme
Fragen verschwende. Und dann bekomme ich das Ergebnis nicht
kostenlos, sondern muß es bezahlen. Danke.
***Stefan
Pascal Gienger
>Im Moment gehen mir gar nicht so sehr meine Kunden auf die Nerven, sondern
>die unterqualifizierten Examplare der Sorte Mensch, die mich zu ihren
>Kunden oder Mitarbeitern machen möchten.
>
>Da sind zum Beispiel Kopfgeldjäger zu erwähnen. Von den letzten 6
>waren 5 noch nicht mal informiert was ich mache [1].
Sei doch froh. Mich hat letzte Woche jemand angerufen, der wollte mich
davon überzeugen, daß alles, was nicht Microsoft und Windows NT ist
demnächst aufs Abstellgleis rollt und ich doch bei denen als NT-Admin
anfangen soll (man beachte die verkorkste Logik [*]). Nicht, daß ich gegen
solche Anrufe etwas habe, aber Sonntag morgen um 9 Uhr war mir dann doch
etwas _zu_ daneben! Ich frage mich immer nur, _woher_ diese Menschen
ihre Infos und vor allem die Telefonnummer haben. Usenet scheinen sie nicht
zu benutzen, sonst würden solche Anrufe wie bei Uwe oben nicht
passieren ;-) Auf die Anfrage, woher er meinen Namen und die Nummer habe,
antwortete er nicht ("kann ich Ihnen nicht sagen").
Pascal
[*] Hat "Microsoft" so ein Krankheitsbild? ;-)
--
Unix, Pascal Gienger, Steinstr. 21 /\ 12 .rtsnietS ,regneiG lacsaP xinU
Networx 78467 Konstanz / \ znatsnoK 76487 xrowteN
& WWW fin...@bluewin.de / \ ed.niweulb@essenif WWW &
T: +49 7531 52709, F: 52739 / \ 93725 :F ,90725 1357 94+ :T
Robert Kiessling
> Dazu kommen noch Carrier, die einem mittelgroßen regional operierenden
> ISP Leitungen aller Art anbieten wollen.
Ein Produkt mit separatem Namen zu haben kann auch einige interessante
Erlebnisse bringen. Ruft doch neulich ein Vertreter eines unserer
Carrier an, uebrigens gut informiert ueber unsere Vertragsbeziehung,
und moechte jemanden von der Netzplanung (oder so) der Firma
<Produktname> sprechen:
"Wie wir wissen, sind sie momenten bei <firma> angeschlossen. Moechten
Sie nicht zu uns wechseln?"
Tja, leider hatte er am Telefon den technischen Leiter der <firma>
erwischt, der sich selbstverstaendlcih erst nach 15min zu erkennen
gegeben hat.
Das war durchaus aufschlussreich.
Robert
Felix von Leitner
> Delphi? Ist so etwas wie Turbopascal, nicht? Haben Sie zwei Stunden
> Zeit? Dann zähle ich Ihnen mal die wichtigsten Gründe auf warum
> Pascalprojekte grundsätzlich scheitern.
Cool, sag mal! ;)
> Java? Schon mal angesehen und ... Wie, Java auf embedded systems?
> [Klick]
Du hast ja keine AHNUNG, wie sehr das um sich greift gerade...
Aber denke über die Alternativen nach!
Im Bereich Digital-Fernsehen werden jedenfalls jetzt gerade die
Standards gemacht, und die Leute stellen sich das so vor, daß man da
ActiveX überträgt. Endlich kann auch der Fernseher Viren haben, und
wenn mein Nachbar erstmal BO2K in seinem Fernseher hat werde ich viel
Spaß haben...
> Auf die Bemerkung hin daß das wir zu einem USP 4 Mbit haben folgte dann
> das Angebot Kompression auf der 2mbit zu fahren.
Der größte Hammer bei solchen Angeboten ist doch, daß die Leute dann
irgendwelche Schmalspur-Router einsetzen, deren CPU nicht mal
ansatzweise in der Lage ist, 2 MBit/s zu komprimieren!
> Mal ehrlich, wer zahlt 1680 DM wenn noch nicht mal eine Seite Fax
> ohne Fehler ist? Ok, Entscheidungsträger.
Habt ihr auch schonmal diese Werbeschreiben vom Interest-Verlag
bekommen, wo sie einem Fachwissen zu TCP/IP und zum Internet (T-Offline)
vermitteln möchten? "Seien Sie einer der ersten, die ... verstanden haben!"
Yeah, right.
> Kann es wirklich sein daß die Verdummung so weit um sich gegriffen hat?
Ja.
Felix
--
Wherever possible put people on hold and leave for the day. Be
comforted that, in the face of all aridity and disillusionment and
despite the changing fortunes of time, there will always be a big
future in computer maintenance.
Georg Bauer
Ohse) wrote:
>Muß die Welt mir das an tun?
Ja. Denn sonst wäre ich der einzige, dem die Welt das antut. Besonders
die tollen Leitungsangebote sind mir sehr bekannt. "Wir sind
Netzbetreiber und bieten Ihnen eine 2-MB-Anbindung an unseren
150-MB-Backbone an". Klar. In Realiter haben die einen per 64KB-Leitung
angebundenen Pop, der dann an einer 2MB-Leitung hängt. Und dann
irgendwann mal bei einem Upstream-Provider landet, der dann woanders
irgendwo dranhängt, wo ein 150-MB-Backbone existiert. Und ich soll mich
dann an den tollen Pop mit 2MB anhängen (nachdem ich ihm sagte, daß 64KB
für uns uninteressant sind)? Kicher. Und Netzbetreiber nennt sich so
einer jetzt? Das einzige Netz, das die betreiben können, ist das
Haaarnetz der Frau des Chefs ...
Wobei ich warscheinlich im Moment noch die witzigeren Angebote bekomme,
da wir wirklich ein kleiner Provider sind. Es ist schon abenteuerlich,
was man alles meint einem Laden in unserer Größenordnung anbieten zu
müssen. Besonders knuffig sind die Angebote zum Wiederverkauf von
Webhosting-Angeboten über andere Provider ...
bye, Georg
Stefan Scholl
> anfangen soll (man beachte die verkorkste Logik [*]). Nicht, daß ich gegen
> solche Anrufe etwas habe, aber Sonntag morgen um 9 Uhr war mir dann doch
> etwas _zu_ daneben! Ich frage mich immer nur, _woher_ diese Menschen
> ihre Infos und vor allem die Telefonnummer haben. Usenet scheinen sie nicht
Kollegen ausfragen.
Die Leute rufen wirklich beliebige Nummern in einer Firma an und
labern drauf los. Notfalls lassen sie sich weiterverbinden.
***Stefan
Sven Paulus
|> Die Leute rufen wirklich beliebige Nummern in einer Firma an und
|> labern drauf los. Notfalls lassen sie sich weiterverbinden.
Kommt mir von den Krankenkassentypen bekannt vor, die staendig durch
die Uni geistern: <gezielt ins Zimmer reinlauf, obwohl am der
Tuerschild nur mein Name steht> "Guten Tag, sind Sie der Herr XY?" -
"Aeh, nein, sollte ich?" - "Nunja, auch egal, ich komme von der Barmer
Ersatzkasse ...". Argh! Das kommt davon, weil Uni-Gebaeude i.A.
keinen Pfoertner haben ...
Ingmar Hupp
Na und? "Nach draussen gehts den Gang runter und dann rechts durch die
Glastuer" - wo ist das Problem, sind weder Kunden noch Vorgesetzte oder
sonstige Wesen die das Heucheln von Respekt erforderlich machen koennten.
--
Ingmar
Aldo Valente
> Mal ehrlich, wer zahlt 1680 DM wenn noch nicht mal eine Seite Fax
> ohne Fehler ist? Ok, Entscheidungsträger.
Eben, einer entwirft das Fax, ein anderer macht die Schulung. Wäre
schlimmer, wenn es nicht so wäre.
Aldo
--
Why are married women heavier than single women?
Single women come home, see what's in the fridge and go to bed.
Married women come home, see what's in bed and go to the fridge.
--Mort Bernstein
Anders Henke
> Mich hat letzte Woche jemand angerufen, der wollte mich
> davon überzeugen, daß alles, was nicht Microsoft und Windows NT ist
> demnächst aufs Abstellgleis rollt und ich doch bei denen als NT-Admin
> anfangen soll
Damit hat er doch vollkommen recht. 10 Millionen Arbeitslose wollen
beschäftigt werden - NT bietet da doch optimale Voraussetzungen.
Ich halte mein NT-3.5-Werbeheftchen "das neue Windows NT macht ihren PC
schneller" in Ehren, immerhin steht da auf der zweiten Seite "4 MB" als
Systemanforderung, in der Mitte dann 16 und am Ende schließlich "32
empfohlen").
> Nicht, daß ich gegen solche Anrufe etwas habe, aber Sonntag morgen um 9 Uhr
> war mir dann doch etwas _zu_ daneben!
Ja. Wie soll man sonst beim geregelten 40-Stunden-Tag seine Arbeit
erledigen?
Unter der Woche liest man News und wird wegen irgendeinem harmlosen
Krempel von der Seite gefragt ("mein Word schmiert ab", "mein Rechner
will seit dem neuen Drucker nicht mehr drucken", "ich habe unsere
Internet-Seiten mit Word überarbeitet, wie bekomme ich die nun auf
unseren Server").
> Ich frage mich immer nur, _woher_ diese Menschen ihre Infos und
> vor allem die Telefonnummer haben.
Garantiert sitzt in deiner Firma irgendein Vertriebsheini, der den
lieben langen Tag nichts anderes zu tun hat als irgendwelche Infos
anzufordern und als Branche immer "Internet", als Telefonnummer
grundsätzlich die Telefonzentrale einträgt.
Auf diese Weise kam ich in der letzten Woche zu einem "Umfrage"-Anruf
aus den USA, bei dem man mir einen Kabeltester und eine "easier
administration for windows"-Software anbieten wollte. Eine Stunde später
rief die gleiche Callcenter-Tante an und wollte mir einen MSCNE-Fernkurs
andrehen ...
grüsse, Anders
--
http://www.sysiphus.de/
Uwe Ohse
>Cool, sag mal! ;)
Man soll noch Pascal ja schnell lernen können (kann ich nicht beurteilen,
ich hab's über einen ziemlich langen Zeitraum hinweg in kleinen Portionen
gelernt). Das wird gerne dahingehend optimiert daß man Pascal dann
auch gleich am ersten Projekt lernt. Die Folge ist "Aua" (was ich dazu
eigentlich zu sagen habe ist nicht für die Öffentlichkeit geeignet).
Man soll mit Pascal ja auch die strukturierte Programmierung lernen
können (das ist richtig. Man muß nur nicht). Das verleitet die ein
Projekt finanzierenden Stellen dazu, auch diese Lernphase in das Projekt
hineinzuverlegen.
Daher, und obwohl eigentlich bei etwas Nachdenken klar sein sollte daß
das Unsinn ist, findet man in vielen Pascal benutzenden Projekten eine
erhöhte Anfänger- und/oder Chaotenzahl.
Die obigen Umstände machen die weiteren Probleme nur noch schlimmer:
* Die Schulung kommt zu kurz. Pascal ist ja so schön schnell zu lernen.
Ich hab's noch nie erlebt daß einer der Pascalprogrammier in meinem
Umfeld geschult worden ist. Learning by doing, on the job? Beim
ständig wachsenden Sprachumfang? Aber nicht im Ernst, oder?
Nun kommt die Schulung überall zu kurz, aber bei anderen Sprachen
bzw. Toolkits ist eine Einarbeitung - oder wenigstens Zeit zum
Selbststudium - in neue Releases nach meiner Erfahrung durchaus
üblich.
* was sich heute Pascal nennt ist eine unglaublich aufgeblasene
Menge Funktionen um einen eigentlich schmalen Sprachkern. Und
es gibt oft genug weit mehr als einen Weg.
Das verführt, ohne strenge Kontrolle bzw. feste Regeln, dazu daß
der Eine dieses Subset der Sprache verwendet, der Andere das Nächste.
Das ist alles andere als wartungsfreundlich.
* das oft genug gehörte Argument der besseren Typsicherheit ist einfach
falsch. Es gibt bei Pascal und Abkömmlingen ebensoviele Wege um
Typprüfungen herum wie bei "g++ -Wall 30*-Wanderes".
Schweinekram ist in Pascal genauso möglich wie überall sonst auch, und
* um Code-Review führt auch bei Pascal kein Weg vorbei. Und er dauert
genauso lange, und erfordert genauso gut ausgebildete und disziplinierte
Leute (wenn man ihn unterläßt sind die Folgen ebenso) wie bei allen
anderen Sprachen.
Code review ist ein Handwerk.
* die Portabilität von praktisch genutzten Pascaldialikten ist bescheiden.
Das Problem mag sich nicht stellen weil Portabilität sowieso nicht
notwendig ist, aber ab und zu ist das ein Fehlschluß.
Und selbst wenn das Projekt niemals portiert wird wird vielleicht
eine Portierung von Libraryfunktionen interessant.
Das Problem stellt sich auf dem Massenmarkt eher weniger, klar (die
Masse portiert sich nicht auf eine andere Plattform. Oder?)
* die Wartung von Pascalprojekten ist ab und an unvorhergesehen teuer.
"Das" (benutzte) Pascal ist als Sprache ziemlich instabil, und
der Hersteller hat die unglückliche Tendenz, seine undokumentierten
Features zu brechen. (Ein auch unter Linux unglücklich häufiges
Phänomen, nur um das mal loszuwerden).
Ich kenne einen Fall in dem das ein heftiges Problem war - die alte
BP-Version war nicht nutzbar (arbeitete mit irgendetwas externem,
unheimlich interessantem, nicht zusammen. Muß wohl 95 gewesen sein),
die Neue verhielt sich ein klein wenig anders bei einer weniger als
halblegalen Sache in der OO-Schnittstelle.
Leider gibt es keine mir bekannte Methode derartige Fallen zu vermeiden
- in soetwas tappen die meisten Leute unbemerkt hinein.
Bei weniger herstellergebundenen Sprachen hat man wenigstens die
Chance, einen anderen Compiler über die Sachen laufen zu lassen und
zu gucken was passiert (die immer wieder mal auftauchenden Alternativen
zu BP sind für größere Sachen im Allgemeinen weniger tauglich).
Und bei standardisierten Sprachen hat man auch die Möglichkeit,
mal im Standard nachzulesen und nicht die Implementierung
auszuprobieren.
(ich schenke mir weitere Bemerkungen über die Vorteile von Standards)
* Pascalcode sieht optisch genauso grauenvoll aus wie jeder andere auch
(Sprachen, die Codeformatierung erzwingen, einmal ausgenommen).
Um wenigstens einmal Code einzustreuen:
if not ((Empfaengernummer = Benutzernummer) or (Sendernummer =
Benutzernummer) or ((Benutzernummer = MausVar.WochenSysop)
and ((Empfaengernummer = - 1) or (Sendernummer = - 1))))
then begin
MsgOk := False;
WriteLn(LogF, '?Mitteilung "', RefId, '" nicht gefunden');
(für die Leute die nicht sehen was ich meine: Die Struktur der
Bedingung ist etwas undurchsichtig)
Codelesbarkeit ist keine Eigenschaft der Sprache, sondern eine
des Programmierers (für indent-Fans: Mit entsprechend gearbeiteten
Makros wird indent nicht fertig).
* nur um das gesagt zu haben: Pascalcode kann genauso gut wie ein
Coredump aussehen wie C.
Was ich mit all dem sagen will ist kurz gefaßt:
a) Pascal hat keine wesentlichen Vorteile gegenüber anderen Sprachen
b) es kommt auf den Programmierer an, nicht auf die Sprache.
c) Erfahrung mag teuer sein, Unerfahrenheit ist teurer.
diese Punkte werden üblicherweise ignoriert, stattdessen wird insbesondere
die Erfahrung gerne mit Pascal umschifft. (daß es erfahrene und gute
Pascalprogrammierer gibt, und sogar jede Menge davon, ist kein
Widerspruch. Es gibt leider noch mehr Schlechte.)
Das ist alles _nicht_ Wirths Schuld.
Apropos Sprache: kann es eigentlich sein daß Programmierer, die
nur in einer Sprache relativ fit sind, auch zu ziemlich einseitigem
(eingleisigem?) Code neigen?
Anders gefragt: kann es sein daß man mindestens zwei Sprachen sprechen
muß bevor man vernünftigen Code schreiben kann?
>Du hast ja keine AHNUNG, wie sehr das um sich greift gerade...
>Aber denke über die Alternativen nach!
Diesen Unsinn bleiben lassen?
Ich _habe_ Ahnung wie sehr das um sich greift.
Und ich ziehe es eindeutig vor daß meine Armbanduhr strohdoof
bleibt und keine Viren, Applets oder Makroviren die vorhandenen
Pufferüberläufe, Sicherheitsprobleme, Vorzeichenfehler und allgemeine
Programmiererkurzsichtigkeit ausnutzen.
Oder in meinem Herzschrittmacher, natürlich.
Obwohl es bestimmt spaßig wird die Vertreter der jeweiligen Konkurrenz
durch Manipulation ihrer Bordcomputer in den Straßengraben zu schicken
oder im Kreis fahren zu lassen. Oder ihre Wecker zwar um 1,2,4 Uhr
schellen zu lassen, aber eben nicht um 7.
Was mich mal wieder daran erinnert daß ich mir noch eine neue Stereoanlage
besorgen sollte bevor die ohne Netz nicht mehr funktioniert ...
>Habt ihr auch schonmal diese Werbeschreiben vom Interest-Verlag
>bekommen, wo sie einem Fachwissen zu TCP/IP und zum Internet (T-Offline)
>vermitteln möchten? "Seien Sie einer der ersten, die ... verstanden haben!"
Ja. Gestern trudelte hier noch ein Wisch eines Distributors ein,
Kundenseminar über Unsicherheit im Netzwerk. 4 Stunden, von denen knapp 60
Minuten für Begrüßung, Kaffeepause und Schlußwort draufgehen. Und danach
versteht man dann Firewalling, Authentisierung, Datenverschlüsselung,
IPSec und VPN.
Kinder, Kinder - selbst für ein kostenloses Mittagessen tu' ich mir das
nicht an. IPSec in drei Stunden? Das gibt Kopfschmerzen, so schnell bin
ich nicht.
>Ja.
Kritiklose Einstellung gegenüber der Technik und leichtfertiges Vertrauen
Unbekannten gegenüber. Nun denn.
>there will always be a big future in computer maintenance.
oh ja.
Gruß, Uwe
--
Unfortunately, most programmers like to play with new toys. I have many
friends who, immediately upon buying a snakebite kit, would be tempted
to throw the first person they see to the ground, tie the tourniquet
on him, slash him with the knife, and apply suction to the wound.
-- Jon Bentley, _writing efficient programs_
Uwe Ohse
konkreter: ich weiß nicht welcher Verlag das war, aber der Satz ist bekannt.
Matthias Heidbrink
UO>Man soll noch Pascal ja schnell lernen können (kann ich nicht
UO>beurteilen, ich hab's über einen ziemlich langen Zeitraum hinweg in
UO>kleinen Portionen gelernt). Das wird gerne dahingehend optimiert daß
UO>man Pascal dann auch gleich am ersten Projekt lernt.
Ehrlich gesagt, das funktioniert auch in ziemlich allen anderen Sprachen ;-)) .
UO>Die Folge ist "Aua" (was ich dazu eigentlich zu sagen habe ist nicht
UO>für die Öffentlichkeit geeignet).
UO>
UO>Man soll mit Pascal ja auch die strukturierte Programmierung lernen
UO>können (das ist richtig. Man muß nur nicht).
Auf der anderen Seite hat (Borland) Pascal Strukturierungsmittel wie Nested
Functions (OK, der GCC packt das auch, aber das ist kein Standard-C) und ein
echtes Modulkonzept.
UO>* das oft genug gehörte Argument der besseren Typsicherheit ist einfach
UO> falsch. Es gibt bei Pascal und Abkömmlingen ebensoviele Wege um
UO> Typprüfungen herum wie bei "g++ -Wall 30*-Wanderes".
Natürlich. Besonders, wenn man im C-Umfeld programmiert, wo kein Mensch saubere
Typdefinitionen macht, sondern für alles Standardtypen, wilde
Pointerkonstruktionen und Konstanten-Flags verwendet.
Außerdem: Man kann in Pascal Schweinekram programmieren, aber es passiert nicht
versehentlich und im Gegensatz zu C sieht man solche Stellen im Code. Und wenn
man schon Schweinekram programmieren muß, dann finde ich eine lokale Variable
mit "absolute" wesentlich sauberer als wilde Pointerkonstruktionen in C.
Low-Level-Programmierung in Java ist dagegen eine Strafe...
UO>* die Portabilität von praktisch genutzten Pascaldialikten ist
UO>bescheiden.
Leider.
UO> Und selbst wenn das Projekt niemals portiert wird wird vielleicht
UO> eine Portierung von Libraryfunktionen interessant.
Das ist eher weniger das Problem, man muß sich allerdings auf einen definierten
Sprachumfang einigen.
UO>* die Wartung von Pascalprojekten ist ab und an unvorhergesehen teuer.
UO> "Das" (benutzte) Pascal ist als Sprache ziemlich instabil, und
UO> der Hersteller hat die unglückliche Tendenz, seine undokumentierten
UO> Features zu brechen. (Ein auch unter Linux unglücklich häufiges
UO> Phänomen, nur um das mal loszuwerden).
Deshalb sind diese Features ja undokumentiert ;-) . Es ist, glaube ich, relativ
häufig, daß das, was ein Compiler schluckt, nicht 100%ig der Sprachdefinition
entspricht. Oder die Sprachdefinition mehrdeutig ist ;-)) .
UO>* Pascalcode sieht optisch genauso grauenvoll aus wie jeder andere auch
UO> (Sprachen, die Codeformatierung erzwingen, einmal ausgenommen).
UO> Um wenigstens einmal Code einzustreuen:
UO> if not ((Empfaengernummer = Benutzernummer) or (Sendernummer =
UO> Benutzernummer) or ((Benutzernummer = MausVar.WochenSysop)
UO> and ((Empfaengernummer = - 1) or (Sendernummer = - 1))))
Original-MAUS-Sourcen?-) Mal ganz abgesehen davon, daß ich persönlich die
Einrückungen anders mache, denke ich, daß ein gut formatierter Pascal-Source
besser lesbar ist als ein gut formatierter C-Source.
Dazu kommt, daß Pascal es einfacher macht, aussagekräftige Bezeichner zu
verwenden.
UO>Apropos Sprache: kann es eigentlich sein daß Programmierer, die
UO>nur in einer Sprache relativ fit sind, auch zu ziemlich einseitigem
UO>(eingleisigem?) Code neigen?
UO>Anders gefragt: kann es sein daß man mindestens zwei Sprachen sprechen
UO>muß bevor man vernünftigen Code schreiben kann?
Es gibt allgemeine Strukturen, z. B. einen Algorithmus wie Quicksort oder eine
Idee wie Modularisierung. Und es gibt sprachspezifische Strukturen, zum einen
Lösungen, die in einer Sprache eleganter sind als in einer anderen und deshalb
vorzuziehen sind, zum anderen, weil bestimmte Sprachen bestimmte Strukturen gar
nicht erst ermöglichen.
Jemand, der in Lisp programmiert, gehört erschlagen, wenn er Quicksort
verwendet und nicht Mergesort, weil letzerer eben besser zu der Struktur seiner
Programmiersprache paßt.
Wenn ich zum Beispiel in Pascal programmiere, mache ich Sachen mit Strings, die
ein C-Programmierer niemals tun könnte, weil er keine vollwertige
Stringunterstützung zur Verfügung hat. Zum Beispiel nehme ich sie manchmal als
Datenpuffer. Ich arbeite auch viel mit Nested Functions, um Codeduplikation und
gelegentlich auch Tipparbeit zu vermeiden. Und diese Sachen fehlen mir
furchtbar, wenn ich in C arbeiten muß.
Mittlerweile mache ich einen Sport draus, möglichst viele Betriebssysteme (und
ggf. die Hardware dazu) zu haben, damit ich mir möglichst viele verschiedene
Möglichkeiten ansehen kan, wie man ein Problem löst. Inzwischen habe ich ein
Gefühl dafür, ob ein Programm von jemandem geschrieben wurde, der nichts
besseres als Windows kennt oder dessen Religion UNIX heißt ;-) .
UO>Ich _habe_ Ahnung wie sehr das um sich greift.
UO>Und ich ziehe es eindeutig vor daß meine Armbanduhr strohdoof
UO>bleibt und keine Viren, Applets oder Makroviren die vorhandenen
UO>Pufferüberläufe, Sicherheitsprobleme, Vorzeichenfehler und allgemeine
UO>Programmiererkurzsichtigkeit ausnutzen.
Add me ;-)
Ciao, Matthias
Florian Weimer
> Auf der anderen Seite hat (Borland) Pascal Strukturierungsmittel wie Nested
> Functions (OK, der GCC packt das auch, aber das ist kein Standard-C) und ein
> echtes Modulkonzept.
Allerdingsh hat Pascal nur einen sehr flachen Namensraum. Bei großen
Projekten kann das ein Nachteil sein.
> UO>* das oft genug gehörte Argument der besseren Typsicherheit ist einfach
> UO> falsch. Es gibt bei Pascal und Abkömmlingen ebensoviele Wege um
> UO> Typprüfungen herum wie bei "g++ -Wall 30*-Wanderes".
>
> Natürlich. Besonders, wenn man im C-Umfeld programmiert, wo kein
> Mensch saubere Typdefinitionen macht, sondern für alles
> Standardtypen, wilde Pointerkonstruktionen und Konstanten-Flags
> verwendet.
So streng typisiert ist Pascal auch nun wieder nicht. (Strenger als
C allemal, aber das sagt ja wohl nichts.) Zum Beispiel kann man nicht
verschiedene Integer-Typen deklarieren, die nicht automatisch ineinander
konvertiert werden.
> UO>* die Portabilität von praktisch genutzten Pascaldialikten ist
> UO>bescheiden.
>
> Leider.
Deswegen nimmt man auch Ada. *duck*
> UO>Anders gefragt: kann es sein daß man mindestens zwei Sprachen sprechen
> UO>muß bevor man vernünftigen Code schreiben kann?
Zwei reichen wohl nicht ganz. Drei oder vier mit verschiedenen Paradigmen
sollten es schon sein.
Lutz Donnerhacke
>Deswegen nimmt man auch Ada. *duck*
*aufsteh*
Lutz Donnerhacke
>Jemand, der in Lisp programmiert, gehört erschlagen, wenn er Quicksort
>verwendet und nicht Mergesort, weil letzerer eben besser zu der Struktur
>seiner Programmiersprache paßt.
Nein. Es zeigt nur die Beschränktheit von Lisp.
Marc Haber
>Matthias_...@b.maus.de (Matthias Heidbrink) writes:
>> Auf der anderen Seite hat (Borland) Pascal Strukturierungsmittel wie Nested
>> Functions (OK, der GCC packt das auch, aber das ist kein Standard-C) und ein
>> echtes Modulkonzept.
>
>Projekten kann das ein Nachteil sein.
Ich habe es damals sehr genossen, nur lokal benötigte Hilfs-Funktionen
und -Prozeduren auch nur innerhalb der größeren Funktion/Prozedur
deklarieren zu können, wo sie benötigt werden.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Tilman Schmidt
>
> Na und? "Nach draussen gehts den Gang runter und dann rechts durch die
> Glastuer" - wo ist das Problem, sind weder Kunden noch Vorgesetzte oder
> sonstige Wesen die das Heucheln von Respekt erforderlich machen koennten.
Wie sagt man so schön? Eine gute Erziehung ist ein Handicap fürs Leben.
--
Tilman Schmidt E-Mail: Tilman....@sema.de (office)
Sema Group Koeln, Germany til...@schmidt.bn.uunet.de (private)
"newfs leaves the filesystem in a well known state (empty)."
- Henrik Nordstrom
Ullrich Jans
> Deshalb sind diese Features ja undokumentiert ;-) . Es ist, glaube
> ich, relativ häufig, daß das, was ein Compiler schluckt, nicht
> 100%ig der Sprachdefinition entspricht. Oder die Sprachdefinition
> mehrdeutig ist ;-)) .
Mir faellt da ein Compiler ein, der eine Zweideutigkeit in der
Sprachdefinition je nach Mondphase interpretiert... [1]
Gruss, Ulli
[1] Allerdings per Kommandozeilenoption abschaltbar [2]
[2] Bei Bedarf kann ich ja mal schauen, wo der im Netz liegt...
--
Ullrich Jans Kaiserstr. 1
Tel: +49 721 375446 76131 Karlsruhe
Usenet: un...@rz.uni-karlsruhe.de RealUlli@IRC
Holger Spielmann
> Deswegen nimmt man auch Ada. *duck*
Ada ist der gelungene Versuch, die Schwächen von C, Pascal und
Fortran in einer Sprache zu vereinigen.
--
___Holger Spielmann,_D-39124_Magdeburg___
Public key available - see: http://tpp24.net/spielmann/holger/
Rudi Schlatte
> Jemand, der in Lisp programmiert, gehört erschlagen, wenn er
> Quicksort verwendet und nicht Mergesort, weil letzerer eben besser
> zu der Struktur seiner Programmiersprache paßt.
<Pedant>
Außer, er will ein Array sortieren...
(eq |Lisp 1.5| |Common-Lisp|)
=> NIL
</Pedant>
Camillo Klemd
>* Florian Weimer wrote:
>>Deswegen nimmt man auch Ada. *duck*
*grossen vorschlaghammer reich*
*grins*
ff! millo
--
| DI Camillo Klemd | CVG mbH Chemnitz | Softwareschmied
| camill...@cvg.de | CK768-RIPE | & Sysadmin
+----------------------+------------------+----------------
| Auch bei Wahrheiten muß man auf das Verfallsdatum achten.
Lutz Donnerhacke
>In article <slrn7skd4...@taranis.iks-jena.de>, lu...@iks-jena.de (Lutz Donnerhacke) wrote:
>>* Florian Weimer wrote:
>>>Deswegen nimmt man auch Ada. *duck*
>>*aufsteh*
>
>*grossen vorschlaghammer reich*
Was soll ich damit? Ada ist deutlich besser als diese unportablen
Makroassembler wie C oder dessen Aufbohrungen um beneidete Features aus
Smalltalk.
Man kann in Ada portabel auf manschinenabhängige Strukturen zugreifen.
Man kann in Ada beweisbar korrekte Programme schreiben, ohne den
Sprachumfang erheblich zu beschränken.
Man kann in Ada struturierte Datentypen wie Elemtentare behandeln.
Und der wichtigste Grund: Markus Kuhn mag Ada.
Robert Kiessling
> Und der wichtigste Grund: Markus Kuhn mag Ada.
Er mochte auch einmal OSI.
Robert
Uwe Ohse
>Ehrlich gesagt, das funktioniert auch in ziemlich allen anderen Sprachen ;-)) .
Ja. Aber so extrem hab' ich das regelmäßig bei Pascal gesehen, nirgendwo
sonst.
>Auf der anderen Seite hat (Borland) Pascal Strukturierungsmittel wie Nested
"können". Ja.
>Außerdem: Man kann in Pascal Schweinekram programmieren, aber es passiert nicht
>versehentlich und im Gegensatz zu C sieht man solche Stellen im Code. Und wenn
>man schon Schweinekram programmieren muß, dann finde ich eine lokale Variable
>mit "absolute" wesentlich sauberer als wilde Pointerkonstruktionen in C.
mir ist der gravierende Unterschied zwischen beidem nicht klar.
Ob nun ein Teppich über dem Hundehaufen liegt oder nicht ...
>Original-MAUS-Sourcen?-)
Ja. Der einzige greifbare Pascalsource mit der Eigenschaft, zwar
prinzipiell lesbar, aber eben unleserlich formatiert zu sein. Eine der
besseren Stellen darin, sollte ich vielleicht dazu erwähnen. So wenig
irreführende Variablennamen sind an anderen Stellen rar.
>Einrückungen anders mache, denke ich, daß ein gut formatierter Pascal-Source
>besser lesbar ist als ein gut formatierter C-Source.
Ich denke daß gut geschriebener Code in allen Sprachen gut lesbar ist.
(Intercal hat einfach das Problem daß es keinen gut geschriebenen
Intercal Code geben kann.)
>Dazu kommt, daß Pascal es einfacher macht, aussagekräftige Bezeichner zu
>verwenden.
Jaja. Pascalcompiler verweigern die Arbeit wenn nur als 70% der
Variablennamen nur einen Buchstaben lang sind. Und Vokale weggelassen
werden.
Ach, nicht?
Wir reden hier übrigens nicht über irgendwelche Steinzeitlinker, die
nur 6 Zeichen lange Bezeichner zulassen.
>Wenn ich zum Beispiel in Pascal programmiere, mache ich Sachen mit Strings, die
>ein C-Programmierer niemals tun könnte, weil er keine vollwertige
>Stringunterstützung zur Verfügung hat.
wir interpretieren "vollwertige Stringunterstützung" völlig unterschiedlich.
>Zum Beispiel nehme ich sie manchmal als Datenpuffer.
Ein Weg um Typprüfungen herum. Wiederholung:
>UO>* das oft genug gehörte Argument der besseren Typsicherheit ist einfach
>UO> falsch. Es gibt bei Pascal und Abkömmlingen ebensoviele Wege um
>UO> Typprüfungen herum wie bei "g++ -Wall 30*-Wanderes".
>Ich arbeite auch viel mit Nested Functions, um Codeduplikation und
>gelegentlich auch Tipparbeit zu vermeiden. Und diese Sachen fehlen mir
>furchtbar, wenn ich in C arbeiten muß.
Nested functions um Codeduplication zu vermeiden?
Functions schreibt man _deshalb_. Nested functions schreibt man um den
Namensraum sauberer zu halten.
Und das ist, nebenbei bemerkt, nur ein kläglicher Ersatz für richtige
Namensräume, und sollte schon wegen des von Dir erwähnten "echten"
Modulkonzeptes nicht nötig sein.
Nein, mit nested functions kann ich mich nicht anfreunden, was auch
daran liegt daß man sie in C auch ganz prima als "static" functions
in entsprechend kleinen Quelltexten schreiben kann, ohne etwas zu
verlieren. Und das ist eben nicht das Wahre.
Gruß, Uwe
Walter Koch
lu...@iks-jena.de (Lutz Donnerhacke) schrieb/wrote
>Ada ist deutlich besser als diese unportablen
>Makroassembler wie C oder dessen Aufbohrungen um beneidete Features aus
>Smalltalk.
Falls Du Doppel Plus C meinst: Welche?
>Und der wichtigste Grund: Markus Kuhn mag Ada.
Och?
Gruss,
Walter
--
Walter Koch Hochdahl am Neandertal
http://www.hsp.de/~koch/ qrv:db0iz-9
wal...@1409.org ham:dg9ep@db0iz
ko...@hsp.de
Florian Weimer
> >Allerdingsh hat Pascal nur einen sehr flachen Namensraum. Bei großen
> >Projekten kann das ein Nachteil sein.
Eigentlich bezog ich mich auf das beschissene Unit-Konzept von Turbo
Pascal (ein anderes kenne ich nicht). Da aber Mr. Wirth nicht einmal
bei Modula-2 das Problem der zirkulären Importe und der `elaboration
order'[1] in den Griff bekommen hat, denke ich, daß sich da aber nicht
viel getan hat. Schließlich müllt man noch mit jedem `use' den globalen
Namespace ein wenig mehr zu, außerdem gibt es keine geschachtelten Units.
> Ich habe es damals sehr genossen, nur lokal benötigte Hilfs-Funktionen
> und -Prozeduren auch nur innerhalb der größeren Funktion/Prozedur
> deklarieren zu können, wo sie benötigt werden.
`Nested functions' (oder wie man das sonst nennen möchte) sind nicht
ganz so trivial zu implementieren[2], wenn man den Unterschied zu
Library-Level-Funktionen gering halten möchte (Effizienz, Funktionszeiger
etc.). Ich bin jetzt zu faul auszuprobieren, inwieweit die Pascal-Version
diesen Anforderungen genügt und dabei noch verhindert, daß man aus
Unwissenheit dumme Sachen anstellt.
[1] Eigentlich ein Ada-Terminus. Hier: Reihenfolge, in der der
Initialisierungscode der Units ausgeführt wird.
[2] Es sei denn, man hat Closures. ;)
Matthias Heidbrink
UJ>Mir faellt da ein Compiler ein, der eine Zweideutigkeit in der
UJ>Sprachdefinition je nach Mondphase interpretiert... [1]
Welcher ist das?-)
Bei uns an der Uni wurde eine Programmiersprache (OPAL) entwickelt, bei der
nichtdeterministische Auswertungen sogar ein Feature der Sprache sind.
Allerdings geht es da nicht um Lücken in der Sprachdefinition, sondern darum,
daß der Programmierer in dieser Sprache im Quelltext ausdrücken kann, daß er
eine Entscheidung zwischen verschiedenen Möglichkeiten offen lassen möchte.
Ciao, Matthias
Matthias Heidbrink
FW>Matthias_...@b.maus.de (Matthias Heidbrink) writes:
FW>
> Auf der anderen Seite hat (Borland) Pascal Strukturierungsmittel wie
>Nested Functions (OK, der GCC packt das auch, aber das ist kein
>Standard-C) und ein echtes Modulkonzept.
FW>
FW>Allerdingsh hat Pascal nur einen sehr flachen Namensraum. Bei großen
FW>Projekten kann das ein Nachteil sein.
Du meinst, weil es keine geschachtelten Units gibt? Es gibt Leute, die verrückt
genug sind, große Projekte in einer Sprache zu schreiben, die nur einen
einzigen Namensraum (plus eine Möglichkeit, lokale Bezeichner zu definieren)
hat.
FW>So streng typisiert ist Pascal auch nun wieder nicht. (Strenger als C
FW>allemal, aber das sagt ja wohl nichts.) Zum Beispiel kann man nicht
FW>verschiedene Integer-Typen deklarieren, die nicht automatisch
FW>ineinander konvertiert werden.
Du hast recht, allerdings ist auch die Frage, ob es nicht Overkill wäre, an
allen diesen Stellen explizite Casts zu fordern oder gar überhaupt keine
Umwandlungen machen zu können. Außerdem gibt es wenigstens Range Checking.
Viele der Dinge, die man in C mit Integertypen machen würde, kann man mit
Aufzählungstypen und z. B. Mengen nachen. Dann ist es sicher.
FW>Deswegen nimmt man auch Ada. *duck*
Ich habe gar nichts gegen Ada, außer daß die Sprache den gleichen Nachteil wie
C++ hat, zu groß zu sein und daß ich noch kein Entwicklungssystem dafür gesehen
habe, das an Delphi rankommt.
Ciao, Matthias
Matthias Heidbrink
[händereib] Bist Du dicher, daß wir nicht doch lieber nach
maus.wissenschaft.informatik gehen sollten?
[weggesparte Einarbeittungszeit]
>Ehrlich gesagt, das funktioniert auch in ziemlich allen anderen Sprachen
>;-)) .
UO>Ja. Aber so extrem hab' ich das regelmäßig bei Pascal gesehen,
UO>nirgendwo sonst.
Ehrlich gesagt, ich kenne das nicht anders. Wenn jemand behauptet, daß er in
einer Schulung von ein paar Tagen eine Programmiersprache und Programmieren
gelernt hätte, dann muß das einfach schiefgehen.
Meine Theorie zu Deiner Erfahrung ist, daß Du das wahrscheinlich deshalb
gesehen hast, weil es in Pascal schlecht geht, aber in C-Sprachen so viel
schlechter geht, daß man die Ergebnisse nach /dev/null entsorgt, anstatt sie
jemandem zu zeigen. Das als Vorteil von C anzusehen, dazu kann ich mich
allerdings nicht durchringen.
>Außerdem: Man kann in Pascal Schweinekram programmieren, aber es passiert
>nicht versehentlich und im Gegensatz zu C sieht man solche Stellen im
>Code. Und wenn man schon Schweinekram programmieren muß, dann finde ich
>eine lokale Variable mit "absolute" wesentlich sauberer als wilde
>Pointerkonstruktionen in C.
UO>
UO>mir ist der gravierende Unterschied zwischen beidem nicht klar.
UO>Ob nun ein Teppich über dem Hundehaufen liegt oder nicht ...
Der Unterschied ist, wenn der ganze Fußboden mit Hundehaufen übersät ist (C),
dann macht das keinen Unterschied mehr. In Pascal gibt es aber nur relativ
wenige Sprachkonstruktionen, mit denen man Schweinekram machen kann, z. B.
"absolute", explizite Casts oder untypisierte/uninitialisierte Pointer. Wobei
man sehr viel weniger Casts und Pointer braucht als in C.
>Einrückungen anders mache, denke ich, daß ein gut formatierter
>Pascal-Source besser lesbar ist als ein gut formatierter C-Source.
UO>
UO>Ich denke daß gut geschriebener Code in allen Sprachen gut lesbar ist.
UO>(Intercal hat einfach das Problem daß es keinen gut geschriebenen
UO>Intercal Code geben kann.)
Was ist Intercal? Und außerdem soll es ja Leute geben, die Line Noise viel,
viel besser finden als eine Sprache, die zumindest die elementaren
Schlüsselwörter erzwingt. If it was hard to write, it should be hard to read
;-) .
>Dazu kommt, daß Pascal es einfacher macht, aussagekräftige Bezeichner zu
>verwenden.
UO>
UO>Jaja. Pascalcompiler verweigern die Arbeit wenn nur als 70% der
UO>Variablennamen nur einen Buchstaben lang sind. Und Vokale weggelassen
UO>werden. Ach, nicht?
UO>Wir reden hier übrigens nicht über irgendwelche Steinzeitlinker, die
UO>nur 6 Zeichen lange Bezeichner zulassen.
Ich meine folgendes: Wenn Du mehrfach geschachtelte Namensräume, Objekte oder
Records hast, wo Zugriffe auf ein inneres Element erfolgen, so tippt man sich
in C-Sprachen die Pfoten wund. Deshalb verwendet jeder C-Programmierer, den ich
kenne, möglichst kurze (und kryptische) Bezeichner.
In Pascal-Sprachen habe ich einen Befehl zum Umschalten des Namensraums, damit
habe ich das Problem nicht.
>Wenn ich zum Beispiel in Pascal programmiere, mache ich Sachen mit
>Strings, die ein C-Programmierer niemals tun könnte, weil er keine
>vollwertige Stringunterstützung zur Verfügung hat.
UO>
UO>wir interpretieren "vollwertige Stringunterstützung" völlig
UO>unterschiedlich.
Ich meine Stringunterstützung, die funktioniert und nicht, daß die Sprache ein
"Feature" bietet, konstante Arrays und Pointer darauf in einem einzigen Schritt
zu definieren.
Was glaubst Du, warum kaum ein in C geschriebenes Programm brauchbare
Fehlermeldungen oder detailierte Debuggingausgaben auszugeben (womit nicht
meine, "segmentation violation - core dumped" und auch nicht nichtssagende
Fehlernummern oder endlose Speicher-Hexdumps, sondern etwas lesbares)? Weil es
in C viel mehr Arbeit ist, das ordentlich zu programmieren, als hin und wieder
eine Fehlernummer im Source nachzusehen. In Borland Pascal dagegen kann man so
was tatsächlich programmieren und während der Programmentwicklung auch noch
Zeit sparen.
>Zum Beispiel nehme ich sie manchmal als Datenpuffer.
UO>
UO>Ein Weg um Typprüfungen herum.
Muß nicht sein. Lies zum Beispiel mal Daten von einem Modem und versuch', darin
Modemmeldungen zu erkennen. In Pascal lese ich Chars von dem Gerät, packe sie
an einen String dran und kann dann Stringmatching machen, ohne daß es stört,
wenn da mal ein Nullbyte dazwischen ist.
>Ich arbeite auch viel mit Nested Functions, um Codeduplikation und
>gelegentlich auch Tipparbeit zu vermeiden. Und diese Sachen fehlen mir
>furchtbar, wenn ich in C arbeiten muß.
UO>Nested functions um Codeduplication zu vermeiden?
UO>Functions schreibt man _deshalb_.
UO>Nested functions schreibt man um den Namensraum sauberer zu halten.
Eben. Und weil Namensräume niemals größer sein sollten als nötig, müssen
Funktionen, die nur lokal gebraucht werden, auch lokal definiert werden können.
Das wird sogar effizienter, weil Nested Functions auf Parameter und z. T.
Variablen der übergeordneten Funktion zugreifen können.
Ich habe einmal einen mehrfach rekursiven Graphalgorithmus schreiben müssen,
der genau diese Eigenschaft ausgenutzt hat. Er hatte zwei Nested Funktions, die
auf dem Graphen gearbeitet haben, der der Prozedur übergeben wurde und die sich
gegenseitig und auch noch die äußere Prozedur rekursiv aufgerufen haben.
Hätte man diese Aufgabe in einer C-Sprache lösen wollen, so hätte man für das,
was da mit lokalen Variablen gelöst wurde, eine eigene Stackverwaltung
schreiben und einige der Parameter kopieren müssen. Wesentlich mehr Aufwand,
wesentlich mehr Fehlerquellen, wesentlich weniger Effizienz.
UO>Und das ist, nebenbei bemerkt, nur ein kläglicher Ersatz für richtige
UO>Namensräume, und sollte schon wegen des von Dir erwähnten "echten"
UO>Modulkonzeptes nicht nötig sein.
Ich kenne keine Programmiersprache, die Namensräume oder ein Modulkonzept hat,
die das gleiche können, was Nested Functions leisten. Wenn es das gäbe, dann
müßte es zwangsläufig so aufwendig zu benutzen sein, daß es niemand benutzen
würde und die Autoren würden zwangsläufig daraus folgern, daß Nested Functions
in keinem Verältnis zum AUfwand stünden. Genau wie die C++-Leute anscheinend
den Boolean-Datentyp in ihre Sprache aufgenommen haben, der in allen (oder fast
allen?) Situationen zu den üblichen Integers zuweisungskompatibel ist, um zu
beweisen, daß niemand einen Boolean-Datentyp braucht.
Und ehe Du fragst, Stroustrup hat auch nicht verstanden, was der Unterschied
zwischen Namensräumen und Modulkonzept ist. Wirth hat es bei Modula-2
verstanden, deshalb kann es da Module innerhalb von Modulen geben, aber keine
Module, die über 1000 Dateien zersplittert sind, sodaß man nichts mehr
wiederfindet.
UO>Nein, mit nested functions kann ich mich nicht anfreunden, was auch
UO>daran liegt daß man sie in C auch ganz prima als "static" functions in
UO>entsprechend kleinen Quelltexten schreiben kann, ohne etwas zu
UO>verlieren.
Und wenn Du es tausendmal wiederholst, es stimmt nicht. Siehe Beispiel oben.
Ciao, Matthias
Kristian Koehntopp
>Muß nicht sein. Lies zum Beispiel mal Daten von einem Modem und versuch', darin
>Modemmeldungen zu erkennen. In Pascal lese ich Chars von dem Gerät, packe sie
>an einen String dran und kann dann Stringmatching machen, ohne daß es stört,
>wenn da mal ein Nullbyte dazwischen ist.
Ein Entwickler, der sein Geld wert ist, liest Statusmeldungen
von einem Modem, indem er einen Knuth-Morris-Pratt-Matcher
("Algorithms", Sedgewick, pp. 280-285.) implementiert, also
quasi ein Array von Automaten erzeugt, die durch die
einkommenden Zeichen betrieben werden. Auf diese Weise erspart
man sich nicht nur Probleme mit Nullbytes, gleich in welcher
Sprache, sondern auch das vollkommen zweckbefreite Durchziehen
von Strings durch ein Array und den noch sinnloseren Aufwand von
n Stringvergleichen der Länge m für jedes gelesene Zeichen.
Kristian
--
Kristian Koehntopp, Knooper Weg 46, 24103 Kiel, +49 170 2231 811
"We must be the change we wish to see"
-- Ganhdi, also a proper Linux motto.
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) schrieb/wrote
>>Ada ist deutlich besser als diese unportablen
>>Makroassembler wie C oder dessen Aufbohrungen um beneidete Features aus
>>Smalltalk.
>
>Falls Du Doppel Plus C meinst: Welche?
Eigentlich meine ich C doppel plus (falscher Ansatz) vs. Objective-C
(richtiger Ansatz)
Camillo Klemd
>Was soll ich damit? Ada ist deutlich besser als diese unportablen
>Makroassembler wie C oder dessen Aufbohrungen um beneidete Features aus
>Smalltalk.
also es tut mir ja unendlich leid, aber bei ada denke ich immer zuerst an ein
reinigungs-scheuermittel aus DDR-zeiten. aber ich gebe gern zu: auch das hat
bestens funktioniert...
Frank Doepper
> Ich meine folgendes: Wenn Du mehrfach geschachtelte Namensräume, Objekte
> oder Records hast, wo Zugriffe auf ein inneres Element erfolgen, so tippt
> man sich in C-Sprachen die Pfoten wund. Deshalb verwendet jeder
> C-Programmierer, den ich kenne, möglichst kurze (und kryptische)
> Bezeichner.
In Pascal tippt man sich aber *immer* die Pfoten wund. ;-)
F.
--
http://home.pages.de/~woffs/ FD581-RIPE
Ignatios Souvatzis
Dafür entwickelt ihr eine eigene Sprache?
switch(random()) {
case 1: dies(); break;
case 2: jenes(); break;
default: keineahnung(); break;
}
--
* Progress (n.): The process through which Usenet has evolved from
smart people in front of dumb terminals to dumb people in front of
smart terminals. -- o...@burnout.demon.co.uk (obscurity)
Ullrich Jans
> UJ>Mir faellt da ein Compiler ein, der eine Zweideutigkeit in der
> UJ>Sprachdefinition je nach Mondphase interpretiert... [1]
> Welcher ist das?-)
Die Sprache ist Sather-K, der Compiler heisst FIASCO ("Fiasco Is A
Sather COmpiler").
Leider musste der Compiler anscheinend umbenannt werden, und zwar in SAK.
Sourcen und die Doku finden sich bei:
ftp://i44ftp.info.uni-karlsruhe.de/pub/sather
Das beste ist die Doku... ;-))
Gruss, Ulli
Holger Kipp
> UO>Ja. Aber so extrem hab' ich das regelmäßig bei Pascal gesehen,
> UO>nirgendwo sonst.
>
> Ehrlich gesagt, ich kenne das nicht anders. Wenn jemand behauptet, daß er in
> einer Schulung von ein paar Tagen eine Programmiersprache und Programmieren
> gelernt hätte, dann muß das einfach schiefgehen.
>
> Meine Theorie zu Deiner Erfahrung ist, daß Du das wahrscheinlich deshalb
> gesehen hast, weil es in Pascal schlecht geht, aber in C-Sprachen so viel
> schlechter geht, daß man die Ergebnisse nach /dev/null entsorgt, anstatt sie
> jemandem zu zeigen. Das als Vorteil von C anzusehen, dazu kann ich mich
> allerdings nicht durchringen.
>
> >Außerdem: Man kann in Pascal Schweinekram programmieren, aber es passiert
> >nicht versehentlich und im Gegensatz zu C sieht man solche Stellen im
> >Code. Und wenn man schon Schweinekram programmieren muß, dann finde ich
> >eine lokale Variable mit "absolute" wesentlich sauberer als wilde
> >Pointerkonstruktionen in C.
> UO>
> UO>mir ist der gravierende Unterschied zwischen beidem nicht klar.
> UO>Ob nun ein Teppich über dem Hundehaufen liegt oder nicht ...
Also sowas haengt doch immer vom Hundehalter und dem Teppichbesitzer ab...
Gute Programmierer koennen in jeder Sprache guten Code von sich geben.
Allgemein muesste sich also etwa folgende Funktion ergeben:
verfuegbare Zeit
Programmguete = Programmiererguete * ---------------- * Sprachenguete
benoetigte Zeit
Programmiererguete und Sprachenguete sind hier natuerlich keine festen Werte
sondern haengen vom zu loesenden Problem und weiteren Faktoren ab. So aendert
sich die Programmiererguete (PG) je Programmierer in Abhaengigkeit vom Problem
und der Zeit. So steigt die PG je Problem langsam an, erreicht nach einigen
Jahren / Jahrzehnten ihren Hoehepunkt und laesst dann wieder nach, um
schliesslich schlagartig wieder auf 0 zurueckzugehen.
Man kann hier schon deutlich sehen, dass SAP-Programme in ABAP (Sprachenguete
liegt etwa bei 0,2 ;-) auch bei ueberdurchschnittlichen Programmierern weitaus
mehr Zeit zur Implementierung benoetigen, um eine akzeptable Qualitaet zu
erreichen...
> Ich habe einmal einen mehrfach rekursiven Graphalgorithmus schreiben müssen,
> der genau diese Eigenschaft ausgenutzt hat. Er hatte zwei Nested Funktions, die
> auf dem Graphen gearbeitet haben, der der Prozedur übergeben wurde und die sich
> gegenseitig und auch noch die äußere Prozedur rekursiv aufgerufen haben.
> Hätte man diese Aufgabe in einer C-Sprache lösen wollen, so hätte man für das,
> was da mit lokalen Variablen gelöst wurde, eine eigene Stackverwaltung
> schreiben und einige der Parameter kopieren müssen. Wesentlich mehr Aufwand,
> wesentlich mehr Fehlerquellen, wesentlich weniger Effizienz.
Bei Selberschreiben ist immer noch Assembler die einzig wahre Loesung:
Man kann alle Parameter und Variablen selber definieren und verwalten,
und bei groesseren Projekten ist eine vorherige Planung unabdingbar - was
bei Assembler sogar den Entscheidungstraegern klar ist ;-)
(Bei hoeheren Programmiersprachen ist eine vorherige Planung natuerlich auch
unabdingbar, aber stattdessen kann man ja eine Entwicklungsumgebung nehmen...)
Weitere Vorteile: hohe Portabilitaet (bei Maschinen gleicher Hardware)
hoechste Effizienz
Jaja, Erfahrung mit Assembler (auf 6502, 68k, ARM :), Intel :-( ) habe ich
genug, und hoehere Programmiersprachen kenne ich auch...
Sehr interessant ist uebrigens das Wang-BASIC 2200 (aber das kennt hier
wohl keiner mehr).
<einschub>
Hat da irgend jemand mal die Doku zu den Prozessorbefehlen da? Die fehlt
mir naemlich noch (fuer Wang 2200 MVP). Sowohl die 23+1 bit CPU-Befehle
als auch die 8+1 bit Basic Tokens...
</einschub>
Programmiermaessig bin ich derzeit bei Perl5 gelandet - aber auch da kann man
Programme gut oder schlecht schreiben. Immer nach dem Motto: Kunde moechte
das Programm morgen haben... (oder besser schon in einer Stunde)
Als Entwicklungsumgebung wird natuerlich vi eingesetzt (mehr braucht es imho
auch nicht). Nein, ich editiere directories _nicht_ durch Aendern der Inodes
mit Magnet <grins>.
Das bisher schlimmste Erlebnis war die IBM Visual Age C++ Entwicklungsumgebung,
wo sich nach der Standardinstallation nicht einmal "Hello World" compilieren
lassen wollte.
Als naechste Abstufung durfte ich dann noch in Smalltalk programmieren. Die
verfuegbaren Klassen und Methoden sind ja ganz nett, aber ab einer gewissen
Groesse ist die Fehlersuche genau so schlimm - wenn nicht schlimmer. Und
einiges waere in Assembler mit dem richtigen Prozessor (aber lassen wir das:) -
alte Wunden sollte man nicht wieder aufreissen.
Tschuessekens,
Holger
--
ADA is a write-only language. I can write code in ADA, but I can't read it.
Dirk Nimmich
> Ich meine folgendes: Wenn Du mehrfach geschachtelte Namensräume,
> Objekte oder Records hast, wo Zugriffe auf ein inneres Element
> erfolgen, so tippt man sich in C-Sprachen die Pfoten wund.
> Deshalb verwendet jeder C-Programmierer, den ich kenne, möglichst
> kurze (und kryptische) Bezeichner.
Ich hab' nie verstanden, warum sich Programmierer so tolle Editoren
und Entwicklungsumgebungen zulegen und dann noch nicht mal imstande
sind, die Suchen-und-Ersetzen- oder Makrofunktion zu finden.
Olaf Klein
>Was glaubst Du, warum kaum ein in C geschriebenes Programm brauchbare
>Fehlermeldungen oder detailierte Debuggingausgaben auszugeben (womit nicht
>meine, "segmentation violation - core dumped" und auch nicht nichtssagende
>Fehlernummern oder endlose Speicher-Hexdumps, sondern etwas lesbares)?
fprintf(stderr, "3942587\n"); ist auch nicht aufwendiger als
fprintf(stderr, "%s, %d: Hey Programmierer, hier ist ein Bug\n", __FILE__,
__LINE__);
>eine Fehlernummer im Source nachzusehen. In Borland Pascal dagegen kann man so
>was tatsächlich programmieren und während der Programmentwicklung auch noch
>Zeit sparen.
Beispiel?
>Eben. Und weil Namensräume niemals größer sein sollten als nötig, müssen
>Funktionen, die nur lokal gebraucht werden, auch lokal definiert werden können.
>Das wird sogar effizienter, weil Nested Functions auf Parameter und z. T.
>Variablen der übergeordneten Funktion zugreifen können.
Wenn du es effizient haben willst, nimmst du #defines.
>UO>Nein, mit nested functions kann ich mich nicht anfreunden, was auch
>UO>daran liegt daß man sie in C auch ganz prima als "static" functions in
>UO>entsprechend kleinen Quelltexten schreiben kann, ohne etwas zu
>UO>verlieren.
>Und wenn Du es tausendmal wiederholst, es stimmt nicht. Siehe Beispiel oben.
Das war eher ein Beispiel fuer schlechten Programmierstil.
Bis denn, Olaf
Oliver B. Warzecha
<199909010...@b.maus.de>:
> UO>
> UO>Ich denke daß gut geschriebener Code in allen Sprachen gut lesbar ist.
> UO>(Intercal hat einfach das Problem daß es keinen gut geschriebenen
> UO>Intercal Code geben kann.)
>
> Was ist Intercal? Und außerdem soll es ja Leute geben, die Line Noise viel,
> viel besser finden als eine Sprache, die zumindest die elementaren
> Schlüsselwörter erzwingt. If it was hard to write, it should be hard to read
> ;-) .
Intercal ist die Königin der Programmiersprachen. Die einzige Sprache,
die *wirklich* kein "goto"[1] enthält. Der Name steht für (Zitat):
| The full name of the compiler is "Compiler Language With No Pronounceable
| Acronym", which is, for obvious reasons, abbreviated "INTERCAL".
Das klassische Programmierbeispiel in Intercal, hello.i:
DO ,1 <- #13
PLEASE DO ,1SUB#1 <- #234
DO ,1SUB#2 <- #112
DO ,1SUB#3 <- #112
DO ,1SUB#4 <- #0
DO ,1SUB#5 <- #64
DO ,1SUB#6 <- #194
DO ,1SUB#7 <- #48
PLEASE DO ,1SUB#8 <- #22
DO ,1SUB#9 <- #248
DO ,1SUB#10 <- #168
DO ,1SUB#11 <- #24
DO ,1SUB#12 <- #16
DO ,1SUB#13 <- #214
PLEASE READ OUT ,1
PLEASE GIVE UP
Hier ein cat.i, ebenfalls aus dem Beispielverzeichnis der Distribution:
PLEASE DO ,1 <- #1
DO .4 <- #0
DO .5 <- #0
DO COME FROM (30)
DO WRITE IN ,1
DO .1 <- ,1SUB#1
DO (10) NEXT
PLEASE GIVE UP
(20) PLEASE RESUME '?.1$#256'~'#256$#256'
(10) DO (20) NEXT
DO FORGET #1
PLEASE DO .2 <- .4
DO (1000) NEXT
DO .4 <- .3~#255
PLEASE DO .3 <- !3~#15'$!3~#240'
DO .3 <- !3~#15'$!3~#240'
DO .2 <- !3~#15'$!3~#240'
PLEASE DO .1 <- .5
DO (1010) NEXT
DO .5 <- .2
DO ,1SUB#1 <- .3
(30) PLEASE READ OUT ,1
Ist es nicht toll!?
[1] Okay, es gibt COME FROM, aber das ist ja nun wirklich kein "goto",
eher das absolute Gegenteil davon.
--
OBW - Hilfe bei Einrichtung neuer Newsgruppen? ment...@dana.de
"Omega Metallicus is of course old Etruscan for "Let's Party"[...]
Experiments on live guitars were carried out in the most human
conditions imaginable." Steve Hackett, liner notes from "Darktown"
Felix von Leitner
> Man kann in Ada portabel auf manschinenabhängige Strukturen zugreifen.
In C++ auch.
Darf ich fragen, welchen freien Cross-Platform Compiler du benutzt?
> Man kann in Ada beweisbar korrekte Programme schreiben, ohne den
> Sprachumfang erheblich zu beschränken.
Definitionsfrage bzgl "erheblich". Deshalb: In C++ auch.
> Man kann in Ada struturierte Datentypen wie Elemtentare behandeln.
In C++ auch.
> Und der wichtigste Grund: Markus Kuhn mag Ada.
C++ nicht ;)
Ich weiß, daß viele Leute was gegen C++ haben, vor allem, weil so viele
Weenies im Moment C++ benutzen. Sachen, die Microsoft pusht, können ja
nur schlecht sein und so.
Felix
Felix von Leitner
> Ein Entwickler, der sein Geld wert ist, liest Statusmeldungen
> von einem Modem, indem er einen Knuth-Morris-Pratt-Matcher
> ("Algorithms", Sedgewick, pp. 280-285.) implementiert, also
> quasi ein Array von Automaten erzeugt, die durch die
> einkommenden Zeichen betrieben werden.
Man kann da auch andere Automaten basteln oder man kann sich einen
Parser generieren lassen. Wenn da jemand nen KMP-Matcher baut, dann ist
er zwar ein lustiger Typ, aber ich würde mein Geld lieber jemandem
geben, der sich in 5 Minuten nen Parser generieren läßt und den dann
benutzt.
Felix
Lutz Donnerhacke
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Man kann in Ada portabel auf manschinenabhängige Strukturen zugreifen.
>
>In C++ auch.
Ich bitte um ein per Sprachdefinition portables Beispiel für das Einlesen
der folgenden Struktur (msb first):
Octet 1: Bit 7: Validity
Octet 1: Bit 6: Version
(falls Version = 1)
Octet 1: Bit 5-0: Code
Octet 2: erstes Längenbyte
(falls Version = 0)
Octet 1: Bit 5-2: Code
Octet 1: Bit 1-0: Länge
Octet 2: erstes Längenbyte (falls Länge = 0,1,2)
>Darf ich fragen, welchen freien Cross-Platform Compiler du benutzt?
Für das Mappen externer Datenrepräsentationen habe ich eigene Vorstellungen.
>> Man kann in Ada beweisbar korrekte Programme schreiben, ohne den
>> Sprachumfang erheblich zu beschränken.
>
>Definitionsfrage bzgl "erheblich". Deshalb: In C++ auch.
Der Verzicht auf seiteneffektbehaftete Befehle schränkt C++ auf
selbstdefinierte Klassen ein. Das ist eine ernsthafte Einschränkung.
>> Man kann in Ada struturierte Datentypen wie Elemtentare behandeln.
>
>In C++ auch.
union {
vector<bool> bitfeld;
vector<char> string;
priority_queue<events> eventlist;
} yylvalue;
Nicht wirklich.
>Ich weiß, daß viele Leute was gegen C++ haben, vor allem, weil so viele
>Weenies im Moment C++ benutzen. Sachen, die Microsoft pusht, können ja
>nur schlecht sein und so.
<speaker name=FvL>
Du solltest Deinen Haß auf Microsoft nicht dazu benutzen, die hervorragende
IDE zu ignorieren. Insbesondere solltest Du -wenn Du schon so offensichtlich
keine Ahnung hast- Dich aus Diskussionen ernsthafter Leute raushalten.
</speaker>
Lutz Donnerhacke
Das setzt vorraus, daß es gute Parser Generatoren gibt. Ich kenne keine.
Frank Doepper
> Das setzt vorraus, daß es gute Parser Generatoren gibt. Ich kenne keine.
Schreib ihn. Die hier Anwesenden könnten vielleicht etwas sammeln... Würden
zwei Wochen Zingst reichen?
(Ist flex schlecht?)
(Fefe, was hast du mit dem Subject gemacht?!)
Felix von Leitner
> >> Man kann in Ada portabel auf manschinenabhängige Strukturen zugreifen.
> >In C++ auch.
> Ich bitte um ein per Sprachdefinition portables Beispiel für das Einlesen
> der folgenden Struktur (msb first):
> Octet 1: Bit 7: Validity
> Octet 1: Bit 6: Version
> (falls Version = 1)
> Octet 1: Bit 5-0: Code
> Octet 2: erstes Längenbyte
> (falls Version = 0)
> Octet 1: Bit 5-2: Code
> Octet 1: Bit 1-0: Länge
> Octet 2: erstes Längenbyte (falls Länge = 0,1,2)
Na mit Tonnen von ifs oder #ifdefs ;)
Klar ist das eklig, aber es geht.
> >Darf ich fragen, welchen freien Cross-Platform Compiler du benutzt?
> Für das Mappen externer Datenrepräsentationen habe ich eigene Vorstellungen.
Bist du so freundlich, mir noch die Frage zu beantworten?
> >> Man kann in Ada beweisbar korrekte Programme schreiben, ohne den
> >> Sprachumfang erheblich zu beschränken.
> >Definitionsfrage bzgl "erheblich". Deshalb: In C++ auch.
> Der Verzicht auf seiteneffektbehaftete Befehle schränkt C++ auf
> selbstdefinierte Klassen ein. Das ist eine ernsthafte Einschränkung.
Klar, aber der Parser, den ich gerade bastel, benutzt z.B. auch nur
selbstdefinierte Klassen. Letztendlich kann ich C++-Programme nach Ada
uebersetzen und das macht sich auch nicht ploetzlich besser. Wenn ich
ein beweisbar korrektes Ada-Programm schreibe, kann ich das auch nach
C++ uebersetzen.
> >> Man kann in Ada struturierte Datentypen wie Elemtentare behandeln.
> >In C++ auch.
> union {
> vector<bool> bitfeld;
> vector<char> string;
> priority_queue<events> eventlist;
> } yylvalue;
> Nicht wirklich.
Bei geeigneter Definition der Klassen ist das natuerlich moeglich.
Aber wenn du beweisbare Korrektheit haben willst, solltest du keine
Unions benutzen. ;)
> >Ich weiß, daß viele Leute was gegen C++ haben, vor allem, weil so viele
> >Weenies im Moment C++ benutzen. Sachen, die Microsoft pusht, können ja
> >nur schlecht sein und so.
> <speaker name=FvL>
> Du solltest Deinen Haß auf Microsoft nicht dazu benutzen, die hervorragende
> IDE zu ignorieren. Insbesondere solltest Du -wenn Du schon so offensichtlich
> keine Ahnung hast- Dich aus Diskussionen ernsthafter Leute raushalten.
> </speaker>
Lies dir bitte nochmal durch, was ich geschrieben habe und stelle fest,
dass ich in die gleiche Richtung argumentiert habe. Im Uebrigens hasse
ich nicht Microsoft sondern deren Software. Ja, auch den C++-Krams, den
ich nicht intuitiv bedienbar finde, und der mir bei meinen
Programmierversuchen unter Windoze nur im Weg war.
Lutz, deine Aussagen sind unpraezise und ich habe dich darauf
hingewiesen. Wenn du daraufhin mit Inkompetenz-Anwuerfen reagierst,
dann unterminierst du nicht meine sondern deine Position.
Felix
Felix von Leitner
> Man kann hier schon deutlich sehen, dass SAP-Programme in ABAP (Sprachenguete
> liegt etwa bei 0,2 ;-) auch bei ueberdurchschnittlichen Programmierern weitaus
> mehr Zeit zur Implementierung benoetigen, um eine akzeptable Qualitaet zu
> erreichen...
Daraus folgere ich, dass du schon mal ein ABAP-Programm von akzeptabler
Qualitaet gesehen hast...?! Ja wo denn? Das ist ja eine Sensation!
Felix
Felix von Leitner
> Das setzt vorraus, daß es gute Parser Generatoren gibt. Ich kenne keine.
Die Kunst bei Computer Science ist es, mit unvollkommenen Tools das
Problem trotzdem zu loesen. Ich schreibe im Moment meine Parser auch
meistens von Hand, weil sie zeitkritisch sind oder weil die generierten
Parser zu bloated sind. Ansonsten finde ich re2c ziemlich nett fuer
kleine Lexer.
Felix
Lutz Donnerhacke
>> >> Man kann in Ada portabel auf manschinenabhängige Strukturen zugreifen.
>> >In C++ auch.
>> Ich bitte um ein per Sprachdefinition portables Beispiel für das Einlesen
>> der folgenden Struktur (msb first):
>
>> Octet 1: Bit 7: Validity
>> Octet 1: Bit 6: Version
>> (falls Version = 1)
>> Octet 1: Bit 5-0: Code
>> Octet 2: erstes Längenbyte
>> (falls Version = 0)
>> Octet 1: Bit 5-2: Code
>> Octet 1: Bit 1-0: Länge
>> Octet 2: erstes Längenbyte (falls Länge = 0,1,2)
>
>Na mit Tonnen von ifs oder #ifdefs ;)
Sehen wollen. Als C++ Struktur. Danke.
>Klar ist das eklig, aber es geht.
Mach es in Ada. Da ist es nicht ekelig. Und es geht.
>> >Darf ich fragen, welchen freien Cross-Platform Compiler du benutzt?
>> Für das Mappen externer Datenrepräsentationen habe ich eigene Vorstellungen.
>
>Bist du so freundlich, mir noch die Frage zu beantworten?
Die Frage ist damit beantwortet.
<speaker name=FvL>
Wenn Du geistig nicht ausreichende Kapazitäten hast, eine Antwort zu
verstehen, so laß es bleiben.
</speaker>
>> >> Man kann in Ada beweisbar korrekte Programme schreiben, ohne den
>> >> Sprachumfang erheblich zu beschränken.
>> >Definitionsfrage bzgl "erheblich". Deshalb: In C++ auch.
>> Der Verzicht auf seiteneffektbehaftete Befehle schränkt C++ auf
>> selbstdefinierte Klassen ein. Das ist eine ernsthafte Einschränkung.
>
>Klar, aber der Parser, den ich gerade bastel, benutzt z.B. auch nur
>selbstdefinierte Klassen.
FvL schrieb was von Parsergeneratoren... das war der Auslöser der
Diskussion. Du widerlegst Dich so selbst.
>Letztendlich kann ich C++-Programme nach Ada uebersetzen und das macht sich
>auch nicht ploetzlich besser. Wenn ich ein beweisbar korrektes Ada-Programm
>schreibe, kann ich das auch nach C++ uebersetzen.
Richtig. Allerdings geht es in Ada schneller, einfacher und sauberer.
>> >> Man kann in Ada struturierte Datentypen wie Elemtentare behandeln.
>> >In C++ auch.
>> union {
>> vector<bool> bitfeld;
>> vector<char> string;
>> priority_queue<events> eventlist;
>> } yylvalue;
>> Nicht wirklich.
>
>Bei geeigneter Definition der Klassen ist das natuerlich moeglich.
Nein.
<speaker name=FvL>
Wenn Du so offensichtlich keine Ahnung hast, erspare der Welt Deine
Kommentare.
</speaker>
>Aber wenn du beweisbare Korrektheit haben willst, solltest du keine
>Unions benutzen. ;)
FvL schrieb was von Parsergeneratoren... das war der Auslöser der
Diskussion. Alle mir bekannten Implementationen von LR(1) Parsern arbeiten
mit Unions. Du widerlegst Dich so selbst.
>> >Ich weiß, daß viele Leute was gegen C++ haben, vor allem, weil so viele
>> >Weenies im Moment C++ benutzen. Sachen, die Microsoft pusht, können ja
>> >nur schlecht sein und so.
>> <speaker name=FvL>
>> Du solltest Deinen Haß auf Microsoft nicht dazu benutzen, die hervorragende
>> IDE zu ignorieren. Insbesondere solltest Du -wenn Du schon so offensichtlich
>> keine Ahnung hast- Dich aus Diskussionen ernsthafter Leute raushalten.
>> </speaker>
>
>Lies dir bitte nochmal durch, was ich geschrieben habe und stelle fest,
>dass ich in die gleiche Richtung argumentiert habe. Im Uebrigens hasse
>ich nicht Microsoft sondern deren Software. Ja, auch den C++-Krams, den
>ich nicht intuitiv bedienbar finde, und der mir bei meinen
>Programmierversuchen unter Windoze nur im Weg war.
>
>Lutz, deine Aussagen sind unpraezise und ich habe dich darauf
>hingewiesen. Wenn du daraufhin mit Inkompetenz-Anwuerfen reagierst,
>dann unterminierst du nicht meine sondern deine Position.
Eine sachlich begründete Aussage.
Ernsthaft, Felix. Du hast neben der malträtierten Quote einfach das Thema
verfehlt.
Lutz Donnerhacke
>
>Die Kunst bei Computer Science ist es, mit unvollkommenen Tools das
>Problem trotzdem zu loesen. Ich schreibe im Moment meine Parser auch
>meistens von Hand, weil sie zeitkritisch sind oder weil die generierten
>Parser zu bloated sind. Ansonsten finde ich re2c ziemlich nett fuer
>kleine Lexer.
Du kannst (f)lex nehmen. Oder -lperl. Aber bitte unterscheide zwischen
meinem Kritikpunkt der Nichtdarstellbarkeit von Strukturen und Deinem
Kritikpunkt der Codegröße.
Mirko Liss
> Bei Selberschreiben ist immer noch Assembler die einzig wahre Loesung:
> Man kann alle Parameter und Variablen selber definieren und verwalten,
> und bei groesseren Projekten ist eine vorherige Planung unabdingbar - was
> bei Assembler sogar den Entscheidungstraegern klar ist ;-)
> (Bei hoeheren Programmiersprachen ist eine vorherige Planung natuerlich auch
> unabdingbar, aber stattdessen kann man ja eine Entwicklungsumgebung nehmen...)
>
> Weitere Vorteile: hohe Portabilitaet (bei Maschinen gleicher Hardware)
> hoechste Effizienz
Wirklich _portabel_ sind eigentlich nur die Programme, mit denen
Handys laufen; schliesslich schleppen die Leute diese Dinger an
die unmoeglichsten Orte mit.
In welcher Sprache werden Mobiltelefone, die Kuhglocken des
modernen Angestellten, programmiert?
Bingo: Assembler. Also ist nur Assembler wirklich portabel. qed
Und was ist das beste, wenn man auf diese Weise programmiert?
Man braucht sich nicht um ein OS zu kuemmern:
Kein Unix wirft den Kern des Handys, aka die
Leiterplatte, auf den Muell.
Kein Windows laesst das Handy blau anlaufen.
Kein Apple zeigt das Angesicht Satans auf dem
Telefondisplay.
Wozu fuehrt das?
Falls ein hypothetischer Benutzer nicht nur das Handy-Verbot
im Rechnerraum, sondern auch das Ding selbst vergisst,
dann pfeift ein Handy leise 'Servus', 2 Minuten 17 Sekunden
nachdem es im Waschbecken versinkt.
"Hoppla, das ist ja gar kein Stueck Seife..."
MfG,
Mirko
--
M Liß, <n89...@hrz.uni-paderborn.de>
Florian Weimer
> Ich meine folgendes: Wenn Du mehrfach geschachtelte Namensräume,
> Objekte oder Records hast, wo Zugriffe auf ein inneres Element
> erfolgen, so tippt man sich in C-Sprachen die Pfoten wund.
Man tippt sich meistens die Pfoten wund, wenn man wartbaren Code
schreiben will, weil der einfach länger ist. ;) Das kann eigentlich
kein Argument sein.
> Deshalb verwendet jeder C-Programmierer, den ich kenne, möglichst
> kurze (und kryptische) Bezeichner.
Der Grund ist wohl eher Tradition (vielleicht unbewußt), da früher bei
vielen Compiler und vor allem Linkern ziemlich wenig Zeichen am Beginn
von Bezeichnern letzlich signifikant waren. Bei manchem Windows-Code,
den ich gesehen habe, werden durchaus längere Bezeichner verwendet,
vermutlich färbt hier die API ab.
> In Pascal-Sprachen habe ich einen Befehl zum Umschalten des
> Namensraums, damit habe ich das Problem nicht.
Falls Du auf das with-Konstrukt anspielst: Das hat nette Nebenwirkung,
daß unter Umständen beim Hinzufügen von Komponenten zu records Code
irgendwo im Programm plötzlich ohne jegliche Warnung seine Bedeutung
völlig verändert, weil eine Variable fortan durch eine record-Komponente
verdeckt wird, die zufälligerweise einen kompatiblen Typ hat. Eigentlich
hat man ja mehrere Namensräume gerade deswegen eingeführt, um solche
Probleme zu verhindern...
> Eben. Und weil Namensräume niemals größer sein sollten als nötig,
> müssen Funktionen, die nur lokal gebraucht werden, auch lokal
> definiert werden können.
ACK.
> Das wird sogar effizienter, weil Nested Functions auf Parameter und z. T.
> Variablen der übergeordneten Funktion zugreifen können.
Wieso ist das effizienter? AFAIK gibt es mehere Möglichkeiten,
geschachtelte Funktionen zu implementieren, und nicht bei allen sind
die Kosten eines Zugriffs auf auf Variablen aus äußeren Scopes mit
Kosten eines Zugriffs auf lokale Variablen identisch.
> Und ehe Du fragst, Stroustrup hat auch nicht verstanden, was der Unterschied
> zwischen Namensräumen und Modulkonzept ist. Wirth hat es bei Modula-2
> verstanden, deshalb kann es da Module innerhalb von Modulen geben, aber keine
> Module, die über 1000 Dateien zersplittert sind, sodaß man nichts mehr
> wiederfindet.
Seperate Kompilierung kann durchaus ein Vorteil sein.
Florian Weimer
> Du hast recht, allerdings ist auch die Frage, ob es nicht Overkill wäre, an
> allen diesen Stellen explizite Casts zu fordern
Explizite Casts sind nicht die Lösung. Lieber stellt man Unterprogramme
und Operatoren mit den benötigten Typen zur Verfügung. Wenn man das
konsequent macht, braucht man zwar ziemlich lange, bis man ein Stück Code
durch den Compiler kriegt, aber die Chancen, daß es dann fehlerfrei ist,
sind doch beträchtlich.
> oder gar überhaupt keine
> Umwandlungen machen zu können. Außerdem gibt es wenigstens Range Checking.
>
> Viele der Dinge, die man in C mit Integertypen machen würde, kann man mit
> Aufzählungstypen und z. B. Mengen nachen. Dann ist es sicher.
Aber selbst bei Teilbereichstypen hat man wieder diese blöde
Kompatibilität zum Integer-Typ.
Florian Weimer
> Bingo: Assembler. Also ist nur Assembler wirklich portabel. qed
Ich habe vor einiger Zeit in diesem Bereich C-Code gesehen. Was nun?
Andreas Bogk
> * was sich heute Pascal nennt ist eine unglaublich aufgeblasene
> Menge Funktionen um einen eigentlich schmalen Sprachkern. Und
> es gibt oft genug weit mehr als einen Weg.
Na besser ist das. Nicht dass ich Pascal mag oder so, aber was ich
absolut nicht mag, sind Sprachen, die mir einen sogenannten einzig
wahren Weg vorschreiben wollen, Probleme zu loesen. Das ist im
uebrigen auch einer der Gruende, warum perl so erfolgreich ist:
there's more than one way to do it. One size^Wlanguage fits all.
Gruss Andreas
--
"We show that all proposed quantum bit commitment schemes are insecure because
the sender, Alice, can almost always cheat successfully by using an
Einstein-Podolsky-Rosen type of attack and delaying her measurement until she
opens her commitment." ( http://xxx.lanl.gov/abs/quant-ph/9603004 )
Holger Kipp
Nun ja, ein Mitarbeiter hat hier was ganz Tolles gezaubert zur Einplanung
von Varianten - inklusive Fehlerueberpruefung und paralleler Prozesse, was
gegenueber der seriellen Einplanung Faktor 7 und hoeher bringt.
Allerdings musste er da viel von Hand machen, weil <geschoent on>
ein paar SAP-eigene Sachen nicht ganz sauber <geschoent off> implementiert
sind.
Ich versuche ja immer einen grossen Bogen um ABAP zu machen - aber ab und
an erwischt es mich auch - und sei es nur, um OSS-Hinweisen folgend ein paar
Vorabhinweise einzupflegen... <schauder>.
Demnaechst stehen mir wieder zwei SAP-Installationen ins Haus - die Pakete
stehen schon auf dem Tisch neben mir =8-O Aber im Grunde ist es auch nicht
schwerer als die Installation von Postgres, Perl und Apache. SAP ist
schliesslich auch nur eine Datenbank mit Applikation oben drauf... >:->
Tschoe,
Holger
Stefan Scholl
> (Intercal hat einfach das Problem daß es keinen gut geschriebenen
Dafür ist die Sprache unheimlich höflich.
Stefan Scholl
> irreführende Variablennamen sind an anderen Stellen rar.
Du meinst so schöne Variablennamen wie ich heute in einem
RPG/400-Source gesehen habe? Da dürfen die Felder 6 Zeichen groß
sein und es gab im Source echt Felder die sich nur durch die
ersten zwei Stellen unterschieden haben: das eine begann mit "$$"
und das andere mit "§$".
Kristian Köhntopp
Felix von Leitner wrote:
> Man kann da auch andere Automaten basteln oder man kann sich einen
> Parser generieren lassen. Wenn da jemand nen KMP-Matcher baut, dann ist
> er zwar ein lustiger Typ, aber ich würde mein Geld lieber jemandem
> geben, der sich in 5 Minuten nen Parser generieren läßt und den dann
> benutzt.
Du überschätzt den Aufwand und die Qualität des Outputs von Parsergeneratoren.
Kristian
--
Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH
Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00
Using PHP3? See our web development library at
http://phplib.shonline.de/ (GPL)
Thomas 'Mike' Michlmayr
Matthias Heidbrink <Matthias_...@b.maus.de> wrote:
[...]
>Ehrlich gesagt, ich kenne das nicht anders. Wenn jemand behauptet, daß er in
>einer Schulung von ein paar Tagen eine Programmiersprache und Programmieren
>gelernt hätte, dann muß das einfach schiefgehen.
die aussage geht auch allgemeiner: "wenn jemand behauptet, dass er in einer
schulung von ein paar tagen was _wirklich_ gelernt haette, dann muss das
einfach schiefgehen".
--
Thomas 'Mike' Michlmayr | Verein für Internet-BEnutzer Österreichs
<mike...@cluon.priv.at> | http://www.vibe.at/
Felix von Leitner
Deine Ursprungsaussage war:
> >> >> Man kann in Ada portabel auf manschinenabhängige Strukturen zugreifen.
Ich sagte dazu:
> >> >In C++ auch.
Du fordertest daraufhin etwas anderes, nämlich:
> >> Ich bitte um ein per Sprachdefinition portables Beispiel für das Einlesen
> >> der folgenden Struktur (msb first):
> >
> >> Octet 1: Bit 7: Validity
> >> Octet 1: Bit 6: Version
> >> (falls Version = 1)
> >> Octet 1: Bit 5-0: Code
> >> Octet 2: erstes Längenbyte
> >> (falls Version = 0)
> >> Octet 1: Bit 5-2: Code
> >> Octet 1: Bit 1-0: Länge
> >> Octet 2: erstes Längenbyte (falls Länge = 0,1,2)
Das hat zwar mit deiner ursprünglichen Forderung nicht viel zu tun, ist
aber auch in C++ lösbar, und zwar, wie ich entgegnete,
> >Na mit Tonnen von ifs oder #ifdefs ;)
Und jetzt kommt von dir als weitere Einschränkung:
> Sehen wollen. Als C++ Struktur. Danke.
Ja, Lutz, man kann sein Problem auch solange umdefinieren, bis man Recht
hat. Und tatsächlich kann man in C++ keine struct definieren, die
maschinenunabhängig die geforderte Struktur abbildet. Was nicht heißt,
dass man nicht, wie ursprünglich von dir gefordert, portabel auf
maschinenabhängige Strukturen zugreifen kann.
> >Klar ist das eklig, aber es geht.
> Mach es in Ada. Da ist es nicht ekelig. Und es geht.
Ich benutze keine Sprachen, für die ich keinen freien, stabilen,
plattformunabhängigen Compiler habe, der performanten Code erzeugt. GNU
Ada erfüllt nicht den vollen Sprachstandard.
> >> >Darf ich fragen, welchen freien Cross-Platform Compiler du benutzt?
> >> Für das Mappen externer Datenrepräsentationen habe ich eigene Vorstellungen.
> >Bist du so freundlich, mir noch die Frage zu beantworten?
> Die Frage ist damit beantwortet.
> <speaker name=FvL>
> Wenn Du geistig nicht ausreichende Kapazitäten hast, eine Antwort zu
> verstehen, so laß es bleiben.
> </speaker>
Lutz, wenn du ein Problem hast, sag es doch einfach.
Jedenfalls sind deine Vorstellungen vollkommen irrelevant, wenn es um
die Frage geht, welchen freien Cross-Platform Compiler du benutzt.
Mögliche Antworten sind:
- "es gibt keinen"
- "ich mach nicht wirklich Ada, ich will mich nur von der C++-Masse
abheben"
- GNU Ada
Ich tippe auf Antwort 3. Ich fände es aber zynisch, wenn du eine
Sprache wegen ihrer Features pluggst, und dann einen unvollständigen
Compiler benutzen würdest.
> >> >> Man kann in Ada beweisbar korrekte Programme schreiben, ohne den
> >> >> Sprachumfang erheblich zu beschränken.
> >> >Definitionsfrage bzgl "erheblich". Deshalb: In C++ auch.
> >> Der Verzicht auf seiteneffektbehaftete Befehle schränkt C++ auf
> >> selbstdefinierte Klassen ein. Das ist eine ernsthafte Einschränkung.
> >Klar, aber der Parser, den ich gerade bastel, benutzt z.B. auch nur
> >selbstdefinierte Klassen.
> FvL schrieb was von Parsergeneratoren... das war der Auslöser der
> Diskussion. Du widerlegst Dich so selbst.
Vielleicht bin ich ja doof, aber wenn
1. war der Auslöser der Diskussion nicht der Parsergenerator, sondern
deine Aussagen über Ada
2. sehe ich den Widerspruch hier nicht. Erkläre ihn mir doch einfach.
Vielleicht geht letzteres entspannter, wenn du das per Mail machst. In
den News hast du in letzter Zeit offenbar das Bedürfnis, an unpassenden
Stellen persönliche Angriffe zu fahren. Das war früher nicht dein Stil.
> >Letztendlich kann ich C++-Programme nach Ada uebersetzen und das macht sich
> >auch nicht ploetzlich besser. Wenn ich ein beweisbar korrektes Ada-Programm
> >schreibe, kann ich das auch nach C++ uebersetzen.
> Richtig. Allerdings geht es in Ada schneller, einfacher und sauberer.
Das ist eine Behauptung, die noch zu belegen wäre.
Der Ansatz, Behauptungen durch Wiederholung beweisen zu wollen, ist
schon vor Jahrtausenden gescheitert und in der Rhetorik statt der Logik
anzusiedeln.
> >> >> Man kann in Ada struturierte Datentypen wie Elemtentare behandeln.
> >> >In C++ auch.
[Codefragment: Union von drei Template-Klassen gelöscht]
> >> Nicht wirklich.
> >Bei geeigneter Definition der Klassen ist das natuerlich moeglich.
> Nein.
Offenbar habe ich falsch verstanden, welche Forderungen du an dieses
Konstrukt am Ende stellen würdest. Erläuter das doch bitte.
Laß mich kurz erklären, was ich unter strukturierten Datentypen
verstehe.
struct foo {
bool lutz;
string fefe;
}; // strukturierter Datentyp
foo bar, baz;
...
bar=baz; // wird hier wie ein Elementar behandelt
> >Aber wenn du beweisbare Korrektheit haben willst, solltest du keine
> >Unions benutzen. ;)
> FvL schrieb was von Parsergeneratoren... das war der Auslöser der
> Diskussion. Alle mir bekannten Implementationen von LR(1) Parsern arbeiten
> mit Unions. Du widerlegst Dich so selbst.
LR(1) ist eine bestimmte Klasse von Parsern, die ich bislang nicht
erwähnt habe. Behauptungen, die auf Annahmen basieren, die man nicht
vorher hinterfragt hat, sind unlauter und unter deinem früheren Niveau.
> Eine sachlich begründete Aussage.
Das
[x] ist kein vollständiger Satz
[x] hat keinen klaren Bezug
[x] ist damit wertlos
> Ernsthaft, Felix. Du hast neben der malträtierten Quote einfach das Thema
> verfehlt.
Wo soll ich denn ein Quote malträtiert haben?
Felix
Felix von Leitner
> > Man kann da auch andere Automaten basteln oder man kann sich einen
> > Parser generieren lassen. Wenn da jemand nen KMP-Matcher baut, dann ist
> > er zwar ein lustiger Typ, aber ich würde mein Geld lieber jemandem
> > geben, der sich in 5 Minuten nen Parser generieren läßt und den dann
> > benutzt.
> Du überschätzt den Aufwand und die Qualität des Outputs von Parsergeneratoren.
Von der Qualität stand da nichts, sie war also kein Kriterium.
Und warum postulierst du, daß es keinen Parsergenerator gibt, der bei
geringem Aufwand Output generiert?
Felix
Robert Kiessling
> >Aber wenn du beweisbare Korrektheit haben willst, solltest du keine
> >Unions benutzen. ;)
>
> FvL schrieb was von Parsergeneratoren... das war der Auslöser der
> Diskussion. Alle mir bekannten Implementationen von LR(1) Parsern arbeiten
> mit Unions. Du widerlegst Dich so selbst.
Es gibt auch modernere Sprachen mit Typsystemen, das kein Probleme
damit haben, Vereinigungstypen sauber zu definieren, so dass auhc
beweisbare Korrektheit damit problemlos moeglich ist. Die Entwicklung
von Programmiersprachen ist nicht vor 30 Jahren stehengeblieben.
Robert
Bodo Moeller
> [...] weil Namensräume niemals größer sein sollten als nötig,
> müssen Funktionen, die nur lokal gebraucht werden, auch lokal
> definiert werden können. Das wird sogar effizienter, weil Nested
> Functions auf Parameter und z. T. Variablen der übergeordneten
> Funktion zugreifen können.
> [...] in einer C-Sprache [...] wesentlich weniger Effizienz.
Quatsch. Statt mit verschachtelten Funktionen zu arbeiten, kann man
Zeiger auf die jeweils zu betrachtenden Variablen in zusätzlichen
Argumenten übergeben. Was glaubst du wohl, wie das compilierte
Pascal-Programm jeweils die richtigen Variablen findet?!
Boris Majowski
> On Wed, 1 Sep 1999 00:24:00 +0200, Matthias Heidbrink
> wrote:
>>Was glaubst Du, warum kaum ein in C geschriebenes Programm brauchbare
>>Fehlermeldungen oder detailierte Debuggingausgaben auszugeben (womit nicht
>>meine, "segmentation violation - core dumped" und auch nicht nichtssagende
>>Fehlernummern oder endlose Speicher-Hexdumps, sondern etwas lesbares)?
> fprintf(stderr, "3942587\n"); ist auch nicht aufwendiger als
> fprintf(stderr, "%s, %d: Hey Programmierer, hier ist ein Bug\n", __FILE__,
> __LINE__);
das andere haelt aber die zu dokumentierende liste der fehler
erfreulich kurz:
Anhang Fehlermeldungen
MsgID Grund Abhilfe
1 Es ist ein Fehler aufgetreten. Re-Installieren Sie das Program
und fertich.
Josef Wolf
> Das setzt vorraus, daß es gute Parser Generatoren gibt. Ich kenne keine.
Willst Du damit sagen, dass kein derzeitig verfuegbarer
parsergenerator in der Lage ist, einen parser fuer modem-responses
zu erzeugen? Brrr... diese mutige Behauptung wuerde ich mir nicht
getrauen.... Aber da wir hier in dasr sind: lass mal hoeren!
--
-- Josef Wolf -- j...@raven.inka.de -- Germersheim, Germany --
Josef Wolf
> Matthias Heidbrink schrieb:
> > Ich meine folgendes: Wenn Du mehrfach geschachtelte Namensräume,
> > Objekte oder Records hast, wo Zugriffe auf ein inneres Element
> > erfolgen, so tippt man sich in C-Sprachen die Pfoten wund.
> > kurze (und kryptische) Bezeichner.
>
> und Entwicklungsumgebungen zulegen und dann noch nicht mal imstande
> sind, die Suchen-und-Ersetzen- oder Makrofunktion zu finden.
Eigentlich wolltest Du sagen: "Matthias hat nicht begriffen, was man
mit Zeigern anfangen kann.". Aber es ist gut, dass Du das nicht gesagt
hast, denn das waere hier OT =8-()
Camillo Klemd
>[Ada]
>>also es tut mir ja unendlich leid, aber bei ada denke ich immer zuerst an ein
>>reinigungs-scheuermittel aus DDR-zeiten. aber ich gebe gern zu: auch das hat
>>bestens funktioniert...
><grybel>
>Schrieb sich _das_ nicht _geringfuegig_ anders?
ja stimmt, jetzt wo du es sagst... es schrieb sich, glaub ich, ata oder atta.
aber als sachse isses ja eh ada oder adda...
>Aber Du hast recht,
>funktioniert hat es: Wenn man Sprelakartplatten bis auf den
>Pressspankern durchscheuern wollte...
und nicht nur dann...
es erwies sich an vielen stellen als gutes feines schleifmittel, z.b. beim
saeubernden vorbereiten von leiterplattenmaterial.
und "spuelhaende" bekam man auch nicht davon.
>Grüßle Silke
ff und schoenes WoE, millo
--
| DI Camillo Klemd | CVG mbH Chemnitz | Softwareschmied
| camill...@cvg.de | CK768-RIPE | & Sysadmin
+----------------------+------------------+----------------
| Auch bei Wahrheiten muß man auf das Verfallsdatum achten.
Lutz Donnerhacke
>> Objekte oder Records hast, wo Zugriffe auf ein inneres Element
>> erfolgen, so tippt man sich in C-Sprachen die Pfoten wund.
>
>schreiben will, weil der einfach länger ist. ;) Das kann eigentlich
>kein Argument sein.
Es ist schon allein wegen M-/ sinnlos.
>> Deshalb verwendet jeder C-Programmierer, den ich kenne, möglichst
>> kurze (und kryptische) Bezeichner.
>
>Der Grund ist wohl eher Tradition (vielleicht unbewußt), da früher bei
Der Grund ist vi. Mit emacs wäre das nicht passiert.
Andre Poenitz
: ja stimmt, jetzt wo du es sagst... es schrieb sich, glaub ich, ata oder atta.
*seufz* "ATA" mit einem "T". Millo, ich glaube, Du hast in Deiner
fruehen Jugend zu selten Toepfe gescheuert...
: und "spuelhaende" bekam man auch nicht davon.
Genau, blitzend weisse Knoechechen ;-)
Andre'
--
Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik
poe...@mathematik.tu-chemnitz.de ... +49 3727 58 1381
Lutz Donnerhacke
>On 2 Sep 1999 07:13:34 GMT, Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>
>> Das setzt vorraus, daß es gute Parser Generatoren gibt. Ich kenne keine.
>
>Willst Du damit sagen, dass kein derzeitig verfuegbarer
>parsergenerator in der Lage ist, einen parser fuer modem-responses
>zu erzeugen? Brrr... diese mutige Behauptung wuerde ich mir nicht
>getrauen.... Aber da wir hier in dasr sind: lass mal hoeren!
Ich will nur nicht behaupten, daß modem-responses (AT-Befehlssatz ohne die
eigentliche Modemfunktionen) allein eine sinnvolle Aufgabe zum Parsen
darstellen. Solltest Du allerdings das komplette Protokoll meinen (also das
gesamte Hin und Her), so wird es langsam interessant. Hänge dann noch die
eigentliche Funktionalität (Datenübertragung) rein und sage mir jetzt den
verfügbaren Parsergenerator.
Lutz Donnerhacke
>Ja, Lutz, man kann sein Problem auch solange umdefinieren, bis man Recht
>hat.
;-) Glücklicherweise ist es ein mehrseitiger Prozeß.
>Und tatsächlich kann man in C++ keine struct definieren, die
>maschinenunabhängig die geforderte Struktur abbildet. Was nicht heißt, dass
>man nicht, wie ursprünglich von dir gefordert, portabel auf
>maschinenabhängige Strukturen zugreifen kann.
Daß man in der Lage ist, portabel maschinenabhängige Strukturen mit
aufwendigen Programmen zu verarbeiten, habe ich als trivial vorausgesetzt.
Entschuldige, wenn ich Dich unterschätzt haben sollte.
>>>Klar ist das eklig, aber es geht.
>> Mach es in Ada. Da ist es nicht ekelig. Und es geht.
>Ich benutze keine Sprachen, für die ich keinen freien, stabilen,
>plattformunabhängigen Compiler habe, der performanten Code erzeugt. GNU
>Ada erfüllt nicht den vollen Sprachstandard.
Das ist schade. Ich habe gerade eine Arbeit über die direkte Implementation
des \pi-Kalküls vorliegen (was genial für beweisbare korrekte parallel
kunkurrierende Implementationen ist) und für das kein Compiler existiert.
>>>>>Darf ich fragen, welchen freien Cross-Platform Compiler du benutzt?
>>>> Für das Mappen externer Datenrepräsentationen habe ich eigene
>>>> Vorstellungen.
>>>Bist du so freundlich, mir noch die Frage zu beantworten?
>> Die Frage ist damit beantwortet.
>> <speaker name=FvL>
>> Wenn Du geistig nicht ausreichende Kapazitäten hast, eine Antwort zu
>> verstehen, so laß es bleiben.
>> </speaker>
>Lutz, wenn du ein Problem hast, sag es doch einfach.
>Jedenfalls sind deine Vorstellungen vollkommen irrelevant, wenn es um
>die Frage geht, welchen freien Cross-Platform Compiler du benutzt.
Im Kontext des Zugriffs auf maschinenabhängige Strukturen habe ich konkrete
Vorstellungen von einem Mapper (Parsergenerator und Generatorgenerator), die
noch nicht implementiert sind.
>Mögliche Antworten sind:
> - "es gibt keinen"
> - "ich mach nicht wirklich Ada, ich will mich nur von der C++-Masse
> abheben"
> - GNU Ada
Die Auswahl der Zielsprache ist noch nicht festgelegt. Evtl. wird in C++ mit
STL implementiert. Evtl. in ANSI-C. Evtl. in Ada. Evtl. in Oz, Scheme oder
Haskell.
>Ich tippe auf Antwort 3.
Nack.
>Ich fände es aber zynisch, wenn du eine Sprache wegen ihrer Features
>pluggst, und dann einen unvollständigen Compiler benutzen würdest.
Ack.
>Vielleicht bin ich ja doof, aber wenn
> 1. war der Auslöser der Diskussion nicht der Parsergenerator, sondern
> deine Aussagen über Ada
> 2. sehe ich den Widerspruch hier nicht. Erkläre ihn mir doch einfach.
Ich sehe den Diskussionsbeginn im Parsergenerator, Du in Ada. Klassisches
Usenet Problem.
>Vielleicht geht letzteres entspannter, wenn du das per Mail machst. In
>den News hast du in letzter Zeit offenbar das Bedürfnis, an unpassenden
>Stellen persönliche Angriffe zu fahren. Das war früher nicht dein Stil.
d.a.s.r enthält Namensteile, denen ich Folge leistete. Fehlten diese, wäre
es extrem schlechter Stil.
>[Codefragment: Union von drei Template-Klassen gelöscht]
>Offenbar habe ich falsch verstanden, welche Forderungen du an dieses
>Konstrukt am Ende stellen würdest. Erläuter das doch bitte.
In C++ sind neu definierte Datentypen nicht den primitiven Datentypen
gleichgestellt. Das macht sich u.a. an der Union bemerkbar. Es gibt andere
Fälle, bei denen man ziemliche Kopfstände machen muß, wenn man es bemerkt.
>> FvL schrieb was von Parsergeneratoren... das war der Auslöser der
>> Diskussion. Alle mir bekannten Implementationen von LR(1) Parsern arbeiten
>> mit Unions. Du widerlegst Dich so selbst.
>LR(1) ist eine bestimmte Klasse von Parsern, die ich bislang nicht
>erwähnt habe. Behauptungen, die auf Annahmen basieren, die man nicht
>vorher hinterfragt hat, sind unlauter und unter deinem früheren Niveau.
Zum Niveau hatte ich mich bereits geäußert. Ansonsten ist es richtig, daß
LR(1) nur eine bestimmt Teilmenge von Problemen beschreiben, so daß ich auf
die Aussage 'ich würde mein Geld eher jemanden geben, der Parsergeneratoren
benutzt' zumindest dann allergisch reagieren dürfen können möchte, wenn ich
es gerade mit realweltlichen nicht LR(1) Problemen zu tun habe.
Robert Kiessling
> Das ist schade. Ich habe gerade eine Arbeit über die direkte Implementation
> des \pi-Kalküls vorliegen (was genial für beweisbare korrekte parallel
> kunkurrierende Implementationen ist) und für das kein Compiler existiert.
Den Klammersatz verstehe ich nicht. Der \pi-Kalkuel macht eine
verteilte Implementierung erst einmal sehr schwer.
Robert
Frank Doepper
> *seufz* "ATA" mit einem "T". Millo, ich glaube, Du hast in Deiner
> fruehen Jugend zu selten Toepfe gescheuert...
"ATA macht blank. ATA gehört in den Küchenschrank."
F.
--
http://home.pages.de/~woffs/ FD581-RIPE
Mirko Liss
Echt? Scheisse, Beweis widerlegt.
Oder doch nicht. Wenn ich etwas Ballast[1] ueber Bord werfe,
kann ich's vielleicht ja noch retten, und so meine
Usenet-Ehre[2] verteidigen:
Wenn ich den Chip auslese, dann komme ich immer nur auf
Maschinencode. Der Versuch, den ROM-Inhalt als C-Code
zu lesen, schlaegt fehl. Der Text ergibt weder bei
Interpretation als ASCII-Text noch als Unicode-Text
irgendeinen Sinn. Deine Beobachtung, dass auch C verwendet
wird, kann ich also nicht stuetzen.
Wenn Du geistig nicht ausreichende Kapazitaeten hast,
diese Antwort zu verstehen, so laß es bleiben!!!!!
Man kann dieses Problem natuerlich so lange umdefinieren,
bis man Recht hat!!!!!
B1FF s3z uR lAyMe !!$%!!
Mit freundlichem Grinsen,
Mirko GibmirTiernamen Liss
[1] Ballast: Charaktereigenschaften, die erfolgreiches
Disputieren nach Schopenhauer behindern: Vernunft,
Sachkenntnis( zB. von Schopenhauer), Geschmack,
Hoeflichkeit und Freundlichkeit.
[2] Usenet-Ehre: Der Versuch, in den News ein Revier abzustecken.
Ursache vielfaeltiger Flame-Wars, die meist persoenlichen
Angriffen und in Maekeleien an der Rechtschreibung kulminieren.
Siehe den Sommerloch-Veganer-Thread in de.rec.mampf u.a. Ortes;
siehe "Why use..."-Thread in c.l.python und c.l.perl.misc .
Ich liebe diese Threads, wenn sie in Fremdsprachen ausgetragen
werden. Man lernt dabei so viele neue Worte.
--
M Liß, <n89...@squid.upb.de>
Matthias Leisi
>> In Pascal-Sprachen habe ich einen Befehl zum Umschalten des
>> Namensraums, damit habe ich das Problem nicht.
>Falls Du auf das with-Konstrukt anspielst: Das hat nette Nebenwirkung,
>daß unter Umständen beim Hinzufügen von Komponenten zu records Code
>irgendwo im Programm plötzlich ohne jegliche Warnung seine Bedeutung
>völlig verändert, weil eine Variable fortan durch eine record-Komponente
"with" ist boese. Nicht nur durch das hinzufuegen von Komponenten,
auch schon durch den uebergeordneten Kontext gibt es
Doppelbedeutungen. Spassig wird es dann bei testweise auskommentierten
Strukturen.
Fazit: "with" ist fuer Warmduscher - und fliegt spaetestens beim
ersten Codereview raus.
Mat "bekennender Pascal-/Delphi-Entwickler" thias
Felix von Leitner
> Der Grund ist vi. Mit emacs wäre das nicht passiert.
vim: <C-P>
int sehrlangerbezeichner;
main() {
se<C-P>
}
->
int sehrlangerbezeichner;
main() {
sehrlangerbezeichner
}
vi setzt wohl tatsächlich praktisch niemand direkt ein. Höchstens vim
oder nvi, und damit geht das.
Felix
Felix von Leitner
> >Und tatsächlich kann man in C++ keine struct definieren, die
> >maschinenunabhängig die geforderte Struktur abbildet. Was nicht heißt, dass
> >man nicht, wie ursprünglich von dir gefordert, portabel auf
> >maschinenabhängige Strukturen zugreifen kann.
> aufwendigen Programmen zu verarbeiten, habe ich als trivial vorausgesetzt.
> Entschuldige, wenn ich Dich unterschätzt haben sollte.
Klar ist das trivial. Umsomehr hat mich deine Aussage gewundert.
Diese Art von Mißverständnis würde nicht passieren, wenn du genau
schriebest, was du meinst.
> >> Mach es in Ada. Da ist es nicht ekelig. Und es geht.
> >Ich benutze keine Sprachen, für die ich keinen freien, stabilen,
> >plattformunabhängigen Compiler habe, der performanten Code erzeugt. GNU
> >Ada erfüllt nicht den vollen Sprachstandard.
> Das ist schade. Ich habe gerade eine Arbeit über die direkte Implementation
> des \pi-Kalküls vorliegen (was genial für beweisbare korrekte parallel
> kunkurrierende Implementationen ist) und für das kein Compiler existiert.
Daß ich sie nicht benutze heißt nicht, daß ich mich nicht ein bißchen
damit beschäftige. Gib doch mal bitte eine URL zu der Arbeit, oder ist
die (noch) geheim?
> >Lutz, wenn du ein Problem hast, sag es doch einfach.
> >Jedenfalls sind deine Vorstellungen vollkommen irrelevant, wenn es um
> >die Frage geht, welchen freien Cross-Platform Compiler du benutzt.
> Im Kontext des Zugriffs auf maschinenabhängige Strukturen habe ich konkrete
> Vorstellungen von einem Mapper (Parsergenerator und Generatorgenerator), die
> noch nicht implementiert sind.
Das ist ja schön und gut, beantwortet aber meine Frage nicht, welchen
freien Cross-Platform Ada-Compiler du benutzt.
> Zum Niveau hatte ich mich bereits geäußert. Ansonsten ist es richtig, daß
> LR(1) nur eine bestimmt Teilmenge von Problemen beschreiben, so daß ich auf
> die Aussage 'ich würde mein Geld eher jemanden geben, der Parsergeneratoren
> benutzt' zumindest dann allergisch reagieren dürfen können möchte, wenn ich
> es gerade mit realweltlichen nicht LR(1) Problemen zu tun habe.
ACK.
Felix
Lutz Donnerhacke
>> Der Grund ist vi. Mit emacs wäre das nicht passiert.
>
>vim: <C-P>
>
> int sehrlangerbezeichner;
> main() {
> se<C-P>
> }
Error: Cut buffer is empty.
Hm..
Lutz Donnerhacke
>> des \pi-Kalküls vorliegen (was genial für beweisbare korrekte parallel
>> kunkurrierende Implementationen ist) und für das kein Compiler existiert.
>
>Daß ich sie nicht benutze heißt nicht, daß ich mich nicht ein bißchen
>damit beschäftige. Gib doch mal bitte eine URL zu der Arbeit, oder ist
>die (noch) geheim?
Ich habe den Text unter ftp.iks-jena.de:/pub/mitarb/lutz/popl97.ps.gz
abgelegt. URL entfallen-
>> Im Kontext des Zugriffs auf maschinenabhängige Strukturen habe ich konkrete
>> Vorstellungen von einem Mapper (Parsergenerator und Generatorgenerator), die
>> noch nicht implementiert sind.
>
>Das ist ja schön und gut, beantwortet aber meine Frage nicht, welchen
>freien Cross-Platform Ada-Compiler du benutzt.
Keinen. Ich benutze Ada nicht. Ich finde Ada schön und möchte mir den
Eindruck nicht durch praktische Probleme trüben lassen.
>> Zum Niveau hatte ich mich bereits geäußert. Ansonsten ist es richtig, daß
>> LR(1) nur eine bestimmt Teilmenge von Problemen beschreiben, so daß ich auf
>> die Aussage 'ich würde mein Geld eher jemanden geben, der Parsergeneratoren
>> benutzt' zumindest dann allergisch reagieren dürfen können möchte, wenn ich
>> es gerade mit realweltlichen nicht LR(1) Problemen zu tun habe.
>
>ACK.
Eben.
Ingo Schroeck
> Mirko Liss <n89...@squid.uni-paderborn.de> writes:
>> Bingo: Assembler. Also ist nur Assembler wirklich portabel. qed
> Ich habe vor einiger Zeit in diesem Bereich C-Code gesehen. Was nun?
C ist ist doch nur ein Macro Assembler.
Florian Weimer
> >Na mit Tonnen von ifs oder #ifdefs ;)
>
> Sehen wollen. Als C++ Struktur. Danke.
Kann man mit C++ überhaupt auf zwei benachbarte Octets im Speicher
zugreifen?
Florian Weimer
> Ich benutze keine Sprachen, für die ich keinen freien, stabilen,
> plattformunabhängigen Compiler habe, der performanten Code erzeugt. GNU
> Ada erfüllt nicht den vollen Sprachstandard.
Könntest Du das bitte ein wenig präzisieren? AFAIK ist GNAT der einzige
Compiler, der die ISO-Norm in ihrer Gänze (inklusive der Anhänge)
unterstützt.
Anders Henke
> "ATA macht blank. ATA gehört in den Küchenschrank."
Aber immer daran denken - ATA darf man nach dem BZT erst dann verwenden,
nachdem mindestens einmal RING eingesetzt hat.
Anders
--
http://www.sysiphus.de/
Josef Wolf
> Bei Selberschreiben ist immer noch Assembler die einzig wahre Loesung:
Quatsch!
$ cat >a.out
[ ... viel Tipperei geloescht... ]
^D
$ chmod 750 a.out
Josef Wolf
> Ich meine folgendes: Wenn Du mehrfach geschachtelte Namensräume, Objekte oder
> Records hast, wo Zugriffe auf ein inneres Element erfolgen, so tippt man sich
> in C-Sprachen die Pfoten wund. Deshalb verwendet jeder C-Programmierer, den ich
> kenne, möglichst kurze (und kryptische) Bezeichner.
Aeh?
> In Pascal-Sprachen habe ich einen Befehl zum Umschalten des Namensraums, damit
> habe ich das Problem nicht.
Wer tippfaul ist, verwendet in C-Sprachen Zeiger und hat je Schachtelebene
einen Zeiger. Er kann somit auf alle Schachtelebenen mit wenig Tipperei
zugreifen. Waehrend Du staendig am hin- und herschalten bist.
> >Wenn ich zum Beispiel in Pascal programmiere, mache ich Sachen mit
> >Strings, die ein C-Programmierer niemals tun könnte, weil er keine
> >vollwertige Stringunterstützung zur Verfügung hat.
Meinst Du mit 'vollwertige Stringunterstuetzung' etwa auch eine
Laengenbeschraenkung (oder hat sich das mittlerweile geaendert?)
Oder meinst Du die Unfaehigkeit einen String mit Laenge 19 in einem
String der fuer Laenge 20 definiert ist abzuspeichern (aber moderne
Pascal-Dialekte haben dieses Manko sicherlich auch nicht?)
> Ich meine Stringunterstützung, die funktioniert und nicht, daß die Sprache ein
> "Feature" bietet, konstante Arrays und Pointer darauf in einem einzigen Schritt
> zu definieren.
> Was glaubst Du, warum kaum ein in C geschriebenes Programm brauchbare
> Fehlermeldungen oder detailierte Debuggingausgaben auszugeben (womit nicht
> meine, "segmentation violation - core dumped" und auch nicht nichtssagende
> Fehlernummern oder endlose Speicher-Hexdumps, sondern etwas lesbares)? Weil es
> in C viel mehr Arbeit ist, das ordentlich zu programmieren, als hin und wieder
> eine Fehlernummer im Source nachzusehen.
Ist Dein perror(3) kaputt?
> In Borland Pascal dagegen kann man so
> was tatsächlich programmieren und während der Programmentwicklung auch noch
> Zeit sparen.
Und man schreibt sich die Finger wund, wenn man umfanfreichere
Dateioperaionen machen muss.
PS: Wo war doch gleich nochmal das Papier, das erklaerte, warum man
Pascal meiden sollte?
PPS: Nein, ich meine _nicht_ "real programmers don't use pascal".
Es war vielmehr ein sachlich geschriebenes Papier...
Josef Wolf
> Matthias Heidbrink schrieb:
>
> > Objekte oder Records hast, wo Zugriffe auf ein inneres Element
> > erfolgen, so tippt man sich in C-Sprachen die Pfoten wund.
> > Deshalb verwendet jeder C-Programmierer, den ich kenne, möglichst
> > kurze (und kryptische) Bezeichner.
>
> und Entwicklungsumgebungen zulegen und dann noch nicht mal imstande
> sind, die Suchen-und-Ersetzen- oder Makrofunktion zu finden.
Suchen-und-ersetzen verbieten sich fast von selbst, wenn man eine
Versionsverwaltung verwendet, die auf diff(1) basiert.
Aber ich glaube, das ist hier reichlich OT.
Andreas Kabel
>
> Und man schreibt sich die Finger wund, wenn man umfanfreichere
> Dateioperaionen machen muss.
>
> PS: Wo war doch gleich nochmal das Papier, das erklaerte, warum man
> Pascal meiden sollte?
> PPS: Nein, ich meine _nicht_ "real programmers don't use pascal".
> Es war vielmehr ein sachlich geschriebenes Papier...
@unpublished{Kernighan1981a,
author = {Brian W. Kernighan},
month = {April 2},
note = {Available as http://wwwwbs.cs.tu-berlin.de/\~{\mbox{}}jutta/c/bwk/bwk-on-pascal.html \bibnote{. Copy}},
title = {{Why Pascal is Not My Favorite Programming Language}},
year = {1981}
}
http://www.lysator.liu.se/c/bwk-on-pascal.html
Gruss,
Andreas
In Standard-Pascal kann man nicht mal zwei sortierte Files zeilenweise
in ein drittes File sortieren...
--
Andreas Kabel | aka...@slac.stanford.edu
Stanford Linear Accelerator Center | +1(650)926-5069 (office)
2575 Sand Hill Road, MS 26 | +1(650)926-5368 (fax)
Menlo Park, CA 94025 | +1(650)917-8559 (home)
Thomas Klix
> On 3 Sep 1999 07:12:54 GMT, Andre Poenitz <poe...@mathematik.tu-chemnitz.de> wrote:
> > *seufz* "ATA" mit einem "T". Millo, ich glaube, Du hast in Deiner
> > fruehen Jugend zu selten Toepfe gescheuert...
GOTT, mußt Du alt sein - noch Werbung in der DDR erlebt?
Sagjanur,
Thomas, mit Zufallsig
--
"Oh Gott, ist der alt!"
(Florian Kühnert über Wau Holland auf dem CCC'98)
Thomas Köhler
> * Florian Weimer wrote:
> >Matthias_...@b.maus.de (Matthias Heidbrink) writes [neu umbrochen]:
> >
> >> Objekte oder Records hast, wo Zugriffe auf ein inneres Element
> >> erfolgen, so tippt man sich in C-Sprachen die Pfoten wund.
> >
> >schreiben will, weil der einfach länger ist. ;) Das kann eigentlich
> >kein Argument sein.
>
> Es ist schon allein wegen M-/ sinnlos.
^N/^P und ^X - ein Grund mehr für vim statt vi[1]: ":help ins-completion"
> >> Deshalb verwendet jeder C-Programmierer, den ich kenne, möglichst
> >> kurze (und kryptische) Bezeichner.
> >
> >Der Grund ist wohl eher Tradition (vielleicht unbewußt), da früher bei
>
> Der Grund ist vi. Mit emacs wäre das nicht passiert.
Mit vim auch nicht.
CU,
Thomas [vi-clones rulen]
[1] http://www.vim.org/why.html
--
Thomas Köhler Email: jean...@picard.franken.de
<>< WWW: http://home.pages.de/~jeanluc/
IRC: jeanluc
LCARS --- Linux for Computers on All Real Starships
Felix von Leitner
> > Ich benutze keine Sprachen, für die ich keinen freien, stabilen,
> > plattformunabhängigen Compiler habe, der performanten Code erzeugt. GNU
> > Ada erfüllt nicht den vollen Sprachstandard.
> Könntest Du das bitte ein wenig präzisieren? AFAIK ist GNAT der einzige
> Compiler, der die ISO-Norm in ihrer Gänze (inklusive der Anhänge)
> unterstützt.
Ach ja? Als ich das letzte Mal guckte (ist schon eine Weile her, geb
ich ja auch gerne zu), war dem nicht so. Dann muß ich mir GNAT wohl
nochmal anschauen.
Felix
Michael Holzt
>Wenn ich den Chip auslese, dann komme ich immer nur auf Maschinencode.
>Der Versuch, den ROM-Inhalt als C-Code zu lesen, schlaegt fehl.
>Deine Beobachtung, dass auch C verwendet wird, kann ich also
>nicht stuetzen.
Du bist so hohl, Du schwimmst auch in Milch, oder?
Paul Schmitz-Josten
Silke Graubner schrieb am Fri, 03 Sep 1999 22:34:05 GMT in
<37df4424....@news.btx.dtag.de>:
(DDR-Scheuermittel)
>10 Punkte: ATA ist richtig!
Das gabs hier "drieben" aber auch. Muß ne Vorkriegsmarke sein.
Ciao,
Paul, beim Erstposting einmal rundrum "hallo" sagend
Lutz Donnerhacke
Ja. Nicht portabel, aber es geht:
pair<int,int> get_two_octets(int * p) {
return pair<int, int>(*p & 0xff, (*p >> 8) & 0xff);
}
Lutz Donnerhacke
>$ cat >a.out
>[ ... viel Tipperei geloescht... ]
>^D
>$ chmod 750 a.out
Du kannst Dir viel Tipperei sparen, wenn Du den Codereuser der Fachbergriffe
der Informatik benutzt.
$ (cat /usr/lib/a.out.head; cat) > a.out
...
Kristian Koehntopp
>PS: Wo war doch gleich nochmal das Papier, das erklaerte, warum man
> Pascal meiden sollte?
>PPS: Nein, ich meine _nicht_ "real programmers don't use pascal".
> Es war vielmehr ein sachlich geschriebenes Papier...
Das Paper heisst "Why Pascal Is Not My Favorite Programming
Language" von Brian Kernighan und ist als ACM Classic im Web
verfuegbar. Und auf Lysator (http://www.lysator.liu.se/c ist
sowieso sehr empfehlenswert, das Paper findet man unter
http://www.lysator.liu.se/c/bwk-on-pascal.html).
Viele der im Paper angesprochenen Probleme von Pascal sind
jedoch inzwischen in den real existierenden Implementationen von
Pascal (und Pascal mit Objekten) behoben. In den Sprachen von
Bor^wInprise, die mit ISO-Pascal nichts mehr zu tun haben, gibt
es zum Beispiel Casts und Zeigerarithmetik, Initialisierung,
Includes, Units, Short Circuit Evaluation, alternative
Zugriffsmethoden auf Dateien und noch eine ganze Menge Dinge
mehr, von denen ISO-Pascal noch niemals etwas gehoert hat.
Ich nehme trotzdem C.
Kristian
--
Kristian Koehntopp, Knooper Weg 46, 24103 Kiel, +49 170 2231 811
"We must be the change we wish to see"
-- Ganhdi, also a proper Linux motto.
Olaf Klein
>Ich nehme trotzdem C.
Du wolltest sagen: Fuer Sachen, die man nicht in (Bourne-)Shell, perl, sed,
awk, emacs-lisp, usw. programmieren kann/will, nehme ich trotzdem C.
Wahrscheinlich ist die Fixierung auf C / C++ zum Teil Gewoehnung, aber auch
begruendet durch die Einfachheit der Sprachdefinition (zumindest bei C),
und die Faehigkeit, von "ganz schmutzig" bis "super penibel" programmieren
zu koennen.
Bis denn, Olaf
Thomas Klix
[X] Dein Ironie-Detektor bedarf *dringendst* einer Wartung.
[X] Du wähnst Dich in daf.
[ ] Hier ist doc.
[ ] "recovery" im Hierarchienamen hat keine Bedeutung.
[X] Ernst gemeinte Diskussionen können hier auftreten.
[ ] Ernst gemeinte Diskussionen sind hier richtig.
[?] Diese Unterhaltung gehört nach daa'ooo.
[?] Ich bin Ankreutz-Fan.
Thomas
--
Und, wenn Du bereit bist die Erleuchtung zu empfangen, wirst Du Dir
auch gewahr, daß zu einem X-Post immer ein Flup2 gehört. Alles das kann
Dir das geschriebene Wort in dni sagen. Und Du wirst sehen: Das Usenet
macht mehr Spaß, wenn man es benutzbar hält. Und Du wirst glauben.
(Nils Ketelsen in de.admin.news.misc)
Ralph Angenendt
>GOTT, mußt Du alt sein - noch Werbung in der DDR erlebt?
>
>
>--
>"Oh Gott, ist der alt!"
>(Florian Kühnert über Wau Holland auf dem CCC'98)
Ach komm, Du hast doch bestimmt solange auf <f><y><n>:q!<n> getippt,
bis die .sig zu Deinem Posting passte.
Ralph
--
Deutsch ist eine der schoensten, praezisesten und poetischsten
Sprachen ueberhaupt. Viel besser als Englisch. Sie hat sich nur das
falsche Volk ausgesucht.
-- Harry Rowohlt