¿Cuál es el problema real con un diseño basado en prototipo?

7

Siento que cualquier cosa que pueda desarrollarse usando OO / lenguajes funcionales se puede hacer 'mejor' en general usando un lenguaje basado en prototipos, porque parecen tener lo mejor de todos: funciones de alto orden, flexibilidad para simular cualquier estructura OO , productividad (baja verbosidad) y escalabilidad debido a la concurrencia. Pero parece que se evitan para la creación de aplicaciones ejecutables y de proyectos más grandes en general. ¿Por qué eso?

    
pregunta WindScar 30.10.2011 - 22:28

5 respuestas

13
  

Pero parece que se evitan para la creación de aplicaciones ejecutables y de proyectos más grandes en general. ¿Por qué eso?

No lo sé, pero la suposición es falsa.

Los proyectos más grandes usan lenguajes prototípicos:

¿Cuánto "más grande" quieres? ¿Espera que alguien escriba un código que emule a una computadora y solo pueda tomar un ISO de Linux y ejecutar un sistema operativo completo desde su navegador y pueda comenzar a escribir código desde una línea de comandos de Linux en C ++ ... o algo tan ridículo como eso? De acuerdo, también tenemos eso .

En serio, ¿qué es "más grande"?

Nuevamente, tiene el lenguaje más proliferar en github que ha llevado a un IDE, un servidor web, un motor de gráficos 3D, una herramienta de procesamiento de documentos PDF, un decodificador de video, una biblioteca de encriptación y un emulador x86.

Ni siquiera me voy a molestar en enlazar con la interminable cantidad de aplicaciones web y cosas en la tienda de chrome, marcos de todas las formas y tamaños, herramientas de análisis de código estático u otros proyectos 'triviales' que nadie usa porque el lenguaje es tan dolorosamente lento y no podemos estar seguros de cómo escribir código en él.

Oh, espera, podemos estar seguros de cómo escribir código de calidad en JavaScript. Se llama leer el manual divertido, escribir pruebas unitarias, análisis de código estático y otras cosas divertidas que haces en todos los demás idiomas si también eres competente en ese idioma.

No es "arriesgado" porque tiene un prototipo, solo significa que necesita saber lo que está haciendo, de la misma manera que necesita saber cómo programar en cualquier paradigma que disfrute. No es "lento" porque es un prototipo, los idiomas que no mencioné se ejecutan a velocidades cercanas a C. Puede encontrar más información en su motor de búsqueda local.

Buen día.

    
respondido por el Incognito 01.11.2011 - 14:59
3

De acuerdo, dejemos de lado el debate de nativos frente a JIT y estático frente a dinámico. Supongamos que damos por sentado que alguien quiere usar un lenguaje dinámico de JIT, como java, python o javascript. ¿Por qué eligen un idioma con herencia clásica en lugar de uno con herencia prototípica?

La razón dominante es que javascript no es muy adecuado para la programación de grandes sistemas y javascript es el único lenguaje prototípico lo suficientemente popular como para obtener la aprobación de "nivel C" para un nuevo proyecto. Javascript es malo para la programación de grandes sistemas porque carece de un mecanismo de escritura estricto. En sistemas grandes, usted confía en las API para abstraer los detalles de la implementación. La escritura estricta traslada la responsabilidad de direccionar correctamente las API del desarrollador al compilador. Quieres que el compilador haga ese trabajo.

Una segunda razón es porque la herencia clásica es lo que la mayoría de los programadores conocen y han recibido capacitación, y la herencia prototípica es demasiado extraña para ellos. Nunca subestime la cantidad de factores que la "popularidad" tiene en las decisiones técnicas.

El rendimiento no tiene en cuenta la decisión. Todos los días se programan grandes sistemas en java, y javascript V8 tiene aproximadamente el mismo orden de magnitud de rendimiento que java ( 3 veces más lento en los puntos de referencia sintéticos ).

    
respondido por el Joeri Sebrechts 31.10.2011 - 13:41
2

Son lentos como el infierno. ¿Cuánto tiempo cree que se necesita una máquina virtual JavaScript para realizar una llamada OO, en comparación con C ++? Y, básicamente, pierdes tiempo inventando estructuras que otros idiomas te proporcionan. Y espero que tampoco disfrutes de la seguridad de tipos.

He hecho un montón de codificación en Lua. Reinventar la rueda de la clase cada vez no era mi idea de un buen momento. Ahora trabajo en C ++ fuera de elección.

La flexibilidad es lenta e insegura.

    
respondido por el DeadMG 31.10.2011 - 00:58
2

A aquellos que se quejan de la velocidad y la escalabilidad hacen estas preguntas:

  1. ¿Qué tan rápido debe ser? Estoy hablando de requisitos aquí, no de generalidades (la página completa debe responder en el tipo de detalle)
  2. Cuántos usuarios van a usar este sistema ahora, cuántos en 5 años.
  3. Se conectará con otros sistemas y, de ser así, cómo.

Las respuestas a las preguntas anteriores influirán enormemente en su decisión. No necesita velocidades de C ++ para el 95% de las aplicaciones, tal vez más. En cuanto a la escalabilidad. Menos de 1/10000 del 1% de las aplicaciones alguna vez escalará a los niveles de google / ebay / amazon. La mayoría, probablemente menos del 1% escalará hasta el punto de que tenga más de 100 solicitudes por segundo, incluso en la empresa.

Ahora, si trabaja para, digamos, AOL o Google, entonces, por supuesto, la velocidad y la escalabilidad probablemente importen, para el resto de nosotros, no tanto, es mucho más importante hacerlo y hacerlo de manera rápida en el el menor costo posible.

    
respondido por el Bill Leeper 31.10.2011 - 18:12
1

No creo que haya nada fundamental, pero específicamente en javascript hay algunos problemas que pueden causar problemas en el software a gran escala:

  1. La encapsulación es débil: es muy fácil que cualquier otro código inspeccione y modifique cualquier otro código. Esto permite algunas cosas poderosas, pero también puede llevar a problemas en grandes proyectos. Los errores difíciles de encontrar pueden ocurrir si accidentalmente pisas un código que no es tuyo.

  2. comodidad sobre la seguridad: js tiene características como los argumentos.callee que permite que cualquier función pueda acceder a la pila y acceder al objeto raíz (ventana en un navegador). Esto significa que realmente necesita confiar en cualquier código de terceros al que llame. Esto no es un problema para todas las aplicaciones, pero restringe lo que puede hacer (el modo estricto soluciona esto, pero no se puede confiar en el contexto de un navegador)

  3. cualquier cosa numérica es extremadamente incómoda: cada número es un flotante, lo que probablemente sea la opción correcta si solo vas a tener un tipo de número, pero hacer que el manejo de datos binarios y aritmética de enteros sea incómodo.

  4. placa de calderas requerida para el estilo oo típico: es increíble que puedas crear una biblioteca que implemente clases en javascript, pero en el lado negativo necesitarás una, y todos los nuevos necesitarán aprender lo particular biblioteca que utiliza.

Ninguno de estos programas javascript para matar a grandes proyectos, y todos los idiomas tienen sus propios inconvenientes, son solo algunas cosas que hay que tener en cuenta al usar js. El uso de las nuevas funciones de js y solo la orientación a los motores js modernos (v8 por ejemplo), que puede hacer para una aplicación independiente, le permite evitar algunos de estos problemas. Las herramientas externas también pueden proporcionar ayuda (por ejemplo, el compilador de cierre de Google realiza varias formas de comprobación estática).

    
respondido por el maxpolun 11.11.2011 - 20:06

Lea otras preguntas en las etiquetas