Laden...

EBCs 2.0, deren Nähe zur prozeduralen Programmierung und deren Nutzen [inkl. Metadiskussion]

Erstellt von herbivore vor 13 Jahren Letzter Beitrag vor 13 Jahren 20.425 Views
Hinweis von winSharp93 vor 13 Jahren

Abgetrennt von EBCs in Informationssystemen (verteilt)

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 13 Jahren
EBCs 2.0, deren Nähe zur prozeduralen Programmierung und deren Nutzen [inkl. Metadiskussion]

Hallo serial,

Ich kann mich mit EBCs 2.0 allerdings überhaupt nicht anfreunden. Die prozedurale Programmierung, bei der - wie bei EBCs 2.0 - die Aktionen im Vordergrund stehen, haben wir mit Recht hinter uns gelassen.

herbivore

71 Beiträge seit 2010
vor 13 Jahren

@herbivore: Definiere doch mal "prozedurale Programmierung" und zeige dann, dass EBC 2.0 dem entspricht. Ich bin gespannt.

(Und ich meine "prozedurale" und nicht "funktionale" Programmierung. Denn den Begriff benutzt du ja bewusst.)

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 13 Jahren

Hallo ralfw,

ich habe nicht gesagt, dass EBC 2.0 der prozeduralen Programmierung entspricht. Ich habe nur gesagt, dass bei EBCs 2.0 genauso wie bei der prozeduralen Programmierung die Aktionen im Vordergrund stehen. Bei der Objektorientierung stehen dagegen die Klassen, Objekte und Daten im Vordergrund.

herbivore

71 Beiträge seit 2010
vor 13 Jahren

Hm... Wenn du sagst "wie bei der prozeduralen prog", dann ist da für mich schon eine starke Tendenz zur Gleichsetzung.

Aber warum hast du nicht mit der Funktionalen Prog verglichen?

Was ist deine Kritik? OOP und FP oder LP oder prozedural sind ja kein Selbstzweck. "nicht OOP" kann daher keine echte Kritik sein. Wenn du aber zeigen könntest, dass evolvierbarkeit, Korrektheit oder produktionseffizienz mit EBC leiden... Dann wäre das was anderes.

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 13 Jahren

Hallo ralfw,

dass evolvierbarkeit [...] oder produktionseffizienz mit EBC [2.0] leiden

genau das ist meine persönliche Einschätzung. Deshalb hatte ich geschrieben, dass ich persönlich mich mit EBC 2.0 nicht anfreunden kann. Es ist nicht meine Aufgabe zu beweisen, das ich Recht habe. Du schlägt ja den neuen Ansatz vor. Also wäre es im Zweifel an dir, zu belegen, dass die Vorgehensweise tatsächlich besser ist. Das verlange ich allerdings nicht. Ich behalte mir nur vor, skeptisch sein zu dürfen, und nicht gleich auf jeden Zug aufspringen zu müssen, der gerade erst losgefahren ist.

herbivore

71 Beiträge seit 2010
vor 13 Jahren

@herbivore: Natürlich musst du nix beweisen. Ich auch nicht. Ein Diskurs kommt so allerdings auch nicht zustande. Keiner lernt was. Wenn du das willst... auch ok. Einfach nur Meinungen dem anderen sagen und das war´s, das find ich jedoch platt. Da entsteht keine Weiterentwicklung. Das hilft niemandem. Den Anspruch hast du aber, sonst würdest du hier nicht so aktiv sein. Wenn es dich nicht interessierte, dass andere was auf deine Meinung geben, dann würdest keinen Kommentar zu EBC hier ablassen.

Ich bin daran interessiert mich und EBC weiterzuentwickeln. Deshalb stelle ich die Frage in den Raum: Inwiefern leiden Evolvierbarkeit und Korrektheit mit EBC? Warum sind EBC-System da im Nachteil gegenüber was auch immer?

Und ich gehe noch weiter und behaupte: Der, der Neues ablehnt, ohne zu wissen, wo seine eigene Baseline ist, also messen zu können, wie die Qualität von Merkmalen seiner Software ausgeprägt ist, der ist - sorry to say - Ideologe oder Dogmatiker. Denn dann besteht keine Falsifizierbarkeit seiner Behauptung.

Bei gegebener Baseline hingegen, stellt er zurecht die Frage: Kann das Neue diese Baseline übertreffen? Und dann ist es natürlich am Neuen zu zeigen, ob es das schafft.

Ohne Baseline jedoch... da ist es recht arrogant zu sagen, dass etwas Neues nicht besser ist.

Was sind also deine Merkmale? Wo ist deine Baseline für diese Merkmale?

Wenn du darauf Antworten geben kannst, verlierst du nichts an Skepsis. Keine Sorge. Du musst auch nicht Hurra rufen für EBC. Aber du würdest dich dann einer Diskussion stellen - bei der deine Position gestärkt oder geschwächt werden könnte. Ich ebenso. Das würde die Sache und die Community weiterbringen.

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 13 Jahren

Hallo ralfw,

Ein Diskurs kommt so allerdings auch nicht zustande.

mit EBCs 1.0 habe ich mich ausführlich beschäftigt, und einen sehr umfangreichen Diskurs mit dir geführt. Gerade vor diesem Hintergrund finde ich es unverschämt von dir, dass du nun so tust, als wäre ich nicht bereit einen Diskurs zu führen. Nur habe ich natürlich nicht jedesmal die Zeit, mich so intensiv mit einem Thema zu beschäftigen. Manchmal muss es also zwangsläufig oberflächlicher bleiben.

Meine Einschätzung kund zu tun, lasse ich mir deshalb aber trotzdem nicht nehmen. Und wenn sie nur dazu dient, dass jemand, der deine Blog-Beiträge liest, im Hinterkopf hat, dass es verschiedene Meinungen zu dem Thema gibt und ihm dadurch bewusster wird, dass er eine eigene Abwägung vornehmen sollte.

Ich finde es immer wieder interessant, in welche Ecken du deine Diskussionspartner zu stellen versuchst. Schon mehrfach hast du versuchst, Hürden aufzubauen, die mit hohem Aufwand für die Diskutanten verbunden sind. Wenn du dann wie hier auch gleich noch schreibst, was die Leute sind (arrogant, Dogmatiker, ...), wenn sie die von dir aufgestellten Bedingungen nicht erfüllen, ist das offensichtlich kein fairer Stil.

Statt von mir zu verlangen, dass ich eine Baseline definiere, tu du das doch. Du willst doch deine Idee unter die Leute bringen. Und zeige ausgehend von dieser Baseline, dass dein Vorschlag sie übertreffen kann.

herbivore

71 Beiträge seit 2010
vor 13 Jahren

@herbivore: Wir haben ausführlich über EBC 1.0 gesprochen. Aber deine Kritik bezieht sich auf EBC 2.0. Neues Spiel, neue Diskussion.

Wenn du dann nur eine Meinung kundtust und sie nicht substanzierst... dann ist das dein volles Recht. Aber ich bleibe dabei: schade, dass du so dogmatisch, weil unbegründet bist.

Wenn du meinst, dass ich Hürden aufbaue, dann sag doch gern, was an einer Hürde dir zu hoch ist. Leider hab ich das noch nicht gehört. Der Verweis auf wenig Zeit, weil du ja arbeiten musst (und ich anscheinend nicht), ist sicher legitim. Aber das ist ja ein Totschlagargument. Damit kann ich mich immer rausziehen. Auch legitim. Hilft nur wiederum der Sache nicht.

Wenn hier das Forum der vielarbeitenden Praktiker ist, dann ist das recht. Kein Problem. Nur weiß ich nicht, ob ich mich dann hier an Diskussionsanfängen beteiligen möchte, wenn die nicht weitergehen können, weil die Diskutanten keine Zeit haben.

Einerlei.

Zur Baseline: Wie wäre es, wenn wir uns auf einem Community Event zu einem Shootout träfen? Du bestimmst eine .NET User Group. Dort kommen wir zusammen, bekommen eine Aufgabe gestellt und lösen sie gleichzeitig mit unterschiedlichen Ansätzen. Das wäre doch mal was, oder?

Da können wir auch mal nen Bier trinken auf die ganzen Hürden und Dogmen, die so im Raum stehen.

Sowas wäre natürlich kein wissenschaftliches Experiment. Zuviele Faktoren könnten die unterschiedlichen Geschwindigkeiten erklären. Aber es wäre ein Event, der die Aufmerksamkeit auf eine wichtige Diskussion lenken helfen würde. Nämlich die, wie Software entworfen wird und werden könnte.

Am Ende stünde natürlich nicht nur eine Zielfahne, die geschwenkt würde, sondern ein Review und eine Diskussion. Was war leicht, was schwer mit der jeweiligen Methode.

Wie wäre das?

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 13 Jahren

Hallo ralfw,

du machst wirklich ein ganz schönes Fass auf. Und schließt von einer Einzeläußerung auf das gesamte Forum. Jetzt lass es bitte mal gut sein.

Dass dein Vorschlag sich auf den ersten Blick möglicherweise großzügig liest, ändert nichts daran das er auf das gleiche hinaus läuft, was ich eben schon kritisiert habe: Eine zusätzliche Hürde, zusätzlicher Aufwand.

herbivore

71 Beiträge seit 2010
vor 13 Jahren

Mein Vorschlag hat nix mit Großzügigkeit zu tun. Ich gäbe ja nichts her. Doch, hm, ich stelle meine Position zur Diskussion, also gebe ich sozusagen Sicherheit auf. Ich würde mich aufs Glatteis begeben, denn ich könnte ja daneben liegen. Aber das ist es mir wert. Mir ist Erkenntnisgewinn lieber als recht zu haben.

Schade dennoch, dass du ihn ausschlägst. Aus welchen Gründen auch immer.

Aber er steht hier und jeder andere kann ihn ja auch annehmen. Wer also meint, mit seinem Entwurfsparadigma "besser" zu sein als EBC, der kann mich gern anschreiben. Dann machen wir ein freundschaftliches Shoot Out in einer User Group aus.

Mit "besser" meine ich, dass das andere Paradigma (oder allgemeiner: Vorgehen beim Entwurf und in der Implementierung) zu Code führt, der evolvierbarer ist und dessen Korrektheit einfacher geprüft werden kann. Zu Evolvierbarkeit gehört: Änderungen/Erweiterungen können leichter eingebaut werden und der Code ist verständlicher.

Zur Diskussion stünde nicht TDD oder ein Vorgehensmodell. Es müssten also nicht mal automatisierte Teste geschrieben werden. Es ginge rein um EBC vs "Herausforderer" (z.B. OOP?).

J
537 Beiträge seit 2007
vor 13 Jahren

@herbivore,
schade, dass Du dich da so herauswindest. Ich hätte das Ergebnis sehr gerne gesehen.

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Jürgen Gutsch,

tja, da sieht man es: ralfw hatte mit seiner Unfairness mindestens bei dir Erfolg. Er versucht mir mehrfach etwas aufzudrängen, was klar seine Aufgabe wäre. Und wenn ich dann nichts anderes mache, als mich entschieden dagegen zu verwehren, wird mir das als Herauswinden ausgelegt, tztztz.

Das ist so, als wenn ich immer wieder behaupten würde, ich bekomme noch 100 Euro von dir und es dir als Herauswinden auslegen würde, wenn du das beharrlich und berechtigt verweigerten würdest.

Und das mir, der ich mich der Diskussion um EBC 1.0 wirklich sehr ausführlich gestellt habe. Mit einem erheblichen Aufwand für mich.

Aber EBC 2.0 halte ich einfach für so krank, dass ich darin nicht den mindesten Aufwand investieren werde. Das ist für mich ein tot geborenes Kind. Ich habe es bisher vermieden, das so deutlich zu sagen. Aber dein Beitrag zwingt mich dazu, offen zu legen, warum ich mich in diesem konkreten Fall auf keine Diskussion einlasse. Jede Beschäftigung damit ist in meinen Augen verlorene Zeit.

Damit sollte jetzt wirklich alles klar sein.

herbivore

J
537 Beiträge seit 2007
vor 13 Jahren

Hallo herbivore,

jetzt geraten wir wieder so aneinander 😦

tja, da sieht man es: ralfw hatte mit seiner Unfairness mindestens bei dir Erfolg. sorry, aber ich sehen keine Unfairness 😦

Aber EBC 2.0 halte ich einfach für so krank, dass ich darin nicht den mindesten Aufwand investieren werde. Aber das tust du hier doch den ganzen Thread über. Den Aufwand den du hier unnötigerweise damit verbracht hast, dich unbegründeter Weise angegriffen zu fühlen, hättest du für eine Diskussion nutzen können. Oder es eben ganz lassen können.
Entweder lässt man sich mit Ralf auf eine Diskussion ein oder nicht. Mit einer halben Diskussion gibt er sich halt - bekanterweise - nicht zufreiden 😉

(Wetten das dieser Beitrag gleich gelöscht ist? fg)

71 Beiträge seit 2010
vor 13 Jahren

@herbivore: Dass du EBC 2.0 "so krank hälst"... nun, das ist dein gutes Recht. Niemand zwingt dich, dich damit zu beschäftigen. Lass es.

Nur sieh bitte ein: Rausprusten von bloßer Meinung, platte Urteile... die helfen niemandem. Dafür musst du kein Forum wie hier betreiben. Das ist was für einen Stammtisch. Denn das polarisiert nur, ohne Substanz zu liefern.

Nochmal: Ich bin nicht gegen deine Auffassung. Aber ich find es schad, dass du mit solcher Plattheit hier versuchst, anderen Differenzierheit für ihren Blick nahezubringen.

Aber egal.

Zur Unfairness: Warum ich unfair bin, wenn ich anbiete, dass deine feste Meinung, EBC 2.0 sei krank und bringe daher nix, sich mit meiner Meinung einen kleinen Wettstreit liefert, verstehe ich nicht.

Unfairness entsteht bei nicht ungleichen Gegnern. Worin sollte aber diese Ungleichheit bestehen? Wir beide benutzen VS2010, R# 5.1 (oder auch nicht, wenn du nicht magst) und einen Block mit Stift. That´s it.

Du hast dann deine Erfahrung mit deiner gesunden Methode im Gepäck - und ich trete als Behinderter mit kranker Methode an. Eigentlich unfair mir gegenüber 😉 Aber das lasse ich mal außen vor.

Wenn du jedoch nicht willst, dann willst du nicht. Auch gut.

K
593 Beiträge seit 2007
vor 13 Jahren

Hallo ihr 2 (3),

interessante (oder auch nicht) Diskussion die sich hier entwickelt hat. Das es momentan mit dem Topic nicht wirklich viel zu tun hat sehen denke ich die meisten. Aber wie hier gegeneinander angegangen wird finde ich wirklich nicht gut.

Ich kann gut verstehen warum herbivore keine nötigkeit darin sieht etwas zu tun, geht mir in anderen Bereichen ähnlich. Man hat einen gewissen Informationsschatz kriegt etwas vorgesetzt und schließt erstmal etwas daraus. Das ist normal und menschlich. Die Meinung mag berechtigt oder unberechtigt sein, egal. Auf jedenfall basiert sie auf die Erfahrungen der jeweiligen Person und sind für diese Person in diesem moment korrekt.

Wenn man jetzt nach diesem Thema nach einer Meinung gefragt wird, oder allgemein gestellt wird, kann man ruhig die Antwort geben die man für richtig hält. Darauf basiert ja sowieso alles.

Ich glaube kaum das man eine Diskussion brauch, worin es darum geht, dass man dazu "zwingen" will sich mit dem Thema so intensiv zu beschäftigen bis man dieselbe Meinung oder eine ausgearbeitete begründung einer anderen Meinung vorzuweisen hat.

Ein allgemeiner Aufruf mag durchaus interessant sein und wird sicher wer interesse hat wahrgenommen. Aber das was hier augenscheinlich passiert halte ich für ziemlich dreißt. Ich verstehe herbivore vollkommen und finde das es in diesem Forum normal etwas anders zu geht. Jeder hat die freie Wahl und es geht nicht darum einen schwarzen Peter unterzuschieben.

Viele Grüße,

Kaji

71 Beiträge seit 2010
vor 13 Jahren

@Kaji: Leider gehts nicht mehr ums Thema EBC. Das ist schad.

Dennoch ist die Diskussion aber nicht nutzlos, finde ich. Denn interessant ist zu sehen, wo die Kritik einsetzt. Sie beginnt eben nicht hier

Ich kann mich mit EBCs 2.0 allerdings überhaupt nicht anfreunden. Die prozedurale Programmierung, bei der - wie bei EBCs 2.0 - die Aktionen im Vordergrund stehen, haben wir mit Recht hinter uns gelassen.

oder hier

Aber EBC 2.0 halte ich einfach für so krank, dass ich darin nicht den mindesten Aufwand investieren werde.

Das halte ich für typisch. Und das ist sehr bedauerlich. Denn damit widersprechen die Forenmitglieder eigentlich dem Sinn des Forums. Das soll nämlich Wissen mehren - so ist zumindest mein Verständnis. Es soll "die Kunst" voranbringen.

Dabei sind Meinungsäußerungen natürlich völlig ok und unvermeidbar. "Ich finde..." ist absolut ok. Und es darf auch mal ein Gefühl dazu kommen. Wenn herbivore sich schüttelt bei EBC 2.0 und sie "krank" nennt... dann ist das halt ne Positionsangabe.

Nur, bitte, Leute, wenn wir alle nur Positionsangaben machen, dann kommen wir nicht weiter. "Ich find dies Mist!" und "Ich find das krank!" und "Das bringt nix!" ist Stammtischniveau. Dafür muss ich hier nicht sein.

Ich wende mich also nicht gegen platte Äußerungen, sondern dagegen, dass man sich einfach darauf zurückzieht und sagt: "Das muss ich nicht begründen."

Dass zu jeder Neuigkeit manche sagen "doof!" und andere sagen "toll!" ist klar. Dafür müssen wir nicht hier rein. Spannend wird es, wenn wir Begründungen für "doof!" oder "toll!" hören. Soll es nicht um Argumente gehen hier?

Da ists natürlich leicht bei Fragen wie "Wie kann ich einen String in Teile zerlegen, wenn die durch ';' getrennt sind?" Dann verweist man auf Split() und alle sind glücklich. Keine Meinung nötig, kein Argument muss gebracht werden, nachdenken nicht nötig. So ist das halt.

EBC ja oder nein oder wann? Scrum ja oder nein oder wann? ORM, NoSql, WPF ja oder nein oder wann? Das sind Fragen auf einem anderen Niveau. Da gibt es keine eindeutigen Antworten - oder wenn, dann müssen sie begründet (!) werden.

herbivore zieht sich nun - aus meiner bescheidenen Sicht - aus der "Begründungspflicht" raus. Nur das ist meine Kritik. Und die trage ich hier sachlich, wenn auch deutlich vor.

Er sagt, er hätte sich einmal eingelassen und lange diskutiert. Aber diesmal wüsste er nun einfach, dass EBC 2.0 krank sei. Und das sagt er einem "unschuldig" Fragenden ohne Not und ohne weitere Begründung. Eine ominöse Anspielung auf Prozedurale Programmierung - das war´s.

Natürlich fühle ich mich damit angesprochen, weil es bei EBC um "mein Thema" geht. Doch das Verhalten ist weit verbreitet. Deshalb habe ich hier einfach mal nachgebohrt.

Nun, das kommt nicht gut an. Es wird als beleidigend angesehen. "Man" fühlt sich unfair behandelt, in die Ecke gedränkt, verpflichtet... Ich interpretiere: Aus der Komfortzone will niemand raus.

Ok, ist aller gutes Recht. Hier ist ja Freizeit. Da kann man machen oder nicht machen, was man will. Ich auch. Tschüssle...

3.170 Beiträge seit 2006
vor 13 Jahren

Hallo zusammen,

das ist ja hier mal eine merkwürdige Diskussion geworden, deren eigentlichen Grund ich nicht erkennen kann.
Denn es beginnt ja offensichtlich mit der Aussage von herbivore

Ich kann mich mit EBCs 2.0 allerdings überhaupt nicht anfreunden. Die prozedurale Programmierung, bei der - wie bei EBCs 2.0 - die Aktionen im Vordergrund stehen, haben wir mit Recht hinter uns gelassen.

Ich formuliere das mal wie folgt um:
Die prozedurale Programmierung, bei der die Aktionen im Vordergrund stehen, haben wir mit Recht hinter uns gelassen. Ähnlich wie dort stehen auch bei EBCs 2.0 die Aktionen im Vordergrund. Deshalb kann ich mich damit überhaupt nicht anfreunden.
Die Kernaussage ist exakt dieselbe. Ich sehe hier weder eine "ominöse Anspielung" (es wird lediglich eine Parallele aufgezeigt), noch einen Anlass eine weitere Begründung zu verlangen. Die gegebene Grund ist zwar nicht sehr ausführlich - aber muss er das wirklich sein?

Ich verstehe auch folgende Aussage nicht:

Dabei sind Meinungsäußerungen natürlich völlig ok und unvermeidbar. "Ich finde..." ist absolut ok. Und es darf auch mal ein Gefühl dazu kommen. Wenn herbivore sich schüttelt bei EBC 2.0 und sie "krank" nennt... dann ist das halt ne Positionsangabe.

Nur, bitte, Leute, wenn wir alle nur Positionsangaben machen, dann kommen wir nicht weiter.

Warum denn bitte nicht? Es kann schon alleine dazu dienen, zu zeigen, daß es andere Positionen gibt. Und wenn wir mit unserer Position hinterm Berg halten, bringt uns das genauso wenig weiter, als wenn wir sie äußern.

Den Rest der Diskussion halte ich für etwas unglücklich, da sich das irgendwie aufgeschaukelt hat. 😦 😦

Bitte überdenkt beide nochmal was ihr eigentlich wollt und wie ihr das hier kommuniziert habt - denn so wie es sich liest habt Ihr es vielleicht/hoffentlich gar nicht gemeint.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

K
593 Beiträge seit 2007
vor 13 Jahren

Hallo ralfw,

ich denke du bist bei dem Thema im Moment etwas "empfindlich". Durchaus verständlich den es ist dein Thema und du möchtest gerne die Vorzüge, deine Idee und Vision die damit verbunden ist, andere offenbaren und klar stellen.

Leider hat das auch gewisse Nachteile für die Diskussion an und für sich. Natürlich legst du alles daran zu Beweisen das es gut und richtig ist, oder durch ordentliche und feste Begründung einer anderen Meinung belehren zu lassen. Aber es gibt immer Leute die sich gewissen Positionen hergeben.

Das muss sich nicht auf EBC beziehen das passiert schon im Alltag wenn man "über die Jugend" über "Killerspiele" oder sonstwas smalltalk hält. Da erhält man fast nur Positionsangaben.

Und auch wenn es sicherlich Unterschiedliche Meinung darüber geben mag, ist das Forum nicht nur ein Platz um Ausarbeitungen und Tiefgründige Diskussionen zu führen sondern Positionen zu stellen. Ich habe einige schon sehr ausgiebige Diskussionen hier bezüglich zu EBC gelesen und fand sie sehr interessant, aber bitte, das muss und sollte doch nicht immer so sein.

Und was, wie ich finde, hier eigentlich ganz stark vergessen wird, ist das was unter dem mycsharp Logo zu finden ist... "Gemeinsam mehr erreichen" es geht hier schließlich nicht um eine Position sondern um viele Positionen und Meinungen, einige sagen zum einem mehr, die anderen etwas weniger.

Bitte versuche nicht bei jeder Positionsangabe die Leute unnötig zu bedrängen. Ich denke du hast schon gemerkt das hier viele Leute bereit sind bei Interesse und Zeit viel Freizeit zu opfern um Sachen auszuprobieren einzulesen und Meinungen auszuformulieren. Direkte Ansprachen sind häufig schon eine Konfrontation.

Das soll aber nichts negatives gegen dich sein, ich finde das du dich sehr bemühst viel zu machen und dich ausgiebig mit Themen beschäftigst, aber nicht nur stur in deiner Meinung bist. Ich hoffe nur das du vielleicht nur meine Meinung verstehst und sicher versucht dein Thema voranzubringen, aber den Menschen ihre Freiheit lässt selbst zu bestimmen wieviel sie machen wollen und nicht unnötig zu bedrängen.

In dem Sinne hoffe ich mich auf viele weitere Themen auf mycsharp! Wobei ich seit einiger Zeit eher stiller Leser bin, aber trotzdem regelmäßig und gerne hier lese!

Viele Grüße,

Kaji

4.207 Beiträge seit 2003
vor 13 Jahren

Hoi Jürgen,

(Wetten das dieser Beitrag gleich gelöscht ist? fg)

erstaunlich, es steht noch drin .... normalerweise hätte ich darauf nämlich auch gewettet 😉.

Übrigens kann ich mich Deiner Meinung nur anschließen:

@ herbivore: Ralf ist im Gegensatz zu Dir sachlich geblieben, und Formulierungen wie "krank" empfinde ich in diesem Zusammenhang als leicht "krank" ... Ralf kommt ja nun auch nicht daher und behauptet, mit den EBCs das Beste seit der Erfindung von geschnittenem Brot gefunden zu haben. Er hat ja nun schon mehrfach darauf hingewiesen, dass er an Erkenntnisgewinn und Erfahrungsaustausch interessiert ist.

Dass Du das so abblockst - schade. Zumal die Gründe zumindest für mich nicht wirklich nachvollziehbar sind (Argumente sehen für mich anders aus), mit "ich finde das krank" kann ich ja alles aushebeln und mich einer Diskussion entziehen.

Und was genau Du für ein Problem mit EBCs hast, wo Du die Nähe zur prozeduralen Programmierung siehst - das habe ich zumindest leider noch nicht verstanden, weil außer ein paar flapsigen Kommentaren keine wirkliche Antwort von Dir auf die Fragen kam.

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

71 Beiträge seit 2010
vor 13 Jahren

Ich antworte mal in zwei Teilen. Hier zum eigentlichen Thema EBC, zum Inhalt:

Wer ist noch an einer Diskussion zu EBC 1.0 oder 2.0 interessiert? Hat noch jemand Fragen? Weiß jeder, was herbivore eigentlich damit meint, wenn er von Prozeduraler Programmierung spricht, der EBC zu ähneln scheint und deshalb "krank" sei?

Ich weiß leider nicht, was das im Konkreten bedeutet. Ich habe ca. 12 Jahre prozedural mit Pascal und C programmiert. Und ich kann nur sagen: EBC 1.0 und 2.0 fühlen sich ganz, ganz anders an.

Mein Angebot wiederhole ich: Wer meint, EBC bringe nichts oder sei gar "krank", der kann das gern demonstrieren und ich stelle mich daneben und versuche mitzuhalten mit EBC. Das wäre doch mal ein Experiment, oder?

Im Kämmerlein kann jeder seinen Striemel programmieren und glauben, das sei produktiv. Doch erst der direkte Vergleich zeigt ja, ob da wirklich was dran ist. Ich jedenfalls bin bereit, mit EBC "vorgeführt zu werden". Wenn ich bei so einem Vergleich kläglich mit einer "kranken" Methode scheitere... dann wäre das bitter - aber letztlich ein großer Erkenntnisgewinn. Selbstverständlich würde ich die Vertreter der obsiegenden Methode zum Bier einladen 😃

Also: Hat noch jemand zur Sache einen substanziellen Beitrag zu leisten oder eine Frage zu stellen? Dann mal los...

71 Beiträge seit 2010
vor 13 Jahren

Teil 2 meiner Antwort, jetzt zur Form:

Ich sehe hier weder eine "ominöse Anspielung" (es wird lediglich eine Parallele aufgezeigt), noch einen Anlass eine weitere Begründung zu verlangen. Die gegebene Grund ist zwar nicht sehr ausführlich - aber muss er das wirklich sein?

Du beziehst dich auf die Erwähnung der Prozeduralen Programmierung bei herbivore. Muss er das wirklich begründen? Natürlich nicht - aber dann nehme ich ihn nicht als relevante Stimme war. Wir sind nicht im Fußballstadion und nicht am Stammtisch.

herbivore hat mir erstens persönlich in dieses Forum gebeten. Und zweitens hat er mich persönlich auf den Ursprungsbeitrag dieses Thread aufmerksam gemacht. Das deutet auf sein Interesse an Beiträgen von mir im Allgemeinen und im Speziellen hin. Dass ich niemand bin, der nur "Toll!" ruft, war ihm klar. Dahergerede - gerade in Sachen EBC - ist nicht meins. Also: Dass ich bei einer solch platten Antwort nachhake - und das habe ich interessiert und nicht unfreundlich getan -, sollte ihm völlig klar gewesen sein.

Nochmal: Muss man begründen? Ja, wenn man diskutieren will und nicht nur Stimmung machen will. Denn reine Meinungsäußerungen wie "Toll!", "Doof!", "Krank!", "Hat mir immer geholfen!" sind emotionale Äußerungen. Sie vermitteln eine Grundhaltung. Sie vermitteln allerdings keine Begründung.

Wer in diesem Forum eine Frage stellt, will aber nicht einfach Emotionen hören, sondern begründete Äußerungen. Für einen emotionalen Überblick würde eine Umfrage reichen. "Wie findet ihr EBC? Toll, doof, krank, sosolala?"

Super! Kein Problem. Macht eine Umfrage. Die gibt dann ein Stimmungsbild. Auch ne schöne Sache. Das ist dann wie bei Amazon, wenn man die Rezensionen nicht liest, sondern nur die Sternestatistik: "EBC hat 1 mal 5 Sterne, 3 mal 4 Sterne, 7 mal 3 Sterne, 15 Mal 2 Sterne, 2 Mal 1 Stern" oder so ähnlich.

Aber, Leute, ihr verlangt jeden Tag mehr von denen, die in Büchern, Zeitschriften, Blogs schreiben. Ihr verlangt jeden Tag mehr von Herstellern und Referenten auf einer Bühne. Wenn euch die mit Stimmungsäußerungen zu EF, WF, WCF, BT, NoSql, WPF, SL, LS und was sonst kommen... dann lacht ihr sie aus. Dann ruft ihr: "Begründe, begründe, begründe!"

Und in dem Fall mag es auch ok sein, weil es eine Einwegkommunikation ist und ihr im Publikum seid.

Hier im Forum jedoch ist es anders. Hier sind wir alle gleich. Wer also was behauptet, eine Stimmung äußert, der sollte sie auch begründen (können) und zumindest drauf gefasst sein, dass er darum gebeten wird.

Messt nicht mit zweierlei Maß.

Wenn ich bei herbivore nachgehakt habe, dann ist das der Symmetrie der Situation hier zuzuschreiben. Sein Verweis, ich sei doch der Proponent von etwas Neuem und hätte daher eine größere Beweispflicht, ist hier untauglich. Ich stehe hier nicht auf der Bühne, sondern bin Peer. Auch ich habe nur eine Meinung wie ihr, die ich vertrete. Und Vertreten bedeudet, weil wir eben nicht im Stadion irgendwie aus Kurven brüllen, dass ich mich zumindest um Begründung bemühe.

"Das ist wie Prozedurale Programmierung" ist auf einem hohen Abstraktionsniveau natürlich auch eine Begründung. Klar. Aber wenn ich das nicht verstehe, dann darf ich doch mal nachfragen, oder? Und - sorry to say - wenn dann zurückkommt, "Das muss ich nicht weiter erklären.", dann ist das schlicht arrogant. Denn das heißt "Du bist dumm, dass du mich nicht verstehst."

[Das] passiert schon im Alltag wenn man "über die Jugend" über "Killerspiele" oder sonstwas smalltalk hält. Da erhält man fast nur Positionsangaben.

Das hat du natürlich recht. "Positionsangaben" gibts andauernd im Alltag und auf Partys. Das ist ja auch ok, wenn die Situation passend ist. Wenn die Musi laut dudelt, ist es schlecht mit einer differenzierten Diskussion.

Nur sind wir hier nicht im Alltag, sondern in einem professionellen Forum. Meine Grundannahme: Hier wollen die Leute echt was lernen. Dazu gehört dann aber mehr als "Positionsangaben". Das wird jeder aus der Schule noch wissen.

In einer ersten Runde für ein Stimmungsbild mag es reichen, nur Positionsangaben abzulassen. Ok. Aber wollen wir dabei stehenbleiben? Dann sollten wir ein Umfrageforum eröffnen. Jeder kann da ganz einfach Umfragen zusammenstellen. "Mit welcher Programmiersprache arbeitet ihr?", "Sollte man .NET Remoting oder WCF im Intranet einsetzen?", "Ist EBC besser als OOP?" usw. usf. Super Sache! Noch ein RSS-Feed für das Umfrageforum und schon kann ich in meinem Newsreader sehen, ob es wieder eine spannende Umfrage gibt, bei der ich einfach mal meine "Positionsangabe" machen kann.

Wäre das nicht ne schöne Anwendung, die die Community basteln könnte? Ein bisschen Aufwand treiben - und dann viel Zeit sparen, denn dann würden wir nicht mehr in unselige Diskussionen mit Missverständnissen und Kränkungen verfallen, weil irgendwer auf die Idee kommt und nach einer Begründung fragt.

Wer macht mit?

Bitte versuche nicht bei jeder Positionsangabe die Leute unnötig zu bedrängen.

Vielen Dank für die Verhaltensregel: "Wer im Forum auf eine 'Positionsangabe' stößt, bedränge bitte den Meinungsäußerer nicht, sich zu erklären." Das ist nämlich unnötig.

Aber warum ist das unnötig? Weil er schon bald in einem Folgeposting seine Position von allein erklären wird? Oder weil er selbst nicht weiß, warum er die Position hat und eine Nachfrage daher nichts brächte? Oder weil man doch wissen müsste, dass der Meinungsäußerer für dererlei Details keine Zeit hat?

Nein, ich verstehe nicht, warum eine interessierte und ganz und gar freundliche Nachfrage ein "Bedrängen" sein soll. Und ich verstehe auch nicht, warum eine solche interessierte und ganz und gar freundliche Nachfrage "unnötig" ist.

Direkte Ansprachen sind häufig schon eine Konfrontation.

Ich nehme an, das meinst du ernst. Du meinst es auch nett im Sinne einer Erklärung für mich als Elephant im Porzellanladen.

Wenn das aber wirklich, wirklich so ist, dass "direkte Ansprache [...] häufig schon [als] Konfrontation" aufgefasst werden... dann muss ich mich fragen, wo wir hier sind? Im Verein Deutscher Authisten? Ich bin schier sprachlos. (Ist ja aber vielleicht auch gut so, denn direkte Ansprache ist ja womöglich Konfrontation.)

[...Pause...Ich muss mich sammeln...]

Ne, ich finde dazu keine Worte mehr. Ein Forum, in dem ich ahnen muss, dass direkte Ansprache im Sinne von "Kannst du deine Meinung bitte begründen" als Konfrontation angesehen wird, ist für mich kein Ort, an dem ich sein will. Dafür ist mir meine Zeit zu schade. Ich bin kein Therapeut und kein Sonderpädagoge. Und auch kein Seelsorger. Wenn die Mühseligen und Beladenen hier zum Austausch von "Positionsangaben" zusammenkommen wollen, dann sei das so. Das mag seinen Wert haben. Sie mögen sich in ihrem Leide gegenseitig stützen. Aber ich stütze nicht mit.

Das mag arrogant klingen... aber es ist eher enttäuscht. Im doppelten Sinne. Ich bin enttäuscht, dass man mich zu einem solchen Forum eingeladen hat. Und ich habe mich nun einer Täuschung ent-ledigt. Denn ich war der Täuschung (oder Illusion) erlegen, dass hier Leute zusammenkommen, die echt was lernen wollen.

Nun, wenn das aber nicht so ist - denn Lernen findet nicht statt, wenn alle auf Zehenspitzen gehen und Konfrontationen ausweichen oder in Begründungsaufforderungen Angriffe sehen -, dann ziehe ich mich zurück. Nicht beleidigt, nein, sondern um eine Erkenntnis reicher und traurig. But I´ll cope.

(Natürlich weiß ich, dass nicht alle hier so mimosenhaft authistisch sind. Du beschreibst eine Tendenz. Die ist mir jedoch schon zuviel. Dass es solche Leute gibt in solchen Foren, ist mir klar. Fühlt man sich aber bemüßigt, das zu betonen und darauf Rücksicht zu nehmen, ist die Entwicklungskultur (auch im doppelten Sinn) am Ende.)

Und nun? Am besten Wünsche ich gute Besserung, oder? Oder sollte ich noch einen Link zu Konflikttrainings einschließen, damit nicht jede Nachfrage als Konfrontation gewertet wird? Ne, ich lass es. Sonst werd ich noch zynisch.

In Summe kann ich aber bei aller Ungemütlichkeit des Diskussion sagen: Ich hab etwas gelernt. Nicht, was ich lernen wollte, aber was anderes. Und das ist auch ok. Die Erkenntnis lauert überall 😉

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 13 Jahren

Hallo ralfw,

nochmal, du schließt aus einem Einzelfall wider besseres Wissen auf das gesamte Forum. Es wurde in diversen Threads über EBCs in der Form diskutiert, wie du sie dir wünscht: differenziert, fundiert, begründet. In einem einzigen Thread ist das nun aus bestimmten Gründen nicht so und dann ist gleich das ganze Forum quasi ein billiger Stammtisch. Das wird der Realität nun wahrlich nicht gerecht.

herbivore

3.170 Beiträge seit 2006
vor 13 Jahren

Hallo ralfw,

"Das ist wie Prozedurale Programmierung" ist auf einem hohen Abstraktionsniveau natürlich auch eine Begründung. Klar. Eben.
Aber wenn ich das nicht verstehe, dann darf ich doch mal nachfragen, oder? Sicher.
Und - sorry to say - wenn dann zurückkommt, "Das muss ich nicht weiter erklären.", dann ist das schlicht arrogant. Denn das heißt "Du bist dumm, dass du mich nicht verstehst." Das sehe ich nicht so: Es könnte ebenso gut heissen: "Für mich ist der Grund ausreichend, und daher will ich mich damit auch nicht weiter beschäftigen, und weitere Begründungen kann ich wegen diesem Umstand auch nicht geben."
Ob der Grund tatsächlich ausreichend ist, ist wohl Sache des Einzelnen, und da gehen Meinungen eben auseinander, dann aber zu behaupten, das sei arrogant, oder das so zu interpretieren, daß man sich als "dumm" bezeichnet fühlt (das hat nämlich keiner getan - das ist Deine ganz persönliche Interpretation), das ist - sorry to say - sicher auch nicht das hohe Niveau das Du Dir selber wünschst, damit drängst Du Deinen Gesprächspartner gewissermassen in die Ecke.

Das finde ich nicht gut, und deshalb hatte ich mich überhaupt erst in diesem Thread geäussert.
Seid nett zueinander.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

K
593 Beiträge seit 2007
vor 13 Jahren

Hallo ralfw,

ich finde es durchaus interessant welche Interpretationen aus meinem Text kommen. (Das ist nicht ironisch gemeint!) Nur leider scheinst du manche Sachen zu schreiben die aber so nicht waren.

Aber warum ist das unnötig? Weil er schon bald in einem Folgeposting seine Position von allein erklären wird? Oder weil er selbst nicht weiß, warum er die Position hat und eine Nachfrage daher nichts brächte? Oder weil man doch wissen müsste, dass der Meinungsäußerer für dererlei Details keine Zeit hat?

Mal ganz ehrlich, warum sind die 3 Punkte keine erklären? Ich meine sie können alle gut und gerne zutreffen.

Nein, ich verstehe nicht, warum eine interessierte und ganz und gar freundliche Nachfrage ein "Bedrängen" sein soll. Und ich verstehe auch nicht, warum eine solche interessierte und ganz und gar freundliche Nachfrage "unnötig" ist.

Ich mag ja gut und gerne die erste Nachfrage als freundlich durchgehen lassen und war ja auch vollkommen korrekt. Nur nachdem herbivore klar gemacht hatte, das er eben nunmal nicht die Zeit oder Lust dazu hätte zu Begründen, hast du nicht aufgehört sondern angefangen zu bedrängen und das, finde ich, muss nicht sein.

Ich meine du hast nachgefragt, dein Partner hat abgelehnt und du hast dich nicht damit zufrieden gegeben.

Ich frage mich auch was du mit deinem Stammtischniveau willst? Ich meine du weißt sicherlich auch das die Stammtische unterschiedlich sind.

Zudem finde ich schon, dass das niveau in diesem Forum ziemlich hoch ist. Und obwohl hier häufig begründet und ausgearbeitet wird, finde ich sollte man auch antworten können wenn es mal so ist. Ich meine wollen wir da landen das wir uns 4 mal überlegen zu einem Thread zu antworten weil man sich unsicher ist ob man es ausreichend begründen kann, bzw die Zeit hat diese sich zu nehmen?

Ich meine wenn gefragt wird wie man performant mit Set- und GetPixel arbeiten kann mit einem Bild dann würde ich auf eine der extra dafür gemachten Klassen verweisen. Jetzt kann mich natürlich der Fragende nach erklärung bitten warum die eine oder andere Besser ist. Wenn ich aber wenig Lust darauf habe werde ich ihm eher erklären das er das er selber ausprobieren möge oder ein anderer das vielleicht machen möchte. Trotzdem finde ich habe ich ihm geholfen weil ich es beantwortet habe.

Und dann bringt es sicherlich auch nicht mich ernergisch dazu bringen zu wollen das zu erklären. Und in meinen Augen ist hier nicht viel anderes passiert.

Daher lasst uns doch weiter gemeinsam produktiv in diesem Forum beschäftigen und uns nicht damit beschäftigen etwas zu wollen, was andere augenscheinlich nicht wollen.

Viele Grüße,

Kaji

3.511 Beiträge seit 2005
vor 13 Jahren

Leute Leute,

kommt mal wieder runter. Jeder hat seine Meinung. Wäre schlimm wenn alle die gleichen Meinungen hätten. Man kann eine Meinung nicht einen anderen aufzwingen. Belasst es doch bitte dabei. Wenn herbivore nicht begründen will, warum es "krank" ist, dann will er es halt nicht. Ich kann dich Ralf, da ganz gut verstehen, dass du es gerne wissen willst, weil es nunmal dein Hauptaugenmerk momentan ist. Aber wenn er nunmal nicht, will er es nicht.

Bleibt bitte sachlich und werdet nicht perönlich.

Ich bin enttäuscht, dass man mich zu einem solchen Forum eingeladen hat. Und ich habe mich nun einer Täuschung ent-ledigt. Denn ich war der Täuschung (oder Illusion) erlegen, dass hier Leute zusammenkommen, die echt was lernen wollen.

Ich gehe mal davon aus, das hier jeder was lernen will. Jeder auf seine Art und Weise. Das jetzt runter zu reduzieren auf diesen einen Beitrag enttäuscht mich ebenfalls. Aber hey, das ist meine Meinung 😃

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

U
282 Beiträge seit 2008
vor 13 Jahren

Ich schreibe jetzt mal hier. Bin nicht der Guru in Software-Architektur, habe aber EBC 1.0 mal ausprobiert. Die Idee finde ich gut. Insbesondere Hat es mich ein wenig aufgerüttelt und irgendwie bewusst gemacht, dass auch Abhängigkeiten von Interfaces problematisch sind.

Habe dann alles über lose Komponenten gemacht, die von außen verdrahtet wurden. War eine schöne Idee, es gab auch keine Abhängigkeiten mehr im Code. Aber dennoch musste ich an verschiedenen Stellen Annahmen über die Situation des Systems treffen. Damit alles zusammen funktioniert musste ich einfach davon ausgehen, dass das System bei einer Bestimmten Nachricht etwas tut und dann wenig Später eine andere Nachricht eintrifft.

Meine Komponenten hatten also sehr wohl eine starke Kopplung, nur war die nicht mehr explizit formuliert sondern steckte implizit überall drin. Ich hatte das Gefühl, die Abhängigkeiten aus dem Code in die Dokumentation verschoben zu haben.

Ein anderes Problem war mehrfache Datenhaltung. Derzeit habe ich ein zentrales Datenrepository, auf dem alles Arbeitet. Alles haben eine Referenz auf das Repository. Wenn nun die Komponenten nur noch über nachrichten informiert werden, muss jede Komponenten die Daten duplizieren. Das war aber viel Aufwand. Und sorgte für Probleme.

Repository sendet "neuer Punkt XY" zu vielen Komponenten. Komponenten A bekommt das mit und sagt "Punkt XY wird rot" und sendet an alle Komponenten "Punkt XY ist rot". Komponenten B bekommt mit, das XY rot ist, weiß aber aus dem Repository noch gar nicht, dass XY existiert. Haben hingegen alle eine Referenz auf das Repository, so ist in jedem Fall der Punkt XY bei Komponente B bekannt.

Einige Nachrichtenflüsse die bisher traditionell implementiert waren (Objekt kennt Quelle und hört auf deren Events) habe ich jetzt auf Methodenaufrufe von außen umgestellt. Bei vielem war der klassische Ansatz aber auch IMHO besser geeignet.

Ich will das aber jetzt nicht Beweisen müssen. Mag auch sein, dass ich nicht Intelligent genug bin, um EBC richtig einzusetzen (einfache Verwendbarkeit ist IMHO aber ein wichtiges Kriterium, mindestens so wichtig wie Flexibilität oder Robustheit). Ich stelle nur Fest: Habe mich eingelesen, habe es versucht umzusetzen, hat aber nur teilweise funktioniert.

Ich finde die Beiträge zu EBC ein wenig wie Clean Code Development: Es rüttelt auf, schafft Problembewusstsein, aber ist mir zu puristisch. Bei CCD wurden mir viele Dinge bewusst, dennoch habe ich immer noch Methoden mit mehr als 5 Zeilen und finde manchmal auch angenehmer einen Algorithmus in eine 30 Zeilen-Methode zu packen leichter als ihn auf 5 Methoden in zwei Klassen zu splitten (war jetzt überspitzt, trifft aber im Kern mein Empfinden).

Hinweis von gfoidl vor 13 Jahren

Bitte die Diskussion nicht auf das Thema CCD umschwenken. Bleibt beim Thema und da sachlich. Danke.

71 Beiträge seit 2010
vor 13 Jahren

Ich meine du hast nachgefragt, dein Partner hat abgelehnt und du hast dich nicht damit zufrieden gegeben.

Da hast du recht. Jetzt sehe ich, was du mit "bedrängen" meinst. Ja, das mag zuviel des Guten gewesen sein.

In der Form nicht schön.

Bei meinem Urteil, dass eine nicht-Begründung auf dem Level, wie sie gegeben wurde, unzureichend ist, bleibe ich jedoch. (Denn lasst uns ehrlich sein: Niemand weiß, was herbivore überhaupt in diesem Zusammenhang unter Prozeduraler Programmierung versteht.)

Nur sollte ich aus dem Gefühl heraus nicht drängen, sondern nur still den Kopf schütteln. Ok, das ist auch eine Erkenntnis. Danke für den Hinweis, Kaji.

71 Beiträge seit 2010
vor 13 Jahren

Mal zurück zur Sache, wenn denn meine Nachfrage nicht als Konfrontation empfunden wird 😉

Ein anderes Problem war mehrfache Datenhaltung. Derzeit habe ich ein zentrales Datenrepository, auf dem alles Arbeitet. Alles haben eine Referenz auf das Repository. Wenn nun die Komponenten nur noch über nachrichten informiert werden, muss jede Komponenten die Daten duplizieren.

Warum sollte eine EBC-Architektur zu mehrfacher Datenhaltung führen? Das verstehe ich nicht. Wenn du früher ein Repository hattest, dann kannst du mit EBC 1.0 und auch EBC 2.0 weiterhin ein zentrales Repository haben.

A
69 Beiträge seit 2010
vor 13 Jahren

Ich persönlich habe mich ein wenig mit EBC 1.0 beschäftigt und schon damals hatte ich dabei das Gefühl, das das so ähnlich wie mit den c++ templates & co ist.... abgefahrene sache die niemand wirklich braucht.

Oder wie es Joel formuliert hätte: Don't Let Architecture Astronauts Scare You

Ebc ist für mich ein set von Abstraktionen. Im sinne von "Aktion wird durch Platine abstrahiert und die komponenten erledigen die Schritte". Hierzu fällt mir dann aber wieder etwas von Joel ein: The Law of Leaky Abstractions
Manchmal muss eben eine Komponente von einer oder anderen mehreren wissen oder eine komponente muss mal eben wissen, das vor ihr schritte 1, 2 und 3 erfolgreich oder nur teilweise erfolgreich durchgelaufen sind und dann wird es auch mit EBC haarig.... dann fängt man an statusobjekte mitzuschleifen und validationsmechanismen vor jedem schritt aufzurufen, welche am besten in einer Validationskomponente untergebracht sind, welche aber auch je anch status andere mechanismen fährt usw...
Oder man bietet n eingänge je nachdem welche und wieviele schritte vorher erfolgreich durchgelaufen sind, wobei man dann wieder ein exponenzielles wachstum zur komplexität hat und dann abstrahiert man das ganze wieder teilweise in eine statusobjekt und nlogn eingängen, und ist glücklich, das man nur eine woche gebraucht hat um mit den unerwarteten sonderfällen der BWL leute zurechtkommen zu können....

Da neige ich doch eher in diese richtung: The Duct Tape Programmer

(ja, ich bin einer seiner fans 😉 )

Ich wäre allerdings jetzt auch nicht bereit, einen oder mehrere Tage zu opfern um in eine andere Stadt zu fahren und öffentlich einen Wettstreit auszutragen, welches ein ausgedachtes Problem in möglichst kurzer Zeit lösen soll. Das ist Realitätsferner als ein Drogentrip.
(Betonung liegt auf das Zeit opfern... nicht auf die Fahrt selbst)

71 Beiträge seit 2010
vor 13 Jahren

Was soll ich dazu sagen, Arithmetika? Dass auch EBC wieder keine silver bullet ist? Klar. Habe nie das Gegenteil behauptet. Dass EBC OOP und IBC nicht überflüssig machen? Klar. Habe es nie anders gesagt. Nichts geht weg; es kommt nur was hinzu und verschiebt die Positionen der anderen.

Was soll ich sagen zu

Manchmal muss eben eine Komponente von einer oder anderen mehreren wissen oder eine komponente muss mal eben wissen, das vor ihr schritte 1, 2 und 3 erfolgreich oder nur teilweise erfolgreich durchgelaufen sind und dann wird es auch mit EBC haarig....

Das ist entweder richtig, weil es so allgemein formuliert ist. Oder es ist falsch, weil es eben so allgemein formuliert ist und nicht berücksichtigt, dass EBC eben dann doch mal ganz anders ist.

Wie schon an anderer Stelle hier gesagt: Ohne wirklich konkrete Szenarien lässt sich kein Vergleich anstellen.

Wenn ein Prozessschritt auf den Erfolg zweier anderer warten muss, dann ist das mit IBC und EBC gleich. Die Anforderung steckt ja im Problem.

Aber es kann sehr wohl einen Unterschied machen, ob ich sowas mit IBC oder EBC modelliere. Leider, leider erfährt man diesen Unterschied aber erst, wenn man es tut. Und dann noch: wenn man es richtig tut und nicht irgendwie.

Du hast ja schon gesagt, dass es für dich keine Option ist, deinen Duct-Tape-Programmer Stil gegen EBC antreten zu lassen. Schade. Aber vielleicht mag jmd anderes? Denn ein Vergleich bringt immer Erkenntnisse für alle Seiten.

Das Angebot bleibt bestehen. Wer sich als traut und Zeit hat... Im Fernsehsessel haben alle den Marschallstab beim Fußball in der Tasche. Da gibt es dann Millionen Bundestrainer mit guten Ratschlägen. Auf dem Platz jedoch, da sieht es anders aus. Na, ich glaub, ich werd das Angebot mal öffentlicher ausschreiben in meinem Blog.

742 Beiträge seit 2005
vor 13 Jahren

Ich weiß zwar ehrlich gesagt nicht mehr um was es in der Diskussion ging, aber ich schließe mich Uwe81 aber an.

Ich hatte bisher in meinen noch nicht ausreichenden Experimenten die Erfahrung gemacht, dass sich Abhängigkeiten nicht eliminieren lassen. Eine logische Abhängigkeit zu entfernen ist sehr schwer, bis gar unmöglich, je nachdem wie das Problem gestaltet ist.

Mein Code durch EBCs hat sich dabei so verändert, dass die Abhängigkeiten von den Komponenten weg, in die Platinen gewandert ist. Das ist ja ganz nett, weil ich die Komponenten leicht testen kann, aber die Komponenten haben sich zu einem Chaos entwickelt.

Viele meiner Komponenten hatten bisher lineare Abhängigkeiten:

A -> B -> C -> D -> ... (A verwendet B, B verwendet C, ...), mit EBCs hat sich das in eine Hierarchie geändert:

P1 -> A, B, C; P2 -> D, E, F; P3 -> P1, P2 (Platine P1 verwendet A,B und C, Platine P2 verwendet D, E, F, ...):

Das heisst meine Abhängigkeiten hatten sich nur verändert und wurden nicht weniger.

Toll fande ich zu Beginn auch die Möglichkeit mich in den Programmablauf zu hängen und z.B. zu Loggen oder Proxies zu schreiben. Das geht zwar auf so elementare Weise in normalem Code nicht, aber ich sehe jetzt keinen Nachteil Interface Proxies (wie in Mockup Frameworks) oder AOP Frameworks verwenden zu müssen. Insofern bringen mir hier EBC keine neuen Features, vll. bisschen einfacher zu verwenden, aber auch die PostSharp Entwickler machne eine super arbeit).

Insofern muss ich sagen, dass auf Begeisterung Ernüchterung folgte, aber ich habe mich natürlich nicht wie du, Ralf, im Detail damit beschäftigt.

A
69 Beiträge seit 2010
vor 13 Jahren

Wenn ein Prozessschritt auf den Erfolg zweier anderer warten muss, dann ist das mit IBC und EBC gleich.

Das ist vollkommen richtig. Jedoch habe ich etwas anderes behauptet. Ich meinte, das die Komponente oder der besagte Prozessschritt anders reagieren soll, wenn die jeweiligen Vorbedingungen in bestimmten Konstellationen erfolgreich oder nciht erfolgreich waren.

Das sind so die typischen kaufmännischen Abläufe.

Was soll ich dazu sagen, Arithmetika?

Ich habe dich nicht direkt angesprochen. Daher habe ich auch keine Reaktion erwartet. Ich habe meine Meinung kundgetan und begründet, warum ich diese Meinung habe.

Dass auch EBC wieder keine silver bullet ist? Klar. Habe nie das Gegenteil behauptet. Dass EBC OOP und IBC nicht überflüssig machen? Klar. Habe es nie anders gesagt.

ACK. Habe ich auch nicht behauptet.

Meine Kernaussage ist: Wenn man wirklich gut und Produktiv sein will, dann muss man sich auf einen etablierten Standard konzentrieren und darin möglichst Perfekt werden. Kein Projekt der Welt kann es sich leisten, vor der ersten produktiven Zeile Code alle Entwickler auf eine Schulung zu schicken und erstmal ein oder zwei mittlere Lernprojekte durchzuführen, um nachher eine relativ saubere Lösung zu haben.

Daher wird das mit EBC nichts (in meinen Augen), weil man nicht garantieren kann, das jeder (oder fast jeder) auch wirklich weiß was das ist und wenn auch nur einer nix damit anfangen kann, dann kommt dabei nur murks raus. Das ist schon häufig genug bei OOP so und dabei wissen glücklicherweise schon die meisten (hat ja auch sehr lange gedauert), was OOP ist.

1.361 Beiträge seit 2007
vor 13 Jahren

@Meta-Diskussion:
Hach, ich liebe Meta-Diskussionen. Aber leider bringen sie selten etwas. Bei Diskussion zu einem fachlichen Thema kann man Vor- und Nachteile objektiv darlegen. Hingegen ist eine solche Meta-Diskussion höchst subjektiv. Und so gibt es wohl immer komplementäre Meinungen. Wie hier auch. Achso und die Rolle des Vermittler gibt es natürlich auch stets, die eine entbrannte Diskussion etwas abkühlen wollen. Wie immer - alles hier vertreten 🙂 Die Standpunkte werden immer extremer, die Diskussion immer "unsachlicher" zugunsten ausgefeilter Dialektik - das hat zwar auch seinen Reiz - sowohl für Schreiber als auch für Leser. Aber wieso oft, finden die Gesprächspartner doch nie eine gemeinsame Synthese. Und im Gegensatz zu einem Streitgespräch im Fernsehen gibt es hier leider keine zeitliche Obergrenze. Daher zieht sich das online immer unangemessen in die Länge. Nunjaaa, aber am besten hat mir Ralfs "Sonst werd ich noch zynisch" gefallen. 😁 👍 Aber ich nehm seine Forums-Watsche nicht so ernst, keine Sorge. Aber nun zurück zur "fachlichen", meines Erachtens weitaus interessanteren Diskussion.

@Eigentliche Diskussion:
Zuerst muss ich sagen, dass ich ein unwissender Student bin. Mein Erfahrungsschatz ist arg begrenzt. So habe ich nie ernsthaft etwas anderes als objektorientiert programmiert. Natürlich mit BASIC, Pascal, PHP <4, ASM und auch Sprachen wie Lisp, Haskell, Prolog, ... aber über LinesOfCode im 3-stelligen Bereich kam ich dort nie hinaus. (ich nehm LOC jetzt einfach mal als Maß für die Komplexität) Also was ich gut kenne ist OOP, den Rest nur vom Spielen und Hören-Sagen. Was sich manche für OOP also erst erarbeiten mussten, habe ich sozusagen mit der IT-Muttermilch aufgesogen - im Gegensatz dazu ist aber meine Erfahrung eingeschränkt. Aber vielleicht kann ich trotzdem dazu etwas sagen.

Und ich muss sagen EBC find ich vom Motiv gut. (Sowieso begeistern mich als Jungspund neue Techniken immer: heyyy begeisterung!!! 😉 ) Zwar habe ich noch keine "dicken Business-Anwendungen" geschrieben, aber über Programmiertechniken kann ich ja trotzdem schwadronieren.

Warum find ich das gut? Ich mag diese Datenfluss/Event - basierten/orientierten Konzepte. Programme wie
Generic Manipulator Tool
QuartzComposer
oder ein Programm, dass wir auf Arbeit verwenden, finde ich ausgesprochen gelungen. Die Idee "visuell" zu "programmieren" gefällt mir einfach. Ich sitz ja auch seit einiger Zeit hobbymäßig daran, so etwas umzusetzen. (Auch wenn das "Programmieren ohne Programmieren" nicht jedem gefällt: Programme erstellen ohne Programmierkenntnisse wie steht ihr dazu??? )
Allerdings muss meiner Meinung nach das Programmierkonzept sich auch ändern! Für alle imperativen Sruktur-Elemente wie If/While/For einfach kleine Grafiken einzufügen und somit nur den sequentiellen Kontrollfluss darzustellen ist keine Leistung. Dann sind wir beim AppInventor, der auch nur glossy, bunte Nassi-Shneiderman-Diagramme abbildet.

Wenn man hingegen "richtig" graphisch programmiert, stellt man wohl auf abstrakter Ebene irgendwie "Funktionseinheiten" als Kästchen/Kreise/Knubbel dar. Und deren Interaktion durch Linien. Im Grunde läuft es immer auf einen Graphen hinaus. Und wenn dieser Graph gerichtet ist, liegt das Datenfluss-Konzept schon sehr nah.

Und ich muss sagen, dass mich EBC stark an dieses Fluss-Konzept erinnert. Besonders EBC 2. Zwar spricht ralf ja konkret von Prozessen und weniger von Daten. Aber die beiden Begriffe ergeben ja erst zusammen ein einheitliches Bild. Prozesse verarbeiten Daten - Daten werden in Prozessen verarbeitet. Insofern passt das trotzdem des anderen begrifflichen Schwerpunktes schon - schließlich sind es die beiden Seiten ein und der selben Münze. So oder so hat man einen Fluss. Dass der Name EBC nahelegt, dass die Fluss-Steuerung autonom über "Events" gesteuert wird, ist auch nicht verwunderlich. Ob nun nach Push- oder Pull-Prinzip nachfolgende Prozesse können erst aktiv werden, wenn vorangegangene abgeschlossen sind. Und das wird eben "signalisiert", woraufhin die Daten weiterfließen können, zum nächsten Teilprozess. Für mich ergibt sich dort also schon ein Gesamtbild. Mich würde interessieren, ob Ralf das ebenfalls so sieht - oder mehr in eine andere Richtung drängen möchte.

Nun hat Ralf letztens auf Twitter folgendes gepostet:

PDF-book on Flow-Based Programming. Something for anyone interesed in Event-Based Components:
>
. Und der Verweis ist wirklich angebracht, denn an genau dieses Buch musste ich denken, als ich das erste mal von EBCs gelesen habe. (Achtung: Lesenswert!) Nun frage ich mich: Will Ralf weiter in diese Richtung drängen? oder wo will er enden mit seinen EBC? Weil im Grunde ist es nichts anderes - nur alter Wein in neuen Schläuchen. Aber ok, da sich das Paradigma (noch) nicht flächendeckend durchgesetzt hat, sollte man es ruhig nochmals und nochmals aufräufeln!
Aber vielleicht will Ralf etwas völlig anderes mit seinen EBC - nur ist mir das dann noch etwas unklar.

Wenn es aber doch in diese Flow-Based-Richtung geht, dann sind EBCs aber noch sehr zurückhaltend. Was es zuerst braucht ist eine ordentliche Laufzeitumbegung (wie C#FBP). Ich bezweifle dass man allein mit dem Event-Mechanismus oder Funktions-Delegaten das ordentlich umsetzen kann.
Den Vorteil des Fluss-basierten sehe ich gerade darin, dass man sich _nicht _ über das konkrete Laufzeitverhalten kümmern muss, (Weshalb parallelisieren so einfach wird) das ist Aufgabe der Laufzeit. (Genau wie Speicherverwaltung das mitlerweile auch ist)

Nun aber mal zum Prozeduralen. Ich verstehe Herbivores Einwand so, dass sich EBCs zu stark vom Objektorientierten lösen. Objektorientierung ermöglicht ja gerade das Zusammenfassen von Funktion und Daten in "Objekte", also Modularitäts-Einheiten. Während EBCs (und flow basiertes) vornehmlich die Funktionalität selbst als Modularitäts-Einheit auffassen. Im Grunde wie bei der Prozeduralen Programmierung - was wohl die Ähnlichkeit ausmacht.
Aber allein mit diesem Ansatz müsste man ebenso funktionale Sprachen als "prozedurale Altlast" beschimpfen.

Nun finde ich aber, dass prozedurale Programmierung im Grunde nur die Wiederverwendung von Code-Abschnitten ermöglicht - mehr nicht. Eine Alternative zu Copy'n'Paste. Während die Funktionale Programmierung der Funktion als solches eine eigene Bedeutung zukommen lässt. Das ist eine neue Qualität! Und so ähnlich ist es bei EBC2 / FBP: Die Funktionseinheiten/Module/EventBasedComponents dienen direkt der Prozess-Modellierung. Sind also sowohl Abbildung und Realisierung des zugrunde liegenden Prozesses. Und auch das ist eine neue Qualität.

Die Nähe zum Objektorientieren Design geht natürlich verloren. Aber genau das ist ja die Idee. Oft genug lassen sich Begebenheiten nicht "natürlich" in Objekte quetschen. Da sitzt man vielleicht mit seinen CRC-Kärtchen und versucht ein sinnvoles Object-Theater umzusetzen, aber alles wirkt gekünstelt. Wenn der Hintergrund ein Prozess ist, sollten wir auch an Prozesse denken dürfen. Und warum dann nicht Prozess-Orientiert designen? (Und mit EBC/FBP dann sogar so implementieren) Also ich bin dafür.

Nun muss das natürlich nicht im Widerspruch zu allem ObjektOrientierten stehen. Die Daten, die im Prozess verarbeitet werden - das müssen ja keine "passiven", reinen Datenklassen sein. Ob jetzt nun Active Records oder sonstige "aktive" Klassen, ist ja egal. Aber auf der Ebene kann ruhig objektorientiert gekapselt werden.

Nunja, den eigentlichen Vorteil sehe ich aber woanders. (Ich zitiere einfach mal aus Morrison's Buch🙂

Zitat von: J. Paul Morrison (Flow Based Programming)
[...] in FBP application development there are two distinct roles: the component builder and the component user or application designer. The component builder decides the specification of a component, which must also include constraints on the format of incoming data [...] and the format of output [...] The specification should not describe the internal logic of the component, although attributes sometimes "leak" from internal to external (restrictions on use are usually of this type). The application designer builds applications using already existing components, or, where satisfactory ones do not exist, s/he will specify a new component, and then see about getting it built. Component designers and users may of course be the same people, but there are two very different types of skill involved. [...]

Dass dort unterschiedliche Fähigkeiten gefragt werden, sehe ich absolut genauso. Und EBC/FBP Ermöglicht hier endlich eine Trennung! Mit solchen (EBC-)Komponenten kann ich den Prozess direkt beschreiben. Das ist die Ebene auf der man mit EBC arbeitet. Die von Ralf beschriebene Ebene der Platinen-Verschaltung! Und die ist eben schon etwas anderes als das "Programmieren der darunterliegenden Komponenten". Also sollte man auch ein anderes Paradigma einsetzen (dürfen). Und meines Erachtens versucht genau hier EBC anzusetzen.

Ich sehe im Übrigens durchaus Analogien zu WPF. Denn GUI und Logik sollte nicht nur auf dem Papier getrennt sein, und auch nicht nur im Code nachher wenig Abhängigkeiten haben - man sollte zudem auch anders entwickeln - mit einem anderen Paradigma. Genauso macht es WPF vor. Deklarativ mit XAML. GUIs lassen sich vielleicht so viel besser beschreiben. Das ist der eigentliche Vorteil von WPF. Nachteil ist nur, dass es wohl zu wenig WPF-Designer gibt.

Ich möchte jetzt nicht mit einem pauschalisierenden "Für jede Aktion das richtige Werkzeug" abschließen - auch wenn es stimmt - denn (Das Grundprinzip hinter / Meine Sicht von) EBC hat mehr Potential als nur ein Nischenwerkzeug zu sein.

Soweit meine Sicht von EBCs. Vielleicht geprägt von meinem Vorwissen. Jedenfalls finde ich die ganze "Reduzieren von Abhängigkeiten zwischen Interfaces/Klassen"-Geschichte sowas von unrelevant. Wie Herbivore in einem anderen Post schon klar herausgestellt hat, reduzieren sich keineswegs die Abhängigkeiten.
Ich finde nur, dass die Abhängigkeiten der Prozess-Verarbeitungs-Schritte untereinander auf einer völlig neuen Ebene beschrieben werden. Das macht den Reiz der Trennung zwischen Platine und Bauelement. Wenn alles irgendwie irgendwo Klassen in meinem OODesign sind, dann erkennt man höchstens am Namen "BlaBlaBla-Manager", dass diese Klasse eine besondere, integrierende Aufgabe übernimmt. Mit EBC bekommen diese integrierenden Teile (Platinen) einfach eine eigene Rolle und damit eine neue Qualität. Endlich wird die eigentliche Prozess-Kette explizit - und damit durchschaubarer, verständlicher, variabler, wartbarer, (weitere positiv besetzte Worte, die jede in die Runde wirft, wenns um Modularität geht 😉 ... ).

So, das war jetzt einfach mal meine Meinung zu EBC. Vielleicht interessiert die ja wen 😉 Zumindest habe ich auch begründet.

beste Grüße
zommi

PS: Was die Windows Workflow Foundation zu all dem Zeug leistet, kann ich nicht sagen. Habe mir das noch nie angeschaut.

PPS: Hab mich vor einiger Zeit mal mit Lucid beschäftigt. Sehr schnuckelig 😉

742 Beiträge seit 2005
vor 13 Jahren

Daher wird das mit EBC nichts (in meinen Augen), weil man nicht garantieren kann, das jeder (oder fast jeder) auch wirklich weiß was das ist und wenn auch nur einer nix damit anfangen kann, dann kommt dabei nur murks raus. Das ist schon häufig genug bei OOP so und dabei wissen glücklicherweise schon die meisten (hat ja auch sehr lange gedauert), was OOP ist.

Dann würden wir ja immer noch in den Höhlen hocken und unser Fleisch roh essen, weil das der Standard wäre und noch nicht alle wüssten, dass man Fleisch auch braten kann.

Also das ist eine sehr komische Begründung. Ich kenne kein Unternehmen, indem jeder mit allen Technologien vertraut ist. Softwareentwicklung ist ja nicht homogon, sondern heterogen, gerade wenn es große Projekte sind. Da kommuniziert die komponentenorientierte Silverlight APP mit MVVM Pattern und WCF mit dem ohne OOP geschriebenen PHP Service. Dafür brauchts nur eine Vereinbarung und nicht gleich einen Standard.

A
69 Beiträge seit 2010
vor 13 Jahren

Dann würden wir ja immer noch in den Höhlen hocken und unser Fleisch roh essen, weil das der Standard wäre und noch nicht alle wüssten, dass man Fleisch auch braten kann.

Ich dachte mir schon, das jemand mit diesem Argument kommt.
Würdest du auch demjenigen folgen, der behauptet, das das Fleisch viel besser schmeckt, wenn man dabei zeitgleich von der Klippe springt?

Fakt ist: mit EBC kann man nichts neues machen, was man nicht vorher schon produktiv und gut machen konnte. Man gewinnt durch EBC nichts in meinen Augen. Das einzige, was man momentan bei der verwendung von EBC in kauf nimmt, ist mehr Risiko durch Unkenntniss mehrerer als im vergleich zu OOP.

Ich kenne kein Unternehmen, indem jeder mit allen Technologien vertraut ist.

Habe ich ja auch nciht behauptet. Ich denke nur, das wenn man mit c# programmiert, das man davon ausgehen kann, das die meisten OOP kennen und wir reden hier doch über EBC in c# oder?

71 Beiträge seit 2010
vor 13 Jahren

Hier die "offizielle" Herausforderung an alle, die meinen, EBC sei keine Alternative zu ihrer eigenen Entwicklungsmethode:

Enter the Matrix!

Seid mutig, zeigt was ihr könnt!

71 Beiträge seit 2010
vor 13 Jahren

Würdest du auch demjenigen folgen, der behauptet, das das Fleisch viel besser schmeckt, wenn man dabei zeitgleich von der Klippe springt?

No risk, no fun.

No pain, no gain.

Das war dasselbe, als OOP die Strukturierte Programmierung ersetzt hat.

Das ist jetzt der Fall, da FP OOP den Rang beginnt abzulaufen.

Das war übrigens auch der Fall, als Hochsprachen Assembler verdrängt haben. Was zeterten die alten Kämpen, dass das der Untergang performanter Verarbeitung sei.

Und somit sind wir jenseits der Argumente angekommen. Jetzt geht es um grundsätzliche persönliche Haltungen. Wie risikoavers ist jemand; wie sehr liebt er die Sicherheit, das heimelige Gefühl des Bewährten; wie offen für Neues ist sie?

Da helfen dann keine "Beweise" und nix. Da hilft am Ende nur die Masse, die es halt einfach anders tut als der, der sagt, EBC (oder FP, Rx, Erlang usw.) sei wie der Sprung von einer Klippe.

71 Beiträge seit 2010
vor 13 Jahren

@zommi: Vielen Dank für deinen Beitrag. Hat mir gut gefallen. Eine differenzierte Sichtweise inkl. Mit-/Weiterdenken. Schau doch mal in der EBC-Diskussionsgruppe hier vorbei. Da können wir in die Einzelheiten gehen.

An dieser Stelle nur soviel: Imperative Programmierung ist eben nicht (!) das Thema von EBC. EBC-Diagramme sollen keine Flowcharts sein. Das ist ja der Trick. Wer beim Modellieren mit EBC an Schleifen und Fallunterscheidungen denkt, ist schon zu tief in der Abstraktion abgestiegen. Damit haben EBC nichts zu tun.

Dass EBC erstmal eine richtige Laufzeitumgebung brauchen würden, sehe ich jedoch nicht. Die Praxis zeigt das Gegenteil. Ich habe noch keine solche Umgebung vermisst.

Bei der Verdrahtung kann sich noch was tun im Sinne einer Hilfestellung und "Reverse MDA". Ein Bus ist auch schon implementiert und macht es in manchen Szenarien einfacher zu verdrahten. Der Übergang von/nach Rx ist hergestellt und schließt EBC insofern an ein für Microsoft zentrales Programmiermodell an.

EBC sind damit natürlich nicht am Ende. "Panta rei" gilt auch hier - quasi im doppelten Sinn 😃 Gerade deshalb bin ich ja am kristischen Austausch (!) interessiert.

A
69 Beiträge seit 2010
vor 13 Jahren

Das war dasselbe, als OOP die Strukturierte Programmierung ersetzt hat. Einen essentiellen Punkt scheinst du da außer acht zu lassen. Mit Hochsprachen konnte man schneller zum Ziel kommen. Daher hatte man einen spürbaren und vor allem messbaren Mehrwert. EBC bietet das nicht.

742 Beiträge seit 2005
vor 13 Jahren

Das hat uns die Erfahrung und wohl auch einige Studien gezeigt. Und das wird es auch bei EBC - oder eben nicht. Wer weiß das schon, aber dafür ist es noch zu früh denke ich. Es muss sich ja in der Alltags und Projektwelt noch beweisen und das dauert eben.

71 Beiträge seit 2010
vor 13 Jahren

Mit Hochsprachen konnte man schneller zum Ziel kommen. Daher hatte man einen spürbaren und vor allem messbaren Mehrwert. EBC bietet das nicht.

Sorry, du pickst dir raus, was dir passt. Solange du schneller zum Ziel kommst, aber der Code zu langsam ist, nützt die Zielerreichung nix. Den Assemblerjüngern war eben "schneller zum Ziel" ziemlich egal. Sie haben behauptet, dass die Ergebnisse zu langsam seien.

Wenn ich dir etwas von Evolvierbarkeit sage, du aber einen anderen Wert hast, dann nützt dir das auch nix. Ich weiß nicht, was dein Wert heute ist. Aber das Argument ist, dass irgendwas wichtiger sei als Evolvierbarkeit (das mal als beispielhafter Wert).

Und noch ein Beispiel aus der Geschichte: Musik wurde seit Urzeiten nur mündlich tradiert. Dass man sie aufschreiben könnte oder sollte... das kam niemanden so recht in den Sinn. Dabei haben alle mit den Problemen des Stille-Post-Effektes gekämpft.

Dann trat Guido von Arezzo (http://de.wikipedia.org/wiki/Guido_von_Arezzo) auf. Der erfand die Notenschrift und war daher in der Lage, Musik verlustfrei weiterzugeben.

Hat da die Musikwelt gejubelt? Ne. Die haben sie gewehrt. Iiiiih, da musste man ein neues System lernen. Wie dooof. Da lebte man lieber mit den Problemen des alten weiter.

Nun ja, am Ende hat sich Notenschrift durchgesetzt, wie wir wissen. Und erst dadurch wurde Musik wie Mozarts Zauberflöte möglich.

Jetzt will ich nicht sagen, EBC seien von gleicher Bedeutung wie die Notenschrift. Aber dass Leute widerständig sind, ist für mich auch kein Zeichen dafür, dass EBC nix taugen. Es kommt halt immer auf die Argumente an. Und es kommt auf die rein persönlichen Werte an. Für manche ist Objektorientierung halt ein Wert. Auch ok. Für manche Performance. Für manche aber auch was Neues/Anderes. Und so gehen die weiter und probieren es.

1.134 Beiträge seit 2004
vor 13 Jahren

schade dass diese eigentlich sehr interessante Diskussion still steht.
Es geht doch auch nicht darum ob EBC ein "Allheilmittel" oder die "Pest" sind.

Veränderungen sind immer schwer, es braucht überwindung sich objektiv damit zu beschäftigen. (ohne jetzt EBC's zu werten).

Gitb es jemanden der EBC's im Produktiveinsatz hat ?
Und wenn ja wie sind da die Erfahrungen?

Ich setze EBC's seit 3 Monate ein. Zum einen in Teilbereichen eines bestehenden Systems (> 300k Zeilen Code -5 Entwickler) und zum andern in Greenfield applikationen.

Ein Beispiel in dem EBC's für mich eindeutig Vorteile bringen und inzwischen selbst die Skeptiker überzeugt hat, sind Cross Cutting Concerns.

Tracing, Login,Security,UserManagement, Caching,... Code schrumpft teilweise um 50% (!) und erleichtert die verwendung von Basis komponenten.

Im Sinne von SRP, SOC; eindeutig Vorteile

Schwieriger wird die Beurteilung bei EBC's in Domain Spezifischen komponenten, hier sehe ich vor und nachteile (bsp. pot. komplexe Boards)
Aber das sprngt den Rahmen der Diskussion.

Es würde mich freuen wenn eine Diskussion wie diese Konstruktiv und mit von 2 Vertretern gegensätzlicher Standpunkte in konstruktiver und angstfreier manier geführt werden würde.

Wichtig wäre zum beiden wo liegt ein Konsens ?
Z.Bsp. CCC und Topologie aus der DomainLogik zu halten ist für mich inzwischen eine zwingende Anforderung an guten code. Ob das via AOP oder EBC (1 oder 2) oder IBC passiert, ist erst die nächste frage.

Gibt es denn überhaupt soweit einen Konsens ?

Und das wäre für jeden ein Mehrgewinn.

Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)

S
902 Beiträge seit 2007
vor 13 Jahren

Ich bin auch wieder mal da!
Wollte mit meinem thread keinen streit vom zaun brechen =(

@ralfw: Auch wenn ich mich vielleicht mit dem "engagement", wie hier das für und wider diskutiert wird nicht ganz anfreunden kann, möchte ich trotzdem sagen das die ebcs mich wahnsinnig interessieren...und darum sollte es ja hier gehen.
Ich finde es gut, dass es überhaupt leute gibt, die sich sowas einfallen lassen. Es ist dann natürlich klar, dass man "sein baby" ins trockene bringen möchte.

@Haggy: danke, denn dein beitrag ist eigentlich genau das, worum es mir eingangs ging. Ich kann mir eben ebcs für ccc super vorstellen. Aber mir macht es eben probleme bei domainlogik. Produktiv habe ich sie noch nicht im einsatz, eben weil mir da noch zu viele fragezeichen über dem kopf stehen. Sollten diese allerdings beseitigt werden, würde ich ebcs gern produktiv einsetzen.

Hinweis von herbivore vor 13 Jahren

Für das Thema mit der Domainlogik gibt es aber den anderen Thread: EBCs in Informationssystemen (verteilt). Bitte dafür den benutzen.

Aber auch in diesem Thread hier geht es schon wieder sehr konfus zu. Der Titel hier ist ja "EBCs 2.0, deren Nähe zur prozeduralen Programmierung und deren Nutzen". Leider wurde EBC 1.0 und EBC 2.0 hier ziemlich in einen Topf geworfen.

1.134 Beiträge seit 2004
vor 13 Jahren

Das dieses Diskussion aus dem Ruder lieft hat ja nichts mit deiner Frage zu tun.

~~
Für mein Gefühl gehts da eher um persönliche Dinge.

Ein posting zu EBC's wurde vor ein paar wochen auch kommentarlos gelöscht.

Ich finde es sehr schade dass bei einem sehr guten Forum, Themen wegen persönlichen Ansichten nicht diskutiert werden könne...[/color]~~
Bei dem gelöschten Thread, handelte sich um ein Mißverständniss bzw. ein Bedienungsfehler meinerseits, wurde mit herbivore geklärt.

Hinweis von herbivore vor 13 Jahren

Ich bin froh, dass wir das Missverständnis ausräumen konnten.

Wenn ihr glaubt, dass mal etwas schief gelaufen ist, wendet euch bitte - immer zuerst per privater Nachricht - vertrauensvoll ans Team. Wie das am einfachsten geht, steht in Kontakt zum Team. Dadurch lassen sich Missverständnis klären, bevor sie durch einen öffentlichen Post unnötig weitere Irritationen im Forum auslösen.

Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)

U
282 Beiträge seit 2008
vor 13 Jahren

Bezieht sich auf eine Frage einige Beiträge weiter Vorne.

Warum sollte eine EBC-Architektur zu mehrfacher Datenhaltung führen? Das verstehe ich nicht. Wenn du früher ein Repository hattest, dann kannst du mit EBC 1.0 und auch EBC 2.0 weiterhin ein zentrales Repository haben.

Damit Komponenten entkoppelt sind, darf IMHO nicht nur eine Komponente das Interface der anderen nicht kennen müssen, sondern auch sehr wenige Annahmen über deren Zustände machen.

Nun gebe es ein zentrales Repository, auf das ale Komponenten (über EBC-Methoden, also von außen verdrahtet) zugreifen. Dann hat eine Komponente also Pins
Out_PointGenerated
Out_PointSelected
Out_PointRestricted
In_PointStateChanged
In_PointSelected
In_PointAdded
Func<Point, PointState> GetState
...

Nun muss ich Annahmen machen: Wenn ich Out_PointGenerated aufrufe, kommt In_PointAdded zurück. Bei Out_PointSelected wird In_PointSelected aufgerufen. Bei Out_PointRestricted wird (wenn der Punkt nicht bereits restringiert ist) In_PointStateChanged aufgerufen. Nachdem Out_PointGenerated aufgerufen wurde, darf ein aufruf von GetState nicht fehlschlagen.

Dann sind die Komponenten aber nicht mehr entkoppelt. Zwar braucht eine Komponente die andere nicht zur Compile-Zeit, aber durch die ganzen Verhaltensannahmen sind sie gekoppelt.

Das ist bei einem Interface nicht anders. Aber: Wenn ich bei einem Interface die Methode "AddPoint" aufrufe (entspricht Out_PointGenerated) ist es "natürlich" zu erwarten, dass "PointsAdded"-Event geworfen wird. Wenn ich "AddPoint" aufgerufen habe kann ich erwarten, das der Punkt da drin ist und "GetState" funktioniert.

Um diese Kopplung zu vermeiden, müsste jede Komponente alle Punkte verwalten, alle Zustände kennen und nur auf ihren eigenen Zuständen arbeiten. Dann gäbe es nach außen sehr wenige nachrichten, die jeweils auf Validität geprüft werden können.

Vielleicht ist das mein Hauptkritikpunkt: Wenn meine Komponente zwei Methoden hat:
Out_DoSomething
GetSomething

und nach Out_DoSomething(a) muss GetSomething(a) funktionieren oder einen bestimmten Wert haben, nützen mit EBC nichts mehr. Denn dann erwarte ich, dass die Komponenten in einer bestimmten Art und Weise Verdrahtet sind. Damit ist die Kopplung da. Und dann ist mir lieber, die Abhängigkeit steht mittels Interface relativ explizit im Code.

U
282 Beiträge seit 2008
vor 13 Jahren

Noch als Ergänzung zu dem Thema Abhängigkeit:

Habe mit einem Bekannten mal die Diskussion gehabt, ob Templates oder Polymorphie besser sei (in C++, auch wenn das natürlich so pauschal nicht zu diskutieren war).

Sein Argument war, dass bei Templates keine Abhängigkeiten entstehen würden.

Also bei Polymorphie: Die Methode
Sort(MeinTyp, ICompoarer<MeinTyp>)
muss das interface IComparer kennen.

Bei Templates: Die Methode
template<typename TComparer>
Sort(MeinTyp, TComparer)
muss den Comparer nicht kennen.

Für mich war das aber keine Reduktion der Abhängigkeit. Sie ist nicht zur KompileZeit vorhanden, aber sie ist implizit da, weil angenommen wird, dass TComparer bestimmte eigenschaften hat.

So ähnlich sehe ich es mit EBC:
Wenn eine Komponente nur dann funktioniert, wenn ihre Pins in einer gewissen weise verdratet sind, ist sie nicht mehr unabhängig vom System. Dann verschleiert EBC die Abhängigkeiten eher.

Daher bleibt mein Statement: EBC weist auf Probleme hin (Abhängigkeiten zu Interfaces sind auch Abhängigkeiten). Wenn man diese einfach Auflösen kann in unabhängige "Pins" (auch wenn ich bei Methoden und Events in alter notation bleibe) mache ich es gerne und reduziere die Abhängigkeiten. Ist das Interface aber zu komplex bleibe ich lieber bei IBC mit expliziten Abhängigkeiten.

71 Beiträge seit 2010
vor 13 Jahren

@Uwe81: Logische Abhängigkeiten gehen mit EBC natürlich nicht einfach so weg. Darüber müssen wir hier also nicht diskutieren.

Aber ich ahne, dass du dir das EBC-Leben zu schwer machst. Du denkst nämlich in deinem Beispiel in EBC 1.0. Und du nutzt keine ad hoc Pins für die Anlieferung von Responses zu Requests.

Diese Probleme verschwinden mit EBC 2.0.

Um dir das zu erläutern, müsstest du aber das Problem erklären, das zu zu lösen versuchst.

5.941 Beiträge seit 2005
vor 13 Jahren

Hallo Arithmetik

Einen essentiellen Punkt scheinst du da außer acht zu lassen. Mit Hochsprachen konnte man schneller zum Ziel kommen. Daher hatte man einen spürbaren und vor allem messbaren Mehrwert. EBC bietet das nicht.

Sagt wer? Du?

Erstmal: EBCs bieten auch Mehrwert(e), ob das jetzt die Produktivität sein mag oder nicht, wage ich noch nicht zu beurteilen.

Ich weiss nur, das ich mit einem Kollegen zusammen per EBC, eine komplexe Implementation in sehr kurzer Zeit, vollkommen ohne Abhängigkeiten innerhalb der Komponenten selber entwickeln konnte, und testbar war am Ende alles, ohne Zusatzaufwand.

Was ich damit sagen will: Produktivität muss kein Mehrwert von EBC sein. Vielleicht ist es ja einer, aber die Primärmehrwerte gehen eher in Richtung der kompletten Entkoppelung der kleinen Komponenten, nur die Blackbox weiss über die Verbindungen Bescheid.

Bitte schildere doch mal deine Ansicht.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

4.207 Beiträge seit 2003
vor 13 Jahren

Hallo "Kollege" 😉!

@ Arithmetik: Jups, kann mich da Peter nur anschließen. EBCs erfordern ein Umdenken in Richtung streambasierter Datenverarbeitung, aber hey, auch die OOP hat ein Umdenken erfordert. TDD ebenfalls. Funktionale Programmierung erfordert ein Umdenken. Na und?

EBCs haben diverse sehr deutliche Vorteile, der wichtigste aus meiner Sicht ist die extreme Entkopplung. Die Eignung für TDD & Co sind daraus eigentlich nur Folgen.

Aber wie Ralf ja schon angeboten hat: Wer Zweifel hat und ein ehrliches Interesse an einem Vergleich, ist herzlich zu einem "Shootout" eingeladen.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

1.134 Beiträge seit 2004
vor 13 Jahren

Dieses Shootout fände ich sehr spannend ! 😃
Wenn es dazu was gibt könnt ihr ja nochmal bescheidgeben.

Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)