Vorteile von Nicht-Web-Applikationen?
-
u_ser-l schrieb:
außerdem ist einer der Vorzüge gerade, daß keine plugins nötig sind...
nö, aber es geht nur richtig mit safari, bei anderen browsern zickt irgendwas. mit'm IE siehts auch eher schlecht aus.
http://research.sun.com/projects/lively/#supported
da würde ich doch lieber applets nehmen, geht mit fast jedem browser, brauchst nur'n jRE zu installieren.
-
nur ein jre ...
nochmal: eines der Ziele von lively kernel ist, daß keine besonderen environments benötigt werden. Fallen applets also schon mal weg.
Wie willst du Anwendungen zur Laufzeit ändern auf statisch typisierter Grundlage ? Fallen applets schon zweimal weg.
-
u_ser-l schrieb:
nochmal: eines der Ziele von lively kernel ist, daß keine besonderen environments benötigt werden.
dann haben sie ihr ziel verfehlt, weils ja mit den meisten browsern nicht vernünftig geht.
u_ser-l schrieb:
Wie willst du Anwendungen zur Laufzeit ändern auf statisch typisierter Grundlage ?
wer will das? ich jedenfalls nicht.
-
u_ser-l schrieb:
außerdem ist einer der Vorzüge gerade, daß keine plugins nötig sind, nur javascript und svg benutzt wird - Ziel ist ja u.a. die Anzahl der verwendeten Technologien zu reduzieren.
Sun Labs schrieb:
In general, one of our goals has been to leverage existing technologies as much as possible.
Liest sich nicht so.
Sun Labs schrieb:
IMPORTANT! The Lively Kernel requires SVG support and does not run on Microsoft Internet Explorer without extensions. An experimental Microsoft Internet Explorer port, requiring an additional web browser plug-in, is available here
und tschüss
-
lively kernel ist - wie zahlreiche andere Projekte der vergangenen 4 Jahrzehnte aus dem Umfeld der Smalltalk-Entwickler - seiner Zeit voraus. Akzeptanzprobleme beim mainstream: wen wundert's. Wen stört's.
-
u_ser-l schrieb:
lively kernel ist - wie zahlreiche andere Projekte der vergangenen 4 Jahrzehnte aus dem Umfeld der Smalltalk-Entwickler - seiner Zeit voraus.
ach was, überhaupt nicht. es ist nicht mehr als eine studie, um die grenzen von JavaScript auszuloten, noch nicht mal vom prinzip her ist es eine tolle idee. solange der 'lively kernel' nur in einem browser läuft, in zwei anderen nur bedingt und im stinknormelen IE garnicht, ist er praktisch unbrauchbar.
-
ACK.
Liest sich auch irgendwie so wie "wir machen sowas wie Java, nur ohne VM, und schlechter, und dass Windows & IE von vielen Leuten verwendet wird ist ein Gerücht". Toll. Wie innovativ. Wie wegweisend.
*kicher*
-
;fricky schrieb:
u_ser-l schrieb:
Wie willst du Anwendungen zur Laufzeit ändern auf statisch typisierter Grundlage ?
wer will das? ich jedenfalls nicht.
Ich schon. Das wäre viel einfacher als Anwendungssoftware über etliche configs zu customizen - der Anwender könnte sie einfach zur Laufzeit umprogrammieren.
Programmierung durch Manipulation und Formung von Objekten in einem dynamischen Laufzeitsystem wird gängige Methode in der Computerwelt der Zukunft sein. Die Welt ist noch nicht so weit, wie die seit Jahrzehnten anhaltende Ablehnung von Systemen wie Smalltalk beweist.
Der heute praktizierte Entwicklungzyklus edit-compile-run-edit-compile ... stammt aus der Computerwelt der 1950er Jahre. Ebenso wie file-basierte Quelltextverwaltung und statische Typisierung.
Um so etwas zu begreifen, muß man aber auch mal über den Tellerrand schauen wollen. Und können.
-
hustbaer schrieb:
ACK.
Liest sich auch irgendwie so wie "wir machen sowas wie Java, nur ohne VM, und schlechter, und dass Windows & IE von vielen Leuten verwendet wird ist ein Gerücht". Toll. Wie innovativ. Wie wegweisend.
*kicher*
perfekt.
-
u_ser-l schrieb:
Programmierung durch Manipulation und Formung von Objekten in einem dynamischen Laufzeitsystem wird gängige Methode in der Computerwelt der Zukunft sein.
Ja, klar.
Macht überhaupt keine Probleme bei der Wartung wenn man nicht weiss was diverse User zur Laufzeit alles am Programm ändern.
-
du verstehst nicht. Das Programm als solches wird zunehmend devaluiert werden und zu einer Sammlung von zusammengehörigen Klassen werden. In Smalltalk wird Software seit eh und je in Form von Klassenbeschreibungen abgespeichert ("fileout") oder kompletten Objektwelten ("image").
Mit einer Sammlung von angelieferten Klassen kann der Anwender machen, was er will. Umprogrammieren, mit eigenen Klassen mischen, Objekte anlegen. Compilierung als separaten Vorgang (auch so ein Unikum aus den 1950er Jahren) gibt es dann nicht mehr, genauer: jede Methode wird dann compiliert, wenn sie in die Objektwelt eingefügt wird.
-
u_ser-l schrieb:
Mit einer Sammlung von angelieferten Klassen kann der Anwender machen, was er will.
im Rahmen der jeweiligen Lizenz, versteht sich.
-
u_ser-l schrieb:
;fricky schrieb:
u_ser-l schrieb:
Wie willst du Anwendungen zur Laufzeit ändern auf statisch typisierter Grundlage ?
wer will das? ich jedenfalls nicht.
Ich schon. Das wäre viel einfacher als Anwendungssoftware über etliche configs zu customizen - der Anwender könnte sie einfach zur Laufzeit umprogrammieren.
wie jetzt? es gibt doch schon systeme, bei denen sich der anwender selbst alles zurechtkonfigurieren kann. denk doch nur mal an dein heissgeliebtes linux. 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.
u_ser-l schrieb:
Programmierung durch Manipulation und Formung von Objekten in einem dynamischen Laufzeitsystem wird gängige Methode in der Computerwelt der Zukunft sein. Die Welt ist noch nicht so weit, wie die seit Jahrzehnten anhaltende Ablehnung von Systemen wie Smalltalk beweist.
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? da wo sie vorteile bringen, wird man sie einsetzen, wo nicht, da nicht. ausserdem hat smalltalk doch sowieso seine 'fanbase', genauso wie c++ eine hat. aussterben werden beide schon nicht.
u_ser-l schrieb:
Der heute praktizierte Entwicklungzyklus edit-compile-run-edit-compile ... stammt aus der Computerwelt der 1950er Jahre. Ebenso wie file-basierte Quelltextverwaltung und statische Typisierung.
naja, ich finds auch immer schockierend, wie heute noch welche mit uralt-tools wie vi(m) und 'make' rumfuchteln können, aber ist nun mal so. und das mit den file-basierten quelltexten ist doch überall da angenehm, wo man sowieso ein filesystem hat. tools zur verwaltung von quelltexten benutzen aber zum speichern eigentlich mengenorientierte datenbanksysteme und nicht dateien und verzeichnisse. zum statischen typsystem: es hat ja den vorteil, dass fehler bereits beim compilen gefunden werden, also ganz sinnlos isses auch nicht.
u_ser-l schrieb:
Um so etwas zu begreifen, muß man aber auch mal über den Tellerrand schauen wollen. Und können.
ach, dir ist doch nur 'squeak' zu kopf gestiegen, deswegen kommste auch auf den lively kernel. software damit sieht nämlich der squeak-umgebung sehr ähnlich.
-
u_ser-l schrieb:
du verstehst nicht. Das Programm als solches wird zunehmend devaluiert werden und zu einer Sammlung von zusammengehörigen Klassen werden. In Smalltalk wird Software seit eh und je in Form von Klassenbeschreibungen abgespeichert ("fileout") oder kompletten Objektwelten ("image").
Mit einer Sammlung von angelieferten Klassen kann der Anwender machen, was er will. Umprogrammieren, mit eigenen Klassen mischen, Objekte anlegen. Compilierung als separaten Vorgang (auch so ein Unikum aus den 1950er Jahren) gibt es dann nicht mehr, genauer: jede Methode wird dann compiliert, wenn sie in die Objektwelt eingefügt wird.
Klar verstehe ich das.
Nur wie willst du ein Update für so eine Software anbieten, ohne dass du
a) sämtliche Interfaces 100% kompatibel halten musst oder
b) der Client sämtliche Dinge wegwerfen kann, die er "gemacht hat, weil er sie machen konnte und wollte"
?
-
hustbaer schrieb:
Nur wie willst du ein Update für so eine Software anbieten, ohne dass du
a) sämtliche Interfaces 100% kompatibel halten musst oder
b) der Client sämtliche Dinge wegwerfen kann, die er "gemacht hat,Das ist ein Problem. Aber dieses Risiko besteht meistens, wenn man in technische Systeme eingreift - oder kannst du eine "handgepflegte" registry von win 95 problemlos in einem vista System verwenden ?
-
;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.
-
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
-
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.
-
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.
-
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.aspxoder ist das etwa was ganz anderes?
