🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: ch.comp
Article #86487

Re: Programmiersprache für Kinder

#86487
From: Christoph Nadig
Date: Mon, 24 Mar 1997 00:00
137 lines
4563 bytes
Jonathan Apfelkern, KSC wrote:
> Christoph Nadig wrote:
> > >> Du wirst auch mit C an irgendwelche Grenzen kommen, glaub mir...
> > >Bis jetzt hab ich sie nicht erreicht...
> >
> > OOP?
> 
> Objective-C oder Java.

Wir sprachen von C? Aber bitte, wie Du willst: Wie stehts dann mit
Selbstprogrammier-
barkeit, wie es z.B. funktionale Sprachen kennen?

> > Solange ich also irgend einen Pointer willkuerlich irgendwohin zeigen
> > lassen kann, kannst Du nicht von sauberer Programmierung sprechen.
> 
> Nein. "..zeigen LASSE" muesste es heissen.

Das ist jetzt eben Ansichtssache. Aber gerade beim Anfaenger (um den es
hier ja eigentlich
gehen sollte) wird oft aus "lassen koennen" "lassen". Und das ist
demotivierend

> > Ich bin sicher, Du wolltest Strings sagen.
> 
> Fuer mich ist das ein char array.

Und umgekehrt ein char array ein String?
Aber Du wolltest bestimmt "String" sagen, denn nur die sind
sinnvollerweise
abgeschlossen... (Was sie natuerlich in jeder anderen Sprache auch sind)

> > Du haettest vielleicht gut daran getan, es nicht abzubrechen...
> 
> Damit ich nach 2 Semestern wegen Ahnungslosigkeit in Algebra
> rausfliege?

Oder Informatik? :-)

> > Kleiner Anhang: Miskonzeptionen von C (nicht vollstaendig)
> > - Vorzeichenbehaftigkeit von chars nicht definiert
> Find ich gut.

Erhoeht die Nicht-Portabilitaet. Find ich auch gut...
 
> > - pointerarithmetik
> Geschmackssache.

Und fuer einen elf-jaehrigen?

> > - float existiert nicht wirklich
> Achja? Was ist real dann?

Habe ich in einem frueheren Posting erklaert. s.a. K&R 

> > - Funktionsrueckgabe default als int
> Was ist daran falsch?
Wieso ausgerechnet int? Was, wenn ich den Prototypen vergesse?

> > - leere Expressions: vgl. for(;;) / if()
> 
> Ach DAS ist genial!

Und wieso darf ichs nur beim for()? Alle anderen leeren Expressions
weist mir jeder
Compiler ab

> > - garbage collection unmoeglich!
> Erklaerung bitte.

Bedingt d. Pointerarithmetik, typenloses malloc() und andere
Unschoenheiten ist die
Struktur im Speicher unbekannt, was dazu fuehren wuerde, dass ein GC
alle
Daten als moegliche Pointer behandeln muesste, was wiederum sehr
ineefizient und
auch sinnlos wuerde.
Du weisst, was ein Garbage Collector ist?

> > - missing return in non-void functions
> Sorry, versteh ich nicht.

Lass mal in einer Function, die einen (z.B.) char pointer als
Rueckgabetyp hat,
die returns weg, und Du wirst ultimativ schnell sehen, was ich meine.
Das gehoert eben auch wieder zu den Sachen, die ein Compiler
*problemlos* erkennen
koennte. Aber ich will ja schliesslich alles koennen, auch einen
ungesteuerten
Absturz programmieren...

> > - unions (fehlendes tag-field)
> Was ist ein tag-field?

Du kennst ja Pascal, nicht? Da waere das Tag-Field das Case Label in
einem variant Record.
Es ist relativ wertlos, uniions zu haben, aber nicht bestimmen zu
koennen, was fuer ein
Typ den nun aktuell eingetraken ist. Vgl. in C++, dort fehlt das
Type-Tag

> > - A[i] und i[A] gleichwertig  (z.B. int i; char A[..])
> Ehm.. Worum gehts da? Das ich char als int behandeln kann?

Ich dachte, Du kennst C. A[i] und i[A] stellen *exakt* den selben Wert
dar, naemlich
den i-ten Eintrag im Array A. Das kommt daher, dass C beide
Kontruktionen als
*(A+i) resp. *(i+A) auffasst...

> Das mag ich aber.

Und int als char?
 
> > - Funktionsrueckgabe default als int.
> Deja vu.

Ooops, tatsaechlich... Es sind einfach zuviele Fehleigenscahften, als
dass man den
Ueberblick behalten koennte :-)

> Ehm, vieles von obengenannten sehe ich nicht als Fehler, auch nicht als
> Bereiche die Probleme bieten koennen.

Natuerlich, Du gehoerst ja auch zu den Leuten, denen 'rm core' und 'gdb'
gaenzlich fremd vorkommen... Wenns denn nur an der niedrigen Quantitaet
liegt...

> for(;;) ist genial.

Ich *will* while()  :-)

Gruss, Christoph

-- 
Christoph Nadig    Spectrospin AG, Switzerland    chn@spectrospin.ch
Technical Details
Message-ID: <33368759.167E@spectrospin.ch>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <331D119C.3EBB@energie.ch> <332F1F29.14675B7A@etter.ch> <5gom0l$6up@raf34.iiic.ethz.ch> <33302658.6C6A9E07@etter.ch> <5gqspo$82g@raf34.iiic.ethz.ch> <3331F15A.6F853833@etter.ch>

Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit
X-Google-Thread: 10c1fa,537a61ae0658f396
X-Google-Attributes: gid10c1fa,public
From: Christoph Nadig <chn@spectrospin.ch>
Subject: Re: Programmiersprache für Kinder
Date: 1997/03/24
Message-ID: <33368759.167E@spectrospin.ch>
X-Deja-AN: 228096414
References: <331D119C.3EBB@energie.ch> <332F1F29.14675B7A@etter.ch> <5gom0l$6up@raf34.iiic.ethz.ch> <33302658.6C6A9E07@etter.ch> <5gqspo$82g@raf34.iiic.ethz.ch> <3331F15A.6F853833@etter.ch>
Organization: EUnet AG
Newsgroups: ch.comp