www.mikrocontroller.net

Forum: PC-Programmierung Welche Programmiersprache für Schüler?


Autor: dibujo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich weiß, dass es schon mehrere 'Welche Programmiersprache?'-Threads 
gibt, und ich habe auch da schon etwas recherchiert. Aber ich denke, 
dass meine Frage etwas raushaut.
Kurze Vorrede:
Ich bin Physiklehrer, der auf einem Mac mit Xcode freizeitprogrammiert. 
Mit Xcode kann ich auch problemlos C-Code für den ATmega8 programmieren 
und brennen. Xcode ist eine Mac-Programmierumgebung, die viele 
Programmiersprachen ermöglicht: C, Objective-C, C++, Java, Python, Ruby. 
Ich selbst kann ein bisschen C- und Objective-C.
Meine Schüler (Oberstufe) leben in der Windoofs-Welt. Sie wollen einen 
Quadrokopter bauen, weshalb sie sich mit der 
Mikrocontrollerprogrammierung auseinandersetzen wollen. Ich selbst bin 
ihnen da etwa einen Monat voraus, also auch noch Anfänger. Ich schätze, 
dass meine Schüler Anfänger- bis Fortgeschrittenen-Erfahrungen in der 
Visual-Basic-Programmierung haben. Außerdem können sie (und ich) ein 
Roboter-Mikrocontroller-Interface in dessen Basic-Dialekt programmieren. 
Sie sind wettbewerbserfahren und haben eine gute 'Frustrationstoleranz'.
Frage 1:
In vielen Forumsbeiträgen wird für Assembler geworben, weil es näher an 
der Hardware (bzw. dem Maschinencode?) ist. Nach meinem Umschiffen von 
Assembler sowie den C-Programmiererfahrungen, die ich jetzt habe, kann 
ich diese Argumentation nicht so recht nachvollziehen, da ich zur 
C-Programmierung genauso die Register verwalten muss. Da ich möchte, 
dass meine Schüler ihr Abi packen und daher auch nur 
Freizeitprogrammierer bleiben, tendiere ich z.Z. dazu, meinen Schülern 
die C-Programmierung ans Herz zu legen, weil ich sie da parallel beraten 
könnte. Einzige Alternative sehe ich in BASCOM, weil sie hier halt schon 
Basic-Erfahrungen einbringen können. Wie seht ihre das?
Frage 2:
Für Steuerungsaufgaben wäre natürlich langfristig eine PC-Programmierung 
nett. Nach den Forumsbeiträgen zu urteilen würden die meisten C# bzw. 
C++ favorisieren, wo die Schüler ihre (dann schon vorhandenen) 
C-Kenntnisse einbringen könnten. Alternative wegen Basic-Erfahrung: 
Visual-Basic. Da ich annehme, dass die Schüler nach dem Abitur in Sachen 
'Programmierung & Technik' weiter machen und studieren werden, wäre auch 
hier eine längerfristige Lösung wichtig, und nicht nur ein möglichst 
schnelles Ergebnis. Zum Zweiten: Wie seht ihr das?
Vielen Dank für Eure, hoffentlich klärenden Beiträge. Berücksichtigt 
dabei bitte auch, dass ich sie beraten möchte. Also bitte keine schrägen 
Individual-Empfehlungen abseits der hier genannten Programmiersprachen, 
außer natürlich es macht wirklich absolut Sinn.
dibujo

Autor: hellboy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An der der FH wo ich studiere wird im ersten und zweiten jahr alles in c 
und oder c++ unterrichtet .....

also wäre es von dem standpunkt her nicht völlig falsch;)

 ASM halte ich für übertrieben! Die systeme sind mitlerweile alle so 
leistungsfähig das das meiner ansicht nach nicht nötig ist! Sollte man 
sehr sehr sehr zeit kritische Routienen brauchen so kann man diese in 
ASM noch in das c programm einbinden.... und für den pc ist asm eh 
schwachsinnig.... Ich denke es wäre sinnvoll mit einem kleinen Projekt 
anzufangen;) direkt an so ein riesen projekt dran ist denke ich 
aussichtslos

Autor: Jonny Obivan (-geo-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auch für c plädieren. Bei mir an der Hochschule war das damals 
auch die Standardsprache für solche Zwecke. Wir haben nur c und c++ 
programmiert. Mit c kann man wirklich nichts falsch machen und die Kids 
lernen was Vernünftiges.

Ich finde die Sprache c für die µC Programmierung auch nicht besonders 
schwer. Wenn es an die Windowsprogrammierung geht, gibts allerdings 
einfachere Sprachen als C++.

Grüße
Jonny

Autor: Randy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mit Xcode kann ich auch problemlos C-Code für den ATmega8
> programmieren und brennen.

C ist auch die Standardsprache für Mikrocontoller. Andere Sprachen gibts 
normal nicht. Dass es für den AVR auch Bascom und ein Pascal Derivat 
gibt ist eher Hobbyprogrammierern zu verdanken. Für Typen die nur in der 
Industrie benutzt werden gibt i.a. vom Hersteller einen C-Compiler und 
das wars.

> In vielen Forumsbeiträgen wird für Assembler geworben, weil es näher an
> der Hardware (bzw. dem Maschinencode?) ist. Nach meinem Umschiffen von
> Assembler sowie den C-Programmiererfahrungen, die ich jetzt habe, kann
> ich diese Argumentation nicht so recht nachvollziehen,

Mit Assembler kann man evtl. und auch nur vielleicht mal da und dort ein 
Byte sparen, aber wenn man kein kostensensitives Produkt in 
Millionenstückzahl produziert wird in der Industrie in C programmiert.
-> Der Mehraufwand


> die C-Programmierung ans Herz zu legen, weil ich sie da parallel
> beraten könnte. Einzige Alternative sehe ich in BASCOM, weil sie hier
> halt schon Basic-Erfahrungen einbringen können.

Ich würde die Bedeutung der Programmiersprache nicht überschätzen. Es 
ist doch so dass es für jedes Konstrukt in Basic ein Entsprechendes in C 
oder Pascal (oder in jeder anderen prozedurorientieren Sprache, den 
ganzen "Algol68"-Ähnlichen) gibt, wahrscheinlich sogar 1:1. Nur die 
Syntax ist ein wenig anders. Aber da - denke ich - werden die Schüler 
sich recht schnell umstellen können.
Das beste Beispiel dafür ist noch Borlad C++. Die hatten ihr Borland 
Delphi (ein Pascal mit OO-Erweiterungen) zuerst draussen, und als sie 
gesehen habe dass der Markt aber auch C++ will, haben sie ihre C++-IDE 
gestrikt indem sie ihrer IDE einen C++-zu-Delphi-Preprocessor 
drangeklatscht haben. Der hat nur die Sytax umgestellt, alle Konstrukte 
und Programmierideen haben 1:1 in beiden Sprachen funktioniert. 
(Deswegen hasse ich auch alle Basic vs. C vs. Pascal Diskussionen, die 
Sprachen sind genau gleich, nur mit leicht abgewandelter Syntax)

Viel wichtiger und kritischer sehe ich die "Programmierumgebung", d.h. 
dass man den Compiler mitsamt der meist vorhandenen IDE (intgrated 
development environment, d.h. das ganze Fenster-Zeug und Klinki-Bunti 
drumrum) und das Programmierkabel im Griff hat. Dass man z.B. weiß wenn 
dieser oder jene seltsame Fehler auftaucht, woran das liegt ("aah, das 
Problem hatte ich schon mal, da muß noch dieses Verzeichis in den Pfad 
oder die Zeile in das Makefile oder ..."). Weil das kann ewig viel Zeit 
kosten. Eigentlich würde ich raten die selbe Programmierumgebung im 
Unterricht zu benutzen die du schon von deinem Privatrechner kennst, 
aber die Schule hat wahrscheinlich keine Macs. Gibts das "Xcode" auch 
für das OS das die Rechner an der Schule haben?
Ansonsten musst du dich an das Forum hier halten wenns mit WinAVR oder 
dem AVR-Studio Probleme gibt.

HTH
Randy

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asssembler, denn mit allem anderen lernt man die Grundlagen nicht und 
kann deshalb nicht effizient proggen. Schön wäre es auch, wenn mal 
jemand nen vollständigen Befehlssatz (so wie die kurze AVR-Asm Referenz, 
die ist extrem super) vom 80x86 mit allen Erweiterungen (MMX, Pentium X, 
SSE etc.) veröffentlichen würde, denn sonst muss man sich den Kram alles 
im Internet zusammensuchen. Ausserdem ist ASM sehr praktisch um 
willentlich und unwillentliche Bugs zu entfernen :)

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ausserdem ist ASM sehr praktisch um
> willentlich und unwillentliche Bugs zu entfernen :)

Programme entdongeln ?

Gruß Fred :)

Autor: Me (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist kompletter Unsinn. Man braucht keines Wegs Assembler zu lernen 
um effizient programmieren zu können. C ist maschinennah genug um damit 
sehr effizient zu programmieren. Will man sein Leben angenehm gestalten 
ist auch C++ sehr gut geeignet. Entgegen vieler Meinungen hier kann man 
auch wunderbar C++ als erste Programmiersprache lernen. C++ ist zwar 
viel komplexer als etwa C, BASIC oder Pascal, aber von der Komplexität 
sieht man am Anfang nicht viel. Man fängt ja nicht gleich mit templates 
und Polymorphie an.

Autor: G. Bremer (picoli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke auch, dass die Programmierumgebung nicht vernachlässigt werden 
sollte.

Gerade Anfängern vergeht häufig schon die Lust am Programmieren, bevor 
sie das System überhaupt zum Laufen gebracht haben.

Mit C bzw. C++ kann man nichts falsch machen. Selbst wenn man später 
Visual Basic oder Delphi oder Java nutzen möchte, fällt dies mit C 
Kentnissen wesentlicher einfacher.

Darum möchte ich an dieser Stelle Anfängern, die einen Einblick in die 
professionelle Programmentwicklung bekommen möchten, noch einmal auf die 
Seite http://www.haiq.info hinweisen.

Dort wird als erstes in 3 Stufen die komplette Programmierumgebung mit 
den OpenSource Paketen von Trolltech (Qt4), dem OpenSource Compiler 
MinGW, sowie der OpenSource IDE (HaiQ) installiert.

Danach geht es direkt in die Programmierung (10 Lektionen, learning by 
doing). Und zwar unabhängig von Microsoft (für alle gängigen 
Betriebssysteme geeignet).

Ich würde einem Anfänger, aus eigener Erfahrung, auch nicht empfehlen, 
vorher dicke Lehrbücher zu studieren. Am Anfang ist das Problem, dass 
man das Wesentliche noch nicht vom Unwesentlichen unterscheiden kann und 
somit gezwungen ist, sich alle reinzuziehen, was am Anfang mehr 
verwirrend denn hilfreich ist.

Nach dem Lehrgang sind die Leute jedenfalls so weit, dass sie einen 
umfassenden Einblick in die graphische C bzw. C++ Entwicklung erworben 
haben, um selbst entscheiden zu können, wie (und ob überhaupt) sie damit 
weitermachen wollen. Dann können sie auch den Ausführungen in 
Lehrbüchern folgen und haben schon mal eine 'bildliche' Vorstellung 
davon, was jene seltsamen Begriffe und Abkürzungen und ... und ... und 
... überhaupt bedeuten.

Und laßt Euch nicht von den 'Profis' verrückt machen. So schwer, wie die 
es oft machen, ist Programmieren gar nicht. Man muß nur den richtigen 
Einstieg finden, um nicht schon zu Beginn den Spaß daran zu verlieren.

In diesem Sinne ... good coding ...

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mit Basic angefangen, danach mit asm, damit konnte man
Sachen machen, die mit Basic nicht gingen! (25 Jahre her)!

Hatte danach einen Abstecher zu Pascal, und bin wieder bei
Basic (Visual-Basic, Bascom) und asm gelandet!

Ich behaupte, mit dieser Kombination kann man (nicht unbedingt ich)
alles, was aus dem C Lager kommt, bezüglich Entwicklungszeit und
Programmausführungsgeschwindigkeit in den Schatten stellen!

Es gibt aber auch Nachteile:

Basic wird selten (gar nicht) an Hochschulen gelehrt, dadurch sind
nur wenige gute Quelltexte im Internet verfügbar.

siehe

http://nehe.gamedev.net/

dort fehlen zu einigen Lektionen die Basic Quellen

Da die meisten der proffessionellen Progs in C programmieren
und Basic nicht verstehen wollen, halten sich hartnäckig
die Vorurteile: Basic ist langsam, hat einen großen Footprint,
keine Zeiger, keine Datenfelder, keine Vererbung .....
Diese Aufzählung lässt sich beliebig erweitern.

Nochmal an alle C-Leute DEM IST NICHT SO.

Basic hat noch ein Nachteil:
Man wird als Anfänger nicht zum struktuierten Programmierung
gezwungen. Dieser Nachteil kann sich aber später zu einem
riesen Vorteil wandeln! Nämlich dann, wenn die C-Leute
komplette Klassenstrukturen durch den Ram ziehen und sich
wundern, dass ihr Programm nicht unter einem GByte Hauptspeicher
läuft! (das war jetzt übertrieben aber beschreibt trotzdem
das Grundproblem)

so zum Schluß:

Jede Hochsprache hat Vor- und Nachteile, darum haben alle
ihre Berechtigung! Wer das Geklammer in C bzw. in Pascal
mag, soll es tun.

Anmerkung:

Kann C und Pascal Quellen lesen möchte aber nicht in diesem Stil
programieren müssen!

Fred

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ihr schon eine gewisse Basic-Affinität habt, dann schau dir mal 
RealBasic an!

http://www.application-systems.de/realbasic/

Das gibts für Mac, Windows und Linux in identischen Versionen und man 
kann auf jeder Plattform auch für die jeweils anderen lauffähige 
Programme compilieren. Fertige Programme benötigen keine Installation 
und bestehen nur aus einer einzigen Datei, es ist keine extra 
Laufzeitumgebung oder RuntimeLib nötig. Das bietet so m.E. z.Zt. keine 
andere IDE.

Damit kann man natürlich nicht für Mikrocontroller programmieren, aber 
für Desktop und Notebook.

Und bevor alle die, die Basic nicht mögen (ist jedem selber überlassen), 
wieder "Buh" und "Bäh" rufen: RB ist ein modernes, objektorientiertes 
System mit Klassen, Methoden und Funktionen. Man kann eigene Klassen 
erstellen oder von vorhandenen ableite und erweitern.

Es gibt praktisch Nichts, was nicht geht, z.B. Netzwerk-, Internet und 
Multimedia, Grafik (Pixel und Vektor), Datenbankzugriffe (MySQL, Oracle, 
Postgre, OpenSQL, SQLLite, ODBC ...), PDF erstellen/lesen, 
Systemzugriffe (die schränken dann antürlich die Plattformunabhängigkeit 
ein), Schnittstellen (seriell, parallel, USB), Drucken usw.

Ich mache seit ca. 5 Jahren große kommerzielle Projekte mit Realbasic 
und habe es bisher nicht bereut.

Frank

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab das früher ähnlich gemacht. Lange Zeit Basic und dann Assembler 
dazu (erst über CALL ABSOLUTE, später dann über libs). War auch immer 
der Meinung, dass man C/C++ einfach nicht braucht.

Irgendwann bin ich dann doch umgestiegen und bin heute der Meinung, dass 
Basic (inzw. Visual Basic) zwar ganz nett für kleine Sachen ist, sonst 
aber nix taugt.
In einer Schule ist es wahrscheinlich wirklich gut aufgehoben, aber 
später bei richtigen Projekten wird man (eigentlich zurecht) ausgelacht, 
wenn man mit Basic ankommt.

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

> In einer Schule ist es wahrscheinlich wirklich gut aufgehoben, aber
> später bei richtigen Projekten wird man (eigentlich zurecht) ausgelacht,
> wenn man mit Basic ankommt.

Ich will nicht bestreiten, dass es so ist. Ist am Ende auch jedem seine 
Sache. Mich würde aber mal interssieren, warum das so ist. Ich vermute, 
dass die meisten heutigen Basic-Gegner auf ihrem Kenntnisstand von MS- 
bzw. QBASIC o.ä. stehengeblieben sind - dann hätten sie natürlich recht.

Irgendwie scheinen nur wenige zur Kenntnis zu nehmen wollen, dass auch 
Basic-Dialekte weiterentwickelt werden. Und ob ich nun "if ... then ... 
end if" schreibe oder das Ganze in geschweifte Klammern, ist nun sowas 
von egal.

Frank

Autor: ZehPlusPlus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob sich BASIC nun weiter entwickelt oder nicht, BASIC ist und bleibt ein 
Beginners All-purpose Symbolic Instruction Code - eine reine 
Anfänger-Programmiersprache.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ZehPlusPlus

da schon wieder einer der keine Ahnung hat!

Fred

Autor: ZehPlusPlus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Fred

da schon wieder einer der keine Ahnung hat!

ZehPlusPlus

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ZehPlusPlus

ich wette das Du nicht mal weißt was ein UDT ist!

Gruß Fred

Autor: ZehPlusPlus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt auf den Zusammenhang drauf an.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ZehPlusPlus

siehste, aber jeder Basic Programmierer weiß
dass ein UDT eine Struktur in C ist!

Fred :]

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung) 
ala CVS oder Subversion? Wie schaut es mit fertigen Make-Skripts aus? 
Wenn ich ein großes Projekt hab will ich nicht jedesmal alles neu 
übersetzen müssen. Ist es möglich mit mehreren Leuten gleichzeitig 
weiterzuarbeiten?

Das allein zur Umgebung - die Sprache selbst erlaubt afair keine 
ordentliche Trennung bei großen Projekten. Selbst bei C++ hat man 
festgestellt, dass das noch etwas mangelhaft ist - und Namespaces 
eingeführt, zusätzlich zu all den Mechanismen die C und C++ ohnehin 
schon bieten.
Header sind in C/C++ auch ein enormer Vorteil, Java hat Packages, und so 
hat jede größere Sprache ihre Mechanismen große Projekte zu kapseln. Hat 
Basic sowas?
Denk mal an den Linux Kernel. Ich hab da eben mal sloccount drübergejagt 
(Programm das Codezeilen zählt und Sprachen zuordnet, dabei werden 
doppelte Sachen ausgefiltert und Leerzeilen, Kommentare etc. auch 
weggelassen).
Das Ding enthält 5 Mio. Codezeilen, aber jedes Modul etc. für sich sieht 
nur einen klitzekleinen Teil davon. Mach sowas mal mit Basic.

Multithreading ist mit Basic auch ein Problem (hat sich da mit .net was 
verbessert? Bei VS 6 würd ich sagen da gibt's kein Problem - es 
existiert einfach nicht).

Autor: ZehPlusPlus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fred:
Ach komm, was soll das getrolle? Die Abk. UDT hat viele Bedeutungen (-> 
Google). Woher soll ich wissen, was du meinst?

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)
> ala CVS oder Subversion?

RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS 
verwaltet werden.

> Wenn ich ein großes Projekt hab will ich nicht jedesmal alles neu
> übersetzen müssen.

Das Übersetzten selbst großer Projekte (z.B. 2 MB Quellcode) dauert nur 
Sekunden, ist egal ...

>Ist es möglich mit mehreren Leuten gleichzeitig
> weiterzuarbeiten?

Man kann Codesegmente als externe Module oder Klassen irgendwo im Netz 
ablegen. Dann können verschiedene Leute daran arbeiten.

> Das allein zur Umgebung - die Sprache selbst erlaubt afair keine
> ordentliche Trennung bei großen Projekten.

s.O., nach der OO-Methode, z.B.

main.ok=DB_Zugriff.open(User.loginData)

wobei z.B. DB_Zugriff ein in sich geschlossenes Modul sein kann, main.ok 
eine boolesche Variable des Fensters main und user.logindata eine 
Eigenschaft des Objektes User ...

> Multithreading ist mit Basic auch ein Problem (hat sich da mit .net was
> verbessert? Bei VS 6 würd ich sagen da gibt's kein Problem - es
> existiert einfach nicht).

RB kann Threads, ohne NET auf allen 3 Plattformen.

Frank

Autor: Hä? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> > Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)
> > ala CVS oder Subversion?
>
> RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS
> verwaltet werden.

Heißt das, man kann den Quelltext nicht mit jedem beliebigen Texteditor 
bearbeiten?

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann wählen bzw. voreinstellen, zwischen

- einem eigenen komprimierten Format (Standard)
- XML
- nur Text

Beim Laden wird das Format automatisch erkannt.

Frank

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also als "Anfänger" einen Quadrokopter bauen zu wollen halte ich für 
sehr mutig. Ich hab mich mal ein bisschen hereingelesen, was alles 
gebraucht wird an Bauteilen und vor allem Algorithmen, holla die 
Waldfee!

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das meiste davon hört sich eher nach Verlegenheitslösung an.

Frank Esselbach wrote:
> RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS
> verwaltet werden.

Kann Visual Basic das auch? Ist Quellcode zwischen den beiden 
austauschbar? Wie schon gefragt wurde - lässt sich Realbasic Code auch 
mit anderen Editoren öffnen?

Selbst in visual studio c/c++ kann ich mir aussuchen welchen Compiler 
ich heute nehmen will - bin also unabhängig. Geht das auch bei Basic?

>> Wenn ich ein großes Projekt hab will ich nicht jedesmal alles neu
>> übersetzen müssen.
>
> Das Übersetzten selbst großer Projekte (z.B. 2 MB Quellcode) dauert nur
> Sekunden, ist egal ...

Nein, ist es nicht. Der Linux Kernel ist gepackt (!) schon ~40MB groß, 
entpackt ist meiner 500MB. Wie sieht es da aus?
Der Kernel ist übrigens gemessen am Gesamtsystem eine eher kleine, aber 
sehr komplizierte Komponente. Gegen zB. KDE ist der Linux Kernel ein 
Winzling.

Noch vergessen: Gibt es alternative Compiler?

>>Ist es möglich mit mehreren Leuten gleichzeitig
>> weiterzuarbeiten?
>
> Man kann Codesegmente als externe Module oder Klassen irgendwo im Netz
> ablegen. Dann können verschiedene Leute daran arbeiten.

Das meinte ich nicht. Gibt es Möglichkeiten für alle Entwickler 
einsehbar bestimmte Sachen zu sperren, damit solang niemand anders an 
der selben Sache weiterentwickelt?
Für sowas braucht es eigentlich ein ausgewachsenes 
Versionskontrollsystem.

>> Das allein zur Umgebung - die Sprache selbst erlaubt afair keine
>> ordentliche Trennung bei großen Projekten.
>
> s.O., nach der OO-Methode, z.B.
>
> main.ok=DB_Zugriff.open(User.loginData)
>
> wobei z.B. DB_Zugriff ein in sich geschlossenes Modul sein kann, main.ok
> eine boolesche Variable des Fensters main und user.logindata eine
> Eigenschaft des Objektes User ...

Das ist keine ordentliche Trennung. Im Namespace hast du nach wie vor 
alle Module etc. rumfliegen. Wie gesagt, sowas kann C, C++, Java, etc. 
auch - und weil es nicht reicht kennen die alle noch weitergehende 
Konzepte.
Man könnte es zwar auch einzig und allein über Module machen, aber man 
könnte auch alles in Assembler entwickeln.

>> Multithreading ist mit Basic auch ein Problem (hat sich da mit .net was
>> verbessert? Bei VS 6 würd ich sagen da gibt's kein Problem - es
>> existiert einfach nicht).
>
> RB kann Threads, ohne NET auf allen 3 Plattformen.

Gibt es dafür gute Debugger? Wie sieht es mit Interthreadkommunikation 
aus?



Wie gesagt - schaut alles nach Verlegenheitslösung aus. Klar 
funktioniert das für einen Hobbyprogrammierer, da funktioniert das 
mitunter sogar besser als eine ausgewachsene Lösung, weil man auch ohne 
lange Einarbeitungszeit damit klarkommt.
Aber bei größeren Sachen stößt man schnell an Grenzen.

Autor: Nico Erfurth (masta79)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde einfach C einführen. Das ist in dem Bereich einfach der 
Standard. Ein wenig ASM am Rande hat aber sicher noch niemandem 
geschadet. Das fördert häufig das Verständniss für die internen Abläufe. 
Als Entwicklungs-Umgebung auf jeden Fall AVR-Studio+WinAVR, damit können 
die auch zuhause problemlos arbeiten. Und dank GCC kann dann auch jeder 
die Plattform nutzen die er gerne hätte (Windoof, Mac, Linux, 
wasauchimmer)

Wichtiger als die Programmiersprache finde ich aber das die Schüler 
lernen die Hardware und ihre Abläufe zu verstehen. Ausserdem sollten sie 
dabei auch lernen strukturiert zu arbeiten und sich vorher ein paar 
Gedanken zu machen bevor zu drauf loshacken. ;)

Autor: tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe an der Schule und an der Hochschule am Anfang zunächst 
immer Assembler gelernt, keine großartigen optimierten Programme, aber 
z.B. eine etwas schwierigere Aufgabe "wie kann man eine Multiplikation 
zweier Binärzahlen lösen wenn es keine Multiplikationsbefehl gibt" Oder 
wie wird ein Unterprogramm geschrieben (Sprungbefehle). Ich finde das 
sehr wichtig, dass man Assembler-Grundzüge lernt, denn wenn man später 
mal Fehler im C-Code suchen muss, dann kann es passieren dass man wieder 
auf der Assemblerebene landet.
Nach jeweils einem Semester bzw. Schuljahr wurde dann C eingeführt, da 
kamen dann auch mal komplexere Sachen, LCD ansteuern, 
RS232-Kommunikation, I2C-Bus, SPI-Schnittstelle.

Autor: (=^. .^=)ミャー (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Wir haben in der Schule Common LISP und in der Uni Scheme gelernt)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Randy schrieb:
[...]
> Ich würde die Bedeutung der Programmiersprache nicht überschätzen.
[...]

Naja, also das letzte mal, als ich mir BASIC angeschaut habe, war das 
auf dem C64. ;-)

Als ich da mal was schönes abstraktes programmieren wollte,
und zwar ein Programm, das mir die kürzeste Verbindung zwischen zwei 
Bahnhöfen im Berliner U-Bahn-Netz ausgibt, da war's das dann mit Basic.
Zumindest das Commodore-basic von damals ermögglichte mir nicht eine 
Möglichkeit, solche Probleme zu lösen (oder jedenfalls nicht sinnvoll).

Es gab nicht die entsprechenden Datenstrukturen, die dazu notwendig 
gewesen wären. Das hatte mir damals einen riesen Frust eingebracht und 
meine Computerbegeisterung stark abgebremst.

Als ich dann später C lernete, sah ich, daß dies zwar als Sprache solche 
Datenstrukturen auch nicht mitbringt, mir aber die Möglichkeit gibt, 
diese selber zu bauen.


Inwieweit sowas nun beim Controller-programmieren von Wichtigkeit ist?
Hmhhh, kommt wohl drauf an, wie simpel/primitiv man seinen Code bauen 
will, oder wie komplexe Sachen man implementieren will.

Vielleicht ist da auch was größeres als ein 8-Bit-AVR von nöten, wenn 
man wirklich komplexe Sachen bauen will, oder muss sich seine eigene 
Sprache und seinen eigenen Compiler bauen.

Aber ich denke, wenn man schon eine Hochsprache wie C nimmt, will man 
vielleicht auch die Möglichkeiten ausschöpfen.
Ansonsten darf ich mal festhalten, daß der Befehlssatz des AVR ja doch 
ziemlich C-ähnlich ist, und wenn man keine sehr abstrakten Dinge baut, 
kann man auch fast gleich beim Assembler bleiben.

Und hin und wieder muss man auch Assembler nehmen, da der C-Code ggf. 
nicht das bietet, was man sucht.... zum beispiel musste ich letztens 
Assembler-Code nutzen, um die Taktrate eines AVR's umzuprogrammieren, 
weil der vom avr-gcc gelieferte Code nicht nutzbar dafür war. (brauchte 
zu viele Taktzyklen).

Alles in Allem tendiere ich daher dazu, bei etwas größeren projekten C 
zu nehmen, und aber auch Assembler zu kennen, wenigstens mal sich das 
anzuschauen. Am besten auch mal ein komplettes projekt in Assembler zu 
machen (auch wenn es nur was kleines ist).

BASIC halte ich für Schüler als zum kennen lernen OK.
Man wird ja nicht gleich zu krasse Sachen programmieren wollen, wenn man 
die Materie gerade kennen lernen will.

Wenn man aber z.B. Robotik machen will (wie bei mir demnächst), und auch 
mal etwas komplexere Algorithmen nutzen will, also etwas abstrakter an 
die Sache dran geht, dann ist absehbar, daß man mit BASIC nicht weit 
kommen wird.

[...]
> (Deswegen hasse ich auch alle Basic vs. C vs. Pascal Diskussionen, die
> Sprachen sind genau gleich, nur mit leicht abgewandelter Syntax)
[...]


Wenn man immer nur
setze_Port(), lösche_Port(), und if-then-else sowie wait_soundso_ms()
macht, stimmt das.

Wenn man aber auch mal abstraktere Sachen bauen will,
kommt man um eine geeignete Programmiersprache nicht herum.


Aber dies basiert auf dem BASIC von Commodore; inwieweit denn der BASCOM 
auch wirklich inder Lage ist, andere Datenstrukturen anzubieten, weiss 
ich nict, aber soweit ich das gesehen habe, was so im netz zu finden 
war, sieht es da nicht so rosig aus.


Oliver

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schrieb:
> Asssembler, denn mit allem anderen lernt man die Grundlagen nicht und
> kann deshalb nicht effizient proggen.
[...]

Sehe ich genauso.

Anfangs wollte ich nur Assembler nehmen; aber auf Arbeit wird C 
genommen.
Also mache ich nun beides. :-)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:
> Habe mit Basic angefangen, danach mit asm, damit konnte man
> Sachen machen, die mit Basic nicht gingen! (25 Jahre her)!

heheh.... siehste: mit BASIC alleine ging es nicht.


[...]
> Ich behaupte, mit dieser Kombination kann man (nicht unbedingt ich)
> alles, was aus dem C Lager kommt, bezüglich Entwicklungszeit und
> Programmausführungsgeschwindigkeit in den Schatten stellen!
[...]

Wenn man gut C kann, und abstrakt programmiertt, kann man das evtl. auch 
wieder toppen ;-)



>
> Es gibt aber auch Nachteile:
>
> Basic wird selten (gar nicht) an Hochschulen gelehrt, dadurch sind
> nur wenige gute Quelltexte im Internet verfügbar.

Welches BASIC denn?
da gibt es wohl mehr BASIC's als es C's gibt :-)



[...]
> Da die meisten der proffessionellen Progs in C programmieren
> und Basic nicht verstehen wollen, halten sich hartnäckig
> die Vorurteile: Basic ist langsam, hat einen großen Footprint,
> keine Zeiger, keine Datenfelder, keine Vererbung .....
> Diese Aufzählung lässt sich beliebig erweitern.
>
> Nochmal an alle C-Leute DEM IST NICHT SO.

Es gibt in BASIC Pointer?
Welches BASIC ist das denn?

Das ist mir jedenfalls neu.
Kann man sich in BASIC auch eigene Datenstrukturen bauen?



>
> Basic hat noch ein Nachteil:
> Man wird als Anfänger nicht zum struktuierten Programmierung
> gezwungen. Dieser Nachteil kann sich aber später zu einem
> riesen Vorteil wandeln! Nämlich dann, wenn die C-Leute
> komplette Klassenstrukturen durch den Ram ziehen

C hat keine Klassen.
Das gibt es bei C++, aber nicht bei C.

Und wer ein bischen  mitdenkt, beim programmieren,
der macht seinen Code auh schlank.
Unter anderem durch Auswahl geeigeneter Datenstrukturen.



> und sich
> wundern, dass ihr Programm nicht unter einem GByte Hauptspeicher
> läuft! (das war jetzt übertrieben aber beschreibt trotzdem
> das Grundproblem)

Das wäre im prinzip auch bei BASIC ein Problem.... ausser,  man kann so 
komplexe Sachen damit garnicht bauen... was meiner Meinung nach der Fall 
ist.



[...]
> Kann C und Pascal Quellen lesen möchte aber nicht in diesem Stil
> programieren müssen!
[...]

Tja, die Syntax von BASIC (BASCOM) habe ich mir vorhin nochmal 
angeschaut.
Sieht schon recht leserlich aus.
Es gibt durchaus besser lesbaren Code als das meiste C-Zeugs.
Gibt auch wesentlich bessere Sprachen als BASIC, Pascal, C, C++ usw.
aber nicht für's MicroController-Umfeld zugeschnitten.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. schrieb:
> Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)
> ala CVS oder Subversion?

Man kann das versionskontrollsystem für jeglichen Programmcode benutzen.

Was hat das denn mit der programmiersprache zu tun?!

...tse.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Esselbach schrieb:
>> Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)
>> ala CVS oder Subversion?
>
> RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS
> verwaltet werden.

Häh?

Man kann doch den Sorurce, den man tippt mit cvs bzw. svn verwalten...

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Oliver B.

Der letzte Eintrag der nicht von dir ist ist vom 06.07.2008

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tim schrieb:
> Also ich habe an der Schule und an der Hochschule am Anfang zunächst
> immer Assembler gelernt, keine großartigen optimierten Programme, aber
> z.B. eine etwas schwierigere Aufgabe "wie kann man eine Multiplikation
> zweier Binärzahlen lösen wenn es keine Multiplikationsbefehl gibt" Oder
> wie wird ein Unterprogramm geschrieben (Sprungbefehle).

Soweit stimme ich zu.


> Ich finde das
> sehr wichtig, dass man Assembler-Grundzüge lernt, denn wenn man später
> mal Fehler im C-Code suchen muss, dann kann es passieren dass man wieder
> auf der Assemblerebene landet.


Hier sehe ich das anders, jedenfalls, wenn die Diskussion hier so weit 
weg vom Microkontroller ist.... im Unix-/Linux-Umfeld musste ich mir nie 
den Assemblercode anschauen, um C-Probleme zu lösen.
Aber letztens, beim Prograsmmieren von Startcode für einen AVR-Chip 
musste ich das tatsächlich.
Dann müssten wir die Diskussion aber wieder zurück zum Theme Controller 
führen.

Wenn es hier ganz allgemein um Programmiersprachen geht,
nicht auf controller bezogen, dann darf ich bitte noch OCaml und Haskell 
erwähnen, sowie Python.

Für deftige Projekte im Unixoiden Umfeld würde ich zu OCaml raten.
Wenn man viele Libraries braucht und Performance nicht so ein Problem 
darstellt, oder man auch GUI-zeugs oder Web-zeugs machen will, kann man 
mit Python gut voran kommen. (Oder mit Perl; Python ist aber noch besser 
strukturiert als Perl.)


Für Controller-Zeugs steht IMHO nur C und Assembler zur Debatte,
aber meine BASIC-kenntnisse sind ein paar Dekaden alt.

Lasse mich gerne davon überzeugen, daß man mit BASIC heutzutage auch 
eigene Datenstrukturenimplementiewren kann.

Da hätte ich gerne mal Beispielcode dafür gesehen,
aber auch für ein BSDIC, das auch auf AVR läuft. :-)

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut Lenzen schrieb:

> @ Oliver B.
>
> Der letzte Eintrag der nicht von dir ist ist vom 06.07.2008

Jetzt nicht mehr ;-)

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C ist eine gute Idee weil es nebenbei viel Hardwaregrundlagen 
vermittelt.

Bei BASIC empfinde ich die sehr kontextbehaftete Grammatik eher als 
Lernhindernis...

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
den richtigen geist schilt man mit LISP

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schilt? grillt? killed?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das i liegt auf der Tastatur neben dem u.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was ist LUSP?

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch auf die gefahr hin, dass es schon jemand vorgeschlagen hat (ich hab 
nicht den ganzen Thread gelesen)

Schülern, als Einstieg in die Programmierung würde ich Logo (falls es 
das noch gibt) oder Processing empfehlen.

bei beiden sieht man schnell Resultate und kann recht feine sachen damit 
machen

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zwieblum schrieb:
> den richtigen geist schilt man mit LISP

achso, den Geist chillt man mit LISP? ;-)


ich dachte, es wäre eher gut, ihn anzuregen ;-)


Ja,LISP hätte ich beinahe auch genannt;
aber da das steht eigentlich noch auf meiner
wenn-ich-zeit-habe-schaue-ich-mir-das-mal-näher-an-Liste.

daher habe ich's weggelassen

Autor: Niklas Gürtler (erlkoenig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Schülern, als Einstieg in die Programmierung würde ich Logo (falls es
> das noch gibt) oder Processing empfehlen.
Leider gibt es Logo noch, hat aber Probleme mit der DOS-Emulation unter 
XP und modernen Grafikkarten.
> bei beiden sieht man schnell Resultate und kann recht feine sachen damit
> machen
Sag mal, bist du wahnsinnig? Logo ist die krankste 
"Programmiersprache", die ich je gesehen habe. Da mein Lehrer kein 
Englisch konnte und so Dinge wie "if" ihm daher unmöglich waren zu 
lernen, mussten wir das deutsche Logo verwenden. Die Lernkurve bei Logo 
ist ein ganz flacher Logarithmus:
Tatsächlich, am Anfang sieht man schnell, wie einfach es ist ein paar 
Linien zu zeichnen. Sobald die Programme aber minimal komplexer werden, 
wirds ekelig: Keine Zeilenumbrüche in "WENN"-Blöcken möglich (nicht nur 
nicht in der Bedingung, sondern auch nicht im auszuführenden Code!!) - 
d.h. wunderschön lange Zeilen - mysteriöse Bugs im Parser, absolut 
unverständliche und verwirrende Fehlermeldungen, hirnrissige Namen der 
Befehle, nur globale Variablen (keine funktionslokalen Variablen möglich 
- sehr viel Spaß bei der Fehlersuche), keine structs o.ä., bekloppte 
Syntax...
Logo ist der mit Abstand beste Weg, Schülern zu erklären "lernt 
niemals programmieren, es ist eine einzige Qual und ihr werdet es eh 
nicht verstehen".
Selbst ich als damals schon der C/C++ -Programmierung mächtiger hatte 
oft genug Schwierigkeiten zu verstehen, warum dies oder das jetzt schon 
wieder nicht funktioniert.
Auch die doch sehr beschränkten Möglichkeiten in Sachen Ein/Ausgabe 
hindern einen daran, richtig Freude am Programmieren zu kriegen.
Ich hatte damals ein Gtk+ -basiertes "Framework" geschrieben, welches 
die gleichen Ein/Ausgabe -Möglichkeiten wie Logo in C/C++ bietet (also 
der "Igel" und so) und sogar Makros geschrieben dass man alles mit 
deutschen Befehlen machen kann. Aber der Lehrer hat sich geweigert das 
auch nur anzusehen. Hab meine Programme trotzdem damit gemacht (waren 
natürlich viel schneller, einfacher und leistungsfähiger als 
Logo-Programme), wenigstens hat der Lehrer die nicht einfach mit 6 
bewertet...

Autor: Daniel -------- (root)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am besten eine statische und eine dynamische Sprache.
sauberes C und Python(oder Ruby)
Damit kann man im praktischen Leben 80% locker abdecken.

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Wenn man mich nach einer Programmiersprache für µC fragt, würde ich 
immer sagen, "C", auch wenn ich's nicht kann und mich mit ASM vergnüge. 
Alle anderen Programmiersprachen mögen auch Spaß machen, aber es geht in 
der Schule um Grundlagenwissen. Es fängt auch kein Erstklässler mit 
komplexen Gleichungen an, sondern lernt das kleine Einmaleins.
Um Programme schreiben zu können, Sollte (muß) ein wenig Verständnis der 
Hardware gegeben sein.
Ein Basic-Befehl "Print" hat wesentlich mehr Code, als diese 5 
Buchstaben vorgaukeln. Das ist bei Anwendungsprogrammen auf PC Basis 
irrelevant, weil Speicher ohne Ende. Was kümmert da ein Programm von 
einigen MByte oder gar GByte. Bei µC sieht's da doch ein wenig anders 
aus. Ist ja auch für völlig andere Aufgaben gedacht. Ein 8k 
Assemblerprogramm ist schon sehr komplex. Bei "C" hab ich allein schon 
wegen der Bedeutung von verschiedenen Zeichen, die Teilweise mühselig 
auf der Tastatur gesucht werden müssen doch sehr schnell das Interesse 
verloren, diese Sprache sprechen zu müssen. Das ich trotzdem "C" 
empfehle hat den Grund, das "C" sehr Hardwarenah programmiert werden 
kann und zusätzlich mathematische Funktionen durch eingebundene 
Bibliotheken erleichtert. Eine Realzahl-Multiplikation zu Fuß in 
Assembler ist dagegen eine echte Herausforderung. Andererseits wird für 
Steuerungstechnik soviel mathematische Funktionalität selten gefordert. 
Da ist m.E. Assembler für ein schnelles Verständnis der Vorgänge im 
Prozessor besser geeignet. Basic, Pascal oder andere Hochsprachen halte 
ich für Schulzwecke nicht geeignet. Wenn man Schüler für µC begeistern 
kann, lernen sie auch gern Assembler oder "C".
Gruß oldmax

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C ist keine schoene Anfaengersprache - zu viele Dinge, die man am Anfang 
einfach tun muss, ohne eine Chance zu haben, sie zu verstehen.

Assembler ist da wesentlich schoener und es beschaeftigt sich nur mit 
kleinen, leicht zu verstehenden Dingen. Problem ist da eher zu 
vermitteln, was so kleine, primitive Aktionen wie das Umherschieben von 
ein paar Werten mit der Computerwelt zu tun hat, die der Anwender kennt. 
Und es wird schnell langweilig, weil es doch sehr muehsam sein kann, 
etwas Interessantes zu erreichen.

Deswegen ist eine Sprache wie Basic toll fuer den Einstieg, vor Allem 
wenn auf einfache Art und Weise grafische Ausgabe moeglich ist. Dadurch 
hat der Einsteiger ein schnelles Erfolgserlebnis, vor Allem im 
Unterricht, wenn man sich z.B. an bereits bekannten mathematischen 
Aufgaben orientieren kann.

Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C. Zu dem 
Ganzen dazu gehoert auch das grundlegende Verstaendnis digitaler 
Schaltungen. Assembler mag einem nach Basic zuerst wie ein Rueckschritt 
erscheinen, aber waehrend man mit Basic grundlegend, aber noch recht 
abstrakt algorithmisches Denken kennenlernt, bringt einem Assembler die 
noetigen Grundlagen ueber die "reale Welt" eines Computerprogramms 
naeher. Dann muss man spaeter in C auch nicht solche Kapriolen machen, 
um Pointer zu erklaeren :-/

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> C ist keine schoene Anfaengersprache - zu viele Dinge, die man am Anfang
> einfach tun muss, ohne eine Chance zu haben, sie zu verstehen.

Richtig.

> Assembler [...] wird schnell langweilig, weil es doch sehr muehsam sein > kann, 
etwas Interessantes zu erreichen.

Das gilt insbesondere für Anfänger, die in ASM bei mehr als einem 
Hallo-Welt-Programm bereits von der Komplexität erschlagen werden. 
Assembler ist gut, um die Funktionsweise einer CPU zu verstehen - 
beschäftigen sollte man sich damit, wenn man schon etwas programmieren 
kann.

> Deswegen ist eine Sprache wie Basic toll fuer den Einstieg

Seh ich auch so. Ich gehe dabei davon aus, dass du kein C64-Basic 
meinst, sondern ein modernes mit lokalen Variablen, Block-IFs usw. à la 
Visual Basic. Hab auch selbst vor Urzeiten mit QuickBasic (semi-modern) 
angefangen, hat mir glaube ich nicht geschadet.

> Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C

Meine Lernreihenfolge war Basic -> C -> Assembler -> Pascal (nur passiv, 
um in Pascal geschriebene Beispiele aus einem Buch über 
Grafikprogrammierung nachzuvollziehen) -> etwas besser C -> C++ -> 
diverse Skriptsprachen.

Aktuell versuche ich meinen C++-Stil zu verbessern, finde aber kaum Zeit 
um was zu programmieren ;-)

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der mechatroniker schrieb:

> Seh ich auch so. Ich gehe dabei davon aus, dass du kein C64-Basic
> meinst, sondern ein modernes mit lokalen Variablen, Block-IFs usw. à la
> Visual Basic. Hab auch selbst vor Urzeiten mit QuickBasic (semi-modern)
> angefangen, hat mir glaube ich nicht geschadet.

Ich meine tatsaechlich sowas wie C64. Die Idee ist ueberhaupt nicht, 
damit komplexere Programme schreiben zu koennen. Sondern einfach der 
bequeme Einstieg in algorithmisches Denken. Keine Klassen, keine 
Objekte, nur Schleifen, wenige Funktionen, maximal 2-3 Seiten.

Schaden tun die von dir erwaehnten Features wahrscheinlich auch nicht - 
aber irgendwo muss der Reiz, eine richtige (TM) Sprache zu lernen, ja 
herkommen :-)

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit 
Tcl/Tk.

Durch den sehr einfachen Sprachaufbau ist man dort schnell drin und man 
hat mit Tk die Möglichkeit, sehr schnell grafische Ergebnisse zu 
erhalten (z.B. durch Malen auf einem canvas).

Assembler finde ich zumindest für die Grundlagen sinnvoll: die logischen 
Verknüpfungen, Verschieben, Aufbau eines Funktionsaufrufes (Stack, push, 
pop) lässt sich gerade an einem Mikrocontroller schön erklären und 
direkt nachvollziehen.

Viele Probleme, die z.B. in C auftauchen, entstehen, weil die Leute 
nicht wissen, was der Compiler dort auf Maschinenebene ausspuckt.

Und es macht sicher Spaß, wenn kleine Erfolgserlebnisse (LED-Laufband 
oder so.) direkt anzeigen, dass es funktioniert hat. Mit preiswerten 
Controllern lässt sich da sicherlich einiges machen, um Schüler zu 
begeistern.

Chris D.

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C: Viel zu schwierig für unbedarfte Schüler.
C++: Die schlimmst Hybridsprache die je gebaut wurde. Viel zu komplex 
und die Programme die rauskommen sind meistens Zwitter zwischen C und 
wirklich objektorientiert.
Pascal: ist tot
Basic: kann man machen muss man aber nicht (Microsoftzentriert)
LISP: es gibt immer noch unverbesserliche

Wenn dann nehmt was modernes: entweder JAVA oder C#. Man hann zu Beginn 
damit auch ohne großes Wissen über objektorientierte Programmierung 
arbeiten und durch die Benutzung von Objekten gewöhnt man sich den 
Umgang damit von vorneherein an.

Und wenns um Microcontrollerprogrammierung geht, debuggen muss man doch 
eh in Assembler und was der Controller wirklich tut versteht men eh nur 
wenn man weiss was was die Register und Ports so machen und wie die 
Zusammenhänge genau sind, also besser erst nur Assembler als auch noch C 
dazulernen. Für größere Projekte ist das natürlich etwas anderes.

Mein Senf, Udo :-)

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Udo R. S. schrieb:

> Wenn dann nehmt was modernes: entweder JAVA oder C#.

Java vereint hier die Nachteile von C und Basic - Sehr maechtig, 
vermittelt keine Grundlagen und erfordert die Einhaltung vieler 
"obskurer Rituale".

Erklaere mal einem Anfaenger, was eine NullPointerException ist...

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Wenn es um PC Programmierung geht, klar, Finger von Assembler. Da ist 
jede Hochsprache besser geeiget. Ich benutze auch Delphi ( Pascal) und 
mir würd heut nicht mehr einfallen, in Assembler zu schreiben, obwohl es 
der Compiler versteht und einbinden kann.
Wenn es aber um die Programmierung von µC's geht, da bleib ich dabei, 
ist BASIC oder PASCAL der falsche Weg. Bestenfalls "C" wegen der 
Hardwarenähe und weil's eben immer noch für viele die "richtige" 
Programmiersprache ist bis hin zu PC-Anwendungen. Schließlich gibt's da 
auch ein Visual C.
Assembler muß nicht langweilig sein. Nehmt ein greifbares Projekt, nicht 
zu groß, aber doch anspruchsvoll. Z. B. eine Datenerfassung mit 
Schnittstele zu einem PC. Dann machen beide Programmiersprachen, die für 
den µC und die für die Visualiserung am PC Sinn und Spaß. Oder die 
Steuerung einer ( alten) Eisenbahnanlage. Vielleicht ein Kreis, ein 
Ausweichgleis und evtl. ein paar Signale. Ist schnell aufgebaut und man 
kann in der Praxis arbeiten.
Gruß oldmax

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bin ich aber gespannt wie mit Java den uC programmiert ;-).

Java ist keineswegs eine schlechte Sprache, nur sehe ich immer wieder 
auf meiner Arbeit von FH Abgängern welche nur Java gelernt haben, wie 
weit weg sie von der Realität sind.

In dem Alter würde ich C nehmen, kein C++ und kein C#. Man sollte nicht 
zu viel ein bisschen können sondern besser eine Sprache verstehen. Für 
diejenigen die das Flair dafür haben ist der Schritt von Strukturiertem 
Programmieren nach Objekt Orientiertem Programmieren nicht so schlimm.

Auch unter dem Aspekt das die Lehrperson (noch ein Kompliment an den 
Lehrer, dass er sich soviele Gedanken macht und sich einsetzt) auch 
nicht die grossen Vorkenntnisse hat, macht C in meinen Augen wirklich 
Sinn.
Es steht der Hardware recht nah und ist nicht unnötig komplex.

Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.

IMHO

Grüsse,
R.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Assembler macht man nix, das muss man nur mal gemacht haben :^)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rene H. schrieb:
> Da bin ich aber gespannt wie mit Java den uC programmiert ;-).

NanoVM ;)

> Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.

C sollte man auf dem PC nur in absoluten Ausnahmefällen verwenden.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> C: Viel zu schwierig für unbedarfte Schüler.

Denken: Viel zu schwierig für unbedarfte Schüler.

ja  ja, clickibunti denkt für dich ....

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Denken: Viel zu schwierig für unbedarfte Schüler.

Über seltsame Idiome, Pointer, den Sinn der main(), kompliziertes 
Stringhandling nachzudenken, während man gerade versucht zu lernen, 
algorithmisch zu denken: natürlich.

Es gibt sogar Lehrer, die unterrichten die erste Mathestunde in 
deutscher Sprache statt in hebräischer. Ja, richtig, sowas, was die 
Schüler schon können. Ist das jetzt klickibunti?

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Bleibt doch mal auf dem Teppich und müllt hier nicht mit 
unqualifizierten Antworten das Forum zu. Einen Glaubenskrieg über 
verschiedene Sprachen kann ich ja gerade noch nachvollziehen, da die 
Meisten noch was damit anfangen können. Ich finde es gut, wenn ein 
Lehrer sich auch nach anderen Sprachen erkundigt und nicht einfach sagt 
"so spreche ich, also hört auf mich"
Gruß oldmax

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der mechatroniker schrieb:
>> Denken: Viel zu schwierig für unbedarfte Schüler.
>
> Über seltsame Idiome, Pointer, den Sinn der main(), kompliziertes
> Stringhandling nachzudenken, während man gerade versucht zu lernen,
> algorithmisch zu denken: natürlich.

Alles richtig.
Aber mit Ausnahme der Sonderstellung von main() kann man auch in C 
durchaus schon interssante Programme schreiben, in denen weder seltsame 
Idiome (was immer das auch sein mag) noch Pointer vorkommen. Irgendwann 
muss es natürlich sein, das ist schon klar. Aber man muss einen Neuling 
zumindest nicht gleich am Anfang damit überfallen damit er überhaupt 
irgendetwas programmieren kann.

Stringhandling ist zugegebenermassen in C ein schwieriges Thema, eignet 
sich allerdings gut um in die Pointerthematik einzuführen. Und bis dahin 
hat man mit Schleifen, Abfragen, Sequenz, einfachen Funktionen u.dgl. 
ein weites Betätigungsfeld in dem sich auch viele interessante 
Aufgabenstellungen finden lassen.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oldmax schrieb:
[...]
> Basic, Pascal oder andere Hochsprachen halte
> ich für Schulzwecke nicht geeignet.

Wieso denn nicht?

BTW: C gilt auch als Hochsprache, auch wenn manch einer es als 
fast-Assembler ansieht.

Verglichen mit Ocaml, Haskell oder Lisp oder auch Python
ist es zwar recht low-level, aber es ist dennoch eine sog.
Hochsprache.


Gruß,
  Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> In Assembler macht man nix, das muss man nur mal gemacht haben :^)

So ähnlich sehe ich das auch.
Gerade auf einem µC ist es nicht schlecht, wenn man die ersten 
Gehversuche in Assembler macht und so einen Blick ganz nah an die 
Hardware werfen kann. Die Scheu vor dem Datenblatt verfliegt dann ganz 
schnell.

Aber für eine ernsthafte Anwendung wäre mir das zu mühsam. Ein wenig 
Komfort möchte ich bei der Programmierung schon haben und da ist es mir 
dann auch egal, ob der Compiler ein paar Prozentpunkte an Speed 
verschenkt oder nicht.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
[...]
> Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C. Zu dem
> Ganzen dazu gehoert auch das grundlegende Verstaendnis digitaler
> Schaltungen. Assembler mag einem nach Basic zuerst wie ein Rueckschritt
> erscheinen, aber waehrend man mit Basic grundlegend, aber noch recht
> abstrakt algorithmisches Denken kennenlernt,

Dafür ist BASIC sicherlich nicht so gut geeignet, wie funktionale 
Sprachen, also z.B. Lisp oder OCaml.

Mein Favorit ist OCaml.
Aber ich habe nicht damit angefanmgen, sondern damals (1982 oder so)
mit BASIC.


> bringt einem Assembler die
> noetigen Grundlagen ueber die "reale Welt" eines Computerprogramms
> naeher. Dann muss man spaeter in C auch nicht solche Kapriolen machen,
> um Pointer zu erklaeren :-/

Wenn man mit Assembler anfängt, hat man direkt den bezug zur Maschine 
und den digitalen Schaltungen. Wozu also BASIC?

Konsequenter wäre demnach eher
Assembler ==> C ==> BASIC.
Man will aber BASIC nicht mehr wollen, denke ich, wenn man bereits C 
kann.

Daher eher:
Assembler ==> C ==> ( OCaml  Haskell  Python / LISP )

Gruß,
  Oliver

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
[...]
> Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C.
[...]


Hmhhh, jetzt komme ich ja ins Grübeln...
...denn das war auch meine Reihenfolge,
wobei Assembler damals Maschinencode/Assembler war
(so mit Hexcode in Dezimalwerte wandeln und mit Poke
 in den Speicher schreiben und mit SYS (?) den Maschinencode aufrufen)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der mechatroniker schrieb:
[...]
> Aktuell versuche ich meinen C++-Stil zu verbessern, finde aber kaum Zeit
> um was zu programmieren ;-)


Lerne doch lieber eine vernünftige Sprache... sowas wie OCaml :-)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit
> Tcl/Tk.

Buärks!

Hatte ich auch mal gelernt.

Das ist vollkommen uneffektive Syntax.

Ich hatte als erste Scriptsprache Tcl/Tk,
später Perl. Nach Perl war Tcl/Tk für mich durch, ausser, wenn es m al 
schnell um ein bischen GUI-Code ging.

Tcl/Tk wurde als Glue-Sprache entwickelt, um C-Teile zusammen zu bauen 
und schnell eine GUI dafür her zu zaubern.
Tcl wurde nicht dafür entwickelt, tolle programme darin zu schreiben.

Später kamen immerhin Namespaces und andere Schmankerl dazu, da hatte 
ich aber eeh keine Böcke mehr auf Tcl.

Ich fand Tcl's Syntax einfach viel zu uneffektiv.
Zu flach.


>
> Durch den sehr einfachen Sprachaufbau

Eben.

IMHO ist das ZU einfach!


[...]
> Viele Probleme, die z.B. in C auftauchen, entstehen, weil die Leute
> nicht wissen, was der Compiler dort auf Maschinenebene ausspuckt.

Vielleicht im Controller-Bereich, oder wenn man Kerne-Programmierung 
macht.
Ansonsten ist C ja gerade der Sprung weg von der Maschinennähe, auch 
wenn ein Rest Nähe zur Maschine geblieben ist, wenn man sich anschaut, 
daß man auf die Größe der von den Variablen belegten Speichermenge 
(short int  int  long int, float, double, alignment bei structs usw.) 
achten muss.

Für maschinennahe Programmierung ist dies aber auch notwendig.

Daher ist C ein sehr guter Kompromiss von Abstraktion und Maschinennähe.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Udo R. S. schrieb:
[...]
> Wenn dann nehmt was modernes: entweder JAVA oder C#.


C#: M$-zentriert
JAVA: ist einfach grottig.

Vor vielen jahren hatte ich von Java-Projhekten immer gehört, sie wären 
plattformübergreifend und die Sprache wäre so toll.
In der Praxis war der krams unperformant und nicht wirklich 
plattformübergreifend.
Es hakte und klemmte doch immer irgendwo.

Später hiuess es dann, Java sei viel perofrmanter und besser portabel 
geworden (besser portabel als ohnehin grundsätzlich portabel, wie geht 
das?). Bis jetzt habe ich aber noch keine Java-Applikation gesehen, die 
wirklich gut oder performant ist. Obendrein hat Java auch pointer.
Was hat das in einer "modernen" Sprache zu suchen?

JAVA ist uralt und wird nur permanent weiterentwickelt.

IMHO ist es immernoch Schrott.


> Man hann zu Beginn
> damit auch ohne großes Wissen über objektorientierte Programmierung
> arbeiten und durch die Benutzung von Objekten gewöhnt man sich den
> Umgang damit von vorneherein an.

"Alles ist ein Objekt" ist doch ziemlich dogmatisch.
Und: wird das wirklich konsequent umgesetzt?
AFAIK nicht.


>
> Und wenns um Microcontrollerprogrammierung geht, debuggen muss man doch
> eh in Assembler


Bei Java sicherlich ;-)



> und was der Controller wirklich tut versteht men eh nur
> wenn man weiss was was die Register und Ports so machen

Wenn man eine Hochsprache nimmt, will man sich zumindest um die Register 
nicht mehr kümmern müssen, sonst kann man gleich bei Assembler bleiben. 
:->

Wenn man selbst bei JAVA sich um registerinhalte kümmern muss,
dann ist das doch armselig.

Kann man bei JAVA-Programmen wenigstens auch Assembler einbinden?
Dann kann man wenigstens die performancekritischen Sachen orgendltich 
machen ;-)



> und wie die
> Zusammenhänge genau sind, also besser erst nur Assembler als auch noch C
> dazulernen. Für größere Projekte ist das natürlich etwas anderes.
>
> Mein Senf, Udo :-)

Hmhhh, der Senf war aber sehr mild. ;-)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Udo R. S. schrieb:
>
>> Wenn dann nehmt was modernes: entweder JAVA oder C#.
>
> Java vereint hier die Nachteile von C und Basic - Sehr maechtig,
> vermittelt keine Grundlagen und erfordert die Einhaltung vieler
> "obskurer Rituale".
>
> Erklaere mal einem Anfaenger, was eine NullPointerException ist...

Und erkläre mal einem Programmiersprachenkenner, wozu so ein Unfug 
notwendig ist!

Wer will sich denn mit NULL-Pointern rum schlagen, wenn er/sie abstrakt 
programmieren will?

In Python, OCaml usw. gibt es so einen Unsinn nicht.

Java ist wie C++ nur ein verwurschteltes C.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oldmax schrieb:
[...]
> Assembler muß nicht langweilig sein. Nehmt ein greifbares Projekt, nicht
> zu groß, aber doch anspruchsvoll. Z. B. eine Datenerfassung mit
> Schnittstele zu einem PC. Dann machen beide Programmiersprachen, die für
> den µC und die für die Visualiserung am PC Sinn und Spaß. Oder die
> Steuerung einer ( alten) Eisenbahnanlage. Vielleicht ein Kreis, ein
> Ausweichgleis und evtl. ein paar Signale. Ist schnell aufgebaut und man
> kann in der Praxis arbeiten.
[...]

Hilfreich ist es doch, wenn man auf beiden Systemen die gleiche Sprache 
benutzen kann.
daher ist C im Vorteil: das macht auf Mikrokontrollern Sinn, aber auch 
auf PCs.
Ich wollte, als ich mit AVR anfing, eigentlich erst mal nur Assembler 
machen, aber im Job ist Vorgabe, C, und Assembler soll Ausnahme bleiben 
(musste ich aber bei Startup-Code auch mal einsetzen).
Also ist beides für mich derzeit sinnvoll.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> In Assembler macht man nix, das muss man nur mal gemacht haben :^)

heheh, der war gut (auch wenn ich es bei Mikrokontrollern etwas anders 
sehe)

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, noch ein ernsthaftes Statement zu C

> Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.

Ist, wenn das Ziel lautet "Didaktisch sinnvolle Sprache für 
Programmierunterricht für absolute Anfänger" IMHO absolut kein 
Kriterium.

Zu Skriptsprachen: OCaml hatte ich noch nie in der Hand, muss ich mir 
mal anschauen, Tcl/Tk ebenso.

Was ich an Skriptsprachen bis jetzt in der Hand hatte:
- PHP: für größere Anwendungen (und Webanwendungen werden heutzutage 
manchmal etwas größer) zu skriptsprachig, für kleinere Ok. Für Anfänger 
aufgrund der Domäne "Web" und der damit einhergehenden zusätzlichen 
Komplexität (Client/Server, Frage der Datenspeicherung über 
Seitenaufrufe hinweg, sobald man mehr als eine Hallo-Welt-Anwendung 
machen möchte) schätze ich es als eher ungeeignet ein.

- Visual Basic: besser als sein Ruf, IMHO auch als Anfängersprache (Mal 
zwei Textboxen rein, Button, Ins Click-Event ne einfache Berechnung 
anhand der eingegebenen Sachen, was z.B. Anwendung einer Formel aus der 
Geometrie sein kann: solche Sachen lassen sich da gut üben.)

- SQL: sicher nicht gleich mit Datenbank anfangen.

Sonstige Gedanken zu versch. Sprachen:
- FUP: erleichtert den Einstieg IMHO dann, wenn man gewohnt ist, "in 
Hardware" zu denken, nicht aber, wenn man das algorithmische Denken 
überhaupt nicht beherrscht.

- Java: Ich hatte im 1. Semester viele im Java-Kurs, die Probleme hatten 
zu verstehen, warum man eine Klasse braucht und was main ist, und warum 
die "public static" ist. Wäre mir wahrscheinlich nicht anders gegangen, 
wenn ich vorher nicht C und C++ gekannt hätte.

Autor: Claudio H. (bastelfinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde den Schülern erst einmal etwas Theorie beibringen, auf jeden 
Fall Zustandsautomaten (oder je nach Reife der Schüler DFAs, NFAs, 
KellerAutomaten und Turing-Maschinen). Das können die später noch 
gebrauchen. Dann vielleicht UML (Aktivitätsdiagramme, Zustandsdiagramme) 
oder wenigstens Struktogramme.
Damit können die schon den kompletten Quadrokopter entwickeln, ohne 
Programmiersprache :-)
Wenn man diese Grundlagen verstanden hat, dann ist es egal, ob du C, 
ASM, C++ oder Java nimmst. Bei OO-Sprachen würde ich dann 
UML-Objektdiagramme und Klassendiagramme nehmen, zuerst die 
Objektdiagramme, dann ist es oft einfacher zu verstehen.
Irgendwann macht es bei den Schülern "Klick" im Kopf, und sie stecken 
ihren Lehrer bei den Aufgaben in die Tasche :-)

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Aber mit Ausnahme der Sonderstellung von main() kann man auch in C
> durchaus schon interssante Programme schreiben, in denen weder seltsame
> Idiome (was immer das auch sein mag) noch Pointer vorkommen.

Alleine die Klammerflut ist doch fuer einen Neuling reiner Augenkrebs. 
Erklaeren kannst du das am Anfang nicht und einem Lernwilligen die ganze 
Zeit sagen: "Das erklaere ich in ein paar Wochen, jetzt muss das einfach 
mal so gemacht werden" ist doch voellig frustrierend.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:
> Chris D. schrieb:
>> Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit
>> Tcl/Tk.
>
> Buärks!
>
> Hatte ich auch mal gelernt.
>
> Das ist vollkommen uneffektive Syntax.

Also, bisher habe ich damit alles erreicht, was ich erreichen wollte.
Du meinst sicher "ineffizient".

So habe ich auch mal gedacht. Mittlerweile empfinde ich Redundanz als 
äußerst angenehm, zumal sich das nicht weiter auf die Geschwindigkeit 
auswirkt.
Tcl-Programme kann man mit etwas Geschick selbsterklärend schreiben.

> Ich hatte als erste Scriptsprache Tcl/Tk,
> später Perl. Nach Perl war Tcl/Tk für mich durch, ausser, wenn es m al
> schnell um ein bischen GUI-Code ging.

Perl ist nicht schlecht, aber mich störte genau das: GUIs müssen 
irgendwie angebunden werden.

> Tcl/Tk wurde als Glue-Sprache entwickelt, um C-Teile zusammen zu bauen
> und schnell eine GUI dafür her zu zaubern.
> Tcl wurde nicht dafür entwickelt, tolle programme darin zu schreiben.

Und C sollte ursprünglich auch nicht auf Mikrocontrollern laufen...

Der ursprüngliche Zweck und die spätere Verwendung sind eben zwei Paar 
Schuhe :-)

> Später kamen immerhin Namespaces und andere Schmankerl dazu, da hatte
> ich aber eeh keine Böcke mehr auf Tcl.

Oha, dann hast Du viele schöne Sachen verpasst. Selbst Schuld ;-)
Man kann mittlerweile sehr schön OO programmieren - auch große Projekte.

> Ich fand Tcl's Syntax einfach viel zu uneffektiv.
> Zu flach.

Genau das liebe ich so :-)

>> Durch den sehr einfachen Sprachaufbau
>
> Eben.
>
> IMHO ist das ZU einfach!

So ist das halt - jeder hat seinen Geschmack :-)
Ich verwende Tcl mittlerweile sehr erfolgreich auch auf Mikrocontrollern 
- das funktioniert deswegen so gut, weil Tcl so schön einfach ist.

> Ansonsten ist C ja gerade der Sprung weg von der Maschinennähe, auch
> wenn ein Rest Nähe zur Maschine geblieben ist, wenn man sich anschaut,
> daß man auf die Größe der von den Variablen belegten Speichermenge
> (short int  int  long int, float, double, alignment bei structs usw.)
> achten muss.

Eben. Meiner Meinung nach sind in C eine Menge "Reste" übrig geblieben - 
die immer wieder für Ärger sorgen (Pointer, Speicherlöcher usw.)

> Für maschinennahe Programmierung ist dies aber auch notwendig.

Nicht unbedingt. Viele Dinge müssten nicht sein und sind wirklich 
Relikte aus der Steinzeit.

> Daher ist C ein sehr guter Kompromiss von Abstraktion und Maschinennähe.

Das war es sicherlich in den 70ern - heute ist das nur noch veraltet.

Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu 
fehleranfällig für größere Projekte. Da gibt es einfach Besseres.

Chris D.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:

> Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu
> fehleranfällig für größere Projekte. Da gibt es einfach Besseres.

Sowas kommt immer von Leuten, die in ihren Kuschelsprachen noch keine 
wirklich grossen Projekte gemacht haben. Fuer manche ist ja schon ein 
1000-Zeilen Mikrocontroller-Programm ein grosses Projekt - aber ich rede 
von richtigen Projekten, die mindestens einen ganzen Schrank im RZ 
brauchen. Da kannst du dann lange versuchen, das mit Tcl zu machen, 
statt mit den "veralteten" Sprachen C/C++/Java.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Karl heinz Buchegger schrieb:
>
>> Aber mit Ausnahme der Sonderstellung von main() kann man auch in C
>> durchaus schon interssante Programme schreiben, in denen weder seltsame
>> Idiome (was immer das auch sein mag) noch Pointer vorkommen.
>
> Alleine die Klammerflut ist doch fuer einen Neuling reiner Augenkrebs.
> Erklaeren kannst du das am Anfang nicht und einem Lernwilligen die ganze
> Zeit sagen: "Das erklaere ich in ein paar Wochen, jetzt muss das einfach
> mal so gemacht werden" ist doch voellig frustrierend.

Ach komm.
So schlimm ist die Klammerflut dich gar nicht.

In jeder Sprache muss man Syntax lernen, das bleibt nicht aus.
Ob ich mir jetzt merken muss, dass es

   if bedinung then
     anweisungen
   endif

heisst, oder

   if( bedingung )
   {
     anweisungen
   }

ist doch gehupft wie gehatscht. (Die Variante, dass die Klammer bei nur 
1 Anweisung entfallen kann, würde ich einem Anfänger zunächst gar nicht 
unterjubeln)

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Ach komm.
> So schlimm ist die Klammerflut dich gar nicht.

Frag mal Unbedarfte, wie das aussieht. Vor Allem geschweifte Klammern... 
oder guck mal, wie oft Anfaenger Klammerfehler machen. Ich habe da 2 
Semester Erfahrungen als Tutor gesammelt :-/

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Frag mal Unbedarfte, wie das aussieht. Vor Allem geschweifte Klammern...
> oder guck mal, wie oft Anfaenger Klammerfehler machen. Ich habe da 2
> Semester Erfahrungen als Tutor gesammelt :-/

Vor allem im Zusammenhang mit der kontextsensitiven C-Syntax und der 
Folge, dass kein Compiler bei typischen Tippfehlern Fehlermeldungen 
ausgeben kann, die einen Anfänger in die richtige Richtung schubsen 
(auch wenn gerade der gcc in den letzten Jahren recht intelligent 
geworden ist).

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fuer Anfaenger erst mal was schoenes mit dem real ausfuehrbare 
Struktogramme (also nicht UML) zusammenklicken kann, haette auch was. Am 
Besten noch in Kombination mit angeschlossener Hardware. Fuer die BeBox 
gab es mal sowas. So kann man einige regelungstechnische Aufgaben schoen 
implementieren, mit externen Sensoren und Lampen / Motoren. So Sachen 
wie Funktionen auf einem echten Plotter zeichnen waeren damit auch noch 
drin.

Autor: Niklas Gürtler (erlkoenig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer 
in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?
Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher, 
also einer langen Kette von Bytes. Möchte man dort hinein "abstrakte 
Datentypen" (Listen, Trees, etc.) speichern, kann man diese nicht 
hintereinander in den Speicher packen, sondern muss sie über diesen 
verteilen. Um seine Daten dann wiederzufinden, muss man sich merken, wo 
sie sind - mithilfe von Pointern. Das heißt, man kann gar nicht ohne 
Pointer programmieren. Mann kann Pointer lediglich hübsch verpacken, 
sodass der zugehörige Speicher automatisch freigegeben wird, wenn man 
den Speicher aller Pointer, die auf den Speicher zeigen, freigibt 
(Garbage collection, Reference counting). Das gibt es in C deswegen 
nicht, weil C als "flache" (oder "nicht-magische" ;) Sprache konzipiert 
ist - das Programm macht exakt das macht, was da steht, ohne versteckte 
Abläufe im Hintergrund. C++ als C-Weiterentwicklung ist ebenfalls so 
gedacht, ermöglicht aber, dass man sich selber solche versteckten Dinge 
programmiert (z.B. durch Programmierung einer Kapsel-Klasse für 
automatisch Referenzen zählende Pointer, wie z.B. im GTKmm geschehen).
Man kommt also auf keinen Fall um Pointer herum, man kann lediglich eine 
automatische Speicherbereinigung in den Pointer-Datentyp implementieren, 
und das ist in "flachen" Sprachen wie C umständlich (Glib z.B. 
implementiert eine Referenzzählung in C, ist aber Tipparbeit - dafür 
sieht man sofort, was passiert), in C++ gut machbar und in Java, Ruby, 
Python etc. vor-implementiert. Aber das ganze ist eher so eine Art 
verkürzte Syntax, aber kein echtes Sprach-Feature.
Folgerung: Prozessor mit flachem Speicher ohne Pointer geht nicht.
Gegenbeweise sind willkommen.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Chris D. schrieb:
>
>> Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu
>> fehleranfällig für größere Projekte. Da gibt es einfach Besseres.
>
> Sowas kommt immer von Leuten, die in ihren Kuschelsprachen noch keine
> wirklich grossen Projekte gemacht haben.

Komisch ist eher, dass die Leute hier immer genau wissen, was andere als 
Informatiker (und Projektleiter) schon so alles durchgezogen haben :-)
Das waren damals (1999) durchaus große Dinger mit etwa einem Dutzend 
Beteiligter und >300000 Zeilen Code.

Das geht durchaus - aber man muss dazu eben über den Tellerrad schauen, 
anstatt direkt "Wird nie was!" von sich zu geben.

> Fuer manche ist ja schon ein
> 1000-Zeilen Mikrocontroller-Programm ein grosses Projekt - aber ich rede
> von richtigen Projekten, die mindestens einen ganzen Schrank im RZ
> brauchen.

Ich allerdings auch.

> Da kannst du dann lange versuchen, das mit Tcl zu machen,

Das musste man gar nicht lange versuchen - das funktionierte relativ 
zügig ohne Probleme - aber dazu benötigt man Köpfe, die nicht gleich 
"Ähhhh, wie doof, das ist ja ne Skriptsprache." von sich geben.
Die fand man damals bevorzugt jenseits des Atlantiks.

> statt mit den "veralteten" Sprachen C/C++/Java.

Wer sprach bei Java und C++ von veraltet?

Ich meinte ausschließlich C.

Es ist ja nicht so, dass ich kein C verwende - manche wirklich 
zeitkritische Dinge (im Controllerbreich) müssen eben doch in C oder 
Assembler implementiert werden.

Für solche kleinen, überschaubaren Codestücke ist es durchaus ok.

Aber wirklich große Sachen will ich damit heute nicht mehr bauen.
Dafür ist mir die Syntax zu fehleranfällig.

Mittlerweile sind die Festplatten groß und die Rechner schnell genug, um 
mehr Redundanz zugunsten von Fehlerfreiheit zuzulassen.

Chris D.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:
> Peter Stegemann schrieb:
>> Udo R. S. schrieb:
>>
>>> Wenn dann nehmt was modernes: entweder JAVA oder C#.
>>
>> Java vereint hier die Nachteile von C und Basic - Sehr maechtig,
>> vermittelt keine Grundlagen und erfordert die Einhaltung vieler
>> "obskurer Rituale".
>>
>> Erklaere mal einem Anfaenger, was eine NullPointerException ist...
>
> Und erkläre mal einem Programmiersprachenkenner, wozu so ein Unfug
> notwendig ist!
>
> Wer will sich denn mit NULL-Pointern rum schlagen, wenn er/sie abstrakt
> programmieren will?
>
> In Python, OCaml usw. gibt es so einen Unsinn nicht.

In Python nennt sich das nur etwas anders: null reference und None statt 
null.
In OCaml oder F# gibt es das auch, z.B. wenn man C/C++DLLs einbindet und 
man nicht weiß, was Options/Option Types sind (und schon ist man bei 
Monaden...)

> Java ist wie C++ nur ein verwurschteltes C.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Peter Stegemann schrieb:

>> Da kannst du dann lange versuchen, das mit Tcl zu machen,
> Das musste man gar nicht lange versuchen - das funktionierte relativ
> zügig ohne Probleme - aber dazu benötigt man Köpfe, die nicht gleich
> "Ähhhh, wie doof, das ist ja ne Skriptsprache." von sich geben.
> Die fand man damals bevorzugt jenseits des Atlantiks.

Ich hatte da einen ganz tollen Tag, 2001. Da durfte ich teilhaben an der 
Unterhaltung zwischen dem Projektleiter und Skriptfreak eines 
"erfolgreichen" Projektes mit seinem "boesen Zwilling" aus einer anderen 
Firma, die alles in C gemacht hatten. Das war wie beim Skat, wo einer 
alle Stiche kriegt. Der Resourcenverbrauch und der Pflegebedarf der 
Tcl-Loesung war einfach nur peinlich im direkten Vergleich. Zu 
Erkenntnissen hat das natuerlich nicht gefuehrt.

Ich benutze selbst durchaus auch Skriptsachen, mal diese, mal jene - 
wenn der Anwendungsfall passt.

> Mittlerweile sind die Festplatten groß und die Rechner schnell genug, um
> mehr Redundanz zugunsten von Fehlerfreiheit zuzulassen.

Den Spruch hoere ich in dieser oder jener Form seit Jahren. Nur leider 
wachsen auch die Aufgaben und fressen die Leistung schlicht und einfach 
auf.

Btw, >300.000 Zeilen ist nicht beeindruckend.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber hat jemand einen sinnvollen Gegenvorschlag?
> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen"
> Speicher, also einer langen Kette von Bytes.

nicht alle. LISPMASCHINE hatte was anderes. und das ding hat einen 
riesigen vorteil "(" ist einfach viel sexier als "{" oder "[" ...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne alles gelesen zu haben:
Die mit Abstand schlimmsten Einsteigersprachen sind m.M.n. genau 
diejenigen, bei denen eine IDE versucht, mitzuhelfen. Etwa Basic oder 
Delphi.

Ich hab selbst mal Informatikunterricht gegeben, daher kann ich aus 
Erfahrungen erzählen: Die Gefahr war viel zu groß, dass irgendwer 
einfach aus Versehen z.B. mal eine Delphi-Unit umbenannt hat und die IDE 
damit verwirrt hat. Oder mal ein Stück Quelltext gelöscht, welches die 
IDE erzeugt hatte und so weiter.

Das schöne an C ist m.M.n. eigentlich, dass man mit einer leeren Datei 
anfängt, den Compiler in der Hand hat und effektiv nix kaputt machen 
kann. Dass man dann direkt an der Konsole klemmt, ist nur von Vorteil. 
Dann braucht man auch keine 'getchar(), damits Konsolenfenster auf 
bleibt' und solche Scherze.
Einfacher und direkter geht es eigentlich kaum.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer
> in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?
> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,
> also einer langen Kette von Bytes.

Wenn jemand "Pointer" an C kritisiert, dann meint er die fehlende 
Gültigkeitsprüfung bei Speicherzugriffen. Unter den heutzutage 
verwendeten Programmiersprachen ist dieses Problem bei C einzigartig, 
und nebenbei die Quelle für den Großteil aller Sicherheitslücken.

Peter Stegmann schrieb:
> aber ich rede
> von richtigen Projekten, die mindestens einen ganzen Schrank im RZ
> brauchen.

Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch 
mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.

> Da kannst du dann lange versuchen, das mit Tcl zu machen,
> statt mit den "veralteten" Sprachen C/C++/Java.

Das einzige was C und Java gemeinsam haben sind die geschweiften 
Klammern.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Ohne alles gelesen zu haben:
> Die mit Abstand schlimmsten Einsteigersprachen sind m.M.n. genau
> diejenigen, bei denen eine IDE versucht, mitzuhelfen. Etwa Basic oder
> Delphi.
>
> Ich hab selbst mal Informatikunterricht gegeben, daher kann ich aus
> Erfahrungen erzählen: Die Gefahr war viel zu groß, dass irgendwer
> einfach aus Versehen z.B. mal eine Delphi-Unit umbenannt hat und die IDE
> damit verwirrt hat. Oder mal ein Stück Quelltext gelöscht, welches die
> IDE erzeugt hatte und so weiter.

Man muss ja nicht gleich mit GUIs anfangen, reine Konsolenanwendungen 
reichen.
Oder man geht den anderen Weg und fängt z.B. mit squeak.org an (inkl. 
opencroquet.org / opencobalt.org).


>
> Das schöne an C ist m.M.n. eigentlich, dass man mit einer leeren Datei
> anfängt, den Compiler in der Hand hat und effektiv nix kaputt machen
> kann. Dass man dann direkt an der Konsole klemmt, ist nur von Vorteil.
> Dann braucht man auch keine 'getchar(), damits Konsolenfenster auf
> bleibt' und solche Scherze.
> Einfacher und direkter geht es eigentlich kaum.

Geht schon: Z.B. die REPLs von F#/OCaml, Haskell oder Ruby (z.B. im 
Browser http://tryruby.sophrinix.com/).
Vorteil: Kein Compiler, kein Warten, direkte Rückmeldung, keine char 
arrays, keine Rückfragen was denn char** argv ist...

Autor: Niklas Gürtler (erlkoenig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Niklas Gürtler schrieb:
>> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer
>> in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?
>> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,
>> also einer langen Kette von Bytes.
>
> Wenn jemand "Pointer" an C kritisiert, dann meint er die fehlende
> Gültigkeitsprüfung bei Speicherzugriffen. Unter den heutzutage
> verwendeten Programmiersprachen ist dieses Problem bei C einzigartig,
> und nebenbei die Quelle für den Großteil aller Sicherheitslücken.
Das resultiert entweder aus ungültigen Array-Zugriffen (die man durch 
vorherige if-Abfragen verhindern kann; andere Programmiersprachen 
automatisieren das, ist aber im Endeffekt das selbe => Nur verkürzte 
Syntax) oder aus ungültigen Pointern, welche man durch fehlende 
Speicherverwaltung bekommt, was man aber auch lösen kann - siehe oben. 
Ist aber eben Tipparbeit, und die "modernen" Sprachen haben in 
Wirklichkeit auch Pointer, nehmen einem also nur diese Tipparbeit ab - 
verkürzte Syntax. Dafür hat man in C aber die volle Kontrolle und sieht 
direkt, was abläuft.
zwieblum (Gast) schrieb:
> nicht alle. LISPMASCHINE hatte was anderes. und das ding hat einen
> riesigen vorteil "(" ist einfach viel sexier als "{" oder "[" ...
Habe ich was verpasst? Die Lispmaschine ist doch wohl ein (vermutlich in 
C geschriebener) Interpreter, der ebenfalls nur flachen Speicher 
verwaltet und Pointer verwendet.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es gab' mal vor äonen (ende 70er/anfang 80er) lispmaschinen. im prinzip 
war's eine in silizum gegossene lisp-umgebung. sogar "treiber" waren 
lisp :-) sun hat das ganze dann anfang 2000 mit java-coprozessoren in 
einer schmalspurvariante probiert.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh, ich vergaß: bild von einer LISP Maschine ist hier: 
http://de.wikipedia.org/wiki/LISP . und in LISP gibt's keinen 
unterschied zwischen daten und code, keine illegale zeigerarithmetik ... 
:-)

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich werde vergeslich: natürlich gibt es auch geniale LISP programme, 
etwa MAXIMA http://maxima.sourceforge.net/ ...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> Das resultiert entweder aus ungültigen Array-Zugriffen (die man durch
> vorherige if-Abfragen verhindern kann; andere Programmiersprachen
> automatisieren das, ist aber im Endeffekt das selbe => Nur verkürzte
> Syntax) oder aus ungültigen Pointern, welche man durch fehlende
> Speicherverwaltung bekommt, was man aber auch lösen kann - siehe oben.

Das Problem dass C kein sicheres Speicherhandling ermöglicht kann man 
nicht lösen, man kann es nur eindämmen indem man 
Sicherheitsüberprüfungen von Hand einbaut. Dazu muss man überhaupt erst 
mal alle Fehlerquellen kennen. Vermittle einem Anfänger mal warum man 
manche Funktionen der C-Library prinzipiell gar nicht sicher verwenden 
kann, oder dass ein Benutzer von einem Programm mit den Zeilen
string = einlesen();
printf(string);
mit etwas Glück an beliebige Adressen springen kann. Das wissen selbst 
viele erfahrene Programmierer nicht.

> Dafür hat man in C aber die volle Kontrolle und sieht
> direkt, was abläuft.

Spätestens wenn man den Coredump im Debugger aufmacht.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wann hast du den letzten coredump debugged?

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der mechatroniker schrieb:
> Ok, noch ein ernsthaftes Statement zu C
>
>> Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.
>
> Ist, wenn das Ziel lautet "Didaktisch sinnvolle Sprache für
> Programmierunterricht für absolute Anfänger" IMHO absolut kein
> Kriterium.

Klar: eine Sprache lernen und viel damit erreichen. :-)


>
> Zu Skriptsprachen: OCaml hatte ich noch nie in der Hand, muss ich mir
> mal anschauen, Tcl/Tk ebenso.

Ocaml ist keine Scriptsprache.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:

> Das Problem dass C kein sicheres Speicherhandling ermöglicht kann man
> nicht lösen, man kann es nur eindämmen indem man
> Sicherheitsüberprüfungen von Hand einbaut.

Das Problem bei X ist, dass es kein Y hat, deswegen muss man... solche 
Argumente kann man fuer jede Sprache beliebig erzeugen.

Jedes Werkzeug ist anfaellig fuer Fehlbedienung. Bei C ist das leichter 
moeglich, dafuer aber kann man in C auch Dinge machen, die mit anderen 
Sprachen nicht oder nur umstaendlich gehen. C steht bei mir nicht 
umsonst erst etwas weiter hinten in der Liste der Sprachen die ein 
Anfaenger lernen soll - aber es steht auf jeden Fall drauf. Ein 
C-Programm baut nicht von alleine Mist, sondern weil der Programmierer 
Mist gebaut hat. Sowas sind stets Struktur- und Organisationsprobleme 
und die hat er in jeder Sprache, wenn er sein Handwerk nicht lernt. 
Deswegen ist eine harte Schule zur rechten Zeit eine gute Schule - 
danach kann man es sich dann immer noch mit der persoenlichen 
Lieblingssprache kuschelig einrichten.

Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten 
auch die chaotischsten Programmierer ihre Fehler finden.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zwieblum schrieb:

> wann hast du den letzten coredump debugged?

Ist bei mir ein halbes Jahr her. Seither suche ich nur noch Fehler in 
Java, da wuenscht man sich oefters einen ordentlichen coredump.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Oliver B. schrieb:
>> Chris D. schrieb:
>>> Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit
>>> Tcl/Tk.
>>
>> Buärks!
>>
>> Hatte ich auch mal gelernt.
>>
>> Das ist vollkommen uneffektive Syntax.
>
> Also, bisher habe ich damit alles erreicht, was ich erreichen wollte.
> Du meinst sicher "ineffizient".


jau


>
> So habe ich auch mal gedacht. Mittlerweile empfinde ich Redundanz als
> äußerst angenehm, zumal sich das nicht weiter auf die Geschwindigkeit
> auswirkt.
> Tcl-Programme kann man mit etwas Geschick selbsterklärend schreiben.

Das kann man in allen Sprachen... und auch in allen Sprachen vergeigen.



>
>> Ich hatte als erste Scriptsprache Tcl/Tk,
>> später Perl. Nach Perl war Tcl/Tk für mich durch, ausser, wenn es m al
>> schnell um ein bischen GUI-Code ging.
>
> Perl ist nicht schlecht, aber mich störte genau das: GUIs müssen
> irgendwie angebunden werden.
[...]


Gibt auch Module für, muss man nicxht alles "anbinden".

Tcl/Tk => Perl/Tk




>
>> Tcl/Tk wurde als Glue-Sprache entwickelt, um C-Teile zusammen zu bauen
>> und schnell eine GUI dafür her zu zaubern.
>> Tcl wurde nicht dafür entwickelt, tolle programme darin zu schreiben.
>
> Und C sollte ursprünglich auch nicht auf Mikrocontrollern laufen...

Eben.
Deswegen war ich bisher immer skeptisch diesbezüglich.
Aber wenn das Vorgabe ist und man da mehr Speicher hat als dmalas auf 
C64, dann geht das schon ;-)





>
> Der ursprüngliche Zweck und die spätere Verwendung sind eben zwei Paar
> Schuhe :-)


Klar.


>
>> Später kamen immerhin Namespaces und andere Schmankerl dazu, da hatte
>> ich aber eeh keine Böcke mehr auf Tcl.
>
> Oha, dann hast Du viele schöne Sachen verpasst. Selbst Schuld ;-)

naja, ich kenne ja bessere Sprachen, also habbe ich nicht wirkolich viel 
verpasst. heheh :-)



> Man kann mittlerweile sehr schön OO programmieren - auch große Projekte.


Na und?


Trotzdem wird die Syntax ddurch nicht wesentlich besser geworden sein.



>
>> Ich fand Tcl's Syntax einfach viel zu uneffektiv.
>> Zu flach.
>
> Genau das liebe ich so :-)

Du schreibst lieber 200 Seiten Code, statt drei zeilen? ;-)



>
>>> Durch den sehr einfachen Sprachaufbau
>>
>> Eben.
>>
>> IMHO ist das ZU einfach!
>
> So ist das halt - jeder hat seinen Geschmack :-)

klar.


> Ich verwende Tcl mittlerweile sehr erfolgreich auch auf Mikrocontrollern
> - das funktioniert deswegen so gut, weil Tcl so schön einfach ist.

Auf controllern?
Aha, das war mir neu.

Daß das möglich ist, hänbgt aber nicht mit der verbose-ineffizienten 
Syntax zusammen.

Die  Ausdrucksstärke einer Sprache ist nicht direkt mit der Größe des 
dann resultierenden Maschinenprogramms gleichsetzbar.

Dein Argument greift nicht.







>
>> Ansonsten ist C ja gerade der Sprung weg von der Maschinennähe, auch
>> wenn ein Rest Nähe zur Maschine geblieben ist, wenn man sich anschaut,
>> daß man auf die Größe der von den Variablen belegten Speichermenge
>> (short int  int  long int, float, double, alignment bei structs usw.)
>> achten muss.
>
> Eben. Meiner Meinung nach sind in C eine Menge "Reste" übrig geblieben -
> die immer wieder für Ärger sorgen (Pointer, Speicherlöcher usw.)

Nein, nicht übrig geblieben., sondern  damit eingeführt worden.
Übrig geblieben ist es in java, das damit aufzeigt, daß es über C nicht 
weit hinaus geht. :-)




[...]
>> Daher ist C ein sehr guter Kompromiss von Abstraktion und Maschinennähe.
>
> Das war es sicherlich in den 70ern - heute ist das nur noch veraltet.

Daß Tcl auch auf Mikroco0ntrollern läuft, ist mir neu.
Aber dann kann man ja auch bei BASIC bleiben.


>
> Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu
> fehleranfällig für größere Projekte. Da gibt es einfach Besseres.

??

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer
> in C/C++.
[...]

Aus gutem Grund.


> Aber hat jemand einen sinnvollen Gegenvorschlag?

Ja.
Referenzen, wie in OCaml.
Damit kann man nicht gegen die Wand fahren.




> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,
> also einer langen Kette von Bytes.

"Alle mir bekannten Rechnerarchitekturen"...


eben.



> Möchte man dort hinein "abstrakte
> Datentypen" (Listen, Trees, etc.) speichern, kann man diese nicht
> hintereinander in den Speicher packen, sondern muss sie über diesen
> verteilen.

Schade, daß wir da nicht die rechnerarchitekturen anpassen...


> Um seine Daten dann wiederzufinden, muss man sich merken, wo
> sie sind - mithilfe von Pointern.

...wenn man bei den Konzepten ud Hardware'n bleibt...



> Das heißt, man kann /gar nicht ohne/
> Pointer programmieren.

Doch.
In Sprachen, wo es keine pointer gibt, kann man ohne Pointer 
programmieren.



>  Mann kann Pointer lediglich hübsch verpacken,
> sodass der zugehörige Speicher automatisch freigegeben wird, wenn man
> den Speicher aller Pointer, die auf den Speicher zeigen, freigibt
> (Garbage collection, Reference counting).

Deine Argumentation stimmt, wenn man eine Sprache ohne Pointern auf 
einer Sprache mit Pointern implementiert.

Ansonsten stimmt es nicht.



> Das gibt es in C deswegen
> nicht, weil C als "flache" (oder "nicht-magische" ;) Sprache konzipiert
> ist

historisch gesehen gibt es das nicht, weil es damals wohl nicht so viele 
andere Konzepte gab?!
Obwohl...hmhhh... LISP ist ja auch schon recht alt....



> - das Programm macht exakt das macht, was da steht, ohne versteckte
> Abläufe im Hintergrund.

Hahah, quatsch.

Das programm macht, was im Hintergrund als Maschinencode abläuft, und 
was genau das ist, hängt von der verwendeten C-Lib, dem Compiler usw. 
ab.




> C++ als C-Weiterentwicklung

Nein, es ist einje eigene Sprache... eher verwurstelung.
OO wurde nur so halbwegs umgesetzt.



[...]
> Man kommt also auf keinen Fall um Pointer herum,

doch.

Sprachen "oberhalb" von C haben ggf. keine Pointer.
Evtl. bauen sie auf C auf, dann brauchen sie Pointer indirekt.
Oder sie bauen direkt auf Assembler auf, ohne C-Umweg, dann können sie 
keine Pointer nutzen, denn Assembler hat keine Pointer, nur verschiedene 
Adressierungsarten. :-)


Damit ist eigentlich schon alles erzählt, was es dazu zu sagen gibt. :-)


[...]
> Folgerung: Prozessor mit flachem Speicher ohne Pointer geht nicht.
> Gegenbeweise sind willkommen.

s.o.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
[...]
> Es ist ja nicht so, dass ich kein C verwende - manche wirklich
> zeitkritische Dinge (im Controllerbreich) müssen eben doch in C oder
> Assembler implementiert werden.
>
> Für solche kleinen, überschaubaren Codestücke ist es durchaus ok.
>
> Aber wirklich große Sachen will ich damit heute nicht mehr bauen.
> Dafür ist mir die Syntax zu fehleranfällig.
>
> Mittlerweile sind die Festplatten groß und die Rechner schnell genug, um
> mehr Redundanz zugunsten von Fehlerfreiheit zuzulassen.
...

oh geil, festplatten im Mikrokontroller! :-)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Oliver B. schrieb:
>> Peter Stegemann schrieb:
>>> Udo R. S. schrieb:
>>>
>>>> Wenn dann nehmt was modernes: entweder JAVA oder C#.
>>>
>>> Java vereint hier die Nachteile von C und Basic - Sehr maechtig,
>>> vermittelt keine Grundlagen und erfordert die Einhaltung vieler
>>> "obskurer Rituale".
>>>
>>> Erklaere mal einem Anfaenger, was eine NullPointerException ist...
>>
>> Und erkläre mal einem Programmiersprachenkenner, wozu so ein Unfug
>> notwendig ist!
>>
>> Wer will sich denn mit NULL-Pointern rum schlagen, wenn er/sie abstrakt
>> programmieren will?
>>
>> In Python, OCaml usw. gibt es so einen Unsinn nicht.
>
> In Python nennt sich das nur etwas anders: null reference und None statt
> null.
[...]

Nein.

Dereferenziere einen NULL-Pointer in C, und wenn Deine C-Lib das nicht 
abfängt, knallst Du gegen die Wand.


> In OCaml oder F# gibt es das auch, z.B. wenn man C/C++DLLs einbindet und
> man nicht weiß, was Options/Option Types sind (und schon ist man bei
> Monaden...)

Das mit dem Einbinden von C ist dann nicht mehr OCaml, sondern mixed 
Code.
Also bist Du wieder bei C und den Pointern.

Das ist aber ein verglciuh der hinkt.,

Denn wenn man NUR C nimmt, kann man mit NULL-Pointern gegen die Wand 
fahren.

Nur mit OCaml's Referenzen kannst du nicht gegen die Wand fahren.
Und bei Python auch nicht.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zwieblum schrieb:
>> Aber hat jemand einen sinnvollen Gegenvorschlag?
>> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen"
>> Speicher, also einer langen Kette von Bytes.
>
> nicht alle. LISPMASCHINE hatte was anderes. und das ding hat einen
> riesigen vorteil "(" ist einfach viel sexier als "{" oder "[" ...

...da stand ja auch: "Alle mir bekannten"

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Ohne alles gelesen zu haben:
> Die mit Abstand schlimmsten Einsteigersprachen sind m.M.n. genau
> diejenigen, bei denen eine IDE versucht, mitzuhelfen. Etwa Basic oder
> Delphi.

Die IDE hat aber nicht direkt was mit der Sprache zu tun.

Es gibt auch C mit IDE und sicherlivch auch BASIC ohne...

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Niklas Gürtler schrieb:
[...]
> Peter Stegmann schrieb:
>> aber ich rede
>> von richtigen Projekten, die mindestens einen ganzen Schrank im RZ
>> brauchen.
>
> Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch
> mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.


Eben....


Da las ich letztens den Spruch: "Die dümmsten programmierer schreiben 
die längsten Programme" oder so ähnlich.



Und für die, die es nicht verstehen gibt es hier einen wunderbaren 
Artikel dazu:


http://www.developer.com/tech/article.php/988641/I...


Kann ich nur vollkommen unterstreichen!


Ciao,
   Oliver

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> Andreas Schwarz schrieb:
>> Niklas Gürtler schrieb:
>>> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer
>>> in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?
>>> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,
>>> also einer langen Kette von Bytes.
>>
>> Wenn jemand "Pointer" an C kritisiert, dann meint er die fehlende
>> Gültigkeitsprüfung bei Speicherzugriffen. Unter den heutzutage
>> verwendeten Programmiersprachen ist dieses Problem bei C einzigartig,
>> und nebenbei die Quelle für den Großteil aller Sicherheitslücken.
> Das resultiert entweder aus ungültigen Array-Zugriffen (die man durch
> vorherige if-Abfragen verhindern kann; andere Programmiersprachen
> automatisieren das,
> ist aber im Endeffekt das selbe => Nur verkürzte
> Syntax)
[...]


Diese Argumentation ist unsinnig, denn es ist eh ALLES das selbe: alles 
Assmebler/Maschinensprache.

Also sind alle Programmiersprachen nur Assembler.


Wenn Du auf der Ebene argumentierst, kannst Du nicht ernsthaft erwarten, 
daß wir das ernst nehmen.

Das ist eine Ausrede, mehr nicht.


> oder aus ungültigen Pointern, welche man durch fehlende
> Speicherverwaltung bekommt, was man aber auch lösen kann - siehe oben.
> Ist aber eben Tipparbeit, und die "modernen" Sprachen haben in
> Wirklichkeit auch Pointer,

... Pointer gibt es nur von C her.

Der Prozessor kennt das nicht, er kennt nur Adressierungsarten.

Pointer sind ein Konzept in C, und es gibt Sprachen, die kenne sowas 
nicht.
OCaml kennt referenzen, die sind so was ähnliches, adressieren aber aus 
Programmierersicht nicht auf eine konkrete Adresse im Speicher.
Und es gibt Sprachen, die kennen nicht mal referenzen.

Ja, und es ist alles das selbe: sind bloß Atome und Moleküle, also 
braucht man nicht mal Assembler, sondern nur Physik. ;-)

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:
> Andreas Schwarz schrieb:

>> Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch
>> mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.
> Eben....

Eben was? Es ging nie um die Frage, ob man mit wenigen Zeilen ein ganzes 
Rack beschaeftigen kann, sondern um die Behauptung, C sei zu 
fehleranfaellig fuer grosse Projekte und Tcl besser geeignet.

> Und für die, die es nicht verstehen gibt es hier einen wunderbaren
> Artikel dazu:
>
> http://www.developer.com/tech/article.php/988641/I...

Erstens ist das schon wieder ein anderes Thema, zweitens schiesst der 
Autor sich mit dem letzten Statement in den Fuss:

"Ability to solve customer problems quickly"

Das ist das Standardargument aller Pfuscher, denn es laesst 
Langfristigkeit voellig ausser Acht.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:

> Wenn Du auf der Ebene argumentierst, kannst Du nicht ernsthaft erwarten,
> daß wir das ernst nehmen.

Ist das der Pluralis Majestatis oder bist du jetzt zum Meinungsfuehrer 
fuer die C-Hasser gewaehlt worden?

> ... Pointer gibt es nur von C her.
>
> Der Prozessor kennt das nicht, er kennt nur Adressierungsarten.

Das ist totaler Quatsch, anders kann man es nicht sagen. Was glaubst du 
denn, wie in Assembler auf Speicher zugegriffen wird? Eine 
Speicheradresse in einem Register ist ein Pointer. An einer anderen 
Speicherstelle ist es ein Pointer.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Jedes Werkzeug ist anfaellig fuer Fehlbedienung. Bei C ist das leichter
> moeglich, dafuer aber kann man in C auch Dinge machen, die mit anderen
> Sprachen nicht oder nur umstaendlich gehen.

Welche? So ziemlich alles ist in C umständlicher als in anderen 
Sprachen.

> Ein C-Programm baut nicht von alleine Mist

Gegenbeispiel: gets. Baut per Definition Mist, immer und unvermeidlich.

> Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten
> auch die chaotischsten Programmierer ihre Fehler finden.

Damit findet man nur die Fehler die gerade auftreten, nicht die die noch 
im Code versteckt sind.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:

>> Möchte man dort hinein "abstrakte
>> Datentypen" (Listen, Trees, etc.) speichern, kann man diese nicht
>> hintereinander in den Speicher packen, sondern muss sie über diesen
>> verteilen.
> Schade, daß wir da nicht die rechnerarchitekturen anpassen...

Und wie sehe so eine Architektur aus?

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Peter Stegemann schrieb:
>> Jedes Werkzeug ist anfaellig fuer Fehlbedienung. Bei C ist das leichter
>> moeglich, dafuer aber kann man in C auch Dinge machen, die mit anderen
>> Sprachen nicht oder nur umstaendlich gehen.
> Welche? So ziemlich alles ist in C umständlicher als in anderen Sprachen.

Arbeite mal in Java mit strukturierten Memory-Buffern. Das endet 
unvermeidlich in wilden Offset- und Kopierorgien, wo in C einfach mit 
Pointern gearbeitet werden kann.

Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit 
Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen 
noch nicht.

>> Ein C-Programm baut nicht von alleine Mist
> Gegenbeispiel: gets. Baut per Definition Mist, immer und unvermeidlich.

Und die ruft ein C-Programm sporadisch und unvermeidlich auf, ja? Oder 
entscheidet das vieleicht doch eher der Programmierer? Kaputte 
Bibliotheksfunktionen sind ja nun auch kein Alleinstellungsmerkmal von 
C.

>> Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten
>> auch die chaotischsten Programmierer ihre Fehler finden.
> Damit findet man nur die Fehler die gerade auftreten, nicht die die noch
> im Code versteckt sind.

Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein 
echtes Problem.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Andreas Schwarz schrieb:
>> Welche? So ziemlich alles ist in C umständlicher als in anderen Sprachen.
>
> Arbeite mal in Java mit strukturierten Memory-Buffern. Das endet
> unvermeidlich in wilden Offset- und Kopierorgien, wo in C einfach mit
> Pointern gearbeitet werden kann.

Das geht in C genau so lange gut bis jemand das Programm von Little auf 
Big Endian portieren möchte oder umgekehrt.

> Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit
> Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen
> noch nicht.

Siehe Realtime Java.

>>> Ein C-Programm baut nicht von alleine Mist
>> Gegenbeispiel: gets. Baut per Definition Mist, immer und unvermeidlich.
>
> Und die ruft ein C-Programm sporadisch und unvermeidlich auf, ja? Oder
> entscheidet das vieleicht doch eher der Programmierer? Kaputte
> Bibliotheksfunktionen sind ja nun auch kein Alleinstellungsmerkmal von
> C.

Gemeingefährliche Bibliotheksfunktionen sind ein ziemliches 
Alleinstellungsmerkmal von C. gets ist nur ein Extrembeispiel.

>>> Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten
>>> auch die chaotischsten Programmierer ihre Fehler finden.
>> Damit findet man nur die Fehler die gerade auftreten, nicht die die noch
>> im Code versteckt sind.
>
> Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein
> echtes Problem.

Alle Pfade kann man in nichttrivialen Programmen unmöglich testen, 
bestenfalls alle Zweige; und selbst wenn, dann würde man damit nicht 
alle Fehler aufdecken können, weil das Auftreten auch von den Daten 
abhängig ist, nicht nur vom Pfad.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Siehe Realtime Java.
jaaaa .... wie immer hängt das an der definition von "realtime" ...

> Gemeingefährliche Bibliotheksfunktionen sind ein ziemliches
> Alleinstellungsmerkmal von C.
nun, der sinn von geladenen waffen ist, dass sie auch abgefeuert werden. 
wenn du natürlich vorziehst den elefanten mit erdnüssen zu bewerfen ...

wie wär's mal wenn die superwuppertollen programmierer vor dem code 
hinschludder - hey geil, ich schaff' locker 200 zeilen pro tag - es mal 
mit nachdenken versuchen würden?

"weg mit den bäumen, die töten golffahrer!"

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Oliver B. schrieb:
>> Andreas Schwarz schrieb:
>
>>> Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch
>>> mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.
>> Eben....
>
> Eben was? Es ging nie um die Frage, ob man mit wenigen Zeilen ein ganzes
> Rack beschaeftigen kann, sondern um die Behauptung, C sei zu
> fehleranfaellig fuer grosse Projekte und Tcl besser geeignet.
>
>> Und für die, die es nicht verstehen gibt es hier einen wunderbaren
>> Artikel dazu:
>>
>> 
http://www.developer.com/tech/article.php/988641/I...
>
> Erstens ist das schon wieder ein anderes Thema, zweitens schiesst der
> Autor sich mit dem letzten Statement in den Fuss:
>
> "Ability to solve customer problems quickly"
>
> Das ist das Standardargument aller Pfuscher,

Nein.


> denn es laesst
> Langfristigkeit voellig ausser Acht.

Nein.

Denn man kann (langfristig) nur dann kurzfristig Probleme lösen,
wenn man früh genug vorgebaut hat.

Ich habe den text mehrfach gelesen, und entweder ist der sehr 
vieldeutoig interpretierbar, oder Du hast ihn nicht verstanden.

Ich kann die Argumentation komplett nachvollziehen und habe immer Code 
auf langfristige benutzung hin geschrieben, nicth auf schnelles 
Pfuschen.

Gerade das schnelle Pfuschen (viel Code produzieren, statt drüber 
nachzudenken)  wird in dem Artikel ja kritisiert.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Peter Stegemann schrieb:
>> Andreas Schwarz schrieb:
>>> Welche? So ziemlich alles ist in C umständlicher als in anderen Sprachen.
>> Arbeite mal in Java mit strukturierten Memory-Buffern. Das endet
>> unvermeidlich in wilden Offset- und Kopierorgien, wo in C einfach mit
>> Pointern gearbeitet werden kann.
> Das geht in C genau so lange gut bis jemand das Programm von Little auf
> Big Endian portieren möchte oder umgekehrt.

Du wolltest ein Beispiel, du hast es bekommen. Meinst du ich produziere 
jetzt die ganze Nacht Beispiele, die du dann mit schnippischen 
Bemerkungen relativierst? Ich mache uebrigens die letzten 3 Wochen 
nichts Anderes als das oben erwaehnte - in C waer's schon lange fertig 
und idiotensicher.

Schau dir mal java.util.ByteBuffer an und erklaere dann hier nochmal, 
dass das in C nicht einfacher ist.

>> Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit
>> Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen
>> noch nicht.
> Siehe Realtime Java.

Du willst wirklich behaupten, das Problem sei damit weniger umstaendlich 
in Java geloest, als in C? Du hast das noch nicht wirklich in einem real 
existierenden, nichttrivialen Projekt eingesetzt, oder?

>> Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein
>> echtes Problem.
> Alle Pfade kann man in nichttrivialen Programmen unmöglich testen,
> bestenfalls alle Zweige; und selbst wenn, dann würde man damit nicht
> alle Fehler aufdecken können, weil das Auftreten auch von den Daten
> abhängig ist, nicht nur vom Pfad.

Eine Binsenweisheit, die nicht nur auf alle Fehlermoeglichkeiten 
zutrifft, sondern auch gerne als Ausrede dafuer benutzt wird, gleich gar 
nicht zu testen. Dann muss man sich ueber's Resultat aber auch nicht 
wundern. Mit ordentlichem Testing und Design kann man diese Luecke 
weitgehend schliessen und das muss man in jeder Sprache sowieso tun.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:

> Ich habe den text mehrfach gelesen, und entweder ist der sehr
> vieldeutoig interpretierbar, oder Du hast ihn nicht verstanden.

"This article examines some of the usual definitions for programmer 
productivity, shows why they are wrong, and then proposes an alternate 
definition that accurately captures what programming is really about."

"Ability to solve customer problems quickly -- This is the true 
definition of programmer productivity, and is what Ingrid accomplished 
in the example."

Bis zu diesem Punkt ist der Artikel eigentlich ganz gut - aber ab da ist 
er irrefuehrend. Dass die Faehigkeit, Probleme schnell zu loesen 
langfristig von der Qualitaet der existierenden Basis abhaengt, steht 
da schlicht und einfach nicht.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Oliver B. schrieb:
>
>> Wenn Du auf der Ebene argumentierst, kannst Du nicht ernsthaft erwarten,
>> daß wir das ernst nehmen.
>
> Ist das der Pluralis Majestatis oder bist du jetzt zum Meinungsfuehrer
> fuer die C-Hasser gewaehlt worden?

Wieso?

C ist doch ganz nett. :-)



>
>> ... Pointer gibt es nur von C her.
>>
>> Der Prozessor kennt das nicht, er kennt nur Adressierungsarten.
>
> Das ist totaler Quatsch, anders kann man es nicht sagen.

Soso...


> Was glaubst du
> denn, wie in Assembler auf Speicher zugegriffen wird? Eine
> Speicheradresse in einem Register ist ein Pointer.

Pointer ist eine Abstraktion der Speicherzugriffe der jeweiligen 
Maschine und ihrer Hardware.




> An einer anderen
> Speicherstelle ist es ein Pointer.

Wenn Pointer das selbe sind, wie Adressierungsarten,
dann müssten Pointer ja diverse Adressierungsarten
als diverse Pointer-Arten anbieten.
Das ist aber nicht der Fall.

Wie das in der Maschine (evtl. eine komplett andere Architektur)
umgesetzt wird, ist ja eben nicht 1:1  C -> ASM.

Wäre die Abbildung so primitiv, könnte man ja gleich wiederum Assembler 
nehmen.

Die diversen Adressierungsarten muss man sogar mit teils recht 
umfangreichen C-Konstrukten nachbilden. (Oder anders rum müssen simple 
Pointer-Operationen je nach Hardware recht unterschiedlich /aufwendiger 
gelöst werden.)


Und wenn Pointer 1:1 auf Adressierungsarten umzusetzen wären, dann 
müsste C entweder für unterschiedliche Prozessoren unterschiedliche 
C-Dialekte anbieten, oder wäre ggf. unvollständig.

Was der Compiler macht, ist das Umsetzen von C-Pointern auf die
Maschinenbefehle der jeweiligen Hardware-Architektur.


Das Problem, was man bei C in dem Falle noch nicht gelöst hat (in 
späteren Sprachen sehr wohl), ist, daß man bei falschen/fehlerhaften 
Adressen mit dem Programm in undefinierte Betriebszustände kommt.


Eine Referenz in OCaml funktioniert ähnlich wie ein Pointer in C, ist 
aber nicht dasselbe, sondern ein abstrakteres Gebilde. Zu sagen, eine 
Ocaml-Referenz ist ein Pointer ist genauso quatsch, wie zu sagen, ein 
C-Pointer ist eine Adressierungsart im Prozessor. Man hat nicht umsonst 
verschiedene Namen für die Sachen, denn es sind unterschiedliche Sachen.
Sie haben teils ähnliche Eigenschaften, teils andere Eigenschaften.


Ansonsten könnte man auch den Unterschied zwischen den verschiedenen 
Sprachen komplett aufheben und sagen: ist alles Maschienncode und alles 
Turing-complete, also alles gleich.
Das trifft dann auf die Berechenbarkeit zu, aber nicht auf die Art und 
Weise, wie es benutzt/Programmiert wird.


Man könnte auch sagen: OO: ist alles eh bloß C und Pointer, denn auch 
die Klassen benutzen ja Adressierungsarten und Pointer-Arithmetik.
Daher ist auch OO und nicht-OO das selbe.

Java == C == LISP == TRUE, weil alles mit Pointern arbeitet...


Stimmt.
UND
Stimmt nicht.


Stimmt && Stimmt_nicht == TRUE


Kommt auf die Perspektive drauf an.

Vielleicht reden wir aneinander vorbei.

Autor: Interessierter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Pointer ist eine Abstraktion der Speicherzugriffe der jeweiligen
> Maschine und ihrer Hardware.

Mein Gott seid ihr heutzutage "verbildet". Ihr streitet euch bei den 
simpelsten Begriffen um des Kaisers Bart und schwallt ellenlos lange 
Beiträge mit kaum mehr Inhalt.

Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt. Das 
ist alles, mehr braucht man dazu nicht zu sagen.

Ihr müsst mal wieder lernen einfache Dinge auch einfach erklären zu 
können und nicht wie Politiker die sich vor dem eigenen Rücktritt 
sträuben daherzuschwätzen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:
>>> In Python, OCaml usw. gibt es so einen Unsinn nicht.
>>
>> In Python nennt sich das nur etwas anders: null reference und None statt
>> null.
> [...]
>
> Nein.
> Dereferenziere einen NULL-Pointer in C, und wenn Deine C-Lib das nicht
> abfängt, knallst Du gegen die Wand.

Knallt man bei Python auch, wenn man auf None nicht vorbereitet ist. 
Allerdings hat man im Gegensatz zu C noch einen Airbag und die 
Geschwindigkeit ist geringer.
class Test(object):
   def Foo(self):
   ...
v = Test()
v.Foo()
v = None
v.Foo() # AttributeError

> Nur mit OCaml's Referenzen kannst du nicht gegen die Wand fahren.
> Und bei Python auch nicht.

Python siehe oben.
OCaml/F#: Option Types
let bar (a : int option) = 
    Option.get a

bar None (* Exception *)
Geht somit auch mit OCaml oder F#. Man knallt immer noch vor die Wand, 
wenn man nichts dagegen tut, hat aber zusätzlich zum Airbag noch ABS und 
einen Bremsassistenten (auch wenn normalerweise garantiert ist, dass es 
keine Nullreferenzen gibt).

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:

> Vielleicht reden wir aneinander vorbei.

Du schwafelst. Voellig sinnlos, darauf einzugehen.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Andreas Schwarz schrieb:
>> Das geht in C genau so lange gut bis jemand das Programm von Little auf
>> Big Endian portieren möchte oder umgekehrt.
>
> Du wolltest ein Beispiel, du hast es bekommen. Meinst du ich produziere
> jetzt die ganze Nacht Beispiele, die du dann mit schnippischen
> Bemerkungen relativierst?

Das war keine schnippische Bemerkung, sondern ein Hinweis darauf dass 
das was in C so einfach aussieht bei genauerem Hinsehen oft ziemlich 
fragil ist. Die Doppelbenutzung von Zeigern führt garantiert zu 
Problemen bei der Portierung auf Architekturen mit anderer Endianess, 
wenn man nicht genau auf dieses Problem achtet. Und dann ist der Vorteil 
schon fast dahin.

>>> Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit
>>> Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen
>>> noch nicht.
>> Siehe Realtime Java.
>
> Du willst wirklich behaupten, das Problem sei damit weniger umstaendlich
> in Java geloest, als in C? Du hast das noch nicht wirklich in einem real
> existierenden, nichttrivialen Projekt eingesetzt, oder?

Ich glaube überhaupt nichts, ich wollte nur widerlegen dass man mit 
anderen Sprachen als C keine Echtzeit realisieren könnte.

>>> Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein
>>> echtes Problem.
>> Alle Pfade kann man in nichttrivialen Programmen unmöglich testen,
>> bestenfalls alle Zweige; und selbst wenn, dann würde man damit nicht
>> alle Fehler aufdecken können, weil das Auftreten auch von den Daten
>> abhängig ist, nicht nur vom Pfad.
>
> Eine Binsenweisheit, die nicht nur auf alle Fehlermoeglichkeiten
> zutrifft, sondern auch gerne als Ausrede dafuer benutzt wird, gleich gar
> nicht zu testen.

Wieso darfst du eigentlich Argumente bringen, und wenn ich dann 
Gegenargumente bringe sind das "schnippische Bemerkungen" oder 
"Binsenweisheiten"? :)

Das mit dem Testen ist wieder ein anderes Thema. Der Punkt ist, eine 
Sprache mit Bereichsüberprüfungen kann eine ganze Klasse von Fehlern 
komplett ausschließen, die du durch Testen nicht weitgehend 
ausschließen kannst. Dass ist keine Binsenweisheit oder Theorie, sondern 
hat ganz praktische Auswirkungen: ein Großteil der Sicherheitsupdates 
die du installieren darfst, egal für Windows, Linux, Firefox oder 
sonstwas, sind für C-spezifische Fehler, die mit einer Sprache mit 
Bereichsprüfungen nicht hätten auftreten können. Ich hab mal nach 
"firefox security holes" gegoogelt und die erstbeste rausgesucht:

http://www.mozilla.org/security/announce/2009/mfsa...
"Heap buffer overflow in string to number conversion"
Böse ausgedrückt: 35 Jahre nach der Erfindung von C ist die Komplexität 
einer String-zu-Zahl-Konvertierung damit noch nicht beherrschbar.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeiger in C sind keine Adressen und sind es auch nie gewesen. Zeiger 
sind Zeiger. Punkt.

Wenn man Zeiger nicht missbraucht, kriegt man keine Probleme mit 
Endianess. Ebenso, wenn man Bitvektoren nicht missbraucht. Ein Cast 
eines uint16_t auf einen uint8_t ist eben nicht der korrekte Weg, um an 
die unteren/oberen (arithmetischen) 8 Bits zu kommen...

Delphi ohne IDE würd ich dann auch gern mal sehen -- einfacher wirds 
dann sicherlich nicht.

Man kann sich überdies in jeder Sprache ins Knie schießen. In jeder 
zeitgemäßen Bibliothektsreferenz steht neben 'gets()' ein dickes 
Ausrufezeichen und erläutert, warum gets() gefährlich sein kann -- wo 
ist also das Problem? Dass man mal wieder lesen muss?
Auch in C++ oder PHP kann man Mist mit Referenzen machen, nur da sieht 
man meistens nicht mehr genau, wo denn das referenzierte Objekt 
irgendwie mal verloren gegangen ist oder so. Dagegen ist doch recht 
schnell zu klären, wo ein Zeiger verbogen wurde, würde ich doch meinen.

Führt es denn zu sichererem/'besserem' Quelltext, wenn man immer mehr 
implizit macht? Objekte löscht man z.B. nicht mehr, sondern verlässt 
sich darauf, dass die irgendwann mal eingesammelt werden?

Autor: Niklas Gürtler (erlkoenig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Memo an Hirn: Niemals Diskussionen über Pointer starten) Lassen kann 
ich's aber trotzdem nicht:
Die Lisp-Maschine braucht keine Pointer und hat keinen "linearen 
Speicher"? Heißt das, wenn ich z.B. eine Liste implementieren will 
speichere ich alle Elemente direkt hintereinander ab (wie ein Array), 
und wenn ich zwischen Element 34 und Element 35 ein Element einfügen 
will, kann ich das einfach im Speicher dazwischenschieben? Wie 
funktioniert das? Klingt auf jeden Fall interessant.
C ist halt so konzipiert, dass es die Abläufe in der CPU möglichst genau 
abbildet, aber kürzer als Assembler ist (den Beinamen "Super-Assembler" 
trägt C nicht zu Unrecht), und deswegen hat C zwangsweise Pointer, weil 
es auf Hardwareebene eben nicht anders geht. Automatische 
Gültigkeitsprüfung und/oder Referenzzählung hat C nicht, weil die CPU es 
auch nicht hat. Dieser niedrige Grad an Abstraktion ist gefährlich, wenn 
man ihn nicht anzuwenden weiß, aber man kann gut optimieren. Firefox mag 
zwar eine Menge Sicherheitslücken wegen C haben, aber ich will gar nicht 
wissen, wie langsam Firefox wäre, wenn er in Ruby oder Java geschrieben 
wäre.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:

> Das war keine schnippische Bemerkung, sondern ein Hinweis darauf dass
> das was in C so einfach aussieht bei genauerem Hinsehen oft ziemlich
> fragil ist. Die Doppelbenutzung von Zeigern führt garantiert zu

Was fuer eine Doppelbenutzung?

> Problemen bei der Portierung auf Architekturen mit anderer Endianess,
> wenn man nicht genau auf dieses Problem achtet. Und dann ist der Vorteil
> schon fast dahin.

Ich kann dir nur empfehlen, versuche es wirklich mal in Java. Es muss 
eine ganze Menge passieren, dass der Vorteil von C in diesem Aspekt 
dahin ist.

>> Du willst wirklich behaupten, das Problem sei damit weniger umstaendlich
>> in Java geloest, als in C? Du hast das noch nicht wirklich in einem real
>> existierenden, nichttrivialen Projekt eingesetzt, oder?
> Ich glaube überhaupt nichts, ich wollte nur widerlegen dass man mit
> anderen Sprachen als C keine Echtzeit realisieren könnte.

Niemand hat behauptet, dass es nicht realisierbar waere. Schau es dir 
an, es ist wesentlich umstaendlicher als in C - q.e.d.

> Wieso darfst du eigentlich Argumente bringen, und wenn ich dann
> Gegenargumente bringe sind das "schnippische Bemerkungen" oder
> "Binsenweisheiten"? :)

Ich kann nichts dafuer, dass du dir einen unhaltbaren Standpunkt 
ausgesucht hast.

> Das mit dem Testen ist wieder ein anderes Thema. Der Punkt ist, eine
> Sprache mit Bereichsüberprüfungen kann eine ganze Klasse von Fehlern
> komplett ausschließen, die du durch Testen nicht weitgehend
> ausschließen kannst.

Der Unterschied ist, dass die Sprache mit Ueberpruefung eine Exception 
wirft, die man handeln kann oder auch nicht. Die ohne Ueberpruefung 
laeuft womoeglich weiter und macht Unsinn. Letzteres ist natuerlich 
schlimmer, aber bei keiner der beiden Sprachen wird ein Fehler 
ausgeschlossen.

> Dass ist keine Binsenweisheit oder Theorie, sondern
> hat ganz praktische Auswirkungen: ein Großteil der Sicherheitsupdates
> die du installieren darfst, egal für Windows, Linux, Firefox oder
> sonstwas, sind für C-spezifische Fehler, die mit einer Sprache mit
> Bereichsprüfungen nicht hätten auftreten können.

Es sind Fehler, die einfach zu finden sind, wenn man will. Natuerlich 
ist die Wurzel des Problems in der Sprache zu finden - aber es ist nicht 
das grosse tragische Problem, als das es gerne dargestellt wird, da es 
einfache Mittel dagegen gibt. Der Entwickler muss nur seinen Arsch 
hochkriegen und Purify & Co laufen lassen. Dass das viele nicht tun, ist 
das eigentliche Problem. Es ist ein Mythos, dass schlampige Entwickler 
mit der richtigen Sprache ploetzlich Qualitaetssoftware abliefern.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Andreas Schwarz schrieb:
>
>> Das war keine schnippische Bemerkung, sondern ein Hinweis darauf dass
>> das was in C so einfach aussieht bei genauerem Hinsehen oft ziemlich
>> fragil ist. Die Doppelbenutzung von Zeigern führt garantiert zu
>
> Was fuer eine Doppelbenutzung?

Als Zeiger auf eine Struktur, und als Zeiger auf ein Byte-Array, um 
strukturierte Daten bequem abspeichern/zerpfücken zu können. Meintest du 
das nicht?

> Niemand hat behauptet, dass es nicht realisierbar waere. Schau es dir
> an, es ist wesentlich umstaendlicher als in C - q.e.d.

Gerade meintest du noch nicht dass es kein echtzeitfähiges Java gibt, 
und jetzt weißt du dass es wesentlich umständlicher ist? Übrigens habe 
nicht ich Java ins Spiel gebracht.

> Der Unterschied ist, dass die Sprache mit Ueberpruefung eine Exception
> wirft, die man handeln kann oder auch nicht. Die ohne Ueberpruefung
> laeuft womoeglich weiter und macht Unsinn. Letzteres ist natuerlich
> schlimmer, aber bei keiner der beiden Sprachen wird ein Fehler
> ausgeschlossen.

Der Fehler dass durch unerlaubt Speicherzugriffe der komplette Prozess 
kompromittiert werden kann wird durch eine Sprache mit 
Zugriffsüberprüfungen ausgeschlossen.

> Es sind Fehler, die einfach zu finden sind, wenn man will. Natuerlich
> ist die Wurzel des Problems in der Sprache zu finden - aber es ist nicht
> das grosse tragische Problem, als das es gerne dargestellt wird, da es
> einfache Mittel dagegen gibt. Der Entwickler muss nur seinen Arsch
> hochkriegen und Purify & Co laufen lassen. Dass das viele nicht tun, ist
> das eigentliche Problem.

Tools wie Purify oder Valgrind werden sowieso praktisch in allen großen 
Projekten eingesetzt bei denen irgend etwas sicherheitsrelevant ist; das 
was man von außen zu sehen bekommt sind die Bugs die danach noch übrig 
bleiben.

> Es ist ein Mythos, dass schlampige Entwickler
> mit der richtigen Sprache ploetzlich Qualitaetssoftware abliefern.

Es geht nicht darum dass schlampige Programmierer Qualitätssoftware 
abliefern können, sondern das durchschnittliche Programmierer Software 
abliefern können die nicht kommentarlos abstürzt oder Sicherheitslöcher 
aufreißt nur weil irgendwo ein +1 bei einer Indizierung vergessen wurde.

Autor: Interessierter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. (haku) wrote:

> Zeiger
> sind Zeiger. Punkt.

Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik 
eines Zigarre rauchenden Altkanzlers.

Andreas Schwarz (andreas) (Admin) wrote:

> Der Fehler dass durch unerlaubt Speicherzugriffe der komplette Prozess
> kompromittiert werden kann wird durch eine Sprache mit
> Zugriffsüberprüfungen ausgeschlossen.

Spräche das nicht eigentlich dafür nur noch eine Laufzeitumgebung wie 
.NET einzusetzen?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Laufzeitumgebung wie .NET muss es dafür nicht unbedingt sein, eine 
statisch kompilierte Sprache die alle Zugriffe auf Gültigkeit prüft 
(z.B. D) würde es auch tun. Aber .NET ist sicherlich aufgrund der 
Verbreitung die beste Wahl unter Windows.

Autor: Interessierter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz (andreas) (Admin) wrote:

> Eine Laufzeitumgebung wie .NET muss es dafür nicht unbedingt sein, eine
> statisch kompilierte Sprache die alle Zugriffe auf Gültigkeit prüft
> (z.B. D) würde es auch tun. Aber .NET ist sicherlich aufgrund der
> Verbreitung die beste Wahl unter Windows.

"statisch kompilierte Sprache" was genau meinst du damit? Beispiele 
bekannter Sprachen?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt D, oder auch Ada oder Delphi. Für Gültigkeitsüberprüfungen 
braucht man nicht unbedingt etwas wie .NET.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessierter schrieb:
> Sven P. (haku) wrote:
>
>> Zeiger
>> sind Zeiger. Punkt.
>
> Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik
> eines Zigarre rauchenden Altkanzlers.
Das sollte keine Erklärung sein. Ich wollte und will damit lediglich 
unterstreichen, dass ein Zeiger keine Adresse und vorallem keine 'Zahl' 
ist, auch wenn z.B. im Windows-Kern früher furchtbar gerne 
Zeivervariablen mit Zahlen beschrieben wurden.
So von wegen:
int *l;
l = 5;
Krieg ich die Krise bei.

C an sich ist doch schon ziemlich typensicher. Klar, wenn man C mit 
wildem Herumgecaste dazu zwingt, baut es auch Mist. Aber das macht 
Delphi/Pascal dann auch.

Autor: Interessierter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz (andreas) (Admin) wrote:

> Wie gesagt D, oder auch Ada oder Delphi. Für Gültigkeitsüberprüfungen
> braucht man nicht unbedingt etwas wie .NET.

Jetzt mal ehrlich, wieviel Prozent der weltweit entwickelten Software 
wird in diesen drei von dir aufgezählten Sprachen erstellt? Wobei Delphi 
ja mal einen hohen bekanntheits bzw. beliebtheitsgrad hatte. Gab sehr 
gute Artikel in der c't. Glaubst du wirklich "D" würde C verdrängen? Und 
wie lange wird "D" bestannt haben bis "E", "F", "G" .. es abgelöst haben 
wird? Das sind irgendwo alles interessante neue Sprachkonstrukte aber 
bevor die sich richtig durchgesetzt haben sind sie doch schon wieder weg 
vom Fenster. Selbst das gute alte Pascal dürfte als einführende 
Programmiersprache an Hochschulen noch einen höheren Stellenwert haben 
als "Exoten" wie Ada.

http://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessierter schrieb:
> Glaubst du wirklich "D" würde C verdrängen?

Nein, ich habe das auch nirgendwo angedeutet. .NET und JVM sind wegen 
der hohen Verbreitung unter Windows das sinnvollste. Dabei ist man auch 
nicht auf Java oder C# festgelegt, sondern hat freie Wahl zwischen C#, 
VB, Java, Python, Ruby und vielen anderen Sprachen die auf diesen 
Plattformen laufen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> Firefox mag
> zwar eine Menge Sicherheitslücken wegen C haben, aber ich will gar nicht
> wissen, wie langsam Firefox wäre, wenn er in Ruby oder Java geschrieben
> wäre.

Sieh dir Opera Mini oder Lobo (http://lobobrowser.org/java-browser.jsp) 
an...

Andreas Schwarz schrieb:
> Tools wie Purify oder Valgrind werden sowieso praktisch in allen großen
> Projekten eingesetzt bei denen irgend etwas sicherheitsrelevant ist; das
> was man von außen zu sehen bekommt sind die Bugs die danach noch übrig
> bleiben.

Zum einen das, zum anderen sind diese Tools nur so gut, wie die Tests 
die dann mit der Software gemacht werden (und auch erstmal geschrieben 
werden müssen). Letztlich beweisen die Tools nur das unter diesen 
Bedingungen keine Fehler mehr auftreten, nicht die generelle Abwesenheit 
von Fehlern.

Peter Stegemann schrieb:
> Niemand hat behauptet, dass es nicht realisierbar waere. Schau es dir
> an, es ist wesentlich umstaendlicher als in C - q.e.d.

Nein, z.B. Java-Bytecode direkt in einem Controller (inkl. RTOS und 
Treibern von Ajile http://www.ajile.com/)
oder bei Erlang
http://lambda-the-ultimate.org/node/2393
http://lambda-the-ultimate.org/node/2954
btw gibt's irgendwelche in C geschriebenen Systeme die eine 
Verfügbarkeit von 99.9999999% erreichen?
oder auch Singularity wo u.a. sehr schön gezeigt wird, wie man Prozesse 
in Software isolieren kann ohne den Overhead der dazu bei klassischen 
Systemen notwendig ist (http://www.codeplex.com/singularity)

Sven P. schrieb:
> C an sich ist doch schon ziemlich typensicher.

Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch 
bietet es Typsicherheit.

Interessierter schrieb:
> Jetzt mal ehrlich, wieviel Prozent der weltweit entwickelten Software
> wird in diesen drei von dir aufgezählten Sprachen erstellt?

http://www.tiobe.com/content/paperinfo/tpci/index.html
oder etwas älter
http://www.cs.berkeley.edu/~flab/languages.html

Autor: Interessierter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz (andreas) (Admin) wrote:

Interessierter schrieb:
>> Glaubst du wirklich "D" würde C verdrängen?

> Nein, ich habe das auch nirgendwo angedeutet.

Aber du hast die bekannten Sprachen wie C, C++ dafür kritisiert nicht 
genügend Sicherheit in ihren Bibliotheksfunktionen mitzubringen und als 
Beispiel dafür gets() angeführt. Dagegen hast du als bessere Alternative 
Sprachen gesetzt die Gültigkeitsüberprüfungen übernehmen. Daraus ergibt 
sich doch Zwangsläufig, dass das Bibliotheksorientierte C/C++ durch eine 
sicherere Sprache ersetzt (sprich verdrängt) werden sollte und ich habe 
nur erwähnt, dass ich nicht das Gefühl habe, dass genau das passiert 
(abgesehen von .NET, das im Windows Bereich den bisherigen Unterbau 
abgelöst hat).

> .NET und JVM sind wegen
> der hohen Verbreitung unter Windows das sinnvollste. Dabei ist man auch
> nicht auf Java oder C# festgelegt, sondern hat freie Wahl zwischen C#,
> VB, Java, Python, Ruby und vielen anderen Sprachen die auf diesen
> Plattformen laufen.

Aber im Bezug auf Sicherheit kann auch .NET sog. Unmanaged Code 
ausführen, bietet also im Prinzip all die Unsicherheit die auch die 
C-Bibliotheksfunktionen als Ballast mit sich herumtragen. Damit liegt es 
doch im Prinzip am Anwender ob Programmiercode Sicher ist oder nicht 
oder?

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Opera Mini oder Lobo

aehm, du solltest zum stützen deiner these gute beispiele wählen ...

> Nein, z.B. Java-Bytecode direkt in einem Controller (inkl. RTOS und
> Treibern von Ajile http://www.ajile.com/)
> btw gibt's irgendwelche in C geschriebenen Systeme die eine
> Verfügbarkeit von 99.9999999% erreichen?
> oder auch Singularity wo u.a. sehr schön gezeigt wird, wie man Prozesse
> in Software isolieren kann ohne den Overhead der dazu bei klassischen
> Systemen notwendig ist (http://www.codeplex.com/singularity)

ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder 
mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert 
und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.

aper schön dass LISP bald PASCAL überholt ...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Sven P. schrieb:
>> C an sich ist doch schon ziemlich typensicher.
>
> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch
> bietet es Typsicherheit.

Das ist mir geläufig, ich arbeite seit Jahren damit.
Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht 
das meistens auch vollkommen aus.

Ansonsten würde es  mich ja mal interessieren, in welcher Sprache denn 
ein System geschrieben ist, welches 99,9999999% Verfügbarkeit erreicht. 
Und vorallem, in welcher Sprache diese Sprache implementiert ist...
Hand aufs Herz, Die Lisp-Maschinen und Java-Prozessoren bilden schon 
irgendwo die Ausnahme.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Arc Net schrieb:
>> Sven P. schrieb:
>>> C an sich ist doch schon ziemlich typensicher.
>>
>> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch
>> bietet es Typsicherheit.
>
> Das ist mir geläufig, ich arbeite seit Jahren damit.
> Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht
> das meistens auch vollkommen aus.

Wenn C nicht viel zu viele implizite Casts von sich aus machen würde und 
Casts von void* nach xyz* überhaupt nicht zulassen würde...

> Ansonsten würde es  mich ja mal interessieren, in welcher Sprache denn
> ein System geschrieben ist, welches 99,9999999% Verfügbarkeit erreicht.
> Und vorallem, in welcher Sprache diese Sprache implementiert ist...

Erlang. 1.7 Mio Zeilen in einem ATM-Switch (AXD301, 
http://ll2.ai.mit.edu/talks/armstrong.pdf)
http://www.erlang.org/download.html

> Hand aufs Herz, Die Lisp-Maschinen und Java-Prozessoren bilden schon
> irgendwo die Ausnahme.

Leider.

zwieblum schrieb:
> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder
> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert
> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.

Wie wär's mit Argumenten, statt leerer Behauptungen?

p.s. sowohl aJ100 als auch der ähnliche IM1101 von Imsys sind hier schon 
"behandelt" worden. Erlang sollte eigentlich auch jeder kennen, der 
mit/an parallelen Anwendungen arbeitet oder sich aktuell z.B. mit 
CouchDB beschäftigt

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Sven P. schrieb:
>> Arc Net schrieb:
>>> Sven P. schrieb:
>>>> C an sich ist doch schon ziemlich typensicher.
>>>
>>> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch
>>> bietet es Typsicherheit.
>>
>> Das ist mir geläufig, ich arbeite seit Jahren damit.
>> Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht
>> das meistens auch vollkommen aus.
>
> Wenn C nicht viel zu viele implizite Casts von sich aus machen würde und
> Casts von void* nach xyz* überhaupt nicht zulassen würde...
Hm, C castet von alleine nur void * weg, an allen anderen Stellen muss 
es zumindest warnen.

Ich glaube, Erlang braucht zur Übersetzung auch zumindest zum Bootstrap 
C, Perl und Flex, oder..?

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Oliver B. schrieb:
>>>> In Python, OCaml usw. gibt es so einen Unsinn nicht.
>>>
>>> In Python nennt sich das nur etwas anders: null reference und None statt
>>> null.
>> [...]
>>
>> Nein.
>> Dereferenziere einen NULL-Pointer in C, und wenn Deine C-Lib das nicht
>> abfängt, knallst Du gegen die Wand.
>
> Knallt man bei Python auch, wenn man auf None nicht vorbereitet ist.

Ääääähhh. Bin in Python noch nicht so tief drin,
daß einem die None's um die Ohren fliegen können ist mir neu.

Aber kannst Du das ggf. mal erklären...
...was pasiert denn dann?
Stirbt Python mit einem Coredump?



> Allerdings hat man im Gegensatz zu C noch einen Airbag und die
> Geschwindigkeit ist geringer.

Vielleicht meinst Du ja auch eine andere Art von Problem.

Wenn man in C einen NULL-Pointer dereferenziert oder
einen Pointer ins Nirgendwo benutzt, dann landet man im Nirgendwo.
Das kann man dann INNERHALB von dem C-Programm nicht mehr abfangen.

Das System haut einem auf die Finger und im unixoiden/linuxoiden Umfeld 
wird der prozess gekillt, und ggf. ein Speicherabzug auf die Platte 
geschrieben.

Soweit ich Python kenne, kann man dort Exceptions abfangen.
Dies ist ja auch der Grund, ein Exception-System in der Sprache zu 
haben.
... damit man Probleme selbst abfangen kann, und nicht der Kernel den 
prozess beendet.


>
>
> class Test(object):
>    def Foo(self):
>    ...
> v = Test()
> v.Foo()
> v = None
> v.Foo() # AttributeError
> 

Schicke doch mal kompletten Code, den man eingeben kann.
In python bin ich noch nicht so geübt.

Was passiert denn bei dem Beispiel?
Wird Python vom Kernel abgeschossen?



>
>> Nur mit OCaml's Referenzen kannst du nicht gegen die Wand fahren.
>> Und bei Python auch nicht.
>
> Python siehe oben.
> OCaml/F#: Option Types
>
> let bar (a : int option) =
>     Option.get a
> 
> bar None (* Exception *)
> 


Schick mal lauffähigen Code ;-)

Was soll denn da schlimmes passieren?



> Geht somit auch mit OCaml oder F#. Man knallt immer noch vor die Wand,
> wenn man nichts dagegen tut, hat aber zusätzlich zum Airbag noch ABS und
> einen Bremsassistenten (auch wenn normalerweise garantiert ist, dass es
> keine Nullreferenzen gibt).

Wird Ocaml dann vom Kernel gekillt?
Wäre mir neu. Das wäre ein Bug, wenn dem so wäre.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann schrieb:
> Oliver B. schrieb:
>
>> Vielleicht reden wir aneinander vorbei.
>
> Du schwafelst. Voellig sinnlos, darauf einzugehen.

Du verstehst nicht, was ich meine.
Das ist alles.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessierter schrieb:
>> Pointer ist eine Abstraktion der Speicherzugriffe der jeweiligen
>> Maschine und ihrer Hardware.
>
> Mein Gott seid ihr heutzutage "verbildet". Ihr streitet euch bei den
> simpelsten Begriffen um des Kaisers Bart und schwallt ellenlos lange
> Beiträge mit kaum mehr Inhalt.
>
> Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt. Das
> ist alles, mehr braucht man dazu nicht zu sagen.

Dazu kann man sagen, daß wenn man den Pointer dereferenziert,
das Programm in nicht-definierte Zustände kommen kann,
weil man z.B. einen ungültigen Pointer hat und auf nicht erlaubten 
Speicherbereich zugreift, oder einen NULL-Pointer dereferenziert.

Wenn die C-Lib das nicht abfängt - was sie nicht muss, denn das ist in 
der Sprachdefinition von C nicht vorgeschrieben - dann endet das ganze, 
wenn man Pech hat damit, daß das Betriebssystem einem das Programm 
beendet.

Man kann innerhalb des programs diesen Ausnahmezustand nicht mehr 
abfangen.

Falls Du das noch nicht erlebt hast, hast Du entweder noch nicht viel 
mit Pointern gearbeitet, oder zufälligerweise oder glücklicherweise noch 
nicht ungltige Pointer dereferenziert. Daß Du keine Fehler beim 
programmieren machst, halte ich aber für sehr unwahrscheinlich, denn die 
passieen sicherlich jedem.



>
> Ihr müsst mal wieder lernen einfache Dinge auch einfach erklären zu
> können und nicht wie Politiker die sich vor dem eigenen Rücktritt
> sträuben daherzuschwätzen.


Du hast scheinbar obiges Pointer-Dereferenzieren noch nicht gemacht.

Oder Du weisst nicht, daß Referenzen in manchen anderen Sprachen als C 
dem programmierer keinen Zugriff auf einen bestimmten Speichrberg´eich 
geben, indem in dr Referenz die Adresse auf einen Speicherbereich steht, 
auf die der Programmierer zugreifen könnte.

So eine Referenz gibt einem den Inhalt eines Speicherobjektes, stellt 
aber nicht die Adresse dar.

Und es gibt aufgrund des Sprachdesigns von z.B. Ocaml auch niemals 
udefinierte Variablenwerte.
Es ist alles immer mit einem bestimmten Wert initialisiert und niemals
-  wie es in C möglich ist -, ein Zeiger auf womöglich bereits 
freigegebenen Speicher, wo das Programm dann beim Zugriff auf den 
Speicher
vom Betriebssystem getötet wird.

Bei Sprachen, die Exceptions sauber handhaben braucht man daher auch 
nicht so einen unsinn, wie in java: NullPointerException.

Wenn sowas ein Sprachfeature ist und kein Bug, dann ist das ein Manko 
bei der Sprache.
Bei C sehe ich das noch ein. Bei Java, das immer als "modern" 
angeprioesen wird, sehe ich es als nicht akzeptabel an.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
[...]
> Das mit dem Testen ist wieder ein anderes Thema. Der Punkt ist, eine
> Sprache mit Bereichsüberprüfungen kann eine ganze Klasse von Fehlern
> komplett ausschließen, die du durch Testen nicht weitgehend
> ausschließen kannst. Dass ist keine Binsenweisheit oder Theorie, sondern
> hat ganz praktische Auswirkungen: ein Großteil der Sicherheitsupdates
> die du installieren darfst, egal für Windows, Linux, Firefox oder
> sonstwas, sind für C-spezifische Fehler, die mit einer Sprache mit
> Bereichsprüfungen nicht hätten auftreten können. Ich hab mal nach
> "firefox security holes" gegoogelt und die erstbeste rausgesucht:
>
> http://www.mozilla.org/security/announce/2009/mfsa...
> "Heap buffer overflow in string to number conversion"
> Böse ausgedrückt: 35 Jahre nach der Erfindung von C ist die Komplexität
> einer String-zu-Zahl-Konvertierung damit noch nicht beherrschbar.

hahah, eben.

Sehe ich genauso.

off-by-one errors sind auch so eine nette Sache, die immer wieder vor 
kommt

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Zeiger in C sind keine Adressen und sind es auch nie gewesen. Zeiger
> sind Zeiger. Punkt.

hahah.
Und auf was zeigen Zeiger?
Und was ist daher die Bedeutung der Zeiger (also auf etwas zu zeigen)?!


>
> Wenn man Zeiger nicht missbraucht,

Du brauchst nur einen zeiger auf eine automatische variable
zurückgeben und schon hast Du ein Problem, wenn Du den später 
dereferenzieren willst.

Das magst du zeiger missbrauchen nennen,
es ist aber eine Sache, die eben auch versehentlich mal passieren kann.

Und wenn man Pech hat, geht alles so lange gut, bis der Code das erste 
mal beim Kunden ausgeführt wird. ;-)

Es kann nämlich sein, daß der Speicher vom System noch nicht aufgeräumt 
wurde wenn man am testen ist... und der Fehler fällt beim Testen nicht 
auf.


[...]
> Führt es denn zu sichererem/'besserem' Quelltext, wenn man immer mehr
> implizit macht? Objekte löscht man z.B. nicht mehr, sondern verlässt
> sich darauf, dass die irgendwann mal eingesammelt werden?


Das ist durchaus sehr hilfreich.

Dann kann nämlich das, was ich oben erwähnte, nicht mehr vom 
Prorammierer verursacht werden.

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf diese Weise kann Python nie zum Absturz gebracht werden.
Möglich ist es nur, wenn ein in C geschriebener Module *eiße baut.
Python ist eine sehr durchdachte, syntaktisch sehr einfache Sprache.
Manchmal sogar einfacher zu lesen als Pseudecode ;) zB
if i in [1,2,3,"vier"]
if i not in [1,2,3,"vier"]
if 0 < i < 10

Praktisch ist auch funktionale Sichtweise und unbenannte 
Lambda-Funktionen.
>>> map(lambda x:x**2, filter(lambda t: type(t) in [int,long,float], [1,2,3,4,5,6.0,"sieben"]))
[1, 4, 9, 16, 25, 36.0]

filtert aus einer Liste mit beliebigen Elementen Elemente vom Typ 
int,long,float. Die gefilterte Liste wird auf eine neue Liste
über lambda x:x**2 gemappt.

Grüsse

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> (Memo an Hirn: Niemals Diskussionen über Pointer starten) Lassen kann
> ich's aber trotzdem nicht:

heheh :-)



> C ist halt so konzipiert, dass es die Abläufe in der CPU möglichst genau
> abbildet, aber kürzer als Assembler ist (den Beinamen "Super-Assembler"
> trägt C nicht zu Unrecht), und deswegen hat C zwangsweise Pointer, weil
> es auf Hardwareebene eben nicht anders geht. Automatische
> Gültigkeitsprüfung und/oder Referenzzählung hat C nicht, weil die CPU es
> auch nicht hat.
[...]

Seltsame Argumentation.

Was macht C eigentlich, wenn die CPU etwas älter ist und keine
Fließkomma-Arithmetik hat?

Hat C dann auch keine Möglichkeit, zwei double's zu multiplizieren?

Bzw., in deinem Sprachgebrauch "hat C dann keine double-Multiplikation, 
weil die CPU es auch nicht hat"?

Dein Vergleich hinkt also.




> Dieser niedrige Grad an Abstraktion ist gefährlich, wenn
> man ihn nicht anzuwenden weiß, aber man kann gut optimieren. Firefox mag
> zwar eine Menge Sicherheitslücken wegen C haben, aber ich will gar nicht
> wissen, wie langsam Firefox wäre, wenn er in Ruby oder Java geschrieben
> wäre.

Ruby und Java sind ja auch grottig lahm ;-)


Was die Optimierung von C angeht: abstraktere Sprachen haben Vorteile in 
sehr komplexem Programmen.
Dort ist nämlich optimized-by-the-programmer nicht wirklich mehr so 
einfach. daher sind bei sehr komplexen Programmen eher 
higher-level-als-C-Sprachen im Vorteil.
(nein, ich meine nicht Java, das ich nach wie vor für grottig halte.)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Peter Stegemann schrieb:
>> Andreas Schwarz schrieb:
[...]
>
>> Es sind Fehler, die einfach zu finden sind, wenn man will. Natuerlich
>> ist die Wurzel des Problems in der Sprache zu finden - aber es ist nicht
>> das grosse tragische Problem, als das es gerne dargestellt wird, da es
>> einfache Mittel dagegen gibt. Der Entwickler muss nur seinen Arsch
>> hochkriegen und Purify & Co laufen lassen. Dass das viele nicht tun, ist
>> das eigentliche Problem.
>
> Tools wie Purify oder Valgrind werden sowieso praktisch in allen großen
> Projekten eingesetzt bei denen irgend etwas sicherheitsrelevant ist; das
> was man von außen zu sehen bekommt sind die Bugs die danach noch übrig
> bleiben.

Tools, die die Mankos einer Sprache ausbügeln sollen (workarounds) 
zeigen ja eben die schwäche der Sprache auf.



>
>> Es ist ein Mythos, dass schlampige Entwickler
>> mit der richtigen Sprache ploetzlich Qualitaetssoftware abliefern.
>
> Es geht nicht darum dass schlampige Programmierer Qualitätssoftware
> abliefern können, sondern das durchschnittliche Programmierer Software
> abliefern können die nicht kommentarlos abstürzt oder Sicherheitslöcher
> aufreißt nur weil irgendwo ein +1 bei einer Indizierung vergessen wurde.

Eben.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessierter schrieb:
> Sven P. (haku) wrote:
>
>> Zeiger
>> sind Zeiger. Punkt.
>
> Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik
> eines Zigarre rauchenden Altkanzlers.

heheh

>
> Andreas Schwarz (andreas) (Admin) wrote:
>
>> Der Fehler dass durch unerlaubt Speicherzugriffe der komplette Prozess
>> kompromittiert werden kann wird durch eine Sprache mit
>> Zugriffsüberprüfungen ausgeschlossen.
>
> Spräche das nicht eigentlich dafür nur noch eine Laufzeitumgebung wie
> .NET einzusetzen?

Die Laufzeitumgebung als Workaround der Schwächen der benutzten 
Programmier-Sprache?
Warum nicht gleich eine geeignetere Sprache nehmen?

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Interessierter schrieb:
>> Sven P. (haku) wrote:
>>
>>> Zeiger
>>> sind Zeiger. Punkt.
>>
>> Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik
>> eines Zigarre rauchenden Altkanzlers.
> Das sollte keine Erklärung sein. Ich wollte und will damit lediglich
> unterstreichen, dass ein Zeiger keine Adresse und vorallem keine 'Zahl'
> ist,
[...]

Der Zeiger repräsentiert aber eine Adresse.
Und zwar als Speicherbereichs-Adresse.

Da liegt ja dr Unterschied zu referenzen anderer Sprachen, die zwar auf 
ein Speicherobjekt referenieren, aber nicht über einen zahlenwert, der 
eine Speicherstelle lokalisiert, sondern auf eben jenes 
speicherobjekt.... und zwar so, daß das Verändern dieser referenz zwar 
auf ein anderes Speicherobjekt zeigen kann, aber niemals undefiniert 
sein kann, so daß es auch kein dereferenzieren in der Weise gibt, daß 
das betriebssystem einen das Programm killt, weil man in unerlaiubte 
Bereiche adressieren will.




 auch wenn z.B. im Windows-Kern früher furchtbar gerne
> Zeivervariablen mit Zahlen beschrieben wurden.
> So von wegen:
>
> int *l;
> l = 5;
> 
> Krieg ich die Krise bei.

Warum?

Warum kriegst Du dabei die Krise?


>
> C an sich ist doch schon ziemlich typensicher.


hahahah, der Lacher war echt gut! :-)

Das meinst Du nicht wirklich ernst, oder?



> Klar, wenn man C mit
> wildem Herumgecaste dazu zwingt, baut es auch Mist. Aber das macht
> Delphi/Pascal dann auch.

Au Mann.

C ist nicht "typsicher" - und das ist bei manchen Anwendungsfällen ja 
gerade auch sein Vorteil!

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oliver
>Ruby und Java sind ja auch grottig lahm ;-)

Zitat von http://sds.podval.org/ocaml-sucks.html
The biggest trouble is that integer overflow is not detected even at run time, which places OCaml right next to C and assembly with respect to type checking. One may argue that this is not a type issue (and you might even be right technically), but my retort is that the mathematical integers do not overflow, and I expect a language to provide something at least somewhat resembling them (and no, I cannot always use bignums - they are slow and cannot be used directly in arithmetics, see below).

will damit sagen, dass jede Sprache Schwächen hat. Python mag auch 
grottig
lahm (10-30 mal langsamer) aber dafür ...
>>> 45**1000
1631224649060432385695669024921698220114497546539065437639933142147378286271938088206872361603859422730464755992141422757887547486765791632321606548918183108945590797604715760986270001924228758661078535725478203122328278000120409125453813160548704738619108966809475205987783983665396374981399792084348946027246255604887153918033867782235467281602820898616348046157130247946507683946391110124369467827106312437048246521264863835191437706938390992977489020599595115365036251749287135717651518763112631271056468620419471718314880922520298113909193596398311755379854778111239310882590812123221078091960243137920991760860427854819371902124170807398176507903818663363260160809074086033912099909368893790839017263671192358964437951974115193277952740446826441402574093381395760818982010480150883000396738250868057782963208061549768878199746916422625423243787950279495944842515583534678562175410271083624308804084107696750269476536102664631761155859666931286676253482951072226305987156312317718194781970318071597117292665963164979284695909845494675691206099836556879490633959239966247739914038988998710802854838660276305207534145365538217704788025983881646419275891013161521145599009630899381450962750883983260938372886068735496402983158423102413642505104338627033119034650017513058014424356005156926279208172449965399647974276837875585949786164700659102225262558722324734919635460819910409960416030501637431531998854534507980526054084082094728446659088572194314038426255574880395967725061482278638012925696085310205093476775353069639000291926132802645479137564031762397619603638090666326711250151413611972413034346911079632003183093047482543624937534332275390625L

voila :)
>>> 45**1000 % 56
25L

und ich habe keine 0.1 sekunde gewartet :)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Sven P. schrieb:
>> Arc Net schrieb:
>>> Sven P. schrieb:
>>>> C an sich ist doch schon ziemlich typensicher.
>>>
>>> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch
>>> bietet es Typsicherheit.
>>
>> Das ist mir geläufig, ich arbeite seit Jahren damit.
>> Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht
>> das meistens auch vollkommen aus.
>
> Wenn C nicht viel zu viele implizite Casts von sich aus machen würde

eben.

> und
> Casts von void* nach xyz* überhaupt nicht zulassen würde...

eben.


>
>> Ansonsten würde es  mich ja mal interessieren, in welcher Sprache denn
>> ein System geschrieben ist, welches 99,9999999% Verfügbarkeit erreicht.
>> Und vorallem, in welcher Sprache diese Sprache implementiert ist...
>
> Erlang.

Das hatte ich vermutet. :-)

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>>import time
>>> start=time.time(); d=57**1000; end=time.time(); end-start
5.9604644775390625e-06
>>> d
7496450411170012694546459447435141267418526510887624534055771367839632472790002300002432835214329490647325843753442313354592863592785588369090134965732204395332402710459120293827045762798093767328132734592108110820198669943184111406209695597950612415520830792401541882078311171463823017371326334959386627941096200823949814650342264336375025703475554743590200291815803939809526666022832860105541414527322605443166192318164190235343057997847174157716767519610069805876441079335092474931558331668322462746412094276947257424509083771940268266712064217284769657631242755450516643631157090848205285985799836085648241271213922979532112135731650616466987891287324014599425454948641592088873010784196210817573758355211893130648695469707407073974897321279743918907335453633505430169028991771500435481551987671895219051666505420172399052306593321635382755118559552307172917224966040624653055694899486913549345585371977569034168587262901642802289888459247018813043305739988340184533494284367963404875102478111320426232969825851745750219444072864560606147286717674051569937213535054087568712422411665934691052668801861284240794736639088226641386008975216735661869059136883109572915073054949486515177664814003394778118659485730128355023496281702296704253582721820418915706029136089143778165862760669871877369762575155147870262925758054323696072377707865467728007758989871444627108278283861524587652971274821198684087513881683219630006727790521309377319708106815638840374263549555628398888588728442400001560378509553460147128760793014728880724276020932132815741119726869303934264723300953350513630389911132870335094862079693794935274846633940670433237284286515257214374833539563379170196089945205492510817024888478456156083157141074422742518784703315223704199860639000001L

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:
> Wenn man in C einen NULL-Pointer dereferenziert oder
> einen Pointer ins Nirgendwo benutzt, dann landet man im Nirgendwo.
> Das kann man dann INNERHALB von dem C-Programm nicht mehr abfangen.

Deshalb auch der Satz mit dem Airbag und der Geschwindigkeit,

> Das System haut einem auf die Finger und im unixoiden/linuxoiden Umfeld
> wird der prozess gekillt, und ggf. ein Speicherabzug auf die Platte
> geschrieben.
>
> Soweit ich Python kenne, kann man dort Exceptions abfangen.

Genau das ist der Punkt: Man kann Exceptions abfangen, man kann auch auf 
Nullpointer testen, man kann auch in C mit setjmp/longjmp eine Art 
Exception-Handling basteln...
Das einzige was hier nicht passieren kann, ist, dass damit Code 
eingeschleust werden kann. Trotzdem kann das Programm einen 
undefinierten Zustand hinterlassen (nicht alle Daten gespeichert etc).
# das reicht als Test in Python
v = None
v.Foo() # AttributeError

(* das läuft so in OCaml/F# *)
let bar (a : int option) =
    Option.get a

bar None (* Exception *)

> Dann kann nämlich das, was ich oben erwähnte, nicht mehr vom
> Prorammierer verursacht werden.

Nicht mehr mit denselben Auswirkungen siehe oben

Sven P. schrieb:
> Hm, C castet von alleine nur void * weg, an allen anderen Stellen muss
> es zumindest warnen.

Warnen alle Compiler vor so etwas
int b = 0;
double *dP = (double *)&b;
// oder hier vor
void (*fP)() = (void (*)())&b;
fP();

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel (root) schrieb:
>
>>>>import time
>>>> start=time.time(); d=57**1000; end=time.time(); end-start
> 5.9604644775390625e-06
>>>> d
> 7496450411170012694546459447435141267418526510887624534055771367839632472790002300002432835214329490647325843753442313354592863592785588369090134965732204395332402710459120293827045762798093767328132734592108110820198669943184111406209695597950612415520830792401541882078311171463823017371326334959386627941096200823949814650342264336375025703475554743590200291815803939809526666022832860105541414527322605443166192318164190235343057997847174157716767519610069805876441079335092474931558331668322462746412094276947257424509083771940268266712064217284769657631242755450516643631157090848205285985799836085648241271213922979532112135731650616466987891287324014599425454948641592088873010784196210817573758355211893130648695469707407073974897321279743918907335453633505430169028991771500435481551987671895219051666505420172399052306593321635382755118559552307172917224966040624653055694899486913549345585371977569034168587262901642802289888459247018813043305739988340184533494284367963404875102478111320426232969825851745750219444072864560606147286717674051569937213535054087568712422411665934691052668801861284240794736639088226641386008975216735661869059136883109572915073054949486515177664814003394778118659485730128355023496281702296704253582721820418915706029136089143778165862760669871877369762575155147870262925758054323696072377707865467728007758989871444627108278283861524587652971274821198684087513881683219630006727790521309377319708106815638840374263549555628398888588728442400001560378509553460147128760793014728880724276020932132815741119726869303934264723300953350513630389911132870335094862079693794935274846633940670433237284286515257214374833539563379170196089945205492510817024888478456156083157141074422742518784703315223704199860639000001L
> 

...das ist ja ganz nett... und was willst Du uns damit sagen?

Autor: Zwie Blum (zwieblum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
q Arc Net (arc):
>> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder
>> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert
>> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.
>
>Wie wär's mit Argumenten, statt leerer Behauptungen?

1) der hersteller gibt eine reaktionszeit der interreuptroutine an, aber 
nicht des java codes. auf der ganzen seite war kein eine einzige 
untersuchung/angabe zur latenzzeit.

2) auf der tollen seite http://www.codeplex.com/singularity funktioniert 
kein einziger link zu den original-"papers". ausserdem ist das ding noch 
so was von weit weg vom realen einsatz wie kaffeesudlesen.

3) die "echtzeitfähigkeit" wird durch meist sehr brutales weglassen von 
sicherheitsfeatures erreicht. geeigneter code kann durchaus die 
"sicherheitsprüfung" des compilers erfolgreich bestehen, aber dennoch in 
der vm mist bauen.

abgesehen davon ist's hübsch zu sehen wie sich leute wegen heisser luft 
beflegeln :-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:
Du führst gerne Selbstgespräche, hu?

> Sven P. schrieb:
>> Interessierter schrieb:
>>> Sven P. (haku) wrote:
>>>
>>>> Zeiger
>>>> sind Zeiger. Punkt.
> [...]
>
> Der Zeiger repräsentiert aber eine Adresse.
> Und zwar als Speicherbereichs-Adresse.
Wo steht das? Ein Zeiger zeigt auf ein Objekt.

> und zwar so, daß das Verändern dieser referenz zwar
> auf ein anderes Speicherobjekt zeigen kann, aber niemals undefiniert
> sein kann, so daß es auch kein dereferenzieren in der Weise gibt, daß
> das betriebssystem einen das Programm killt, weil man in unerlaiubte
> Bereiche adressieren will.
Nicht?

#include <iostream>

using namespace std;
const int &min(const int& a, const int& b) {
    if (a > b)
        return a;
    else
        return b;
}

int main() {
    const  int &i = min(1 + 3, 1 + 4);
    cout << i << endl;
}

Bitte sehr. Undefiniertes Verhalten mit Referenzen in C++; i 
referenziert ein temporäres Objekt, das nicht mehr exisitert.

>> So von wegen:
>>
>> int *l;
>> l = 5;
>> 
>> Krieg ich die Krise bei.
>
> Warum?
>
> Warum kriegst Du dabei die Krise?
Weil Zeiger keine Zahlen sind. Es steht nirgendwo geschrieben, dass ein 
(int *) den Wertebereich eines int hat oder alle Werte eines int 
darstellen kann.
Zitat:
>Any pointer type may be converted to an integer type. Except as
>previously specified, the result is implementation-defined. If
>the result cannot be represented in the integer type, the behavior
>is undefined. The result need not be in the range of values of any
>integer type.

Ein Zeiger kann also in einen Integer verwandelt werden, es ist aber 
absolut freigestellt, welche die Abbildung dazwischen ist. Lediglich der 
NULL-Zeiger ist eindeutig 0.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Sven P. schrieb:
>> Hm, C castet von alleine nur void * weg, an allen anderen Stellen muss
>> es zumindest warnen.
>
> Warnen alle Compiler vor so etwas
>
> int b = 0;
> double *dP = (double *)&b;
> // oder hier vor
> void (*fP)() = (void (*)())&b;
> fP();
> 
Nein. Muss er auch nicht, denn die Zeigertypen sind identisch, da du sie 
explizit herumgecastet hast.
Ich glaube, man merkt i.d.R. schon, wenn man einen Cast formuliert.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Oliver B. schrieb:
>> Wenn man in C einen NULL-Pointer dereferenziert oder
>> einen Pointer ins Nirgendwo benutzt, dann landet man im Nirgendwo.
>> Das kann man dann INNERHALB von dem C-Programm nicht mehr abfangen.
>
> Deshalb auch der Satz mit dem Airbag und der Geschwindigkeit,

öööhh.

Dann meinst anscheinend Du zwar das selbe, aber mein Anliegen war,
ide Unterscheidung zwischen C und OCaml/Python darzustellen,
daß eben in C der gesamte Prozess gekillt wird.

Das ist dann von dem Prozess selbst nicht mehr aufzuhalten!
Also kann man für solche Fälle keine Fehlerbehandlung einbauen!

/* geht eben nicht */
/* --------------- */
if( system_wants_to_kill_myself_with_coredump )
{
  fange_das_mal_ab();
}




>
>> Das System haut einem auf die Finger und im unixoiden/linuxoiden Umfeld
>> wird der prozess gekillt, und ggf. ein Speicherabzug auf die Platte
>> geschrieben.
>>
>> Soweit ich Python kenne, kann man dort Exceptions abfangen.
>
> Genau das ist der Punkt: Man kann Exceptions abfangen, man kann auch auf
> Nullpointer testen, man kann auch in C mit setjmp/longjmp eine Art
> Exception-Handling basteln...

...basteln... na das ist ja echt nicht die Art von Qualitätsanpruch, die 
ich meine! ;-)


Man kann Exceptions abfangen. Ja.
Man kann auch auf NULL-Pointer testen.

Oder man kann das vergessen.


Mann kann aber keine NULL-Pointer-Dereferenzierung oder 
Pointer-der-auf-ungültigen-Speicherbereich-zeigt-Dereferenzierung 
abfangen!

if( *ungueltiger_Pointer )
{
  zu_spaet();
}



Eine eine Exception, die man direkt dort, wo sie entsteht vergessen
hat zu catchen, die lässt sich wenigstens noch auf einer anderen Ebene
des programms nochmal abfragen/catchen.
Das geht auch bei einem NULL-Pointer.
Das geht aber nicht, wenn man einen NULL-/ungültigen Pointer 
dereferenziert.

Keine Chance mehr!


Ist das etwa nicht nachvollziehbar, was ich hier schreibe?

Ist der Zusammenhang so schwer zu verstehen?






> Das einzige was hier nicht passieren kann, ist, dass damit Code
> eingeschleust werden kann. Trotzdem kann das Programm einen
> undefinierten Zustand hinterlassen (nicht alle Daten gespeichert etc).
>
>
> # das reicht als Test in Python
> v = None
> v.Foo() # AttributeError
> 
> (* das läuft so in OCaml/F# *)
> let bar (a : int option) =
>     Option.get a
> 
> bar None (* Exception *)
> 

OK, also eben nur eine Exeption.
Der prozess (ocaml /python) läuft weiter.

Also keine nichtabangbare Situation.

Also hat nur C hier ein Problem!

Das ist es, wobvon ich die ganze Zeit rede.

Autor: Daniel (root) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...das ist ja ganz nett... und was willst Du uns damit sagen?

sorry, war etwas aus dem Kontext gerissen. Es bezog sich auf Dein 
Statement,
dass Ruby grottig lahm sei. Ich habe Python verwendet, weil ich es 
gerade am Laufen hatte. Aber gut, jetzt schmeisse ich Ruby an.
irb(main):020:0* start = Time.now; d = 45**1000; Time.now - start
=> 8.6e-05
irb(main):021:0> d
=> 1631224649060432385695669024921698220114497546539065437639933142147378286271938088206872361603859422730464755992141422757887547486765791632321606548918183108945590797604715760986270001924228758661078535725478203122328278000120409125453813160548704738619108966809475205987783983665396374981399792084348946027246255604887153918033867782235467281602820898616348046157130247946507683946391110124369467827106312437048246521264863835191437706938390992977489020599595115365036251749287135717651518763112631271056468620419471718314880922520298113909193596398311755379854778111239310882590812123221078091960243137920991760860427854819371902124170807398176507903818663363260160809074086033912099909368893790839017263671192358964437951974115193277952740446826441402574093381395760818982010480150883000396738250868057782963208061549768878199746916422625423243787950279495944842515583534678562175410271083624308804084107696750269476536102664631761155859666931286676253482951072226305987156312317718194781970318071597117292665963164979284695909845494675691206099836556879490633959239966247739914038988998710802854838660276305207534145365538217704788025983881646419275891013161521145599009630899381450962750883983260938372886068735496402983158423102413642505104338627033119034650017513058014424356005156926279208172449965399647974276837875585949786164700659102225262558722324734919635460819910409960416030501637431531998854534507980526054084082094728446659088572194314038426255574880395967725061482278638012925696085310205093476775353069639000291926132802645479137564031762397619603638090666326711250151413611972413034346911079632003183093047482543624937534332275390625

Im Grunde juckt es doch nicht wirklich ob ein Programm 0.001 Sekunde 
braucht oder 0.02. Selbstverständlich gilt das nicht für alle Programme.

Das Problem, dass ich bei diesen netten Skriptsprachen sehe, ist, dass
doch mehr Fehler erst zur Laufzeit abgefangen werden. Aber sie sind
nur ein Werkzeug und kein "Hammer für alles".

By the way: Etwas Haskell und Clisp kenne ich auch. Ich konnte mich auch
mit der anderen Denkweise anfreunden. Leider hatte ich dann nicht mehr
viel Zeit tiefer einzusteigen.

Grüsse

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Oliver B. schrieb:
> Du führst gerne Selbstgespräche, hu?

falsch gequotet?


>
>> Sven P. schrieb:
>>> Interessierter schrieb:
>>>> Sven P. (haku) wrote:
>>>>
>>>>> Zeiger
>>>>> sind Zeiger. Punkt.
>> [...]
>>
>> Der Zeiger repräsentiert aber eine Adresse.
>> Und zwar als Speicherbereichs-Adresse.
> Wo steht das? Ein Zeiger zeigt auf ein Objekt.
>
>> und zwar so, daß das Verändern dieser referenz zwar
>> auf ein anderes Speicherobjekt zeigen kann, aber niemals undefiniert
>> sein kann, so daß es auch kein dereferenzieren in der Weise gibt, daß
>> das betriebssystem einen das Programm killt, weil man in unerlaiubte
>> Bereiche adressieren will.
> Nicht?
[...]
> Bitte sehr. Undefiniertes Verhalten mit Referenzen in C++; i
> referenziert ein temporäres Objekt, das nicht mehr exisitert.

Ich redete nicht über C++, sondrn OCaml. :-)


>
>>> So von wegen:
>>>
>>> int *l;
>>> l = 5;
>>> 
>>> Krieg ich die Krise bei.
>>
>> Warum?
>>
>> Warum kriegst Du dabei die Krise?
> Weil Zeiger keine Zahlen sind. Es steht nirgendwo geschrieben, dass ein
> (int *) den Wertebereich eines int hat oder alle Werte eines int
> darstellen kann.

Und warum kompiliert das dann?

Müsstest Du nicht eine Krise kriegen,
darüber, daß C sowas erlaubt?

Stattdessen kriegst du eine Krise, wenn man sowas schreibt.

Das ist der Knackpunkt.
Würde die Sprache das nicht erlauben, und dahr den code nicht 
kompilieren, gäbe es keinen Grund, sich drüber aufzuregen / darüber eine 
krise zu kriegen, denn in einem lauffähigen Code würde so ein konstrukt 
nicht auftreten.

Man müsste also auch keine teste darüber machen, keine Warnings dafür 
beim Kompilieren ausgeben und auch keine externen Tools aufrufen, die 
sowas ent-Krise-ln.

Beispiel für Referenzen in Ocaml:
# let x = ref 55;;
val x : int ref = {contents = 55}
# !x;;
- : int = 55
# let x = ref 4567;;
val x : int ref = {contents = 4567}
# !x;;
- : int = 4567
# let x = ref "Hallo";;
val x : string ref = {contents = "Hallo"}
# !x;;
- : string = "Hallo"
# let mal_zwei x1 x2 = x1 *. x2;;
val mal_zwei : float -> float -> float = <fun>
# !x;;
- : string = "Hallo"
# !x 3.98 4.09;;
Error: This expression is not a function; it cannot be applied
# let x = ref mal_zwei;;
val x : (float -> float -> float) ref = {contents = <fun>}
# !x;;
- : float -> float -> float = <fun>
#  !x 3.98 4.09;;
- : float = 16.2782
# 

Normalerweise braucht man auch nicht mal referenzen nehmen,
denn es geht auch meist ohne Referenzen und man macht so Sachen, wie
let a = 22;;

Dann kann man über "a" auf die "22" zugreifen.

Es gibt wederbei den referenzen noch bei variablen ohne referenzen eine 
Operation, die das leistet, was man in C mit "&" erreicht.

Ein Äquivalent für
int x = 55;
int* x_ptr = &p;

existier in Ocaml nicht.

Daher kann es auch keine äquvalenten Probleme geben,
wie in C, wo man undfinierte Pointer hat oder *NULL.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist der Knackpunkt.
>Würde die Sprache das nicht erlauben, und dahr den code nicht
>kompilieren, gäbe es keinen Grund, sich drüber aufzuregen / darüber eine
>krise zu kriegen, denn in einem lauffähigen Code würde so ein konstrukt
>nicht auftreten.

bitte entschuldige, das ist schwachsinn. nur weil es auf einer 
rechnerarchitektur (z.b.: pc userspace) nicht sinnvoll ist heißt nicht, 
dass das konstrukt immer sinnlos ist. z.b. auf microcontrollern macht es 
erstaunlicherweise sinn.

wenn das dem programmierer zu komplex ist, dann soll er lieber eine 
kischelsprache nehmen.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf Mikrocontrollern muss man zwar manchmal bestimmte Adressen 
adressieren, aber dazu ist es nicht nötig zur Laufzeit Pointer 
umzubiegen.

Übrigens:
"Wichtige Regeln - erst lesen, dann posten!

    * Groß- und Kleinschreibung verwenden"

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwie Blum schrieb:
> q Arc Net (arc):
>>> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder
>>> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert
>>> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.
>>
>>Wie wär's mit Argumenten, statt leerer Behauptungen?
>
> 1) der hersteller gibt eine reaktionszeit der interreuptroutine an, aber
> nicht des java codes. auf der ganzen seite war kein eine einzige
> untersuchung/angabe zur latenzzeit.

Woher soll der Hersteller wissen, wie lang deine Interruptroutine 
braucht?
Thread- und JVM-Wechsel werden über interne Hardwaretimer realisiert...

> 2) auf der tollen seite http://www.codeplex.com/singularity funktioniert
> kein einziger link zu den original-"papers".

http://research.microsoft.com/en-us/projects/singu...
(Die Seite ist nicht schwer zu finden...)
http://research.microsoft.com/pubs/69431/osr2007_r...

> ausserdem ist das ding noch
> so was von weit weg vom realen einsatz wie kaffeesudlesen.

Was man sieht ist schon ganz gut brauchbar für ein Forschungsprojekt 
(Helios und Midori gibt's auch noch, Linux wurde auch nicht an einem Tag 
erschaffen)

Oliver B. schrieb:
> Dann meinst anscheinend Du zwar das selbe,

Ja

> aber mein Anliegen war,
> ide Unterscheidung zwischen C und OCaml/Python darzustellen,
> daß eben in C der gesamte Prozess gekillt wird.

eine Möglichkeit gibt's noch: signal.h einbinden und
signal(SIGSEGV, handler) dazu noch setjmp/longjmp, (aber lassen wir das)

> Beispiel für Referenzen in Ocaml:
Man sollte vllt dazu sagen, dass es in OCaml/F#, besser gesagt in 
funktionalen Sprachen allgemein, keine Variablen gibt, sondern nur Werte 
die an einen Namen gebunden werden.
Referenzen erzeugen ein neues "Objekt", kopieren den ursprünglichen Wert 
und dann kann der Wert im neuen Objekt geändert werden (nicht aber die 
Referenz, auch wenn es im Beispiel so aussieht).

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zwieblum schrieb:
>>Das ist der Knackpunkt.
>>Würde die Sprache das nicht erlauben, und dahr den code nicht
>>kompilieren, gäbe es keinen Grund, sich drüber aufzuregen / darüber eine
>>krise zu kriegen, denn in einem lauffähigen Code würde so ein konstrukt
>>nicht auftreten.
>
> bitte entschuldige, das ist schwachsinn.


Das ist nicht Schwachsinn, sondrn Du raffst es einfach nicht.

Wenn Du nicht verstehen willst, und stattdessen meine 
Ansichten/Argumente als Unsinn bezeichnist, dann zeigt das Deine Idiotie 
auf.



> nur weil es auf einer
> rechnerarchitektur (z.b.: pc userspace) nicht sinnvoll ist heißt nicht,
> dass das konstrukt immer sinnlos ist.

Du verstehst es icht.

Ich habe nicht gesagt, daß C immer sinnlos ist.
Und Du verstehst auch nicht, daß die Sprache, in der man programmiert 
vom Compiler übersetzt wird, und daß Dein Argument bzgl. Architekturen 
damit stark schwächelt.


> z.b. auf microcontrollern macht es
> erstaunlicherweise sinn.

C macht auch auf PCs Sinn.

Du raffst nicht, daß ich nicht sage, daß C keinen Sinn macht,
sondern daß es ftmals keinen Sinn macht, die Schwierigkeiten, die es 
mitbringt, hinzunehmen, nur weil man zu faul odr nicht in der Lage ist, 
andere Sprachen zu verstehen.




>
> wenn das dem programmierer zu komplex ist, dann soll er lieber eine
> kischelsprache nehmen.

Dieses Argument ist so bescheuert... es zeigt, daß Du Dich wohl sehr 
toll fühlst, eine an vielen Stellen schwächelnde Sprache zu nutzen, 
daraus das Argument ziehst, ein super toller programmierer zu sein; das 
heisst, nur weil Du willst, daß man Dir huldigt, wie kewl Du doch bist, 
nimmst Du eine Sprache, die so super dolle ist und als "Guru-like" gilt.

dabei reicht Dein geist offenbar nicht aus, auch zu sehen, daß hinterm 
Tellerand noch mehr kommt.

Ich habe selbst C viele Jahre lang benutzt und finde es immernoch besser 
als vieles andere, was einem heutzutage so als "modern" angepriesen 
wird.
Nur denke ich nicht, daß das das non-plus-ultra ist.

Kannst Du überhaupt auch noch andere Sprachen (und kannst Du C wirklich, 
oder laberst Du nur?), oder verteidigst Du C nur, weil Du nix anderes 
kannst und auch zu faul bist, m,al was anderes zu lernen?

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Auf Mikrocontrollern muss man zwar manchmal bestimmte Adressen
> adressieren,
[...]

Zumindest wenn man C nimmt.

;-)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Oliver B. schrieb:
> Du führst gerne Selbstgespräche, hu?
>
>> Sven P. schrieb:
>>> Interessierter schrieb:
>>>> Sven P. (haku) wrote:
>>>>
>>>>> Zeiger
>>>>> sind Zeiger. Punkt.
>> [...]
>>
>> Der Zeiger repräsentiert aber eine Adresse.
>> Und zwar als Speicherbereichs-Adresse.
> Wo steht das? Ein Zeiger zeigt auf ein Objekt.
[...]

Und was ist die Differenz aus zwei Objekten, auf die ein Zeiger zeigt?


Wie bitteschön erklärst Du Zeigerarithmetik mit Deinem 
Erklärungs-Ansatz?

Was hier leider missverstanden wird: "Objekt" muß man im Kontext von C 
anders interpretieren als im Kontext von OO-Sprachen.

Ein Byte auf das ein Zeiger zeigt (und dessen (virtuelle) 
Speicheradresse der Zeiger beinhaltet) wird auch als "Objekt" 
bezeichnet, aber in anderem Sinne als in OO-Sprachen.


Wenn in C die Pointer/Zeiger so abstrakt wären, wie es hier gerne 
dargestellt werden soll, dann bitte erklärt) mir das Mysterium der 
Zeigerarithmetik.

Und wozu gibt es bitteschön sizeof()?



Interessant, daß, wenn man über abstrakte Referenzen spricht, man als 
überkandidelt gilt, und wenn es um C geht, will man dann diese abstrakte 
Denke gerne doch noch schnell einheimsen.

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
[...]
> Weil Zeiger keine Zahlen sind.
[...]


Sondern was sind zeiger?


Und wenn Zeiger keine Zahlen sind,
wie kommt es dann, daß man die Differenz von Zeigern bilden kann?


Banane - Zitrone = 123




...



Ach ja, "2 mal 2 gleich grün".  :-)

Hahahahh :-)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Zwie Blum schrieb:
>> q Arc Net (arc):
>>>> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder
>>>> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert
>>>> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.


[...]


>> aber mein Anliegen war,
>> ide Unterscheidung zwischen C und OCaml/Python darzustellen,
>> daß eben in C der gesamte Prozess gekillt wird.
>
> eine Möglichkeit gibt's noch: signal.h einbinden und
> signal(SIGSEGV, handler) dazu noch setjmp/longjmp, (aber lassen wir das)
>

:-)



>> Beispiel für Referenzen in Ocaml:
> Man sollte vllt dazu sagen, dass es in OCaml/F#, besser gesagt in
> funktionalen Sprachen allgemein, keine Variablen gibt,

jau.

...den rest fand ich aber irgendwie seltsam erklärt...

...ok, ist schon spät ;-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver B. schrieb:
Du redest wirklich mit dir selbst...

> Sven P. schrieb:
> [...]
>> Weil Zeiger keine Zahlen sind.
> [...]
>
> Sondern was sind zeiger?
Zeiger.

> Und wenn Zeiger keine Zahlen sind,
> wie kommt es dann, daß man die Differenz von Zeigern bilden kann?
> Banane - Zitrone = 123
Kann man auch nur bei gleichartigen Zeigern. Objekte können in Vektoren 
liegen (wobei die Adressen der Einzelobjekte eines Vektors nicht 
unbedingt numerisch hintereinander liegen müssen -- kann der Compiler 
frei entscheiden) an. Die Differenz zweier Zeiger (Resultattyp: 
ptrdiff_t) gibt an, wie viele Objekte zwischen den Zeigern im Vektor 
liegen.


Beispiel:
 Objekt1   Objekt2   Objekt3   Objekt4
    ^                   ^
    |                   |
   zeig1               zeig2

Es ist unbestimmt:
- wo die Objekte im physischen Speicher liegen
- wie groß die Zeiger sind, wenn sie in Integer umgewandelt werden

Es steht lediglich fest, dass zeig2 größer als zeig1 ist, da zeig2 auf 
ein Objekt rechts von zeig1 zeigt. Was nicht heißen muss, dass Objekt3 
an einer größeren Adresse im Speicher liegen muss. Zeiger können auch 
Strukturen sein, etwa solcherart:
struct pointer {
  long seg;
  long off;
}
Dann macht der Compiler sich entsprechend Gedanken über die Umsetzung. 
Auf einigen Mikroprozessoren werden Zeiger etwa drei Bytes breit 
implementiert und sind dann transparent für Flash, RAM und EEPROM 
nutzbar. Auch da muss der Compiler dann halt die geeigneten 
Zugriffsmethoden einbauen.

Sizeof gibt die Größe eines Objektes in Einheiten von char wieder. Hat 
auch nichts mit Bits und Bytes zu tun..


Was Zeiger und Integer angeht:
Ich weiß nicht, wieso das in C erlaubt wird, aber bisher hatte ich keine 
sinnvolle Verwendung dafür. Mir sind aber die Unzulänglichkeiten 
bekannt, wieso das in die Hose gehen kann, das reicht mir.
Vielleicht sollte man 'rm' auf der Konsole auch verbieten, das warnt 
auch nicht, wenn man irgendwo im Heimatverzeichnis ein Leerzeichen zu 
viel mitgibt und damit nicht *~, sondern * und ~ löscht.


Wird in C++ eine Exception nicht aufgefangen, wird im Übrigen auch der 
Prozess abgeknallt.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Sondern was sind zeiger?
> Zeiger.

Das ist genau der Typ von Definition, der das Lernen von Programmier-
sprachen manchmal so schwer macht ;-)

Die andere, nicht selbstreferenzierende "Definition": Ein Zeiger bedarf
keiner Definition, er ist einfach da.

Beide Varianten findet man in ähnlicher Form tatsächlich in Lehrbüchern.
Ich frage mich nur, was das soll.

Als ich damals nach Basic und Assembler als dritte Programmiersprache
Pascal lernte, hatte ich anfangs unendliche Schwierigkeiten, das Konzept
der Zeiger zu verstehen und richtig anzuwenden, da es diese ja in Basic
und Assembler überhaupt nicht gab. Irgendwann fiel es mir wie Schuppen
von den Augen: Diese obskuren Zeiger sind ja nichts anderes als die
Speicheradressen der Daten, auf die sie zeigen. Speicheradressen waren
mir aber sehr wohl ein Begriff, da es sie sowohl in Basic als auch in
Assembler gab.

Sowohl beim Lernen als auch bei der Anwendung von Programmiersprachen
finde ich es nicht nur legitim, sondern sogar wichtig, mitunter auf
Rechnerarchitekturebene zu denken, weil das einfach die Codequalität
verbessert.

Sven, du beziehst dich mit der Unterscheidung zwischen Zeigern und Ad-
ressen auf den C-Standard, in dem weitgehend vermieden wird, die Begrif-
fe "Pointer" und "Address" synonym zu verwenden, um dem Compilerentwick-
ler die Möglichkeit offen zu lassen, die Zeiger auf speziellen Rechner-
architekturen auch anders zu implementieren. Man merkt aber an folgenden
Passagen, dass selbst die Autoren des Standards bei Zeigern immer auch
an Adressen denken:

  "p is assigned the address of the first element of an array […]"

Dabei ist p eine Zeigervariable.

  "6.5.3.2 Address and indirection operators"

Der unäre &-Operator wird also "Adressoperator" und nicht etwa "Zeiger-
operator" genannt.

  "The unary & operator yields the address of its operand."

Hier wieder.

  "An address constant […] shall be created explicitly using the unary
  & operator or an integer constant cast to pointer type, […]"

Ohne diese offizielle Erlaubnis, Integers durch Casts als konstante Ad-
ressen zu interpretieren und dann als Zeiger für Zugriffe auf Speicher-
zellen oder I/O-Register zu verwenden, wären bspw. sämtliche io*.h-Da-
teien der AVR-LibC "böse".

Wenn man erst einmal vom akademischen Sockel der Zeiger-Adressen-Unter-
scheidung heruntergekommen ist, merkt man, dass die Referenzen, wie sie
bspw. in C++ und Java vorkommen, nichts weiter als syntaktisch versüßte
Zeiger mit eingeschränkten Manipulationsmöglichkeiten, und damit letzt-
endlich ebenfalls Adressen sind.

Als vor Kurzem ein Kollege ein Verständnisproblem mit C++-Referenzen
hatte und ich ihm mangels Zeit für eine detailliertere Erklärung einfach
antwortete "Das sind letztendlich konstante Zeiger bzw. Adressen, für
die man zur Dereferenzierung kein '*' braucht", konnte er perfekt damit
umgehen. Wahrscheinlich viel besser, als wenn ich ihm eine 30-Minuten-
Predigt, beginnend mit "Ja, das ist etwas ganz Abstraktes und hat mit
Zeigern und Adressen überhaupt nichts zu tun ..." gehalten hätte.

Ich kenne auch keinen Compiler, egal welcher Sprache, der Zeiger und
Referenzen nicht als Adressen der Zielarchitektur implementiert.
Vielleicht gibt es einen, aber es reicht ja, sich das Leben erst dann
schwer zu machen, wenn man einen solchen tatsächlich benutzt ;-)

Autor: Oliver B. (ickbineeenberliner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
[...]
> eine Möglichkeit gibt's noch: signal.h einbinden und
> signal(SIGSEGV, handler) dazu noch setjmp/longjmp, (aber lassen wir das)
[...]

Dir ist aber bewusst, daß signal() nicht reliable ist?

Wenn schon, dann sigaction() und Co.

Die sind aber nicht wirklich zum Sprachumfang von C gehörend.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu schrieb:
>> Sven, du beziehst dich mit der Unterscheidung zwischen Zeigern und Ad-
> ressen auf den C-Standard, [...]
Das ist mir schon klar.

Wenn du den Standard genau liest, wirste feststellen, dass von Adressen 
die Rede ist, nicht aber von Adressen im physikalischen Speicher, ROM, 
RAM, EEPROM, Festplatte oder sonstwo. Der Compiler ganz allein kann sich 
aussuchen, wie er seine Zeiger auf physischen Speicher abbildet und 
wieso und warum.

Natürlich fasst man Zeiger als Adressen auf, aber nicht als 
physikalische Adresse in zu DRAM-Baustein oder Register.
Zwei Zeiger in einem Computer können auch denselben Inhalt haben (oder 
meinethalten zum selben int-Wert kommen, wenn man sie als int 
interpretiert), d.h. auf die gleiche 'Adresse' verweisen und trotzdem 
sind zwei völlig verschiedene Objekte gemeint. Deshalb kann man Zeiger 
z.B. auch nicht ohne Weiteres zwischen zwei Prozessen austauschen.

> Ohne diese offizielle Erlaubnis, Integers durch Casts als konstante Ad-
> ressen zu interpretieren und dann als Zeiger für Zugriffe auf Speicher-
> zellen oder I/O-Register zu verwenden, wären bspw. sämtliche io*.h-Da-
> teien der AVR-LibC "böse".
Die sind nicht böse, sondern funktionieren zunächst einzig und alleine 
mit dem Compiler, für die sie entworfen wurden. Dass die 
Integer-Interpretation eines Zeigers beim avr-gcc ziemlich direkt mit 
der Adresse im SRAM/Registerfile übereinstimmt, haben die 
(avr-)gcc-Leute so eingerichtet.

Auf einer PC-Architektur würde das Prinzip schon nicht mehr aufgehen, da 
mindestens eine MMU die 'Adressen' verbiegen und sonstwo einblenden 
kann.

Wie ich bereits sagte: Die Abbildungsfunktion vom Zeiger zum Integer ist 
eine völlig unbestimmte. Kann linear sein, oder halt auch nicht.


Vielleicht missverstehen wir uns auch einfach dabei, was eine 'Adresse' 
ist ;-)
Ich fasse Zeiger auch als Adressen auf, aber ich mache keine Annahmen 
darüber, wo ich denn im RAM/... gelandet bin. Das verbietet 
beispielsweise eine Reihe von 'Sauereien', wie etwa Structs und Unions, 
um an einzelne Bytes von Datenworten zu kommen und so weiter.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Wenn du den Standard genau liest, wirste feststellen, dass von Adressen
> die Rede ist, nicht aber von Adressen im physikalischen Speicher, ROM,
> RAM, EEPROM, Festplatte oder sonstwo.

Wenn du deine eigene Aussage von weiter oben

> Zeiger in C sind keine Adressen und sind es auch nie gewesen. Zeiger
> sind Zeiger. Punkt.

genau liest, wirste feststellen, dass von Adressen die Rede ist, nicht
aber von Adressen im physikalischen Speicher, ROM, RAM, EEPROM,
Festplatte oder sonstwo. ;-) SCNR

> Vielleicht missverstehen wir uns auch einfach dabei, was eine
> 'Adresse' ist ;-)

In diesem Kontext, wo es um Programmiersprachen geht, beziehe ich auf
Adressen innerhalb des Adressraums, in dem auch die in der jeweiligen
Sprache programmierte Anwendung läuft. Und genau als solche werden
Zeiger und Referenzen üblichweise implementiert.

Dass es auf ganz anderen Hardware-/Softwareebenen auch ganz andere
Adressräume gibt, ist schon klar, aber davon sieht das Programm
(zumindest auf direktem Weg) normalerweise nichts.

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Falls ihr es gemerkt habt, eure Debatte über all die vielen 
Programmiersprachen deren flacher Speicher enlose Verkettung von 
Pointern erzeugt hat den Threadersteller mittlerweile Wortlos gemacht 
und ihr diskutiert mittlerweile eure Votrlieben aus, ohne auf den 
Hintergrund zu achten. Da ist eine Klasse von Schülern, deren Interesse 
für µC und PC Programmierung sinnvoll angeregt werden. Warum nicht mit 
Delphi(Pascal) auf PC, nur weil's da eine IDE gibt, die schnelle 
Ergebnisse bringt. Welcher Dummkopf wird seinen Schülern erzählen, das 
man den Code der IDE mal eben löschen kann oder eine UNIT mal eben 
umtaufen darf? Also versetzt euch doch  bitte mal von eurem hohen 
Programmiererroß auf die Stufe eines Lehrers, der von all den Dingen, 
die hier angesprochen werden vermutlich zu 80% Bahnhof versteht. Soll er 
nun das Handtuch werfen, weil mittlerweile sein Wissen um mindestens 10 
Programmiersprachen gewachsen ist und deren Einsatz in ach so herrlichen 
0815 Anwendungen unentbehrlich ist? Also, zurück zum Thema auf der BAsis 
der Schüler:
Welche Programmiersprache ist ohne teure Lizenz zu bekommen und wie 
verständlich kann ein Lehrkörper damit umgehen.
Wie werden µC eingesetzt und wie kann ich ein Projekt aufziehen, an 
welchem alle Schüler Interesse haben und nicht nur ein paar blinkende 
LED's sehen.
Danach solltet ihr die Programmiersprache auswählen! Nicht jeder Schüler 
wird ein Kollege von euch werden. Manche, weil sie feststellen das zum 
Programmieren eine spezielle Denkweise gehört und sie besser 
fußballspielen können. Andere werden vermutlich Doktoren, Physiker, 
Mathematiker oder Chemiker, vielleicht Lehrer oder auch "nur" Lokführer. 
Wenn ich geschrieben habe, Basic oder  Pascal halte ich für keine gute 
Einstiegssprache, bezog sich das auf µC. Wer meine Texte liest, erkennt 
sehr schnell, das es auch noch PC's gibt, die ich heut nur in krassen 
Sonderfällen mit Assembler traktieren würde. Wer sich für ein Studium 
zum Programmierer entscheidet, erlernt sicherlich mehr als nur C,Basic 
und Pascal und er wird wissen, welche Sprache für welche 
Anwendungssoftware Schwerpunkt ist. Dies hier zu diskutieren ist 
schlichtweg "Thema verfehlt"
Gruß oldmax

Autor: Martin Vogel (oldmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für die Tastenpreller und die breiten Finger, aber da ich mich 
nicht angemeldet hatte, kann ich's nicht korrigieren.
Gruß oldmax

Autor: Gast XIV (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf diesen uralt Thread noch mal meine Meinung.

Um eine Computersprache zu lernen ist keine geeignet.

Schon die Prämissen sind so intuitiv wie die Minkowski Diagramme zur 
speziellen Relativitätstheorie.

Es geht damit los das es eine Anweisungsliste gibt die mit dem was die 
Kiste letzlich macht nichts zu tun hat.

Diese ist angefüllt mit kryptischen wortähnlichen Buchstabenfolgen. Im 
Fall von C kommen noch aberwitzige Sonderzeichen wie {} dazu die auch 
noch exakt an den notwendigen Positionen stehen müssen weil ein 
"compiler" - schon dieses Konstrukt zu begreifen heißt für einen 
unbescholtenen Bürger erstmal 3 Wochen Lernarbeit- sonst zu blöd ist die 
simpelste Textfolge überhaupt auf einem "Schirm" - noch so eine 
aberwitzige Definition - zu "Printen" was ein Normalbürger nun mal mit 
Weihnachtsgebäck assoziiert und nicht mit irgendwas wo der 
betriebsblinde Progger davon ausgeht der Rest der Welt davon schon mal 
gehört hätte.

Von Interaktion hat auch noch keines dieser dubiosen Systeme etwas 
gehört. Ein 10 Print "Hello World" macht selbst wenn alles richtig 
geschrieben ist absolut gar nichts. Man muss das ganze mit "Run" F5 
sonstwas starten um mit ein wenig Glück in irgendeinem anderen Fenster 
etwas zu sehen.

Bis dahin hat der studierende natürlich den nächsten Kram zu lernen der 
mit der eigentlichen Zeile nichts mehr zu tun hat.

Er muss erstmal für ihn sinnlose Konstrukte lernen um einfachste 
Zusammenhänge erstmal zu sehen. Die sog. Einstiegsschwelle  auf die Otto 
Normalprogger auch noch stolz ist da er ja so toll war das ganze zu 
überwinden. Das ist zwar für das Ego Klasse hat aber bestenfalls mit 
wilhelminischer kuk Pädagogik, aber nichts mit Lehrmethoden des Jahres 
2000+ zu tun.

Ein System wo links die Anweisung und rechts das Ergebnis erscheint ist 
mir nicht bekannt. Wäre so etwas aber nicht aber didaktisch um Längen 
besser als der ganze Krampf mit dem die Proggerwelt den Einstieg unnötig 
erschwert?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast XIV schrieb:
> Er muss erstmal für ihn sinnlose Konstrukte lernen um einfachste
> Zusammenhänge erstmal zu sehen.
Hm, deine sinnlosen Konstrukte bilden die Grundlage jeglicher 
Algorithmik. Was sollte man denn anstelle dieser besser lehren? Wie man 
Klicki-Bunti-Spiele programmiert?
Ich muss dann unweigerlich an Klippert-Training denken... da dachte man 
auch, das würde die Lernmethodik seit je her revolutionieren.

Das führt dann zu den 80% Abbrecherquote der Informatikstudiengänge: 
Script-Kiddies, die ein bisschen HTML, Java, CSS können und glauben, 
damit programmieren zu können. Script-Kiddies, die dann auf die Schnauze 
fallen, wenn sie ein Semester lang Lineare Algebra pauken müssen. 
Lineare Algebra dürfte so ziemlich das unanschaulichste Gebiet der 
Mathematik überhaupt sein...

Man muss halt unterscheiden, ob man den Schülern etwas über Informatik 
beibringen kann und will, oder nur schnell irgendwelche Ergebnisse 
erzielen möchte. Informatik besteht halt zum größten Teil nicht aus 
bunten Bildchen und schnellen 3D-Animationen, sondern aus Algorithmen 
und Datenstrukturen.
Entweder man macht Informatik und vermittelt die Grundlagen davon, oder 
man macht eine Spielecke auf und schwimmt irgendwo an der Oberfläche 
herum.

Und ja, wenn Interesse da ist (und das ist durchaus hinzukriegen, wenn 
man obiges gescheit vermittelt), lassen sich diese sinnlosen Konstrukte 
in ein paar Unterrichtsstunden abhandeln.
Es steckt mehr hinter Informatik, als ein paar blöde Ballerspielchen 
zusammenzuklicken. Zur Informatik gehört systematisches und generisches 
Denken, das kann man auch an anderen Stellen immer wieder gebrauchen.

Und kein Lehrer bringt seinen Schülern bei, den automatischen Quelltext 
der IDE zu verunstalten. Braucht er auch garnicht, es passiert einfach. 
Schüler sind neugierig (sollten neugierig sein) und sollten erforschen 
und probieren, was auch wichtig ist. Da ist aber eine IDE (etwa die 
Delphi-IDE) nur hinderlich, bei der man viel zu viel Vorwissen braucht, 
um ein zerschossenes Projekt wieder mit der IDE verträglich zu machen.
Been there, done that. Sowohl als Schüler als auch als Lehrer.

Autor: Interessierter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Falls ihr es gemerkt habt, eure Debatte über all die vielen
> Programmiersprachen deren flacher Speicher enlose Verkettung von
> Pointern erzeugt hat den Threadersteller mittlerweile Wortlos gemacht
> und ihr diskutiert mittlerweile eure Votrlieben aus, ohne auf den
> Hintergrund zu achten.

Genau so ist das.

Deswegen schrieb ich auch:

Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt. Das
ist alles, mehr braucht man dazu nicht zu sagen.

darauf hin schrieb Oliver B. (ickbineeenberliner)

> Dazu kann man sagen, daß wenn man den Pointer dereferenziert,
> das Programm in nicht-definierte Zustände kommen kann,
> weil man z.B. einen ungültigen Pointer hat und auf nicht erlaubten
> Speicherbereich zugreift, oder einen NULL-Pointer dereferenziert.

Oliver, du beschreibst was man mit einem POINTER = ZEIGER machen kann, 
aber nicht was er oder es ist. Was man damit machen kann, darüber kann 
man sich lange auslassen.

Und dann kam der schlaue Sven P. (haku) mit seiner Dedinition über 
Zeiger

> Ein Zeiger zeigt auf ein Objekt.

Wamit er eine Erklärung mit einem neuen zu erklärenden Begriff abzugeben 
versuchte, was gleich völlig zur Verwirrung führt, weil das nämlich die 
nächste Debatte eröffnet: Was ist ein Objekt?

Also auch diese Erklärung ist untauglich.

Dann hat es dem yalu (Gast) dessen Postings ich schätze gereicht und er 
kam mit seiner Definition, zuerst aber seine Kritik:

> Das ist genau der Typ von Definition, der das Lernen von Programmier-
> sprachen manchmal so schwer macht ;-)

> Die andere, nicht selbstreferenzierende "Definition": Ein Zeiger bedarf
> keiner Definition, er ist einfach da.

> Beide Varianten findet man in ähnlicher Form tatsächlich in Lehrbüchern.
> Ich frage mich nur, was das soll.

Richtig! Das frage ich mich auch. Aber nun zu yalu's Versuch einer 
Definition:

> Irgendwann fiel es mir wie Schuppen
> von den Augen: Diese obskuren Zeiger sind ja nichts anderes als die
> Speicheradressen der Daten, auf die sie zeigen.

Ja, that's it. Damit erkläre ich mich sofort solidarisch. Yalu, you made 
my day!

"Zeiger sind ja nichts anderes als die
 Speicheradressen der Daten, auf die sie zeigen."

Meine Definition war

Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt.

Und damit Sven P. (haku) mir jetzt nicht auf's Dach steigt gilt 
natürlich auch folgendes:

Selbstverständlich kann sich an der Speicheradresse auf die der Zeiger 
zeigt auch statt einer einfachen Variablen (so würde man den Zeiger im 
Lehrbuch beginnen zu erklären) eine ganze Struktur befinden, oder ein 
komplizierteres Konstrukt wie ein Objekt. Auch kann der Zeiger auf eine 
Funktion zeigen oder sonst irgend ein Gebilde. Der Speicherbereich auf 
den der Zeiger deutet muss auch gar nicht im RAM liegen, sondern kann 
auch unveränderbar im ROM liegen usw. Man kann auch viel mit dem Pointer 
= Zeiger machen. Man kann ihn inkrementieren (also seine Adresse 
erhöhen), dekrementieren (die Adresse erniedrigen), man kann richtige 
Rechenspielchen mit dem Zeiger veranstalten und ihm auch falls es Sinn 
macht in beliebige (hoffentlich dann passende ;)) Typen umwandeln (per 
type casting je nach Programmiersprache zulässig oder auch nicht). All 
das (und noch mehr) kann man mit dem Zeiger machen, aber der Zeiger 
bleibt letzlich immer eine 'Speicheradresse die auf einen 
Speicherbereich zeigt', egal wie man die Daten auf die er zeigt 
interpretiert.

Und wenn jetzt auch noch Andreas Schwarz dem hier Geschriebenen 
zustimmen kann, dann leben wir alle glücklich und zufrieden mit unseren 
mehr oder weniger ausgeprägten Programmierfähigkeiten (meine sind gerade 
mal wieder ein wenig eingerostet) und erfreuen uns an einem Stückchen 
funktionierenden Programmcodes wenn es denn funktioniert oder wundern 
uns darüber, wenn es bei der Ausführung zur unvorhergesehenen Ausnahme, 
dem Programmausnahmefehler (der sog. exception) kommt.

:)

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Oliver B.:

disqualifizierst du dich immer selber oder machen das auch mal andere 
für dich ? :-)


@ arc net:

nur weils so lustig ist: du kannst mir sichen den großartigen vorteil 
von sips erklären, oder? für alle anderen, m$ sieht ie revolution das so 
- und nein, es gibt darauf (noch) kein trivialpatent:

"SIPs differ from conventional operating system processes in other
ways. They cannot share writable memory with other SIPs; the
code within a SIP is sealed at execution time; and SIPs are
isolated by software verification, not hardware protection."

> Woher soll der Hersteller wissen, wie lang deine Interruptroutine braucht?
> Thread- und JVM-Wechsel werden über interne Hardwaretimer realisiert...

ja, aber ohne die angabe wie lange die contextwechsel der VM dauern ist 
das humbug. wenn da steht - zitat :

"Microprogrammed Real-Time Operating System (RTOS) kernel provides 
microsecond response to interrupts / context switches and direct 
implementation of Java threading primitives"

dann heißt das, dass der interrupthandler der vm n microsekunden zur 
reaktion auf einen interrupt braucht. das ist weder besonders toll noch 
trifft das irgedeine aussage darüber wann der contextwechsel vollzogen 
ist.



ach ja, meine shift-taste ist defekt ;-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, da kann ich mich anschließen.

Wobei ich noch zwei Nachträge zum Verständnis hätte:

(1)
Ein 'Objekt' (in C, laut K&R) ist etwas, das Speicher belegt, das hat 
nichts mit OOP zu tun. Auch ein int ist ein Objekt. Wurde aber bereits 
gesagt.

(2)
Ein Zeiger zeigt auf ein Objekt :-)
Das schließt ein, dass er nicht auf eine Funktion zeigt. In C ist es 
nicht erlaubt, zwischen Zeigern und Funktionszeigern zu konvertieren.
Beispielsweise ist folgendes verboten:
void *(funktionszeiger)(void);
void *zeiger;

funktionszeiger = zeiger;

U.a. führt das zu Problemen, etwa mit dlopen(). dlopen gibt einen Zeiger 
auf eine Funktion einer Bibliothek (als void *) zurück; blöderweise muss 
man den in einen Funktionszeiger umwandeln, was aber eben nicht erlaubt 
ist.
An diesem Problem forscht eine Arbeitsgruppe der Openstd schon eine 
ganze Weile :-]

Wieder ein Grund, warum Zeiger nicht (zwangsläufig) auf Adressen im 
physikalischen Speicher zeigen...

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Welche Programmiersprache für Schüler?

Plankalkül und nix anderes - oder soll die nächste Generation zu 
Warmduschern und Vorwärtseinparkern erzogen werden?

Beispiel (von Wikidingsda gemopst):

P1 max3 (V0[:8.0],V1[:8.0],V2[:8.0]) => R0[:8.0]
max(V0[:8.0],V1[:8.0]) => Z1[:8.0]
max(Z1[:8.0],V2[:8.0]) => R0[:8.0]
END
P2 max (V0[:8.0],V1[:8.0]) => R0[:8.0]
V0[:8.0] => Z1[:8.0]
(Z1[:8.0] < V1[:8.0]) -> V1[:8.0] => Z1[:8.0]
Z1[:8.0] => R0[:8.0]
END

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zwieblum schrieb:
> ach ja, meine shift-taste ist defekt ;-)

Dann schlage ich vor dass du sie reparierst bevor du deinen nächsten 
Beitrag schreibst.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zwieblum schrieb:
> @ Oliver B.:
>
> disqualifizierst du dich immer selber oder machen das auch mal andere
> für dich ? :-)
>
>
> @ arc net:
>
> nur weils so lustig ist: du kannst mir sichen den großartigen vorteil
> von sips erklären, oder? für alle anderen, m$ sieht ie revolution das so
> - und nein, es gibt darauf (noch) kein trivialpatent:
>
> "SIPs differ from conventional operating system processes in other
> ways. They cannot share writable memory with other SIPs; the
> code within a SIP is sealed at execution time; and SIPs are
> isolated by software verification, not hardware protection."

Was bedeutet wohl: "isolated by software verification"?
Richtig, die Fehler, die sonst so auftreten können, werden durch 
vorherige Verifikation ausgeschlossen (Singularity läßt auch das 
"normale" Vorgehen zu, falls man's braucht).
Das das nicht mit "normalen" Sprachen, wie C, geht, dürfte auch bekannt 
sein.
Welche Vorteile hat das nun?
U.a. müssen keine illegalen Speicherzugriffe abgefangen werden,
es müssen keine MMU-Tabellen verändert werden, keine TLB-Flushs,
es braucht keine Call-Gates (früher harte Interrupts mit allem was dazu 
gehört, heute die etwas schnelleren sysenter/syscall-Befehle), weniger 
Overhead bei der Interprozesskommunikation, u.a. weniger bzw. keine 
Parameterüberprüfungen etc. pp.

>> Woher soll der Hersteller wissen, wie lang deine Interruptroutine braucht?
>> Thread- und JVM-Wechsel werden über interne Hardwaretimer realisiert...
>
> ja, aber ohne die angabe wie lange die contextwechsel der VM dauern ist
> das humbug. wenn da steht - zitat :
>
> "Microprogrammed Real-Time Operating System (RTOS) kernel provides
> microsecond response to interrupts / context switches and direct
> implementation of Java threading primitives"
>
> dann heißt das, dass der interrupthandler der vm n microsekunden zur
> reaktion auf einen interrupt braucht. das ist weder besonders toll noch
> trifft das irgedeine aussage darüber wann der contextwechsel vollzogen
> ist.

Kontextwechsel innerhalb von 1 us, Stichworte: stackbasierter Bytecode 
vs. Registerarchitektur, MMU, etc. einfach mal ins Datenblatt schauen 
und selber testen...

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Arc Net (arc):

Die ganze Magie reduziert sich auf automatisches Beweisen der 
Korrektheit eines Programmes. Dass das nicht geht dürfte bekannt sein. 
Die Sprache, die verwendet wird, ist dabei irrelevant, sofern sie 
Turing-complete ist.

Das Ding von Ajile ist ein Java-Prozessor, nicht mehr nicht weniger. Ich 
weiß nicht wo du ein Datenblatt mit Timings gefunden hast, auf der 
Hompage des Herstellers habe ich jedenfalls keines gefunden. Jedenfalls 
verhindert der nicht, dass dein Code Mist baut.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.