Verleitet C++ zum komplizierteren denken?

[fffffffffffff]

Dravere schrieb:

Tachyon schrieb:

Was bringt die "Diskussion"?

Nichts, es gibt höchstens ein paar Leute, welche sich einfach nicht verkneifen können, auf die sau dummen Kommentare von fricky zu antworten.
Lasst fricky seinen Unsinn in die Welt brüllen. Jeder mit ein wenig Grips erkennt dass er völlig fanatisch argumentiert mit völlig falschen Argumenten. Wer das nicht erkennt, den wollen wir im C++ Bereich gar nicht haben. Also was solls?

Ich schliesse mich allerdings Artchi an:
C ist die beste Sprache der Welt! Heil C!

Grüssli

Vielleicht hat auch fricky Recht. Wer weiss, wer weiss....

[Dravere]

fffffffffffff schrieb:

Vielleicht hat auch fricky Recht. Wer weiss, wer weiss....

Ich bin Schweizer. In meinem Land herrscht die Glaubensfreiheit. Daher wenn jemand einem fanatischen fundamentalistischen Führer folgen will, dann soll dieser halt mit in den Glaubenskrieg ziehen. Er soll nur mich damit in Ruhe lassen.
Ich programmiere in vielen Religionen ... eh Programmiersprachen. Ich habe gewisse, welche ich bevorzuge, deswegen werde ich aber nicht andere einfach ohne sinnvolle Argumente verteufeln. Und dabei hätte es bei C++ so verdammt gute Argumente, aber fricky kennt halt kein C++ ...

Heil C!

Grüssli

[;fricky]

asc schrieb:

;fricky schrieb:

...gegenbeispiel: ein betreiber von riesigen baggern und mobilen 'outdoor-bohrmaschinen' wollte seine monstergeräte mit 'ner messdatenerfassung ausrüsten, die dann jeden tag einmal die daten per email an einen server schickt. wir schlugen denen vor: ...keine mechanischen teile, ist wetterbeständig,... wollten sie aber nicht ...

...sie haben in ihren Kontext die falsche Entscheidung getroffen.

ja, haben sie. leider betreffen falsche entscheidungen nicht nur hardware, sondern oft auch software, oder die wahl der programmiersprache (c++ statt C, c++ statt ADA, c++ statt Java, C++ statt C#, c++ statt 'ner scriptsprache wie perl, python, PHP, c++ statt <beliebige sprache hier einsetzen>) und vieles mehr.

Tachyon schrieb:

...Diskussion bringt hier eh nichts und Argumente sind ebenfalls nur Perlen vor die Säue geworfen.

finde ich nicht. es geht doch hier nicht darum andere zu überzeugen (mir jedenfalls nicht), sondern andere sichtweisen kennenzulernen. auch das gefecht von u_ser_1 und volkard, wie nun eine optimale oop-lösung usw. aussehen soll, ist doch interessant, oder nicht?

@pointercrash():
SPSn finde ich garnicht so doof. wo früher der elektriker seine schützschaltungen mit dicken drähten 'programmierte', hackt er heute seine stromlaufpläne in die SPS rein. die dinger haben schon ihre berechtigung. programmierung (die übrigens weit davon entfernt ist, zu kompliziertem denken zu verleiten) und installation sind halt auf's 'grobe' fachpersonal zurechtgeschnitten. sie sind ausbaufähig, echtzeitfähig, extrem haltbar usw. das passt schon alles.

[Tachyon]

;fricky schrieb:

finde ich nicht. es geht doch hier nicht darum andere zu überzeugen (mir jedenfalls nicht), sondern andere sichtweisen kennenzulernen.

Tja, zu doof, daß Scheuklappen die Sichtweise so einschränken, gelle?

[Gast]

pointercrash() schrieb:

Tim schrieb:

pointercrash() schrieb:

Das Zeug muß 24/7 funktionieren und das tut es, auch wenn das Grundkonzept pure Prozessorbeschäftigungstherapie ist.

Welches Grundkonzept denn nun?

Hast keine Lust mehr, zu googeln?

Vielmehr kann ich via google nicht herausfinden was genau du mit "Grundkonzept" meinst, "visuelles Softwaredesigntool" oder "SPS" oder was auch immer. Aber lassen wir das....

[;fricky]

Tachyon schrieb:

;fricky schrieb:

finde ich nicht. es geht doch hier nicht darum andere zu überzeugen (mir jedenfalls nicht), sondern andere sichtweisen kennenzulernen.

Tja, zu doof, daß Scheuklappen die Sichtweise so einschränken, gelle?

naja, das ist nun mal so, manche scheint ein thread wie dieser irgendwie emotional zu treffen. ist für einige vielleicht auch schmerzlich, mitzubekommen, wie die programmiersprache, in die man viel zeit und gehirnschmalz investiert hat, so respektlos niedergemacht wird. das sorgt wohl für die grössten scheuklappen. aber trotzdem glaub ich, dass selbst beim grössten smalltalk-, c++, c-, usw-fanboy irgendwas von dem hängen bleibt, was die anderen hier erzählen. es muss ja nicht dazu führen, dass er sich von seiner liebblingssprache verabschiedet, sondern dass er irgendwas besser/anders macht (z.b. versucht unnötigen kompliziertheiten aus dem weg zu gehen, siehe threadtitel), oder zumindest mal darüber nachdenkt.

[u_ser-l]

volkard schrieb:

Nur eine Verschiebung. Wie erzeugst Du aus zwei Elementen das passende Paar?

du denkst jetzt sicher, die Klasse des zu (aDrawElement1, aDrawElement2) zu erzeugenden Paarelements müßte so bestimmt werden:

(aDrawElement1 isMemberOf: Polar) 
	ifTrue: [ ... ]
	ifFalse: [ ... ]

das wäre möglich, wäre aber nur eine Verschiebung der 'Typweiche', da hast du recht.

In Smalltalk geht aber auch das folgende:

class1st _ aDrawElement1 class.                 "erstes Element eines Paares"
class2nd _ aDrawElement2 class.                 "zweites ...  "

pairClassName _ 'Pair' , class1st , class2nd.   "String-Konkatenation"

pairElement _ pairClassName new.

"Beispiel: falls

	class1st = 'Line'
	class2nd = 'Polar'

	=> pairClassName wird gesetzt auf: 'PairLinePolar'

	und 

	pairElement _ pairClassName new. 

	erzeugt ein Objekt dieser Klasse."

so werden die Elemente des herzustellenden Paar-Arrays automatisch Objekte des richtigen Paar-Typs sein.

[u_ser-l]

der Unterstrich bedeutet übrigens

:=

[volkard]

u_ser-l schrieb:

der Unterstrich bedeutet übrigens

:=

Und was bedeutet

:=

?

[Zeus]

pairElement _ pairClassName new.

=

pairElement := pairClassName new.

[volkard]

u_ser-l schrieb:

pairClassName := 'Pair' , class1st , class2nd.   "String-Konkatenation"
pairElement := pairClassName new.

Jo, das ist ganz hübsch und fühlt sich für Smalltalk irgendwie "gut" an.

[pointercrash**]

Tim schrieb:

pointercrash() schrieb:

Tim schrieb:

pointercrash() schrieb:

Das Zeug muß 24/7 funktionieren und das tut es, auch wenn das Grundkonzept pure Prozessorbeschäftigungstherapie ist.

Welches Grundkonzept denn nun?

Hast keine Lust mehr, zu googeln?

Vielmehr kann ich via google nicht herausfinden was genau du mit "Grundkonzept" meinst, "visuelles Softwaredesigntool" oder "SPS" oder was auch immer. Aber lassen wir das....

Und was ist mit Lesen? Bei einer zyklusbasierten SPS hast Du nur Polling mit einer Art if(..)- Verzweigung zur Verfügung, das ist das Grundkonzept. Bei neueren SPS kommt das ereignisbasierte Zeug dazu, das aber i.a.R an irgendein tolles Modul gebunden ist, in dem dann z.B. drei Timer drin sind. Die grafischen Konfigurationstools lassen ein System zusammenklicken und parametrieren.

;fricky schrieb:

@pointercrash():
SPSn finde ich garnicht so doof. wo früher der elektriker seine schützschaltungen mit dicken drähten 'programmierte', hackt er heute seine stromlaufpläne in die SPS rein. die dinger haben schon ihre berechtigung. programmierung (die übrigens weit davon entfernt ist, zu kompliziertem denken zu verleiten) und installation sind halt auf's 'grobe' fachpersonal zurechtgeschnitten. sie sind ausbaufähig, echtzeitfähig, extrem haltbar usw. das passt schon alles.

Ne, stimmt ja alles so nicht mehr. Dem Werkselektriker platzt der Kopf, wenn Du ihn mit nacktem Step-7- Code konfrontierst. Auch ich finde das nicht mehr lustig, wie man Ereignistrigger einstellt, weder direkt gecodet noch mit den Konfig- Tools. Oft genug stellst Du nach zwei, drei Stunden fest, daß Du genau das Ereignis, das Du brauchst, mit dem Modul nicht herstellen kannst. Tadaa, bettel' den Hersteller an, das reinzumachen.

Robust, ja das sind sie, ideal für Volltrottel, die einen Drehstromanschluß von einem Signalkabel nicht unterscheiden können. Ausbaufähig ja auch, problemlos mit voller Kasse. Echtzeitfähig aber nur in absolut beschämendem Rahmen im Vergleich zur "natürlichen" Power der darin verbauten Prozessoren.

Wer den Overhead von C++ bemäkelt, sollte sich wirklich überlegen, sich argumentativ vor das SPS- Konzept zu stellen.

Btw. Siemens hat ja so 96/97 seine erste Soft- SPS auf Basis von Win CE 1.0 als Revolution vorgestellt. Revolutionär daran war, daß es endlich auch SPSsen gab, die gnadenlos abstürzten. Ob letztlich WinCE dran Schuld war oder Siemens mit dem SPS- Teil danebengelangt hat, weiß ich nicht, ich weiß nur, daß ein Kunde die Dinger zwar getestet und dann "wegen massiver technischer Unsicherheit" den produktiven Einsatz untersagt hat.

[ohjemine]

Seite 35 schon! Ihr denkt schon wieder viel zu kompliziert. Das kommt sich vom vielen C++. :p

[u_ser-l]

volkard schrieb:

Jo, das ist ganz hübsch und fühlt sich für Smalltalk irgendwie "gut" an.

hier ein konkreter Beispielcode, der, so wie er da steht, direkt in einem Workspace ausführbar ist.
Mit der Vereinfachung, daß die vorhandenen Klassen 'ByteString' und 'SmallInteger' statt 'Polar' und 'Line' verwendet werden:

| a b l |

Object subclass: #PairSmallIntegerByteString
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: ''.

Object subclass: #PairSmallIntegerSmallInteger
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: ''.

Object subclass: #PairByteStringByteString
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: ''.

a := #( 1 'abc' 3 ).
b := #( 'xyz' 'def' 4 ).

l := Array new: 9.  

1 to: (a size) do: [ :i | 
	1 to: (b size) do: [ :j | 
		ca := a at: i.
		cb := b at: j.
		caS := (a at: i) class asString.
		cbS := (b at: j) class asString.
		cS := 'Pair' , caS , cbS.

		Transcript show: 'i = ' , i asString, ' j = ' , j asString , ' : ' , cS; cr.

		index := (i - 1) * (b size) + j.

		l at: index put: cS.

		"newObject := (Smalltalk at: cS asSymbol) new.
		l at: index put: newObject."

		" die auskommentierte Zeile setzt voraus, dass Klassen 
			PairByteStringSmallInteger usw.
			existieren ..."
		]	
	].

Transcript show: l asString; cr.

Ausgabe:

i = 1 j = 1 : PairSmallIntegerByteString
i = 1 j = 2 : PairSmallIntegerByteString
i = 1 j = 3 : PairSmallIntegerSmallInteger
i = 2 j = 1 : PairByteStringByteString
i = 2 j = 2 : PairByteStringByteString
i = 2 j = 3 : PairByteStringSmallInteger
i = 3 j = 1 : PairSmallIntegerByteString
i = 3 j = 2 : PairSmallIntegerByteString
i = 3 j = 3 : PairSmallIntegerSmallInteger

#('PairSmallIntegerByteString' 'PairSmallIntegerByteString' 'PairSmallIntegerSmallInteger' 'PairByteStringByteString' 'PairByteStringByteString' 'PairByteStringSmallInteger' 'PairSmallIntegerByteString' 'PairSmallIntegerByteString' 'PairSmallIntegerSmallInteger')

Der Clou befindet sich in den Zeilen

newObject := (Smalltalk at: cS asSymbol) new.
		l at: index put: newObject.

Hiermit wird zur Laufzeit zu einem variablen String cS ein Objekt erzeugt, das
derjenigen Klasse angehört, deren Name cS ist.

[knivil]

auch das gefecht von u_ser_1 und volkard, wie nun eine optimale oop-lösung usw. aussehen soll, ist doch interessant, oder nicht?

Um ehrlich zu sein ... nein.

[Schneewittchen]

Wieso? Dieser kryptische smalltalk code macht mich ganz wuschig.