Vorteile von Nicht-Web-Applikationen?

[u_ser-l]

;fricky schrieb:

dazu brauchste nicht unbedingt programme, die sich, während sie laufen, verändern lassen. und selbst wenn, so'nen grossen vorteil bringts doch auch nicht.

das ist die klassische Denkweise von Software als statischem technischem Produkt.

Software, die sich zur Laufzeit verändern läßt und deren Code in der Objektwelt gleichrangig mit Daten repräsentiert ist, würde ungeheure Möglichkeiten eröffnen. Programmierung wird dann richtig interaktiv.

Beispiel CAD. Viele heutige CAD-Systeme sind objektorientiert in der Weise, daß die graphischen Objekte bspw. ein Kontextmenü mit den wesentlichen Methoden haben und im System repräsentiert sind als Liste von Eigenschaften wie Position, Farbe, Material ... usw.

Dabei wird im Prinzip ein dynamisches Objektsystem implementiert in einer Programmiersprache wie C++, die bereits ein statisches Objektsystem besitzt bzw. simuliert.

Würde man in einer echten Objektwelt arbeiten, bräuchte man diese Stapelung zweier Objektsysteme nicht - die CAD-Objekte könnten im Objektsystem derjenigen (dynamischen) Programmiersprache repräsentiert sein, in der das CAD-Programm implementiert ist, und dessen Objektwelt einfach mitbenutzen.

Um Makros und Skriptfunktionen im CAD-System zu definieren, bräuchte man keinen weiteren Makro- oder Skriptinterpreter, sondern würde einfach den Klassen des CAD-Systems nach Bedarf neue Methoden zufügen, man könnte sogar zur Laufzeit ausgewählten einzelnen CAD-Objekten neue Methoden zufügen und entfernen, gerade so, wie man es aktuell braucht.

;fricky schrieb:

und das mit den file-basierten quelltexten ist doch überall da angenehm, wo man sowieso ein filesystem hat.

eben. Und wieso hat man überall ein Filesystem?

Zur Spezifikation von Objekten braucht man nicht unbedingt ein Filesystem, nur ein Format.

[Dravere]

u_ser-l schrieb:

Um Makros und Skriptfunktionen im CAD-System zu definieren, bräuchte man keinen weiteren Makro- oder Skriptinterpreter, sondern würde einfach den Klassen des CAD-Systems nach Bedarf neue Methoden zufügen, man könnte sogar zur Laufzeit ausgewählten einzelnen CAD-Objekten neue Methoden zufügen und entfernen, gerade so, wie man es aktuell braucht.

Ich soll meinem Bruder erlauben, dass er in meinem Programmen reinpfuscht? Hast du einen Knall? (Bruder ist Architekt)
*SCNR*

Aber so wie ich das bisher gelesen und verstanden habe, machst du meiner Meinung nach einen extrem wichtigen Fehler: Benutzer und Programmierer sind zwei unterschiedliche Dinge. Es ist völlig unrealistisch zu denken, dass alle Benutzer auch Programmierer sein könnten.

Grüssli

[;fricky]

u_ser-l schrieb:

Software, die sich zur Laufzeit verändern läßt und deren Code in der Objektwelt gleichrangig mit Daten repräsentiert ist, würde ungeheure Möglichkeiten eröffnen. Programmierung wird dann richtig interaktiv.

klar, wo so ein system benötigt wird, hat es vorteile. aber z.b. der user der CAD-software möchte mit den, für ihn leicht verständlichen und auf seine welt zurechtgeschnittenen, CAD-objekten hantieren und nicht mit einer viel abstrakteren 'general purpose' OO-programmiersprache.

u_ser-l schrieb:

;fricky schrieb:

und das mit den file-basierten quelltexten ist doch überall da angenehm, wo man sowieso ein filesystem hat.

eben. Und wieso hat man überall ein Filesystem?

weil's intuitiv, einfach ist und den menschlichen 'ordnungssinn' anspricht. ein dateisystem mit dateien, verzeichnissen, unterverzeichnissen usw. ist für niemanden eine grosse intellektuelle herausforderung.

[MisterX]

Das totschalgargument gegen Webapplikationen:

Du mußt dich an jede Menge Datenschutzbestimmungen halten, wenn die Daten auf dem Server berechnet werden. Deutsche und europäische.
(Ich habe diese mal ansehen müssen. Alleine die Texte mit den Vorschriften sind über 40 Seiten im deutschen unf 60 Seiten im Europäischen Recht. Und dazu so geschrieben das sogar ein Anwalt Probleme hat diese zu verstehen.)

Wenn man das nicht tut, kommen schnell Abmahnungen in 10000 er Höhe auf einen zu.

Desweiteren kommt nicht mehr das Kaufrecht sondern das Mietrecht zum Tragen ,wenn man Rechenkapazität auf dem Server für eine bestimmte Zeit bestellt.
(Wer ist schon so doof das permanent bei nur einmaliger Bezahlung anzubieten bei laufenden Serverkosten)
Damit muß die Mietsache aber wärend der gesamten Mietzeit in ordnung gehalten werden. (Und nicht nur 2 Jahre Gewährleistung wie beim Kaufvertrag). Dadurch bastelt man sich mit Updates zu tode. Besondern wenn neue Betriebsysteme rauskommen, auf denen es laufen muß.(Sonst ist es ja nicht in Ordnung)

Programmiertechnisch ist das kein Problem web Applikationen zu erstellen. Aber rechtlich kann einem die erste Abmahnung über 25000€ (Ja die Summen können hier locker so hoch ausfalen) von irgend einem exotischen Datenschutzgesetz was man nichtmals kennt den Tag ganz gut versauen.

Keine Rechtsberatung. Nur meine Meinung.

[jenz]

u_ser-l schrieb:

;fricky schrieb:

dazu brauchste nicht unbedingt programme, die sich, während sie laufen, verändern lassen. und selbst wenn, so'nen grossen vorteil bringts doch auch nicht.

das ist die klassische Denkweise von Software als statischem technischem Produkt.

Software, die sich zur Laufzeit verändern läßt und deren Code in der Objektwelt gleichrangig mit Daten repräsentiert ist, würde ungeheure Möglichkeiten eröffnen. Programmierung wird dann richtig interaktiv.

Beispiel CAD. Viele heutige CAD-Systeme sind objektorientiert in der Weise, daß die graphischen Objekte bspw. ein Kontextmenü mit den wesentlichen Methoden haben und im System repräsentiert sind als Liste von Eigenschaften wie Position, Farbe, Material ... usw.

Dabei wird im Prinzip ein dynamisches Objektsystem implementiert in einer Programmiersprache wie C++, die bereits ein statisches Objektsystem besitzt bzw. simuliert.

Würde man in einer echten Objektwelt arbeiten, bräuchte man diese Stapelung zweier Objektsysteme nicht - die CAD-Objekte könnten im Objektsystem derjenigen (dynamischen) Programmiersprache repräsentiert sein, in der das CAD-Programm implementiert ist, und dessen Objektwelt einfach mitbenutzen.

Um Makros und Skriptfunktionen im CAD-System zu definieren, bräuchte man keinen weiteren Makro- oder Skriptinterpreter, sondern würde einfach den Klassen des CAD-Systems nach Bedarf neue Methoden zufügen, man könnte sogar zur Laufzeit ausgewählten einzelnen CAD-Objekten neue Methoden zufügen und entfernen, gerade so, wie man es aktuell braucht.

;fricky schrieb:

und das mit den file-basierten quelltexten ist doch überall da angenehm, wo man sowieso ein filesystem hat.

eben. Und wieso hat man überall ein Filesystem?

Zur Spezifikation von Objekten braucht man nicht unbedingt ein Filesystem, nur ein Format.

das erinnert mich aber stark an sowas:
http://en.wikipedia.org/wiki/Inner-platform_effect
oder hier:
http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx

oder ist das etwa was ganz anderes?

[u_ser-l]

;fricky schrieb:

der user der CAD-software möchte mit den, für ihn leicht verständlichen und auf seine welt zurechtgeschnittenen, CAD-objekten hantieren und nicht mit einer viel abstrakteren 'general purpose' OO-programmiersprache.

geeignete Implementationssprachen können so wenig Syntax haben, daß man in ihnen weitgehend beliebige user-friendly domain-specific languages als Subsprachen definieren kann:

circ1 := Circle centerX: 37.5 mm centerY: 89 mm radius: 1.342 cm
circ2 := circ1 scaleBy: sqrt 2.
...

Dazu braucht man auch kaum mehr Schulung als für eine programminterne Makrosprache.
Die gängigen "Syntaxmonster" eignen sich dafür in der Tat weniger.

;fricky schrieb:

weil's intuitiv, einfach ist und den menschlichen 'ordnungssinn' anspricht. ein dateisystem mit dateien, verzeichnissen, unterverzeichnissen usw.

ja, in einer nicht wirklich objektorientierten Computerwelt: "File = Papierblatt", "Programm = Black box", "Verzeichnis = Aktenordner". Die elektronische Analogie zu einem herkömmlichen Papierarchiv. Verwaltet man alles dies als Objekte, bräuchte man so etwas nicht, im Minimalfall würde ein Speicherformat zur Spezifikation von Objekten ausreichen.

[u_ser-l]

;fricky schrieb:

in zukunft wirds alles mögliche geben, sogar noch assembler-programmierer und chipdesigner. wie kommste auf den dreh, dass dynamische OO-systeme (oder überhaupt OO-basierte systeme) dominieren werden?

weil die Software- und Programmiersprachenwelt seit mind. 2 Jahrzehnten konsequent dorthin zu konvergieren scheint. Wenn man sich vergegenwärtigt, welche gigantischen Mühen aufgewendet werden, um klassischen Programmiersprachen ein wenig OO beizubringen, wird klar, wie attraktiv den meisten das Ziel der Programmierung in echter OO erscheinen muß - ob bewußt oder unbewußt.

Was assembler angeht: CPUs mit ausreichend Mikroprogrammspeicher und Nanobefehlen ermöglichen es, Bytecode einer Hochsprache zu interpretieren. Da ist sicher noch Potential.

[;fricky]

u_ser-l schrieb:

;fricky schrieb:

der user der CAD-software möchte mit den, für ihn leicht verständlichen und auf seine welt zurechtgeschnittenen, CAD-objekten hantieren und nicht mit einer viel abstrakteren 'general purpose' OO-programmiersprache.

geeignete Implementationssprachen können so wenig Syntax haben, daß man in ihnen weitgehend beliebige user-friendly domain-specific languages als Subsprachen definieren kann:

circ1 := Circle centerX: 37.5 mm centerY: 89 mm radius: 1.342 cm
circ2 := circ1 scaleBy: sqrt 2.
...

naja, sowas ist vielleicht manchmal nett, der durchschnitts-grafiker designed jedoch lieber mit mouse oder grafiktablett, stift und papier und digitalisierts dann, etc, anstatt irgendwelche programmzeilen hineinzuhacken. ausserdem ist so'ne methode unschön wenn's um komplexere grafiken geht, wobei er sich einen wust von vektoren, grafikprimitiven usw. programmieren müsste und am quelltext kaum erkennen kann, wie das objekt überhaupt aussieht. ein CAD-programm ist schon ein musterbeispiel, das nach objektorientierung schreit, aber nicht nach OO in form von computerprogrammen bzw. quelltext und daten, sondern nach optischer OO.

u_ser-l schrieb:

;fricky schrieb:

weil's intuitiv, einfach ist und den menschlichen 'ordnungssinn' anspricht. ein dateisystem mit dateien, verzeichnissen, unterverzeichnissen usw.

ja, in einer nicht wirklich objektorientierten Computerwelt: "File = Papierblatt", "Programm = Black box", "Verzeichnis = Aktenordner". Die elektronische Analogie zu einem herkömmlichen Papierarchiv. Verwaltet man alles dies als Objekte, bräuchte man so etwas nicht, im Minimalfall würde ein Speicherformat zur Spezifikation von Objekten ausreichen.

file, verzeichnis, unterverzeichnis usw. sind doch schon objekte. ich finde das ist eine sehr gelungene und brauchbare (weil einfach für jedes kleinkind verständliche) abbildung auf z.b. sektororientierte speichermedien. wem das nicht gefällt, der kann doch 'ne relationale oder sogar objektorientierte datenbank verwenden. aber für die meisten fälle ist ein verzeichnissystem mit dateien einfach das beste.

u_ser-l schrieb:

;fricky schrieb:

in zukunft wirds alles mögliche geben, sogar noch assembler-programmierer und chipdesigner. wie kommste auf den dreh, dass dynamische OO-systeme (oder überhaupt OO-basierte systeme) dominieren werden?

weil die Software- und Programmiersprachenwelt seit mind. 2 Jahrzehnten konsequent dorthin zu konvergieren scheint.

das kommt mir nicht so vor. eher dass OOP dazugekommen ist (bzw. von der breiten masse der coder anerkannt wird, gegeben hats das ja schon früher) und immer weiter verfeinert wird, aber ohne traditionelle ansätze wirklich abzuschaffen. OOP ist nun mal kein allheilmittel und oftmals einfach die falsche herangehensweise.

u_ser-l schrieb:

Wenn man sich vergegenwärtigt, welche gigantischen Mühen aufgewendet werden, um klassischen Programmiersprachen ein wenig OO beizubringen, wird klar, wie attraktiv den meisten das Ziel der Programmierung in echter OO erscheinen muß - ob bewußt oder unbewußt.

ja, C++, object-pascal, PHP und so, die mixen OO und imperatives programmieren zusammen aber müssen dafür 'nen haufen kompromisse eingehen. dafür sind sie meistens für'n größeres anwendungsgebiet nutzbar als reine OO-sprachen. ob das gut oder schlecht ist sei mal dahingestellt (stichwort: verleitet zu kompliziertem denken, *grins*).

u_ser-l schrieb:

Was assembler angeht: CPUs mit ausreichend Mikroprogrammspeicher und Nanobefehlen ermöglichen es, Bytecode einer Hochsprache zu interpretieren. Da ist sicher noch Potential.

klar, ARM-jazelle z.b. die bytecodes werden übrigens nicht interpretiert, sondern direkt von der hardware ausgeführt. ist schon 'ne tolle sache, aber trotzdem haben java-prozessoren irgendwie nicht die beliebtheit erlangt die man erwartet hätte. warten wir's ab, da kommt bestimmt noch was.

[u_ser-l]

;fricky schrieb:

das kommt mir nicht so vor. eher dass OOP dazugekommen ist (bzw. von der breiten masse der coder anerkannt wird, gegeben hats das ja schon früher) und immer weiter verfeinert wird,

Die OOP wird mMn nicht mehr verfeinert, sondern ist zwischen 1964 (Simula) und 1980 (Smalltalk-80) fertig entwickelt worden, das Ziel steht seitdem fest. Naturgemäß ("alles ist Objekt") ist die echte, konsequente OOP stellenweise inkompatibel mit der Computerwelt, wie es sie in der Vor-OOP-Ära gegeben hat.

Seitdem nähert sich der Rest der Computerwelt sehr allmählich an - Desktop GUI, bytecode-VMs, verteilte Dateisysteme und blockstrukturiert-objektorientierte Hybridsprachen sind bereits in den Mainstream gesickert, weiteres wird wohl folgen. Ruby hat schon entfernt Smalltalk-ähnliche Blocks und message passing, C++ wandert mit STL+boost schon lange in Richtung "mehr OOP" usw.

bk2top: interaktive web-Applications könnten vielleicht besser "aus nur 1 Sorte Holz geschnitzt" sein, etwa nur in javascript mit geeigneten Bibliotheken oder einer anderen, noch zu entwickelnden Sprache, unter weitgehenden Verzicht auf html, css, cgi und wie sie alle heißen.

[;fricky]

u_ser-l schrieb:

;fricky schrieb:

das kommt mir nicht so vor. eher dass OOP dazugekommen ist (bzw. von der breiten masse der coder anerkannt wird, gegeben hats das ja schon früher) und immer weiter verfeinert wird,

Die OOP wird mMn nicht mehr verfeinert, sondern ist zwischen 1964 (Simula) und 1980 (Smalltalk-80) fertig entwickelt worden, das Ziel steht seitdem fest. Naturgemäß ("alles ist Objekt") ist die echte, konsequente OOP...

ach nö, fertig ist's noch lange nicht. man unterscheidet doch noch nicht mal objekte von 'subjekten' (im sinne der aristotelischen logik, linguistik oder sowas). wer weiss heute schon, was in zukunft da noch rauszuholen ist? es gibt dinge wie 'liebe' oder (in der philosophie sogenannte) universalien wie z.b. 'rot', die man nicht wirklich als objekte betrachten kann. 'alles ist objekt', finde ich irgendwie verkehrt. das klingt für mich nach fundamentalismus, sonst nix.

u_ser-l schrieb:

bk2top: interaktive web-Applications könnten vielleicht besser "aus nur 1 Sorte Holz geschnitzt" sein, etwa nur in javascript mit geeigneten Bibliotheken oder einer anderen, noch zu entwickelnden Sprache, unter weitgehenden Verzicht auf html, css, cgi und wie sie alle heißen.

finde ich auch. es wird einfach zu viel miteinander verschmolzen. weniger ist mehr, komplexität verringern ist immer gut. dabei muss man natürlich aufpassen, dass die 'usability' nicht drunter leidet.