'Lo mejor que podemos hacer hoy a JavaScript es retirarlo', dice el creador de JSON, Douglas Crockford [ENG]

231 meneos

2043 clics

'Lo mejor que podemos hacer hoy a JavaScript es retirarlo', dice el creador de JSON, Douglas Crockford [ENG]

"Lo mejor que podemos hacer hoy a JS es retirarlo. Hace 20 años, yo era uno de los pocos defensores de JS. Su combinación de funciones anidadas y objetos dinámicos era brillante. Pasé una década tratando de corregir sus defectos. Tuve un pequeño éxito con ES5. Pero desde entonces, ha habido un gran interés en inflar aún más el lenguaje en lugar de mejorarlo. Así que JS, como los demás lenguajes dinosaurios, se ha convertido en una barrera para el progreso. Deberíamos centrarnos en el próximo lenguaje, que debería parecerse más a E que a JS".

139 92 0 K 613 tecnología

164 comentarios

139 92 0 K 613 tecnología

Comentarios destacados:

#1 Traducción automática:

JavaScript, el lenguaje de programación más popular del mundo según la mayoría de las encuestas, se ha convertido en una barrera para el progreso, según Douglas Crockford, creador de la especificación JSON (JavaScript Object Notation) utilizada en todas partes para serializar datos en las aplicaciones web.

Crockford hizo esta afirmación en una entrevista el mes pasado:

"Lo mejor que podemos hacer hoy a JavaScript es retirarlo. Hace veinte años, yo era uno de los pocos defensores de JavaScript. Su combinación de funciones anidadas y objetos dinámicos era brillante. Pasé una década tratando de corregir sus defectos. Tuve un pequeño éxito con ES5. Pero desde entonces, ha habido un gran interés en inflar aún más el lenguaje en lugar de mejorarlo. Así que JavaScript, como los demás lenguajes dinosaurios, se ha convertido en una barrera para el progreso. Deberíamos centrarnos en el próximo lenguaje, que debería parecerse más a E que a JavaScript".

…...

«12 »

#1 geralt_

Traducción automática:

JavaScript, el lenguaje de programación más popular del mundo según la mayoría de las encuestas, se ha convertido en una barrera para el progreso, según Douglas Crockford, creador de la especificación JSON (JavaScript Object Notation) utilizada en todas partes para serializar datos en las aplicaciones web.

Crockford hizo esta afirmación en una entrevista el mes pasado:

"Lo mejor que podemos hacer hoy a JavaScript es retirarlo. Hace veinte años, yo era uno de los pocos defensores de JavaScript. Su combinación de funciones anidadas y objetos dinámicos era brillante. Pasé una década tratando de corregir sus defectos. Tuve un pequeño éxito con ES5. Pero desde entonces, ha habido un gran interés en inflar aún más el lenguaje en lugar de mejorarlo. Así que JavaScript, como los demás lenguajes dinosaurios, se ha convertido en una barrera para el progreso. Deberíamos centrarnos en el próximo lenguaje, que debería parecerse más a E que a JavaScript".

Según una encuesta de StackOverflow realizada a principios de este año, JavaScript es utilizado por más del 65% de los desarrolladores, muy por delante del segundo clasificado, Python, con un 48% (sin tener en cuenta HTML, CSS y SQL, que no son lenguajes de propósito general). Se trata de un logro improbable teniendo en cuenta sus orígenes.

Brendan Eich inventó el lenguaje para Netscape en 1995, aparentemente en sólo 10 días. "En mayo hice 10 días de trabajo duro, no dormí mucho", dijo Eich en la conferencia dot.JS en 2018. En 2012 Eich dijo a Charles Severance de Computer que: "Entré a hacer... un lenguaje de programación para HTML, para que los diseñadores y programadores web lo usaran, incrustado directamente en la página web... no como Java, que era un lenguaje de profesionales en el que se ejecutaba código real con declaraciones de tipo, y había que escribir de forma que se compilara". Añadió que "el nombre es una total mentira. No está tan relacionado con Java como con un ancestro común, C, en la sintaxis".

Eich calificó el trabajo de "trabajo apresurado", pero también dijo que "sabía que habría errores, que habría lagunas, así que lo hice muy maleable como lenguaje. Eso ha permitido a los desarrolladores web hacer que sea lo que quieran".

¿Por qué JavaScript ha tenido un éxito tan rotundo?

Hay múltiples razones, entre ellas la previsión de Eich, la facilidad de aprendizaje y la tolerancia al código que sería un

… » ver todo el comentario

17 155
#2 frutosm

4 46
#3 xaviazo

Para eso está Dart.

1 21
#4 hrundil

Lo que yo haría es obligar que los navegadores por defecto no cargaran ninguna página con errores de HTML, Javascript, CSS, imágenes que no cargan o lo que sea. Que los creadores tengan presión para hacerlo medianamente bien.

6 48
#5 Nova6K0

Esto sin hablar de la cantidad de scripts maliciosos que hay, gracias a él.

Saludos

3 43
#6 anv *

#4 Pues como desarrollador me vendría muy bien tener una indicación clara de que ja fallado algo en el JavaScript en lugar de sus silenciosamente deje de trabajar en un punto indeterminado.

Y no solo me pasa a mi. Hay montones de páginas que largan decenas de errores de JavaScript si uno se pone a mirar la consola.

12 95
#7 selina_kyle

#5 los habria igual en cualquier otro lenguaje universal para todos los navegadores

12 99
#8 selina_kyle

mientras que no me toquen mi python que bastante me costó aprenderlo...

0 9
#9 MacMagic

#6 Cómo Menéame

17 134
#10 ErMijita

JavaScript ha explotado en popularidad en pocos años y sí, el ecosistema es horriblemente complejo. Es un chiste constante, incluso entre los desarrolladores de JS a tiempo completo, lo loco que se ha vuelto. Ninguno de nosotros puede seguir el ritmo", confesó un desarrollador en un debate reciente en Hacker News.

Esta parte da miedito. Desde luego nunca entendí como la escalada sobre funciones web avanzadas partió de JavaScript sabiéndose cómo estaba montado, quizá fue por los mismos motivos de la eficacia de JavaScript: las prisas.

4 46
#11 honbu

Esperemos que webassembly progrese y haga honor a lo de javascript killer

2 23
#12 sorrillo *

No han matado al COBOL van a matar al JavaScript ...

31 214
#13 raul_lapeira

#12 Lo de matar lenguajes es como matar idiomas... Como decían en Maquinavaja 2 "me pase 45 años sin poder hablar catala y vas a venir tu a tocarme los h***os con el castellano"

3 24
#14 chavi

#4 Concuerdo. Esa carrera para que los navegadores se lo coman todo es muy contraproducente

0 9
#15 raul_lapeira

#11 JS no lo tumba ni cristo. Ojala

3 35
#16 rodrig

JavaScript es basura.

Pero también es verdad que aquí se criticaba a C, un lenguaje precioso, simple y sencillo que entra en cualquier autómata.

0 10
#17 par

#6 Pero eso se puede saber, no?

0 7
#18 chavi *

#6 Porque los hay.
Empiezas a corregir el primero, hasta que se acabe el último.

El problema es ya de librerías de terceros.

1 19
#19 emdi *

Y el cabron lo dice ahora.....

4 41
#20 chavi

#8 Python no funciona como lenguaje de cliente. Son nichos distintos

5 47
#21 armadilloamarillo *

#11 Eso no va a suceder mientras sea necesario manipular HTML, ya que no tiene acceso directo a DOM (Los elementos de HTML) (se accede via JS y no hay planes para modificar esto)

3 31
#22 chavi

#10 ¿?

A qué te refieres exactamente?

0 9
#23 DenisseJoel

#6 Por eso se usa TypeScript.

4 44
#24 raul_lapeira

#3 Otro lenguaje hipster que acabara en el 0.3% en Tiobe... Apuestas?

Pd: espera que YA está en el 0.34%

8 66
#25 PacoJones

Yo lo que estoy hasta los webs es que cada día sale una nueva librería/framework de Javascript que reinventa la rueda.
Además que JavaScript surgió para cubrir unas necesidades de añadir comportamientos y dinamismo a las páginas pero están hiendo demasiado lejos, depurar y trabajar con ello es un tortura, por no mencionar las decenas de herramientas relacionadas con paquetes de módulos y managers y dependencias y configuraciones y bugs... estoy seriamente pensando en pasarme a back-end definitivamente. Estoy mucho más disfrutando con PHP ahora mismo, imaginaos como es mi vida de disfuncional ahora mismo

5 42
#26 selina_kyle

#20 lo sé, pero molaría que los navegadores pudiesen interpretarlo!!

2 27
#27 armadilloamarillo

Lo que hay que eliminar son las aplicaciones en Electron. Vienen del infierno.

8 57
#28 Meneathor

Douglas Crockford: "2022, será el año de COBOL en el navegador"

2 12
#29 sauron34_1

No sé si matar JavaScript, pero que dejen de sacar librerías por dios. Vue está bien, por ejemplo. Que dejen de reinventar la rueda.

3 42
#30 Supercinexin

#10 Fue porque Google, a principios de siglo, decidió que a partir de entonces Javascript iba a ser la solución para crear cualquier tipo de aplicación en la web.

4 43
#31 Supercinexin

#25 Muy guapo ese "hiendo".

6 55
#32 frutosm *

#25 yendo* en lugar de hiendo.
PHP más JavaScript, huye, sal corriendo y no vuelvas a ese proyecto

1 16
#33 PacoJones

#31 #32 ay, mil perdones, me acabo de dar cuenta, sirve la excusa del autocorrector?

1 28
#34 musg0

#4 Se intentó con XHTML con la intención de que los motores HTML fuesen más ligeros y fue un fracaso. Ningún desarrollador lo usaba en modo estricto XML, entre muchas cosas, porque los usuarios algunas veces necesitan meter texto enriquecido y por muy bueno que fuera el editor para meter texto muchas veces sin saberlo generaban código html incorrecto, y los motores de validación tenían difícil decirle al usuario qué estaba mal y que lo entendieran sin acceder al código fuente del html generado.
Por no hablar de bugs que generaban html incorrecto y salían meses después de haber publicado una web y que sólo se daban con combinaciones concretas de datos metidos por los usuarios.
Así que para no quedar mal todo el mundo que lo usaba no validaba los errores y lo usaba como HTML normal. Luego se pasó a HTML 5 y la idea de validación por XML se abandonó.

Para que funcionara algo como lo que dices todos los navegadores y motores web en uso tendrían que ponerse de acuerdo y poner una fecha límite para que las empresas fueran cambiando de paradigma, y eso no va a pasar, ya que tal como está montada la web actualmente generaría muchísimos costes y ralentización de desarrollo a todas las empresas que se dedican a hacer webs, que van a poner todos los impedimentos que puedan, y porque basta que un solo navegador funcione como hasta ahora para que los usuarios migren a ese porque "ese funciona" y el resto es una mierda porque da errores. Suerte explicándoles que ese que funciona es el que realmente lo está haciendo mal.

6 44
#35 xaviazo

#24 Dart es de Google, además es el lenguaje que va con Flutter. Ya me contarás en un par de años.

1 13
#36 ur_quan_master

A estas alturas me conformo con que encuentren al autor de los conceptos transpilador y transpilación y lo azoten con el cable de la impresora ( el paralelo, no el USB)

4 37
#37 runciters_animals

#21 wasm no puede llamar a JS y JS modificar el DOM? con una pequeña lib valdria

2 8
#38 pakorrito

#29 y como vamos a saber si un numero es par o impar???!!!!

5 48
#39 llorencs

#26 Ojalá

1 9
#40 apetor

#35 Sea de quien sea, no necesitamos un LENGUAJE para esto, necesitamos un standard de ejecucion, un runtime abierto y bien documentado que se soporte en todo navegador mediodecente. Que cada uno use el lenguaje que le salga de los hievos. WebAssembly es la idea. Marquen ustedes un hardware virtual y denme el codigo maquina y definicion de formato de los modulos ejecutables.

Un poco de orden, que la web es una gran casa de putas, y mucho es por que para 1 tio que hay con frialdad y ganas de hacer las cosas bien hay 100000 hippies con infulas e ideas de bombero.

18 114
#41 Dedalos *

¿Qué tiene que ver lo bien o mal que estén hechas las páginas con el lenguaje en sí?. Y ¿Que soluciona ser estrictos con la creación web? Dentro de unos márgenes, Internet está hecho para comunicar, el virtuosismo o purismo informático es otra cosa, estará bien pero no es de lo que va Internet.

4 37
#42 Veelicus

#4 no cargarnia ni una, y si ademas añades los temas de accesibilidad entonces se cierra internet

2 28
#43 tamat

#21 hace tiempo que se habla de dotar a WASM de un API para acceder al DOM y otros APIs del navegador, del mismo modo que existen proyecto para un layer IO para WASM que sea standard.

1 16
#44 apetor

#34 Los formatos de texto son caca. Pero mas alla de texto o no texto, hace falta fijar un entorno de ejecucion, hardware virtual descubrible y con versionado pero sin ser una casa de putas. Y luego WebAssembly o algo en esa via, pero ese mismo esta bien.

0 6
#45 KaborlllLLLONE

#37 WASM está pensando para ejecutar rutinas con un tiempo de ejecución normalizado entre navegadores. No está pensado, y no va a estarlo, para hacer más allá de eso.

0 7
#46 shotgan

Lo mejor que podemos hacer hoy con Javascript es "jubilarlo".
Gracias.

0 6
#47 apetor

#21 El glue JS, cancer, decian que era temporal... que se cambiaria a algo nativo... En realidad, si tienes un canvas donde pintar... si, supongo que hay necesidad de generar HTML, pero... bueno, ya veremos.

0 6
#48 apetor

#37 Eso es un cancer.

0 6
#49 apetor

#16 C es dios. JS es basura, por favor, la comparacion...

2 19
#50 --348464--

» ver comentario
#51 KaborlllLLLONE *

#22 Entiendo que se refiere al ecosistema y no tanto al lenguaje. Lenguaje que, por mucho que digan aquí en menéame, es una maravilla. Los closures, o los async, lo thread safe del lenguaje, las funciones anónimas, son features maravillosas.

Ahora bien, el ecosistema es lo putísimo peor... que si libraries y frameworks que salen cada dos por tres, que esta libreria funciona solo en un tipo de paquetes, y esta otra es sólo un módulo, y esta es módulo pero ES6 y esta otra es sólo para CommonJS y esta otra es UMD y este otro grupo de desarrolladores dice que UMD caca y que mejor no hacer eso, etc etc etc. Ya sin entrar a la putísima mierda de frameworks frontend en donde todo está mal, nada tiene sentido. Complejidades, herramientas todavía más complicadas, etc. Convenciones y más convenciones por todos lados, sin ningún estandar efectivo. Typescript ayudando y poniendo orden y al mismo tiempo añadiendo una nueva layer y más y más caos. Después la barbaridades de añadir paquetes de terceros para cualquier gilipollez. Basura deprecated, anticuada, malas practicas por todos lados. MUY malos ingenieros por todos lados, aunque el ecosistema tampoco ayuda en absoluto.

Pero, en serio, Javascript como lenguaje está muy bien y ser el creador del mismo no significa que sepa de lo que está hablando.

7 53
#52 tunic

Potente, flexible, de sintáxis esotérica cuadno se usan cosas avanzadas y muy fácil romper cosas sin siquiera tener la menor idea de por qué. Con la ventaja de que funciona en muchos entornos diferentes una vez se ha estandarizado y se acabó la guerra de los navegadores. Mejor no matarlo, lo mejor es usar otro lenguaje como TypeScript o Elm y transpilar a JS.

Ahora, estoy de acuedo en que ES6 metió algnas cosas criminales (como las falsas clases) que lo hacen aún más lioso.

5 43
#53 chavi

#51 Digamos que no hay otra alternativa a la altura para su nicho.

0 9
#54 chavi

#26 Para que?

2 27
#55 knzio

#17 no siempre es sencillo de encontrar

0 11
#56 Ricky

#26 pyscript.net/

0 6
#57 mcfgdbbn3 *

Sí, como Flash, que lo "jubilaron" y ahora tenemos un montón de minijuegos que no funcionan.

Si "quitan" JavaScript lo que acabará ocurriendo es que la gente tendrá que usar dos navegadores de Internet, uno moderno y otro antiguo, para poder acceder a páginas web cuyos autores no piensan modificar porque las han hecho gratis y demasiado si pagan ellos el hospedaje de su bolsillo.

Lo que tienen que hacer en JS es permitir "programar bien", por ejemplo, permitir usar tipos de dato definidos (int, float, double... pero aún mejores), pero sin renunciar a la opción de usar tipos de dato como ahora, que van en función de lo que declaras. Eso permitiría programar aplicaciones web muy robustas si el programador quiere, y luego si no quiere, hacer las cosas un poco como ahora.

¿Opción más realista? Que los navegadores aceptasen TypeScript.

2 25
#58 honbu

#21 Lo se pero soñar es gratis

0 6
#59 Dark_Wise

Lo siento pero queda JS para largo.
Por curiosidad, sabéis de algún otro lenguaje que tenga desestructuración, y spread?

2 23
#60 --95040--

Javascript es basura, ya en 2003 parecía que podríamos matarlo pero surgió AJAX y fue un balón de oxígeno para el lenguaje pero hoy deberíamos eliminarlo juntamente con PHP. Quizás quedarnos con Python o D o volver al BASIC de MSX.

0 6
#61 --706165--

Cuando veo por aquí a alguno "sentando cátedra" y hablando en tono ranchera "y mi palabra es la ley" solo puedo recordarme a mí mismo hace algunos años. No sé si hará falta otro lenguaje u otro estándar o vete a saber qué pero lo que seguro hace falta es bastante humildad en el sector.

10 70
#62 retoqueteate

Hoy? Y ya desde antaño.

0 6
#63 selina_kyle

#56 eso solo transforma python a Javascript no? Yo me refiero a correr de forma nativa python en lugar de Javascript en un browser

0 9
#64 dav *

#6 JS no falla silenciosamente, otra cosa es que pongas try catch y ocultes el error, pero eso no es problema del lenguaje ( y aún así el Firefox y creo que el chrome se paran en los errores cuando se producen independientemente de que estén capturados)

Cc #17 por supuesto que se puede saber

4 38
#65 rogerius

#40 Los hippies pasamos de todo. No nos cargues con los pecados de otros.

1 21
#66 fluffy *

#49 JS no es basura hombre.
C es como los Stark, rectos, del Norte, fieles a su código. Pero a la hora de la verdad, sin un puto duro. Cuando curraba en C y assembler compartía piso y no llegaba a fin de mes.
Javascript es la familia Lannister: follan entre hermanos, beben, montan orgías... No son los más rectos, pero están podridos de pasta. Y son más divertidos.
Gano en un mes de javascript lo que ganaba en el 2006 en un año de C.
Así que un respeto, que JS siempre paga sus deudas.
Gracias Javascript!

8 63
#67 Setis *

#25 Pues yo llevo como 5 años con React y ExpressJS (y amigos, como NextJS) y no me da problemas. Eso sí, te doy la razón con Angular y NestJS. Que ganas tienen esos de reinventar la rueda y reinventarla cuadrada.

4 30
#68 Setis

#59 Mainstream? Lenguajes de masas? Python tiene.

Lenguajes menos conocidos? Hay a patadas con desestructuración y spread. Por ejemplo Haskell, OCaML, Erlang y Prolog.

1 10
#69 Setis

#36 Vas a tener que azotar a muchos veteranos. Transpilación no es más que un nombre nuevo para compilación.

0 6
#70 apetor

#65 Ya sabes a quienes me refiero.

0 6
#71 apetor *

#66 No se cuanto ganabas o cuanto ganas, pero de hecho, es mas facil que ganes bien en trabajos donde solo se puede usar C, ensamblador y algo de C++, mas que en sitios de JS ( eso si, es probable que te paguen en USD ). Y luego esta lo de sufrir penitencias programando webs... bufff...

Y si, JS ES basura, lo es. Es una casa de putas.

Todabia no ha salido un lenguaje que no sea una casa de putas, no ha salido algo como C, aunque hay algun lenguaje viejo que se acerca y alguno nuevo que se acerca. Y digo C, no C++.

0 6
#72 Arlequin

Es el año de PHP en el front-end

0 10
#73 fluffy

#71 ganaba 24k anuales en 2006, ahora estoy en unos 300k anuales.
Si me consigues un salario similar en C yo me cambio

1 12
#74 apetor

#73 300k no se, lo veo dificil. 80-120k si.

1 9
#75 fluffy

#74 pfff, pues deberías cambiar a javascript, paga mejor.

0 9
#76 Setis

#10 ¿Por qué tienes que seguir el ritmo? El bleeding edge es precisamente así. Mejor deja pasar un poco de tiempo y quédate con los supervivientes. Yo llevo más de 5 años con React y ExpressJS, y desde que empecé he cambiado mi manera de hacer React como 3 veces en total. Por supuesto, no estoy al día de absolutamente todas las librerías que salen todos los días. Pero tampoco lo están ninguno de los programadores de todos los demás lenguajes de programación que sacan librerías a menudo.

El problema es que no hay ningún sustituto para Javascript en frontend. Todas las alternativas han sido deliberadamente peores: ActiveX, Flash, Java Applets, Silverlight. Todas ellas estaban basadas en el lock-in y el "sólo nuestro navegador o nuestras herramientas". Con WebAssembly quizás eso cambie, pero primero tenemos que ver algo que no caiga deliberadamente en los problemas anteriores (por ejemplo Blazor va de nuevo a "solo nuestro framework y nuestras herramientas").

Con respecto al backend, Javascript ofrece alternativas más sencillas que muchos sistemas actuales (excepto NestJS) y al mismo tiempo permite compartir código entre el frontend y el backend. Por ejemplo via NextJS. Esa es una combinación que muy pocos lenguajes de programación pueden ofrecer. De nuevo, WebAssembly puede cambiar eso, pero sólo si la gente deja de obsesionarse con sus herramientas propietarias y su navegador propietario.

Lo cual significa que tendremos Javascript para rato.

1 16
#77 CrudaVerdad

#4 selección darwiniana: navegador que se haga de la vista gorda si hay errores de HTML y que renderice cómo pueda, tendrá una gran ventaja evolutiva comparado a navegador estricto que no presenta nada hasta que el HTML sea correcto.

0 11
#78 --1479--

Explicación: xkcd.com/927/

8 60
#79 CrudaVerdad

Es como el teclado qwerty , una basura porque incita a cometer errores de ortografía y allí sigue. Nadie se atreve a sacar una nueva disposición de teclas.

0 11
#80 Setis

#71 Depende del mercado. C y ensamblador suena a sistemas empotrados. He trabajado en esos mercados. Pagan una mierda. Ahora han subido los salarios un poco, pero porque todos los programadores se iban a hacer webs en Javascript a ganar el doble. Yo soy uno de ellos.

JS es una casa de putas. Una casa de putas que paga bien.

El lenguaje para sistemas que no sea una casa de putas ya existe. Se llama Rust. Básicamente un C con sistema de tipos fuerte.

3 19
#81 apetor *

#80 Seguridad, AV, AntiRansomware,... y lo que viene fuerte, AntiCheat y demas, ensamblador x86 y x86-64, C y mucho internals de Windows y demas.

En cuanto a Rust, si, a ese me referia como algo nuevo sin ser casa de putas, aun asi no llega a lo que es C en algo Lean. Lo importante de Rust no son los tipos, no hay tanto problema, por mucho que se repita tanto, con los tipos, la verdad, no se lo que hace la gente para que eso sea tanto problema. Lo importante de Rust es el Borrowing, arma de doble filo, pero bueno...

0 6
#82 apetor

#75 Prefiero que me pisen los testiculos.

1 16
#83 chavi

#44 Por qué los formatos de texto son caca?
HTML es caca?
JSON es caca?
Yaml es caca?

0 9
#84 zancudo

#26 Dios no lo quiera, cambiar satanás por el diablo

1 15
#85 apetor

#83 Por que son, por naturaleza, mas laxos, mas propensos a problemas de seguridad y menos optimos de procesar. Pero bueno, pa ciertas cosas pues se pueden usar. Pero una web basada en TLVs binarios con webassembly y tal, con un entorno de hardware virtual bien definido, y nos iria mucho mejor que con la casa de putas que tenemos montada ahora.

2 23
#86 ninefingers

#26 Sólo nos faltaba eso ya…

1 14
#87 Setis

#81 ¿Qué crees que es el borrow checker? en.wikipedia.org/wiki/Substructural_type_system Si mal no recuerdo, una variante de Affine Type Systems. Los sistemas de tipos pueden ser mucho más avanzados de lo que se muestra a la gente. Por ejemplo, Agda y Idris usan los sistemas de tipos para empezar a demostrar que los programas son correctos por construcción. Y cuando digo demostrar, digo demostrar matemáticamente con toda la rigurosidad.

0 6
#88 ninefingers

#27 por Dios, escuchen a este hombre.

1 10
#89 ninefingers *

#50 Node es una puta perversión… Espero que el inventor arda en el infierno.

2 14
#90 ninefingers

#60 Es hora de desempolvar Perl.

1 17
#91 fluffy

#82 hay que ser más abierto de mente. Los developers de un único lenguaje sois muy limitados. Lo importante es el algoritmo, el pensarlo, no el lenguaje con el que se expresa. A mí lo mismo me da Python, rust, C, java, C#, javascript, lo importante es lo que voy a implementar.

Abre tu mente hombre. Que además abre puertas.

3 31
#92 JungSpinoza

#35 en un par de años @raul_lapeira te dira que ya esta al 0.36%!

1 20
#93 abnog

#40 No por dios, otra máquina virtual más no, por favor.

3 23
#94 JungSpinoza *

#8 En Python llevais diez años actualizando de la version 2 a la 3 (en realidad 14 años para ser mas exactos). Antes de que la gente termine llegara la version 4 ...

3 30
#95 apetor

#87 Hombre, si me quieres decir que el Borrowing es parte del tipado... vale, pero el borrowing en si puede hacerse incluso en sistemas detipado laxo, vamos, que es algo independiente de eso.

0 6
#96 apetor

#91 Juan Palomo...

0 6
#97 JungSpinoza *

#76 Exactamente. React y Express son de 2013, no hace falta estar todo el dia cambiando de framework. Cambias una libreria aqui, otra por alla ... te preguntas porque hay que escribir todo ese codigo para usar redux saga, cambias a useEffect .. te das cuentas de que es una mierda y vuelves a Redux, luego cambias RecoilJS que luego no funciona por dios sabe que incompatibilidad con react asi que pruebas Jotai y asi hasta que te retiras ...

1 21
#98 JungSpinoza *

#11 #21 #15 JS va a durar mas que Cobol ... los dev de JS tienen el trabajo mas asegurado que los funcionarios

2 29
#99 apetor

#93 Hombre, maquina virtual vas a tener, pero en vez de tener putas mierdas inmantenibles de JS como ahora, tener un virtual hard. Que quieres, bajar codigo x86(-64), ARM(64),... a cliente y ejecutarlo ?

1 13
#100 zancudo

Y la alternativa que propone es E.
Esta es la web del lenguaje: erights.org/ No utiliza ni https y parece sacada de los 90 (falta un gif animado con un cartel de en construcción), con enlaces para probar el lenguaje online sin instalar nada como este: meme.b9.com/cdates.html?channel=erights (que no funciona). También podéis visitar la sección de la wiki Getting Started (wiki.erights.org/wiki/Getting_Started) que no se actualiza desde 2011.

0 8