Google lanzará un nuevo lenguaje de programación, llamado "Dart"

[JXJ]

¿¿pa que otro lenguaje de programacion basado en C. '???

mejro hubieran agarrado delphi o pascal o ada.
para la web.

[D-MO]

Empezado por JXJ

¿¿pa que otro lenguaje de programacion basado en C. '???

mejro hubieran agarrado delphi o pascal o ada.
para la web.

Tampoco es que me agrade mucho la sitaxis C-like, pero:

• Dart está pensado para la web (navegador) primeramente
• Pensado para ser una alternativa mejorada a Javascript
• Javascript es c-like
• Antes de crear dart se plantearon mejorar javascript pero no era factible
• Al ser una alternativa mejorada a javascript, por supuesto que no pretenden ponérsela difícil a los actuales desarrolladores que trabajan con javascript

Porfavor no piensen que soy un fanboy de Dart, ni siquiera lo he probado, tan solo me gusta analizar las cosas antes de comentar algo. Un poco de sentido común basta para ver que la decisión si fué acertada, aunque esta a nosotros no nos guste (que quede en actas que me incluyo).

Esta gente de google no se la jugó al tin marín para elegir la sintaxis de dart, era esta o se iban de GOTOCON directamente al basurero, ya que (como lo digo arriba) está dirigido a quienes en este momento utilizan javascript.

Y por último, sin ánimo de quitar mérito al lenguaje, no me imagino pascal como script del lado del navegador... por el contrario, del lado del servidor me parece bien.

Saludos crípticos

[Casimiro Noteví]

Bueno, es que no estamos criticando al lenguaje, lo que estamos criticando es que lo presenten como un nuevo lenguaje, cuando todos tenemos claro que es C.

[mamcx]

Yo diria que peor en si que la sintaxis, a pesar de lo que he discutido, es que no tiene un caso de uso poderoso que lo justifique. Es solo un javascript "mejorado" pero en que que realmente beneficia?

Veamoslo desde el punto de vista de su publico objetivo, programadores de paginas web.

Lo unico que tiene de medio-gracia es que el sistema de libreria, pero:

- No tiene un modelo de DOM mejorado. O sea, algo que realmente destaque VS tener una lib como mootools o Jquery.
- No tiene una mejor respuesta a generar html dinamicamente
- No tiene un mejor modelo de asincronia, que realmente facilite interfaces fluidas
- No hace mas facil aplicar efectos, transiciones ni demas cosas del CSS3, o Canvas o todo eso
- No incorpora un sistema de validación, integración de manejo de formularios a nivel de lenguaje, ni nada parecido
- No veo como reduce el codigo necesario para hacer las tareas tipicas, ni como supera a jquery y familia
- Ni le veo una integracion profunda con html5, css3 ni demas tecnologia emergente

Todo eso se puede resolver con librerias. Que es lo mismo que se hace con JS. La gracia de inventar un nuevo lenguaje es volver en keywords cosas que requieren librerias y mucho codigo redundante.

Un ejemplo, son como apple metio los "blocks" para hacer multi-hilo facil:

Código PHP:

//A partir de aqui la descarga es asincronica, pero el codigo se ve sincronico
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        // Esto es en el background

        UIImage *avatarImage = nil; 
        NSURL *url = [NSURL URLWithString:urlString];
        NSData *responseData = [NSData dataWithContentsOfURL:url];
        avatarImage = [UIImage imageWithData:responseData];
        NSLog(@"Finishing: %@", urlString);
        
        if (avatarImage) {
            //Retorna al thread main para actualizar la GUI sin bloquear
            dispatch_async(dispatch_get_main_queue(), ^{
                self.image = avatarImage;
            });
            dispatch_async(dispatch_get_main_queue(), completion);
        }
        else {
            NSLog(@"-- impossible download: %@", urlString);
        }
    }); 


Blocks es sintaxis que ahorra un monton de escribir con clases tipo thread, asincronismo y todo eso (y en el caso de obj-c, que es muy "verbosed" ahorra un MONTON). Eso es la gracia de un lenguaje...

Otro ejemplo es node.js

Código PHP:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, "127.0.0.1");
console.log('Server running at http://127.0.0.1:1337/'); 


Una extension a JS que hace facil hacer servidores HTTP multi-hilos asincronicos. Esta enfocado en ese caso de uso y se nota...

[[Crandel]]

Empezado por mamcx

Yo diria que peor en si que la sintaxis, a pesar de lo que he discutido, es que no tiene un caso de uso poderoso que lo justifique. Es solo un javascript "mejorado" pero en que que realmente beneficia?

Veamoslo desde el punto de vista de su publico objetivo, programadores de paginas web.

Lo unico que tiene de medio-gracia es que el sistema de libreria, pero:

- No tiene un modelo de DOM mejorado. O sea, algo que realmente destaque VS tener una lib como mootools o Jquery.
- No tiene una mejor respuesta a generar html dinamicamente
- No tiene un mejor modelo de asincronia, que realmente facilite interfaces fluidas
- No hace mas facil aplicar efectos, transiciones ni demas cosas del CSS3, o Canvas o todo eso
- No incorpora un sistema de validación, integración de manejo de formularios a nivel de lenguaje, ni nada parecido
- No veo como reduce el codigo necesario para hacer las tareas tipicas, ni como supera a jquery y familia
- Ni le veo una integracion profunda con html5, css3 ni demas tecnologia emergente

Posiblemente lo que se busca no es un mejoramiento de esto o aquello. Si a que publico va destinado. Hace poco estuve en una charla de google y android. Lo que me sorprendio es como tiraban tierra sobre escribir aplicaciones nativas para android y apuntaban directamente a escribir todo para la nube y las grandes ventajas que tiene.

A mi hace pensar es que hay un publico desarrollador de aplicaciones de escritorio que quieren mover a la nube. Cuando saben estos programadores de javascript ? les interesa aprenderlo ? pasar de escribir aplicaciones de escritorio con toda la teoria de POO y demas a una programación de paginas web con javascript no es lo que atraiga a muchos de nosotros.

Ahora si lo que les proponemos es un nuevo lenguaje similar a C++ pero para la web, entonces no suena tan feo y muy posiblemente atraiga a muchos mas programadores.

[mamcx]

Empezado por Crandel

Lo que me sorprendió es como tiraban tierra sobre escribir aplicaciones nativas para android y apuntaban directamente a escribir todo para la nube y las grandes ventajas que tiene.

Eso no es sorpresa. Las aplicaciones nativas son una amenaza al modelo de negocios de google, porque una app nativa no muestra publicidad de google. Es por eso que se metieron en android, como una jugada para tratar de impedir el ascenso de apple y cualquier otra plataforma donde exista innovacion y dejar una plataforma web, donde es mas "commodity" y les conviene a ellos.

Lo malo para ellos es que los dispositivos moviles se han puesto firmemente en el area de las app nativas con acceso http a servicios.

Empezado por Crandel

A mi hace pensar es que hay un publico desarrollador de aplicaciones de escritorio que quieren mover a la nube. Cuando saben estos programadores de javascript ? les interesa aprenderlo ? pasar de escribir aplicaciones de escritorio con toda la teoria de POO y demas a una programación de paginas web con javascript no es lo que atraiga a muchos de nosotros.

Ahora si lo que les proponemos es un nuevo lenguaje similar a C++ pero para la web, entonces no suena tan feo y muy posiblemente atraiga a muchos mas programadores.

Eso no funciona, porque HTML/DOM <> Nativo ( y mucho ).

Ya existen desde que recuerdo librerias que intentan hacer apps web como si fuera de escritorio (ej: http://www.sproutcore.com/)... de hecho asp y asp.net fue un intento de todo eso.

El problema es que eso es mas dificil que hacer una gui multiplataforma nativa. Si no ha sido exitoso tratando se hacer una GUI que porte entre windows-linux-mac entonces pretender que funcione web es una utopia.

Y es estupido... para que quiero hacer lo mismo que hago pero en un entorno mas hostil?

La respuesta no es tratar de hacer multiplataforma. Eso es una pendejada... lo que se necesita es responder: Que cosas realmente novedosas puedo lograr en un ambiente web, que no puedo en uno de escritorio?

Un lenguaje/framework que responda eso lograra aceptacion. No importa la sintaxis, si hay que aprender algo nuevo o si toca empezar de cero. Lo mas importante es que existe una caracteristica asesina que haga que la gente se mueva.

Un ejemplo dramático es lo que ocurrió con la plataforma de iOS (iPhone).

Quien sabia hace años sobre obj-c? Es un lenguaje feo, verboso, raro, con idiosincracias que lo hacen alienigena a cualquiera que use java, .net, delphi y todo lo demás. Tienes que comprar un mac si o si. Una plataforma que era cerrada en todo aspecto... Y sin embargo, al dia de hoy ya es todo un boom.

Porque?

Porque era la respuesta a la pregunta: Como hago aplicaciones del nivel de calidad de las que hizo apple para el iPhone?

Originalmente, el plan es que fuera un ambiente web. Pero al probarlo se demostro que era un error, y entonces se le dio impulso al ambiente nativo. Ahora que lo uso personalmente, ni de LOCOS pensaria que se puede lograr lo mismo en un ambiente emulado web. Ni de locos. No hay manera (aunque existen intentos http://www.phonegap.com/ son solo para pendejadas).

Eso es lo que falta en el desarrollo web. A nivel de servidor, todo esta resuelto. A nivel de cliente? Todavia es el mismo modelo de hace una decada, solo que ahora hay librerías que estandarizan el DOM.

Con el avance de hmtl5/css3 se podría ir mas lejos, pero el problema es que la innovación web apesta, es muy lento en comparación con nativo, porque es un proceso politico donde solo unos pocos pueden implementar las extensiones necesarias y por fuera de eso no importa que pienses, no puedes avanzar. En la web, es un ambiente hostil a la innovación (como framework de desarrollo)... quizas por eso en parte es que lo novedoso se ve ahora como nativo+http.

Lo unico que lo "tapa" es que es facil poner bonita una app web. Y que no hay que instalar nada. De resto, es un retroceso al compararlo con desarrollo nativo.

[Ñuño Martínez]

Empezado por roman

A ver, y ¿por qué no nos das una idea por adelantado? Suena interesante.

// Saludos

Empezado por ecfisa

Hola Ñuño.

Por favor no dejes de hacerlo, ya estoy muy interesado con la sola idea de leerlo.

Un saludo.

Lo tengo pendiente de hacer desde hace tiempo, pero siempre lo pospongo. La última razón es que sufro Síndrome del Túnel Metacarpiano desde hace unos meses y al rato de escribir duele...

Aun así: Básicamente es aprovechar cómo está organizada la memoria, para lo cual la flexibilidad de C en cuanto al manejo de datos viene que ni pintado. La herencia es encadenar:

struct ClaseA
{
  int Valor;
};

struct ClaseB
{
  struct ClaseA Inherited;
  int OtroValor;
};

void EscribeValor (struct ClaseA *Objeto)
{
  printf ("El valor es %d.\n", ObjetoA->Valor);
}



int main (void)
{
  struct ClaseB *ObjetoB;

  ObjetoB = (struct ClaseB *)malloc (sizeof (struct ClaseB));
/* Esto se puede hacer porque la primera parte de B es idéntica a la de A,
    aunque posiblemente devuelva un "WARNING". */
  ObjetoB->Inherited.Valor = 10;
  EscribeValor (ObjetoB);
  return 0;
}

Hay más detalles, a ver cuándo me pongo y lo saco.