@Federico: disculpame la ida de mambo (más off topic todavía!). Es que
entendí que se trataba puntualmente de la tecnología (y no del approach;
creo que Luis también).

En cuanto al approach lo único que se me ocurre es si no será mucho
incrustar un CLR (aunque sea mini, no sé) en un plugin... está bien que
probablemente donde corra ya exista ese CLR (imagino que podrá reutilizar el
runtime que tengo corriendo y no lanzará uno nuevo si estoy en Windows x
ej).

Correr lenguajes dinámicos sobre una VM o runtime de bytecode me parece algo
fantástico (ejem... ¿Smalltalk?), y más aún si es una VM/runtime "popular",
que tiene soporte por otros lados (un guiño para la JVM, ¡que no se nos
quede atrás!).

Si meter cosas que no sean presentacionales dentro de XAML fue una buena
movida (más allá del empuje marketinero) se verá con el tiempo, me parece.
Lo que nos concierne en principio es la parte presentacional (queremos que
el cliente siga siendo bastante fino, ¿no?).

Lo de la diferencia de performance (lo que vi yo, con el ajedrez uno
implementado 100% en JScript y otro 100% en el plugin), toma relevancia si
el cliente se torna grueso (btw, para tener eso, no necesitamos descartar el
stack actual, veamos qué sucede con la VM que donó Adobe).

Lo que tiene Microsoft es, para variar, una amplia capacidad de proveer una
plataforma increíblemente amplia (y si la historia nos dice algo, acoplada--
perdón no puedo evitarlo). Abarca mucho...

@Cristian,
1) lock-in!!, lock-in!!, lock-in!!
2) la tecnologia del DLR, XAML, WPF  es fantástica.
3) lock-in!!, lock-in!!, lock-in!!


:) ja


http://download.microsoft.com/download/f/2/e/f2ecc2ad-c498-4538-8a2c-15eb157c00a7/SL_Map_FinalNET.png

Genial ese png! (posta mírenlo si no lo hicieron).

esto esta claramente dirigido a atacar a Adobe(Flash, Flex, Apollo, todas
las herrm. de diseño, PDF), Google (Ajax, videoHosting) y Linux (desktop,
server).

Algo que me parece terrible (y sigo...) es que en todas esas tecnologías que
mencionás hay tantas que son intrínsecamente libres (o sea, libres por
diseño, donde en principio no hay manera de subvertirlas y tornarlas libres
sólo en un afiche marketinero), y sus contrapartes en la oferta de Microsoft
tan centradas en un único vendor dueño del mundo... Lo que es libre (o
"abierto" como hay quien les dice) siempre depende de algo no libre para
funcionar o de alguna manera puede anularse...

Yo no creo que saquen una versión para Linux y nadie me asegura que si
sacan
hoy una version mañana la dejen de mantener, como hacen con el Office para
Mac.

Es un tema de confianza... pueden sacarla, y aún así la gente va a seguir
desconfiando.

Aunque la DLR este con una licencia permisible, me parece que si todo el
stack no es abierto y controlado x una entidad como la W3C no sirve para
nada. .Net no es totalmente libre, solo ciertas partes y versiones.
Seguramente hay partes que no se van a poder implementar fácilmente o va a
ser imposible x patentes.

Exacto. Recalco: "... si todo el stack no es abierto ..." (más allá de
http://www.gnu.org/philosophy/words-to-avoid.html#Open)...

Miguel deIcaza es un grandioso programador pero creo que es bastante
ingenuo.

Pero lo que hace tiene un propósito muy importante, y es permitir una vía
"simple" de migración de software construído bajo .NET (para aquel que haya
cometido inicialmente el error de elegir .NET...). No creo en Mono como algo
sobre lo que construir (aunque esto podría cambiar...).

"Embrace, extend and extinguish" (
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
) es lo que hacen.

Sobre usar AJAX,CSS,DHTML, etc  es verdad que en cierto sentido es matar
moscas a cañonazos y hay muchas formas de hacer lo mismo mas
eficientemente.
Flash nos muestra eso, pero contra velocidad del JS Adobe nos esta dando
una
mano liberando la Tamarin (
http://www.mozilla.org/projects/tamarin/ )
Tal vez, la alternativa open source venga de Mozilla XULRunner (XUL,
SVG,Tamarin), o incluso de Java o OpenLazlo.

XUL lo veo como algo a corto plazo... está bueno, pero para un proyecto yo
valoraría usar un approach más tradicional, standard y crossbrowser.

Además, la verdad que no veo xque ROR no pueda usar algo como
Flex/actionScript o XUL/JS en el frontEnd en lugar de HTML/JS.

Por favor chequeate http://www.flex.org/ruby/  (para el caso de quien
necesite usar Flash de front-end, ¿por qué dejar de lado a nuestro RoR?. XUL
on Rails te la debo, voy a investigar (aunque ya lo bauticé).

Off Topic: ¿alguien tuvo una buena experiencia programando sobre Flash, y
por otro lado, Flex? Yo me frustré tanto...

Nacho
_______________________________________________
ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar

Responder a