Studie zeigt C als beliebteste Sprache in offenen Projekten

volkard

;fricky schrieb:

stimmt schon teilweise, aber wenn einer mit wenig hirnkapazität einen grossen teil davon für die korrekte umsetzung von irgendwas in c++ programme verwenden muss, ist das auch doof.

genausodoof wie, wenn einer mit viel hirnkapazität einen großen teil davon brach liegen lassen muß, weil C keine gescheiten ausdrucksmöglichkeiten bietet.

sagen wir mal, daß man mikrocode für toaster nicht in C++ machen sollte und daß man ein textverarbeitungssystem nicht in C machen sollte.

volkard schrieb:

sagen wir mal, daß man mikrocode für toaster nicht in C++ machen sollte und daß man ein textverarbeitungssystem nicht in C machen sollte.

Es kommt auch stark darauf an, welche Konventionen man verinnerlicht hat. Ich meine, es ist ja möglich nur durch Templates aus C ein C++-Artiges Teil zu machen. Oder das ganze händisch umzusetzen. Was ich sagen will: Die Ausdrucksstärke eine Programmiersprache ist nur zum Teil durch die Syntax gegeben. Die geltenden Programmierparadigmen und -Normen sind da mindestens ebenso wichtig. Und genau so wie es möglich ist, in LISP irgendwas auf eine Liste zu packen, wo sich der Java-Programmierer nur denkt "lol OMG, was issen diese Liste hiernochmal wtf?" während der LISPer über die n-fach verschachtelte Templateklasse aufregt, die er in drei Zeilen Makro elegant geschrieben hätte. Für einen Kollegen aus derselben Sparte ist das aber normal, weil er das schon mindestens 1000 Mal gesehen wenn nicht selbst gemacht hat.

Erhard Henkes

..

volkard schrieb:

genausodoof wie, wenn einer mit viel hirnkapazität einen großen teil davon brach liegen lassen muß, weil C keine gescheiten ausdrucksmöglichkeiten bietet.

naja, aber C für alles nehmen will ja hier auch keiner.

volkard schrieb:

sagen wir mal, daß man mikrocode für toaster nicht in C++ machen sollte

hast recht, obwohl es auch da was gibt: http://en.wikipedia.org/wiki/SystemC
aber benutzen sollte man sowas besser nicht (ausser zum spass vielleicht), weil schon genügend andere sprachen+libraries dafür vorhanden sind, die sich vielfach bewährt haben, auch objektorientierte und so.

Erhard Henkes

Die Grundidee der OOP ist die Kapselung und das Abstrahieren von Objekten auf Klassen. An den Stellen, an denen das wirklich Sinn macht, also nicht künstlich aufgesetzt ist, ist eine Sprache, die vom Grundprinzip auf OOP abzielt, evtl. sinnvoll einsetzbar. Ein wichtiges Argument in der Grauzone ist die fehlerfreie Les- und Wartbarkeit. Die Schreibarbeit in C++ ist deutlich höher. Dafür erhält man gute Strukturen mit Methoden, sprich Klassen.

DEvent

Erhard Henkes schrieb:

Die Grundidee der OOP ist die Kapselung und das Abstrahieren von Objekten auf Klassen. An den Stellen, an denen das wirklich Sinn macht, also nicht künstlich aufgesetzt ist, ist eine Sprache, die vom Grundprinzip auf OOP abzielt, evtl. sinnvoll einsetzbar. Ein wichtiges Argument in der Grauzone ist die fehlerfreie Les- und Wartbarkeit. Die Schreibarbeit in C++ ist deutlich höher. Dafür erhält man gute Strukturen mit Methoden, sprich Klassen.

IMHO ist die Grundidee von OOP, Code und Daten als ein ganzes "Objekt" zu betrachten, und diese Objekte koennen untereinander genau definierte Nachrichten austauschen. Daraus folgt Kapselung und Polymorphie. Klassen sind nur ein Hilfskonstrukt.

Wieso ist C++ eine "gute" Struktur, wenn man alle Member einer Klasse, egal ob public, private oder protected, im Interface Teil angeben muss? Wieso ist es "gut" wenn man etwas am privaten Teil der Klasse veraendern, den gesammten Client-Code nochmal uebersetzen muss? Der Sinn von OOP ist doch ueberhaupt der, dass man, ohne das die Clients auch nur das geringste mitbekommen, den private-Teil des Codes beliebig veraendern kann. Nur wenn das oeffentliche Interface veraendert wurde, muss man die Clients anpassen.

rüdiger

Wo ist der Sinn von solchen Studien? (Zumal die Messmethoden und Datensätze ja oft sehr fragwürdig sind.)

DEvent schrieb:

und diese Objekte koennen untereinander genau definierte Nachrichten austauschen. Daraus folgt Kapselung und Polymorphie. Klassen sind nur ein Hilfskonstrukt.

Schön, dass Du zu dieser Erkenntnis gekommen bist. Kann sein, dass ich mich täusche. Aber iirc gab es da mal einen ewig langen Flamewar, wo Du eine deutlich andere Meinung hattest.

DEvent schrieb:

Wieso ist C++ eine "gute" Struktur, wenn man alle Member einer Klasse, egal ob public, private oder protected, im Interface Teil angeben muss?

Muss man nicht. Siehe PIMPL-Idiom.

volkard

DEvent schrieb:

Wieso ist C++ eine "gute" Struktur, wenn man alle Member einer Klasse, egal ob public, private oder protected, im Interface Teil angeben muss?

Das ordentliche Aufteilen und Zerlegen in Klassen, hat doch nichts mit information hiding zu tun. Der Laden wäre genauso hübsch objektorientiert, wenn alles public wäre. Verstecken ist völlig irrelevant.

Wieso ist es "gut" wenn man etwas am privaten Teil der Klasse veraendern, den gesammten Client-Code nochmal uebersetzen muss?

Das ist nicht gut, aber ist auch nur ein unwichtiges Detail.

Der Sinn von OOP ist doch ueberhaupt der, dass man, ohne das die Clients auch nur das geringste mitbekommen, den private-Teil des Codes beliebig veraendern kann. Nur wenn das oeffentliche Interface veraendert wurde, muss man die Clients anpassen.

Das ist ja auch der Fall. Für den Programmierer. Wie das Übersetzungsmodell innendrin ist, geht Dich doch gar nichts an.

volkard schrieb:

Das ordentliche Aufteilen und Zerlegen in Klassen, hat doch nichts mit information hiding zu tun.

"information hiding" in Form von Trennung zwischen (innerer) Repräsentation und (äußerem) Verhalten ist Grundbedingung für Polymorphismus. Alles Andere würde auch dem "message passing" Prinzip widersprechen.

Dies spielt in C++ eine untergeordnete Rolle, schon weil sauberes "message passing" mit seinem Korollar "alles ist ein Objekt" für C++ in unerreichbarer Ferne liegt, aber daß C++ hinsichtlich Paradigmenreinheit/OOP nicht die Maßstäbe setzt, sollte ohnehin klar sein.

volkard

Für Polymorphismus ist diese Trennung zwar nötig, aber Hiding ist nicht nötig.
Der Rest war unbegründetes Ablästern und bedarf keiner Widerlegung.

u-ser_l schrieb:

...schon weil sauberes "message passing" mit seinem Korollar "alles ist ein Objekt" für C++ in unerreichbarer Ferne liegt...

streng genommen könnte man jedes sprache, die message passing mit methodenaufrufen macht, als 'unsauber' ansehen, weil's nur ein 'gosub' in eine prozedur des anderen objekts ist. stell dir vor, du unterhältst dich mit jemanden und während du auf seine reaktion wartest, frierst du ein. sogar herzschlag und atmung stehen still.

object-message-passing sollte eigentlich mal eine stark vereinfachte Nachbildung menschlicher Kommunikation sein - direkte Ansprache mit Subjekt-Imperativ-Objekt-Sätzen:

Hans sage 'hallo'

mit object-message-passing-Syntax:

Hans sage: 'hallo'

mit Methoden-Syntax:

Hans.sage('hallo')

Die Idee ist ursprünglich gewesen, daß es zur Kommunikation Mensch/Computer zwei Wege gibt:

a. Mensch paßt seine natürliche Kommunikationsweise dem Computer an

b. Man läßt den Computer seine Kommunikationsweise dem Menschen anpassen

Um nicht mio. Jahre warten zu müssen, daß sich a. entwickelt, entschied man sich bei der Entwicklung der OOP für Plan b.

Aus dem object-message-passing folgen dann die weiteren notwendigen Eigenschaften der OOP wie Polymorphie, information hiding usw.

u-ser_l schrieb:

mit object-message-passing-Syntax:
Hans sage: 'hallo'
mit Methoden-Syntax:
Hans.sage('hallo')

^^syntax ist doch ziemlich egal, mir gehts um die beiden varianten synchrones und asynchrones message passing. ersteres sind einfache 'gosubs' und damit statisch und single-CPU-bezogen, können direkt zu maschinencode gemacht werden usw. der asynchrone fall braucht ein laufzeitsystem, objekte sind prozesse und haben eine message-queue. (siehe z.b. sowas wie erlang). sowas finde ich 'natürlicher' als diese methoden-aufruferei. zudem haste damit automatisch unterstützung für multiprozessorsysteme (solche faxen wie OpenMP für C++ sind von vorn herein überflüssig), multitasking-probleme wie race conditions schon auf unterster ebene erscheinen garnicht erst, weil's durch die message-queues entkoppelt ist, usw. wie machts smalltalk eigentlich? synchron oder asynchron?

u-ser_l schrieb:

Aus dem object-message-passing folgen dann die weiteren notwendigen Eigenschaften der OOP wie Polymorphie, information hiding usw.

polymorphie folgt nicht daraus. polymorphie entspringt doch der komponenten-orientierten programmierung. oder nicht?

Polymorphie folgt insofern aus obj.-mess'g.-passing, als: ein und dieselbe message kann je nach Klasse des Empfängers verschiedene Bedeutungen haben, sprich: Polymorphie in Form von überladenen Nachrichten bzw Operatoren (= Spezialfall von Nachrichten beim object-mess'g-passing)

@(A)synchronität: message passing ist (zumindest beim klassischen Smalltalk-80) synchron. Es gibt gewisse Steuerungsmöglichkeiten, indem man Blocks verschickt - ein Block wird ja erst in dem Moment ausgewertet, wenn er nachrichten wie value oder value: ... empfängt.

Ich meine gelesen zu haben, daß frühe evtl experimentelle Smalltalk-Versionen vor 80 auf asynchrones message passing aufgebaut waren, kann das aber momentan nicht nachprüfen.

Die flexibelste Sprache ist und bleibt (Common) Lisp:

(loop for i from 1 to 10 sum i) ===> 55

(loop for i from 1 to 10 collect i) ===> (1 2 3 4 5 6 7 8 9 10)

Welche andere Sprache bietet einem schon die Möglichkeit eine DSL so schön zu implementieren?

Smalltalk!

(1 to: 10) inject: 0 into: [ :sum :item | sum  + item ].  
    =>  55
(1 to: 10) collect: [ :item ].   
    =>  #(1 2 3 4 5 6 7 8 9 10)

aber die lisp-Versionen sind auch ganz schön ...

u-ser_l schrieb:

Smalltalk!

(1 to: 10) inject: 0 into: [ :sum :item | sum  + item ].  
    =>  55
(1 to: 10) collect: [ :item ].   
    =>  #(1 2 3 4 5 6 7 8 9 10)

aber die lisp-Versionen sind auch ganz schön ...

Das ist doch total kryptisch, da sehe ich jetzt keinen Vorteil gegenüber der LISP-Notation (also der Lisp-Syntax und nicht der DSL von loop).

ich formulier's mal um, damit es dem Lisp-Beispiel ähnlicher wird:

(1 to: 10) inject: 0 into: [ :s :i | s + i ].  
(1 to: 10) collect: [ :i ].

was ist daran kryptisch ? Das ist schön und elegant.

außerdem ist es in Smalltalk kürzer:

(loop for i from 1 to 10 sum i) 
(loop for i from 1 to 10 collect i) 
=> 18 Wörter 

(1 to: 10) inject: 0 into: [ :s :i | s + i ].  
(1 to: 10) collect: [ :i ].   
=> 16 Wörter

volkard

u-ser_l schrieb:

ich formulier's mal um, damit es dem Lisp-Beispiel ähnlicher wird:
(1 to: 10) inject: 0 into: [ :s :i | s + i ].  
(1 to: 10) collect: [ :i ].
was ist daran kryptisch ? Das ist schön und elegant.

das ist verdammt schön und elegant. ich hatte mich deshalb damals auch sofort in smalltalk verliebt.