Vorteile von Nicht-Web-Applikationen?

[u_ser-l]

Grundproblem ist wohl, daß html vom Ansatz her nicht primär für Interaktivität, sondern zur statischen Darstellung geschaffen wurde, und das zu einer Zeit, zu der die heutige Funktionsfülle des web wohl nicht abzusehen war. Das wird im zunehmend interaktiven web zunehmend problematisch.

Außerdem erscheint das Technologie-Gemisch von html, js, php, css usw. formal überkomplex angesichts der in der Regel eher einfachen Aufgaben bei der Darstellung durchschnittlicher Websites.

Möglicher Ausweg wäre, auf html & friends zu verzichten und voll auf javascript zu setzen, auf mächtige in javascript implementierte Oberflächen, gutes Beispiel: 'lively kernel'.

[volkard]

u_ser-l schrieb:

Außerdem erscheint das Technologie-Gemisch von html, js, php, css usw. formal überkomplex angesichts der in der Regel eher einfachen Aufgaben bei der Darstellung durchschnittlicher Websites.

Möglicher Ausweg wäre, auf html & friends zu verzichten und voll auf javascript zu setzen, auf mächtige in javascript implementierte Oberflächen, gutes Beispiel: 'lively kernel'.

Gibts da nicht auch was von Microsoft?
http://silverlight.net/

[;fricky]

u_ser-l schrieb:

Möglicher Ausweg wäre, auf html & friends zu verzichten und voll auf javascript zu setzen, auf mächtige in javascript implementierte Oberflächen...

nimmste java-applets. die gibts auch schon länger als 10 jahre.

[u_ser-l]

warum, meinst du wohl, heißt es lively kernel? Weil die Anwendungen zur Laufzeit änderbar sind, dank der dynamischen Eigenschaften von javascript.

[u_ser-l]

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. silverlight oder java applets sehe ich da nicht.

[;fricky]

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.

[u_ser-l]

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.

[;fricky]

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.

[hustbaer]

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

[u_ser-l]

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.

[;fricky]

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.

[hustbaer]

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*

[u_ser-l]

;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.

[u_ser-l]

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.

[hustbaer]

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.

[u_ser-l]

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]

u_ser-l schrieb:

Mit einer Sammlung von angelieferten Klassen kann der Anwender machen, was er will.

im Rahmen der jeweiligen Lizenz, versteht sich.

[;fricky]

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.

[hustbaer]

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"
?

[u_ser-l]

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 ?