Portada
mis comunidades
otras secciones
#31:
Lo terrible de JavaScript (en el lado cliente) no está en su sintaxis o en las inconsistencias del lenguaje sino en su ecosistema.
El mundo front-end se ha convertido en una puta locura donde cada mes sale un nuevo framework/herramienta de despliegue/gestor de paquetería que lo va a revolucionar todo dejando obsoletos los anteriores.
Eso, y la manía de reinventar la rueda una y otra vez y volver a una mala praxis (como lo es por ejemplo entremezclar js con html, entre otros errores que ya habíamos superado).
El mundo front-end se ha convertido en una puta locura donde cada mes sale un nuevo framework/herramienta de despliegue/gestor de paquetería que lo va a revolucionar todo dejando obsoletos los anteriores.
Eso, y la manía de reinventar la rueda una y otra vez y volver a una mala praxis (como lo es por ejemplo entremezclar js con html, entre otros errores que ya habíamos superado).
#102:
#62 Netflix utiliza AWS sólo para la parte del portal, todo lo que es el catálogo y demás, pero una vez que empiezas a reproducir pasas a usar su arquitectura propia. Y la infraestructura de Netflix es enorme, llegan a acuerdos con los ISP para montar sus servidores directamente en los datacenters de estos últimos. Sí, los vídeos maestros se almacenan en S3, pero de ahí se distribuyen a todos sus servidores por el mundo, y lo que a ti te llega a tu casa no viene de S3. Sobre los codecs, han investigado muchísimo en como mantener la mejor calidad de imagen para cualquier ancho de banda, y saltar automáticamente según cambien las condiciones de red.
Decir que Netflix es muy malo técnicamente es no tener ni idea de lo que se está hablando. Mira en https://www.reddit.com/r/programming/search?q=netflix&restrict_sr=1 y empieza a leer todo lo que hacen.
Y por cierto, a lo que #57 se refiere al mencionar el ensamblador es a cosas como SSE y AVX, a menudo el compilador no puede aprovecharlas bien y hay que escribir el código manualmente usando intrínsecos.
Decir que Netflix es muy malo técnicamente es no tener ni idea de lo que se está hablando. Mira en https://www.reddit.com/r/programming/search?q=netflix&restrict_sr=1 y empieza a leer todo lo que hacen.
Y por cierto, a lo que #57 se refiere al mencionar el ensamblador es a cosas como SSE y AVX, a menudo el compilador no puede aprovecharlas bien y hay que escribir el código manualmente usando intrínsecos.
#9:
Hay muchos otros manuales que quieren inculcar Javascript de forma relativamente rapida. Todo depende en la capacidad de estructurar y resumir del autor.
Cuando he tenido que usar esta abominacion y actualizarme he recurrido a https://javascript.info/ .
Luego http://es6katas.org/ esta tambien bastante potable.
Es lo que tiene JS, mucha gente quiere ganarse la medallita por poner orden a "eso", y salen tutoriales chulos, a la par que nuevas revisiones del estandar donde maquillan al muerto mejor y mejor.
Cuando he tenido que usar esta abominacion y actualizarme he recurrido a https://javascript.info/ .
Luego http://es6katas.org/ esta tambien bastante potable.
Es lo que tiene JS, mucha gente quiere ganarse la medallita por poner orden a "eso", y salen tutoriales chulos, a la par que nuevas revisiones del estandar donde maquillan al muerto mejor y mejor.
#33:
#19 Piensa en otros lenguajes que se pensaron para otras cosas y han ido evolucionando y mejorando... PHP era básicamente un apaño para hacer loops y manejar querystrings sin usar cgi-bin. O Delphi era un lenguaje pensado para enseñar a programar y hoy día hay bancos funcionando con eso. Si no recuerdo mal Python se creó con la idea de la docencia también, pero hoy día es el rey del big data junto con R...
Por otro lado, y esto es a la vez una ventaja y una jodienda, JS hoy día tiene varias implementaciones, y no es lo mismo usar Coffeescript que Ecmascript. Te doy la razón en que todo esto es un forzado del lenguaje para llegar a lo que se quiere hacer hoy día con él, pero yo no lo veo algo malo, al contrario, considero que es síntoma de que está vivo y puede crecer y mejorar hasta ser robusto y decente.
Por otro lado, y esto es a la vez una ventaja y una jodienda, JS hoy día tiene varias implementaciones, y no es lo mismo usar Coffeescript que Ecmascript. Te doy la razón en que todo esto es un forzado del lenguaje para llegar a lo que se quiere hacer hoy día con él, pero yo no lo veo algo malo, al contrario, considero que es síntoma de que está vivo y puede crecer y mejorar hasta ser robusto y decente.
#14:
#1 un clásico: https://www.destroyallsoftware.com/talks/wat
#38:
#34 Yo creo que todos esos inventos vienen forzados por una industria que quiere curritos que haga a todo. Las empresas no quieren contratar a un experto en C++ Builder (o PyGTK para ser multiplataforma), otro en Android, otro en iOS y otro en web; quieren a un solo tipo que sea capaz de hacer la web, el backend, la app móvil y la de escritorio. Así que han aparecido inventos para que un desarrollador web pueda desarrollar una "web" ejecutable en escritorio.
#1:
Las bondades de JavaScript.... un lenguaje que hasta hace nada no tenía variables locales. Por lo demás interesante en los tiempos que corren no queda otra que usarlo.
#2:
JavaScript más allá del navegador es una abominación.
Y dentro del navegador, es porque no hay mejores opciones.
Y dentro del navegador, es porque no hay mejores opciones.
Comentarios
Lo terrible de JavaScript (en el lado cliente) no está en su sintaxis o en las inconsistencias del lenguaje sino en su ecosistema.
El mundo front-end se ha convertido en una puta locura donde cada mes sale un nuevo framework/herramienta de despliegue/gestor de paquetería que lo va a revolucionar todo dejando obsoletos los anteriores.
Eso, y la manía de reinventar la rueda una y otra vez y volver a una mala praxis (como lo es por ejemplo entremezclar js con html, entre otros errores que ya habíamos superado).
#1 un clásico: https://www.destroyallsoftware.com/talks/wat
#16 no puedo elaborar tanto en un comentario de Menéame.
Java es abominable en rendimiento con máquina virtual, pero es mucho más decente como lenguaje que JavaScript.
Este es un lenguaje pensado para comprobar formularios que se ha forzado para hacer casi cualquier cosa con el.
Hay muchos otros manuales que quieren inculcar Javascript de forma relativamente rapida. Todo depende en la capacidad de estructurar y resumir del autor.
Cuando he tenido que usar esta abominacion y actualizarme he recurrido a https://javascript.info/ .
Luego http://es6katas.org/ esta tambien bastante potable.
Es lo que tiene JS, mucha gente quiere ganarse la medallita por poner orden a "eso", y salen tutoriales chulos, a la par que nuevas revisiones del estandar donde maquillan al muerto mejor y mejor.
Las bondades de JavaScript.... un lenguaje que hasta hace nada no tenía variables locales. Por lo demás interesante en los tiempos que corren no queda otra que usarlo.
JavaScript más allá del navegador es una abominación.
Y dentro del navegador, es porque no hay mejores opciones.
#2 claro! Por eso empresas como Amazon o Netflix usan NodeJS, que solo tienen unas pocas visitas y casi cero recursos para implementar otras soluciones.
#19 Piensa en otros lenguajes que se pensaron para otras cosas y han ido evolucionando y mejorando... PHP era básicamente un apaño para hacer loops y manejar querystrings sin usar cgi-bin. O Delphi era un lenguaje pensado para enseñar a programar y hoy día hay bancos funcionando con eso. Si no recuerdo mal Python se creó con la idea de la docencia también, pero hoy día es el rey del big data junto con R...
Por otro lado, y esto es a la vez una ventaja y una jodienda, JS hoy día tiene varias implementaciones, y no es lo mismo usar Coffeescript que Ecmascript. Te doy la razón en que todo esto es un forzado del lenguaje para llegar a lo que se quiere hacer hoy día con él, pero yo no lo veo algo malo, al contrario, considero que es síntoma de que está vivo y puede crecer y mejorar hasta ser robusto y decente.
#62 Netflix utiliza AWS sólo para la parte del portal, todo lo que es el catálogo y demás, pero una vez que empiezas a reproducir pasas a usar su arquitectura propia. Y la infraestructura de Netflix es enorme, llegan a acuerdos con los ISP para montar sus servidores directamente en los datacenters de estos últimos. Sí, los vídeos maestros se almacenan en S3, pero de ahí se distribuyen a todos sus servidores por el mundo, y lo que a ti te llega a tu casa no viene de S3. Sobre los codecs, han investigado muchísimo en como mantener la mejor calidad de imagen para cualquier ancho de banda, y saltar automáticamente según cambien las condiciones de red.
Decir que Netflix es muy malo técnicamente es no tener ni idea de lo que se está hablando. Mira en https://www.reddit.com/r/programming/search?q=netflix&restrict_sr=1 y empieza a leer todo lo que hacen.
Y por cierto, a lo que #57 se refiere al mencionar el ensamblador es a cosas como SSE y AVX, a menudo el compilador no puede aprovecharlas bien y hay que escribir el código manualmente usando intrínsecos.
#180 Yo trabajo activamente programando en JavaEE, Python, JS, trabaje mucho con PHP y a veces lo hago para ciertas cosas y realmente para aplicaciones empresariales no he encontrado nada mas facil de trabajar que Java, para aplciaciones "mias" no he encontrado nada mas limpio y rapido que Python
#34 Yo creo que todos esos inventos vienen forzados por una industria que quiere curritos que haga a todo. Las empresas no quieren contratar a un experto en C++ Builder (o PyGTK para ser multiplataforma), otro en Android, otro en iOS y otro en web; quieren a un solo tipo que sea capaz de hacer la web, el backend, la app móvil y la de escritorio. Así que han aparecido inventos para que un desarrollador web pueda desarrollar una "web" ejecutable en escritorio.
#38 Esos inventos (como los llamas) están diseñados para hacerte la vida más fácil, para ahorrarte tiempo y para ayudarte a cometer menos errores. Si quieres ponte a picar con pico y pala pero si hay un martillo neumático y no lo usas es tu problema, no intentes ver fantasmas donde no los hay.
#12 Yo prefiero la regla del 90-90. Aprender el 90% te llevará el 90% del tiempo. Aprender el 10% restante te llevará el otro 90%
https://es.wikipedia.org/wiki/Regla_del_noventa-noventa
#16 Referente a JS: tan solo su implementación asincrona ya es para darle de ostias a quien lo inventara.
Y por el leve tipado dos ostias más.
Por la cantidad de mierdas y problemas de JS salió TypeScript.
Es más, es tan a boleo lo que hacen que se han pasado años añadiendo la necesitad de punto y coma a final de sentencia y luego quitándola, en 2014 debías finalizar con punto y coma, pero no en 2016, luego si, pero a día de hoy no. Es una casa de putas.
Referente a Java si, mi problema con Java es su JVM pero también es su principal virtud. Y parece que con la incursión de .Net-Core Oracle ha decidido darle vida al lenguaje y liberar su desarrollo mejorarlo, el principal problema de Java se llamaba Oracle.
#78 Otra de las cosas divertidas de JS:
La fiesta de los frameworks que son la ostia.
Tengo yogures en la nevera con fecha de caducidad mayor que el 90% de los frameworks de JS
#19 *cof cof cof cof cof cof cof cof * perdón, me atragantaba con la caspa de tu comentario.
#13 no te digo que no, ahora mismo estoy haciendo una aplicación con react y electron, pero me parece un absurdo, cientos de megas de proyecto para una puta app de escritorio para 4 paginas de nada.
Alguien me podría explicar a quién le puede parecer mejor o más intuitivo cambiar:
const foo = function foo()
por esto?
const foo = () => doSomething()
O peor aún, por esto?
const foo = param => doSomething(param)
O por ejemplo, esto:
setTimeout(function() , 1000)
}, 1000)
Que es cierto.. un timeout dentro de otro timeout puede parecer un poco enrevesado pero se entiende, pero... ¿habrán inventado una forma mejor de hacerlo?
const wait = () => new Promise((resolve, reject) => )
wait().then(() => )
.then(() => console.log('I promised to run after 2s'))
Pues no, no sólo es más largo sino que es ilegible a no ser que lo conozcas bien.
#19 Java es abobinable,pues nose ,ponte a programar en PHP algo con una complejidad elevada,o con C y olvídate de liberar memoria,Java rules,porque Java es fácil de aprender e implementar,y en eso no le gana nadie,luego ya no hablaremos de malas practicas de programadores,mala optimización del código,no usar el multithreading(o peor,usarlo mal)
#15 Amazon y Netflix usan muchas cosas que van de C incluso ensamblador a JavaScript.
Digamos que usan todo.
#1 ¿? Javascript siempre ha tenido variables globales y locales...
#54 Yo lo que estoy viendo es que nos estamos alejando cada vez más de lo que se buscaba en un principio, que era que las cosas sonaran más o menos naturales.
Si me pones:
foo = param => doSomething(param)
yo intuitivamente pienso "foo = param" ? quiere decir que están asignando el valor de param a foo? Entonces foo es una variable? y después leo "implica o señala" doSomething(param), aja... pareciera llamar a la función do something con el parámetro param... pero entonces por qué lo asignaro a foo? A no ser que no lo estuvieran asignando. Tal vez estaban "afirmando" que foo equivalía a param. ¿o sería una comparación?
Por otro lado, cuando pones:
function foo(param)
queda clarísimo que estás creando una función llamada foo, que recibirá un parámetro y que ese parámetro se transferirá a la función doSomething().
A mi me gustó cuando aprendí hace muchos años Pascal. Un lenguaje que cualquiera que sepa programación, sin saber nada del lenguaje, puede leer y entender a demás de ser un lenguaje de nivel bastante alto pero con funciones de bajo nivel si hacen falta. Que no necesita punteros como el C pero los tiene si los quieres usar. Donde el compilador valida cada tipo de datos y no te deja cometer errores y a demás que compila en una sola pasada así que la compilación es increíblemente rápida. Pero sobre todo lo que mejor me parece de ese lenguaje era la legibilidad. Hay que teclear más pero a cambio el programa se puede entender y mantener fácilmente.
En ese sentido me sinpatiza bastante Python aunque tengo pendiente hacer algo en serio con él para aprender de verdad.
#33 pero esa es precisamente una de las cosas que lo hace abominable, que cambia constantemente.
¿Te imaginas tener una base de código de pongamos 1 millón de líneas de JavaScript? ¿Cómo estará dentro de 10 años? ¿Y de 30? ¿Cómo mantienes eso, con qué garantías?
El Kernel de Linux tiene 25 millones de líneas de código C que tienen casi 30 años, porque C es extremadamente estable y bien estandarizado.
#3 pues déjate...que los que quedan cobran fortunas por mantener legacy de la banca
#27 Javascript es TAN MIERDERO que cuando mas aceptacion tiene es cuando se inventan lenguajes que se pueden 'compilar' a javascript para NO programar en javascript
#62 mírate el código fuente de los códecs de video en Internet, por ejemplo los de FFMPEG (que usa Netflix) o GStreamer, busca tu mismo el ensamblador, y mira tu mismo los comits de parches y verás si son "un estándar" o se cambian constantemente.
#29 no es inclusivo? vull dir, aprendiendo TypeScript no aprendes también las bases de JavaS?
#37 He trabajado con .Net, .Net Core, PHP (Laravel y CodeIgniter), Java (Hibernate, Struts... hace ya bastante de eso), Perl (para web, ¡nunca más!) y C++. También, en el principio de mis tiempos laborales, con ASP-a-secas (VBScript). Actualmente trabajo con PHP-Laravel.
En total unos 15 años en la industria, los tres últimos como freelance.
Siempre hice backend. Puedo tocar HTML, CSS (y sus cositas asociadas tipo SASS, Bootstrap, etc) y JS (y las típicas librerías, y algo de React y de Meteor) pero mi creatividad es nula así que siempre me centré en el back.
#c-2" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3037976/order/2">#2 La gente que criticais tan duramente a javascript seguramente no habéis probado las últimas versiones del lenguaje, especialmente a partir de la especificación ECMAScript6 el lenguaje dió un salto cuántico y a estas alturas compararlo con antiguas versiones es basicamente como comparar lenguajes distintos.
Sin contar además que a día de hoy han aparecido lenguajes de mas alto orden como Typescript, fuertemente tipado que recuerda a java o C#, que compilan en javascript, por lo que poco tiene que ver el panorama con lo que era hace tan solo unos pocos años.
Además lo que hace fuerte a javascript ahora mismo es la enorme comunidad y ecosistema que tiene detrás, la mayor seguramente de todos los lenguajes de programación.
#21 Ese no es un problema de JS, es un problema de electron. Y sí, cualquier chorrada en electron son cientos de megas, pero es que desgraciadamente hacer una aplicación multiplataforma con interfaz gráfica sigue siendo muy complicado en 2018
#1 Es increíble que te voten positivo. Esto no hace más que demostrarme que la gente no sabe programar en JavaScript y después viene a Menéame a quejarse de cosas que simplemente no deberían hacerse en ese lenguaje.
Veo mucha ignorancia en los comentarios. Joder que triste.
#2 ¿Sabes cómo sé que las películas de 50 sombras de grey son una chusta? Porque me las he visto todas. Lo mismo para Lars Von Trier, aguanté como un campeón anticristo, dancer in the dark, melancolía, ...
Soy de la opinión de que no se puede criticar algo sin conocerlo lo suficiente.
12 años, 12 años enteros de mi vida estuve con Java certificándome como arquitecto, 8 con .NET con MSCD pero sin certificarme como arquitecto. He programado en COBOL, C++, ensamblador, Delphi, Ruby, ... y de ninguno he dicho jamás que sea una abominación.
A día de hoy casi todo lo que hago es NodeJS y Python. Y estoy contento con ello. Seguramente el primer día que escuché hablar de NodeJS me chocaba y tenía mis reticencias, ¿sabes cómo las superé? Usándolo.
Así que te recomendaría que lo usaras antes de emitir un juicio de valor tan negativo.
#134 #53
PHP esta muy extendido debido en parte a la facilidad y bajo coste de deploy.
Si trabajas para una empresa, mediana+ no tendras problemas con los costos de infraestructura que supone tener servidores propios como Tomcat, WildFly, deploys en pyhton con o hasta ISS, pero si desarrrollas para pequeñas empresas o particulares, muchas veces no suelen tener infraestructura y pueden no querer pagar un VPS que ademas les va a requerir mas administracion.
Ahi es cuando PHP "brilla" ya que cualquier hosting berreta de dos duros soporta el lenguaje con toda su especificacion, mientras que si quieres hacer un desarrollo en J2EE o en Python tus alternativas son VPS o servidores propios.
Otro tema es que como PHP esta tan extendido hay bibliotecas de alto nivel para casi todo, entonces cuando te enfrentasa un problema especifico seguramente ya exista una solcion rapida para ello, por no mencinar las miles de aplicaciones que estan escritas en PHP y dispoibles gratuitamente.
Y ojo, no defiendo PHP, no lo suelo usar para casi nada y tengo la suerte de trabajar en Java y Python pro hay que reconocerle algunas cosas al pobre PHP
#8 esos son los privilegiados,que han pillado un buen sitio,hay miles igual en cárnicas,cobrando igual que cualquier currito de otro lenguaje.
#48 Psé, algo de razón sí que tiene #38 (aunque ha errado en las tecnologías mencionadas, el estándar de facto en GUI multiplataforma es Qt, no GTK). Un desarrollo en C++ y Qt va a ser menos propenso a errores que un proyecto en React por muchas razones, como que Qt es un framework más maduro, o que el paso de compilación ya da cierta garantía de la validez del código, cosa que en lenguajes interpretados y/o débilmente tipados no ocurre.
#66 Es parecido, pero no es lo mismo por lo tanto no. En mi opinión Typescript fue interesante hace unos años. Hoy en día ya no tiene tanta utilidad y es mejor directamente utilizar es6+lintern+transpiler.
#121 sí, en mi empresa se pagan muy bien los programadores de C, y no encontramos.
No es mejor interesarse directamente por TypeScript?
..., alguien me puede decir si el manual está bien o no?
(que sois libres en al noticia obviamente de tratar lo que querais) yo estoy ahora mismo tratando de aprender Java (Y SQL) porque es lo mas solicitado en puestos superiores al mio, alguien me puede aconsejar, o comentar si el manual este vale la pena?
Que de 103 comentarios solo uno comenta algo de que hay mil manuales en internet.., el resto son todo comentarios sobre si es mejor Java o C, o si java es bueno o malo
Logo es el futuro, el concepto de la tortuga es revolucionario y no lo tiene ningun otro lenguaje
#14 20 veces te votaba esto
#14 watman!
#12 Mal aplicado. No puedes aprender 80% de cantidad en 20% de tiempo, no tiene sentido, a no ser que aprendas solo las chorradas inutiles y dejes todo lo complejo y útil.
Querran decir que han seleccionado el 20% del lenguaje mas util y te permite hacer el 80% de las cosas.
#38 Yo creo que todos esos inventos vienen forzados por una industria que...
Y yo creo que vienen forzados por unos Illuminati que...
Ahora en serio, si por "Industria" entiendes grandes corporaciones, a ellos se la suda. De hecho cuanto más desarrolladores especializados y aplicaciones específicas para cada entorno se necesiten, más van a poder facturar.
Somos los pequeños desarrolladores autónomos los más beneficiados de estos sistemas unificados, ya que nos permite competir con la "Industria" al requerir menos recursos.
#1
Las bondades de JavaScript.... un lenguaje que hasta hace nada no tenía variables locales. Por lo demás interesante en los tiempos que corren no queda otra que usarlo.
¿Quien te ha dicho tal mentira?
If the variable statement occurs inside a FunctionDeclaration, the variables are defined with function-local scope in
that function, as described in section 10.1.3. Otherwise, they are defined with global scope, that is, they are created
as members of the global object, as described in section 0.
Eso está sacado de la primera versión de ecma 262, que puedes leer aquí:
https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf
Es la primera especificación formal del lenguaje, del año 1997
En serio, no se de donde sacáis esas cosas.
#61 #121 lo único que tengo que añadir,es que no hay curro de C para empezar como junior, todos los "nuevos" acaban haciendo programación de alto nivel,que es lo que tiene mas salida.
Donde este el cobol
#1 las bondades de js,y lo que te deja guarrear,seguro que eres un puritano de python, ensuciate en el barro con js!
#1 #43 JS vs Python... Pelea de inválidos!
#45 Typescript es ES6 con anotaciones para tipos.... nada más.
De hecho, puedes pasar de escribir los tipos y son prácticamente lo mismo.
#8 no me jodas! Y yo, sabiendo cobol, haciendo webs cual adolescente acabado de salir del horno....
Que gustazo, un hilo interesante, con opiniones, discusiones y puntos de vista y sin apenas comentarios chorras!
Lástima que un palomo no haga verano....
#107 Pues ya está, contribuye como otros cientos de "anónimos", al mismo nivel (cosa que nunca he negado). No reinventa nada ni mucho menos prueba tus afirmaciones ("adaptarlas para usos serios", sea lo que sea que signifique eso para ti...).
#152 No, no existía, simplemente tenía un programa que lo cargabas con el diskette y este cargaba basic, que era el lenguaje con el que trabajabas. Luego, para copiar archivos, renombralos, etc usabas otro diskette llamado 'volorg' el cual presentaba un menú y tenía las funciones de un sistema operativo pero que en realidad era simplemente un programa en Basic, lo sé porque llegué a desprotegerlo y editar su código fuente...
#174 Compilar es traducir a lenguaje maquina, al menos según la RAE. Aunque ya sabemos que esto no es siempre así de sencillo. Por ejemplo Java que funciona con un compilador JIT cuando haces javac no estas haciendo una compilación real. Estas generando un bytecode interpretable por la jvm que será la que luego en ejecución traducirá ese bytecode en lenguaje maquina.
#2 Please, elaborate.
Lo que es una abominación es usar cosas como Java, con su VM, para ejecutarse en un servidor. O el monstruo que era (es) .Net antes de Core, parcheando un lenguaje/framework orientado a escritorio para usarse en web.
Edito: ojo, que yo no soy desarrollador JS (soy de backend, y por ahora no me tocó lidiar
aúncon Node más que para cosas sencillitas) pero lo que he usado de JS no me parece tan malo.#30 A mi modo de ver lo que más fuerte hace a JavaScript es la comunidad de Node.JS, además de ser un lenguaje con una curvatura de aprendizaje fácil y un entorno de ejecución muy plug & play. No necesitas un servidor para empezar a programar ya que es lado cliente (excepto librerías de lado servidor). Esa rapidez hacen de Javascript un lenguaje muy versátil y como bien dices el salto desde ECMAScript6 ha sido muy bueno. Mi crítica en otro comentario viene dado pro la falta de estandarización y consenso de los desarrolladores y como bien dices, el leve tipado trae mucho de cabeza ya que es a mi modo de ver un sinsentido.
#63 mmm... no que yo recuerde. Si defines una variable en un constructor no es accesible en el DOM, a menos que lo hagas usando "this.[etc]". (Y diría que dentro de una función tampoco, solo que debes declararlas con "var").
#79 se dice que en un lenguaje la memoria se direcciona a mano, cuando el programador puede controlar a que dirección de memoria apunta una variable de forma arbitraria, e incluso usando aritmética en las direcciones de memoria.
Eso no solo es posible en C, sino que muy habitual y necesario para ciertos casos.
#6
Imagínate que trabajé con diskettes de 8 pulgadas .... y que los primeros ordenadores con los que trabajé no tenían sistema operativo... Pero aquí estoy dando guerra....
#7 no jodas y yo pensando que por haber extrenado un Spectrum 16 kb, que lo conservo con su caja y "to" ya estaba cerca del jurásico
#8 lo se, lo se
#10 Yo empecé bastante antes, hice algunas cositas con el Spectrum, era bastante divertido....
#17 seguro que no usan lotus notes.
#19 lenguaje pensado para comprobar formularios
in yor feis
#47 mi trabajo diario es normalmente en C.
#61 anda que no se nota los que desarrollamos a diario C/C++... te lo noto en los comentarios a la legua. Deja a los niños con su JS y el framework de moda de la semana
No , ya en serio. Me preocupa quién va a programar cosas serias en el futuro, las nuevas generaciones cada vez están más lejos del hardware y todo lo que hay por ahí abajo, qué pena... Las empresas cada vez pagarán más por los que quedemos, eso sí 😂 😂
#14 Caray, mi primer vez. Buenísimo
#89 Agarraros los machos que REST también prehistoria.
#207 Es que lo de usar JS para backend es como lo de usar Delphi para aplicaciones de banca: "yo aprendí esto, así que voy a usar esto para todo y listos, ¿quién quiere aprender otro lenguaje?"
#45 lo probé con la librería JavaScript para juegos phaser, vi que tenía mejor tipado pero no le llegue a coger el punto. Eso sí solo por usar visual studio merece la pena.
#51 Y sin posibilidad de escapatoria,más que a otra cárnica similar
#39 No es mejor o peor, es distinto
La función flecha (=>) no cambia el contexto, así que "this" sigue siendo lo mismo que fuera de la función, mientras que en la definición clásica cambia. Para muchas cosas es mejor.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
#79 Un puntero sería una dirección de memoria puesta "a mano", no? Si pones un número al azar y sigues ese puntero te casca el programa casi con toda probabilidad.
También para recorrer un array de "objetos" (más bien structs) puedes guardar el puntero a la cabeza y vas sumándole el valor de lo ocupa el "struct" que contiene y así accedes a los diferentes campos que contiene.
#90 no hablo de usar una librería para dotar de asíncronía a la implementación si no que la implementación de JavaScript(ECMAScript6 ) es por defecto asíncrona y no controlas la ejecución de eventos a no ser que implementes el event.preventDefault() y personalmente creo que debería ser al revés, por defecto sincronía y si lo necesitas asíncrono.
Otro ejemplo y quizás patino es que por defecto la carga de scripts no es en paralelo y como pete uno se lleva a toda la página por delante.
#79 desde que aprendes a "jugar" con los punteros.... Aunque no tienes perquè hacerlo, claro.
#38 La gente que no sabe programar se te va a quejar, e incluyo los que scriptean en javascript.
"No hay que reinventar la rueda" dirán los que no saben ni que forma tiene una rueda.
#42 si no pones foto de perfil no te van a llamar para la oferta.
#21 Cambiate a Vue.js
React es pasado! es tan poco ... cool
#62 #87
https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-Faster-Sendfile
https://github.com/Netflix/vmaf/blob/master/wrapper/src/libvmaf.h
https://medium.com/netflix-techblog/high-quality-video-encoding-at-scale-d159db052746
Netflix contribuye al kernel de FreeBSD y contribuye a FFMPEG. Ahí tienes las pruebas.
#2 webasembly
#17 ensamblador no usan y c tampoco (al barro no bajan porque hoy en día no es necesario, les sale más rentable escalar horizontalmente o verticalmente en infraestructura que meterse a programar algo que les durará meses, estará plagado de errores, se les complicará mantenerlo y el día que se vaya quienes lo hayan hecho... problemón). Netflix basa todo su rendimiento en la infraestructura de aws. Para la parte de negocio batallan como todo hijo de vecino con soluciones de alto nivel. Cada cierto tiempo sacan artículos de cómo han hecho un cambio en js que ha hecho mejorar la cosa y cosas del estilo. (hay varios publicados). Donde más tiempo gastan es en aws, incluso han liberado algun proyecto para automatizar procesos en aws.
#57 Los codecs van en binario, porque han sido compilados, pero no porque se hayan programado en ensamblador. Y los vídeos están almacenados en S3. Y por otro lado ni siquiera los han desarrollado ellos. Lee más sobre netflix porque te veo un poco perdido. Netflix solo ha tenido mucha suerte desde un punto de vista comercial, técnicamente es muy malo, desde un punto de vista de usabilidad también es muy malo, ... y consiguen el rendimiento gracias a la infraestructura y la ayuda de aws (donde tienen a varias personas asignadas para ellos).
#64 Netflix no ha desarrollado ningún codec y mucho menos en ensamblador. Usa VP9 y H264
#13 ¿Desde cuando en C se direcciona "a mano" la memoria?
#84 A mi casi me pasa el tren por encima. En pocos meses en la empresa:
de React a Vue, Docker, Kafka, menos mal que el backend sigue siendo Rails
#1 Javascript tiene variables locales desde siempre, ej. https://librosweb.es/libro/javascript/capitulo-4/ambito-de-las-variables.html
#102 el 100% de netflix está en aws. Los vídeos en S3.
"como mantener la mejor calidad de imagen para cualquier ancho de banda, y saltar automáticamente según cambien las condiciones de red."
Pues entonces debo decirte que sin éxito.
#197 Erlang es bastante diferente, porque está enfocado al modelo de actor, concurrencia masiva, escalabilidad, tolerancia a errores, etc. Además, las variables son inmutables y la mayoría de los procesos tienen una vida muy corta, lo que facilita enormemente la recolección de basura.
En su campo concreto su máquina virtual (BEAM) es muy buena, pero la JVM es mucho más flexible. Con Erlang, en cuanto te sales de su campo de aplicación, el rendimiento es penoso.
#3
El lenguaje del futuro. Todos los demás quedarán obsoletos y seguirán los mainframes de IBM.
#7
Los primeros OS son de los años 60 ... ¿no estarás exagerando un poco?
Otra cosa es que el OS fuera rústico de narices.
#80 Pues es otro punto de vista interesante...
Yo lo decía porque estoy harto de ver ofertas para "full stack developer", que lo que significa es que tú solito te tienes que currar el front dinámico con Angular o React, el back, la app móvil para dos o tres plataformas y si te descuidas, la app para smartTVs.
En los últimos años como freelance lo que he hecho ha sido colaborar con otros pequeños desarrolladores autónomos: en un proyecto yo me encargo del back, otro del front, y un diseñador de la maquetación; a veces alguien más si hace falta app. Al final el tiempo de desarrollo con tres especializados es inferior al de uno solo "full stack" ya que cada uno se especializa en lo suyo, por lo que la "cooperativa" es más eficiente que uno solo.
Pero como te digo, es solo mi experiencia actual, que puede perfectamente cambiar el mes que viene, y es cierto que la scene de desarrolladores full stack independientes es cada vez más fuerte y ahí tiene todo el sentido lo que propones...
#121 Maldita sea, con lo bonito que es programar paginas web en C.
Cada lenguage tiene su funcion, que si, que con C puedes llegar a optimizar lo que quieras y consigues un bajo consumo de recuros, pues si, pero el tiempo invertido en programar y la curva de aprendizaje que requiere es enorme para poder hacer algo decente.
Los lenguajes de scripting estan para lo que estan, ofrecer dinamismo, no son perfectos y creo que no llegaran nunca al nivel de un lenguaje compilado, pero cumplen su funcion y lo hacen bien.
Estar lejos del hardware no es un problema, mientras el lenguaje que uses haga un uso optimizado de ese hardware al proporcionarte una api de mas alto nivel.
Como ya repeti, el problema no suele ser el lenguaje sino el programador. La pena, que creo que es a lo que te refieres, es que al no tener que tocar un lenguaje de bajo nivel no tendran ni idea de lo optimo o no es su codigo.
#132
No dice eso. y que los primeros ordenadores con los que trabajé no tenían sistema operativo.
Y a nivel de servidores es muy común comprarlos sin sistema operativo. O equipos para hacer el gamba, estilo Raspberry.
Y customizar el OS (supongo que te referiras al antiquísimo config.sys porque los UNIX/linux de toda la vida se han tocado y se siguen tocando) es muy distinto a operar sin él.
#114
Pero cargarías el OS desde el diskette por lo menos.
#163
Todas esas funciones (cargar el programa, copiar, cargar el intérprete las hace el sistema operativo) Claro que comparado con uno de los de ahora es corto de cojones, pero es un sistema operativo. Hasta el Spectrum (que lo que lanzaba era un intérprete de basic) tenía un sistema operativo muy pequeño para interactuar con la máquina.
#3 ¿el COBOL es esa cosa moderna que quier desbancar a Fortran?
#39 para los que estamos acostumbrados y avezados a la programación funcional, foo = param => doSomething(param) nos parece claro y conciso (expresiones lambda de una sola línea.
El const por eso me sobra. De hecho algo guay que tiene python es que no puedes definir lambdas de más de una línea por diseño (y una vez entiendes el por qué... Lo ves como una bendición y buena praxis)
#52 si que usan ensamblador, poco pero hay. Los códecs de video en el lado del server no van en JavaScript
#70 esperemos, porque sin "proactivo" y palabras molonas no tiene ningún futuro.