Ranking de casi un centenar de lenguajes de programación, frameworks y software (divididos en categorías) basado en la actividad (preguntas, respuestas, etiquetas y votos) de StackOverflow hasta febrero de 2016, incluyendo 3 meses más (hasta mayo) de predicción de tendencias.
Esto parece el Barrapunto de hace unos años. Qué manía de mezclar churras con merinas.
Poner Node/JS al lado de C es incorrecto e inapropiado por dos razones:
a) Node es un intérprete de un lenguaje, JS. C es un lenguaje que se traduce a código nativo. Son dos cosas totalmente diferentes y no comparables.
b) Un camión es más lento que un fórmula uno. ¿Qué sentido tiene comparar JS/Node con C, cuando su ámbito de aplicación es totalmente diferente? Nadie programaría un controlador en JS/Node y nadie programaría una API REST con C, al igual que nadie haría el reparto de mercancía en un fórmula uno o iría a un circuito con un camión de reparto.
#3:
Ayy StackOverflow, el yahoo respuestas de los programadores.
Por StackOverflow 🍺 , causa, y a la vez, solución de todos los problemas de código.
#36:
#33 O simplemente que la gente que se dedica a otros lenguajes no está acostumbrada a que le den las cosas más absurdas hechas, mientras que los de javascript son unos vagos, como se demostró de forma empírica con el escándalo de npm y la función de 4 lineas de la que dependían un montón de proyectos.
Ni PHP ha llegado a niveles de tal vergüenza ajena.
#46:
#21#11 Tk es residual, aunque sigue siendo el toolkit de referencia en muchos proyectos (ej: gitk).
Qt en desktop se usa muchísimo: KDE, clientes de escritorio de todo tipo (se me viene Skype a la cabeza, VirtualBox,...)
El día que se implante definitivamente en el desktop el paradigma HTML+JS+CSS, vuelvo a la terminal para siempre, no me jodas. Hay buenas ideas por ahí, como en GTK estilar los constroles con una especie de CSS, o poder poner widgets HTML en el escritorio, o "scriptear" el escritorio con JS, pero de ahí a que el escritorio en sí sea HTML+JS+CSS... que mis ojos no lo vean, por favor.
#63:
#38 Otro con lo del "no tipado". Qué atrevida es la ignorancia. ¿Desfragmentado? ¿Python desfragmentado? Pero, ¿qué entiendes tú por desfragmentación?
> de todas formas mi impresión sobre python va de la mano
> de los ides que probé de las librerías graficas
Es una amplia experiencia la tuya, está claro que te habilita para valorar un lenguaje y emitir el juicio "es una mierda".
> mis problemas al tratar listas/diccionarios que al recoger datos
> nunca sabía en que formato me llegaban y iba a prueba y error
Ah, claro, la causa de tus problemas con las estructuras de datos que manejas es el lenguaje. Bien.
#17:
#3 Antes de SO cuando tenías un problema con una tecnología tocaba rastrear la red por foros especializados y listas de correo infinitas hasta encontrar solución.
Pillo la cita de los Simpson pero SO más que causa es consecuencia de los problemas de código. Siempre los ha habido y los habrá, pero el bien que hace tener una comunidad dedicada a concentrar todos ellos es cuantificable en tiempo ahorrado.
#18:
#2 en realidad es cuanto aumenta la actividad en stack overflow por lenguaje, así que Javascript es el lenguaje que da más problemas y con el que nadie sabe que falla porque no debugga
#73:
#2You must enable JavaScript in order to visualize the ranking interactive charts.
¡Ese ránquin está amañado!
#28:
#5 Más que imbatible es que es tan inusable que hay que pasarse todo el día haciendo preguntas en stackoverflow para conseguir hacerlo funcionar.
#40:
#37 Y yo, pero es muy iluso pensar que con un manual vas a encontrar soluciones a todos los problemas. Los manuales siguen existiendo. Desgraciadamente no contienen todas las respuestas que cabría desear, pues solo describen las funcionalidades y algún ejemplo. Si fuera suficiente con ellos no haría falta buscar ayuda extra y SO directamente no existiría.
Supongo que criticas (como imagino que era el caso de #3) que ahora la gente pasa de pensar y va directamente a SO a copypastear la respuesta más votada. En eso estoy de acuerdo. A SO habría que ir "aprendido". Pero con los plazos tan ridículamente cortos que tenemos los programadores prefiero googlear las preguntas a ponerme a leer un manual de cientos de páginas. Y sin los plazos también, una vez sabes la base, es más ameno aprender por tu cuenta y hacer consultas puntuales que no pasar más tiempo atascado en tonterías que en el meollo del asunto por alguna suerte de purismo.
Perdón por el tocho, he escrito más de la cuenta pero también me apetecía matizar mi comentario #17 .
#29:
#28 Jajaja, hay gente que dice eso, sí. Pero las gráficas no solo son preguntas, también incluyen respuestas y votos positivos y negativos. Por lo tanto mide toda la actividad en torno a cada lenguaje, aunque sí es verdad que si se pregunta mucho habrá más respuestas que si no se preguntara nada.
#3 Antes de SO cuando tenías un problema con una tecnología tocaba rastrear la red por foros especializados y listas de correo infinitas hasta encontrar solución.
Pillo la cita de los Simpson pero SO más que causa es consecuencia de los problemas de código. Siempre los ha habido y los habrá, pero el bien que hace tener una comunidad dedicada a concentrar todos ellos es cuantificable en tiempo ahorrado.
#37 Y yo, pero es muy iluso pensar que con un manual vas a encontrar soluciones a todos los problemas. Los manuales siguen existiendo. Desgraciadamente no contienen todas las respuestas que cabría desear, pues solo describen las funcionalidades y algún ejemplo. Si fuera suficiente con ellos no haría falta buscar ayuda extra y SO directamente no existiría.
Supongo que criticas (como imagino que era el caso de #3) que ahora la gente pasa de pensar y va directamente a SO a copypastear la respuesta más votada. En eso estoy de acuerdo. A SO habría que ir "aprendido". Pero con los plazos tan ridículamente cortos que tenemos los programadores prefiero googlear las preguntas a ponerme a leer un manual de cientos de páginas. Y sin los plazos también, una vez sabes la base, es más ameno aprender por tu cuenta y hacer consultas puntuales que no pasar más tiempo atascado en tonterías que en el meollo del asunto por alguna suerte de purismo.
Perdón por el tocho, he escrito más de la cuenta pero también me apetecía matizar mi comentario #17 .
#40 En mi opinión es lo que hace que páginas como las de PHP tengan una documentación bien pensada (porque pueden hacerse comentarios con ejemplos y pueden votarse, que era lo más parecido a stackoverflow que había antes de la existencia de este). Imagino que era por pura necesidad, porque en sus inicios PHP era una absoluta mierda (ahora ha mejorado mucho) y sin eso no podría haberse adoptado.
Hay documentaciones por ahí que son para flipar de lo absolutamente inútiles que resultan (normalmente una descripción más o menos formal sin ejemplos y sin contexto). Es inaceptable que hoy día haya documentación en la que no se pueden poner comentarios para añadir "gotchas", notas, advertencias, funciones auxiliares, patrones, etc. por parte de los usuarios.
#37 Si tenemos que usar los manuales o la documentación de muchos proyectos por ahí que dan auténtica pena, lo llevamos claro.
Desde que se inventaron los documentadores automáticos, la documentación se ha convertido en una colección de comentarios de clases y métodos que no explican gran cosa y o bien tienes que acabar mirando el código o bien tienes que acabar haciéndote con un libro que lo explique.
Stack Overflow muchas veces rellena el hueco que ha creado la pésima documentación y las pésimas explicaciones.
#33 O simplemente que la gente que se dedica a otros lenguajes no está acostumbrada a que le den las cosas más absurdas hechas, mientras que los de javascript son unos vagos, como se demostró de forma empírica con el escándalo de npm y la función de 4 lineas de la que dependían un montón de proyectos.
Ni PHP ha llegado a niveles de tal vergüenza ajena.
#28 Jajaja, hay gente que dice eso, sí. Pero las gráficas no solo son preguntas, también incluyen respuestas y votos positivos y negativos. Por lo tanto mide toda la actividad en torno a cada lenguaje, aunque sí es verdad que si se pregunta mucho habrá más respuestas que si no se preguntara nada.
#28: O tal vez que la gente que empieza con Python lo deja por imposible y ni siquiera intenta preguntar.
A mi Python me ha dado problemas, no me resulta tan cómodo como JavaScript, y es que JS permite programar a gente que no es experta, mientras que Python requiere de más nivel y habilidad.
#33 ami python me parece una mierda.Un lenguaje desfragmentado y no tipado. Tiene su utilidad para pequeños scripts pero ami no me gusta demasiado.
de todas formas mi impresión sobre python va de la mano de los ides que probé de las librerías graficas y de mis problemas al tratar listas/diccionarios que al recoger datos nunca sabía en que formato me llegaban y iba a prueba y error. y la desfragmentacion tb es una mierda
#38 Eso es cuestión de costumbre. No de lenguaje.
Cuando estás acostumbrado al duck typing no tienes esos problemas; los tienes al cambiar a un lenguaje donde tienes que hacer casts para sumar dos números... cosa absurda donde las haya, por ejemplo.
Por cierto #33, #38, qué lenguaje recomendaríais para qué cosa?
Javascript es el único lenguaje verdaderamente multiplataforma actualmente. No hay otro lenguaje que pueda hacer lo siguiente:
Aplicaciones web, aplicaciones móviles, scripts de sistemas, aplicaciones de servidor, excepcional intercomunicación entre redes, uso de bases de datos, servicios REST...
Si yo quiero, por ejemplo, algo tan importante como una buena lista de expresiones regulares, en javascript la puedo escribir una vez y ejecutar en prácticamente todos los dispositivos.
Javascript ha hecho realidad lo que prometió Java.
#63 pues que tiene varias versiones incompatibles entre sí.
La causa de que me parezca una mierda es que saber en que formato me estaban volviendo las cosas x ejemplo de una consulta sql era a prueba y error. También es cierto que lo utilize hace años cuando estaba empezando y tal vez hoy no cometería ese error pero en Java nunca lo he cometido, asique algo habrá.
También me cuesta más montar estructuras orientadas a objetos pero esto es más unan
cuestión de aprendizaje no es una limitación del lenguaje. Pero me cuesta o costaba encontrar código python con estructura orientada a objetos.
Tampoco me gusta el tema de la tabulacion para mi dificulta la lectura(no el tabular, sino prescindir de otros simbolos)
> pues que tiene varias versiones incompatibles entre sí.
¿Y? Si es un proyecto "legacy", usas la versión 2.*, si no, pues la 3. Punto. Fin del problema.
Si tienes que migrar código... pues usas 2to3 o te mantienes en la versión 2.*, que tendrá soporte y actualizaciones unos cuantos años más.
> La causa de que me parezca una mierda es que saber
> en que formato me estaban volviendo las cosas x ejemplo
> de una consulta sql era a prueba y error.
#38 No entiendo lo de defragmentado, pero es fuertemente tipado, no "no tipado".
Edito: acabo de leer las respuestas, ni caso. Pongo un por las molestias.
#33 Pues fíjate, yo opino lo contrario, y conozco bien los dos lenguajes. Python es más ordenado, desde los mismos desarrolladores se anima a que se haga código elegante, fácil de leer, mantenible, etc. Se puede guarrear, pero ya solo el que te fuercen a indetar el código ayuda mucho.
Solo se ha tomado en serio a Javascript desde hace poco tiempo, antes era una especie de VisualBasic para la web. Desde mi punto de vista de desarrollador veterano (>15 años picando código), a JS lo que le hace falta ahora es que se estandarice un estilo, una forma de hacer las cosas y sobre todo, que la gente que programe JS lo haga con una cierta base.
#56 Precisamente, Angular, Ember, Metor... eso son frameworks o conjuntos de utilidades, yo hablo del lenguaje en sí mismo. Tu respuesta me reafirma en lo que pienso. Hablas a alguien de un lenguaje y te responde mencionando frameworks sobre ese lenguaje. Como hace unos años que la gente se te presentaba diciendo "se programar en jQuery"
#60 El lenguaje es tremendamente expresivo. Te pongo ejemplos de frameworks porque sí hay cosas programadas muy bien en javascript. No sólo eso, sino que usarlas lleva a seguir buenas prácticas de programación.
Javascript es, sobretodo, expresivo. Es su mayor fuerza...
#49: Pues yo prefiero JS, para mi es más fácil de leer porque lo tengo separado bien con llaves, corchetes y paréntesis. Yo al menos veo mejor la separación en JS que en Python.
En cuanto a la elegancia es cuestión de gustos, y la mantenibilidad depende de lo que escribas.
le hace falta ahora es que se estandarice un estilo
¿Y porqué hay que estandarizar nada? ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona? ¿Como la combinación "traje+corbata+cero joyas+pelo corto" que se imponía por la fuerza antes y aún se sigue intentando imponer?
Precísamente lo ideal es que uno siga su propio estilo, porque si te tienes que amoldar a estilos ajenos al final sólo podrá programar a quién le siente bien esas formas. Yo haré poco código y este será "cutre", pero al menos lo que hago está ahí y es más útil que si hubiera nada.
#83 Se ve que nos has trabajado en un proyecto de desarrollo con varias personas, si cada programador usara su propio estilo el código seria casi inmantenible. En un proyecto la mayor parte de tiempo estas haciendo cambios de código ya existente, si tienes que estar adaptandote a varios estilos tu rendimiento acaba cayendo en picado.
#86: Si hay un proyecto de varias personas (en los que los "casual developers" no solemos participar), se acordarán las normas de ese grupo entre ellos salvo que el proyecto esté liderado por alguien.
Es decir, si yo hago una aplicación y alguien me quiere ayudar, preferiría que siguiera mi estilo. Si con otra persona fundamos un proyecto, acordaríamos el estilo entre los dos antes. Y por supuesto, si programo yo solo sigo mi estilo sin preguntar ni pedir permiso a nadie.
En ningún caso hay por qué seguir algún "estilo oficial", como si hubiera algún estilo mejor que los demás.
#88 Aunque lo hagas tu solo o entre poca gente, no sabes si en un futuro se pueda unir más gente y siempre es más fácil que estos se adapten a un estilo estandar que no a tu estilo particular. En los proyectos de código abierto hay unos códigos de estilo y no suelen ser muy diferentes a los estandar por eso mismo.
#97 Yo empecé con Python hace menos de 2 años y la verdad es que, cada día que pasa, me enamora más!
Tiene muy buenas prácticas asociadas, cómo escribir el código correctamente y siguiendo unas directrices. Y tal como dice #94 no hay que tomárselo como un peñazo de "me están imponiendo algo", sino la ventaja de que si alguien retoma tu trabajo (o tú el de otra persona), vas a entender sin esfuerzo qué ha programado.
Espero que #83 lo entienda... Es más, creo que a todos nos ha pasado de volver a código escrito por nosotros mismos meses (ya no digo años) antes y preguntarte que qué coño es esa diarrea de letras sin orden ni concierto 😹 Siguiendo pautas de buena escritura te ahorras también avergonzarte de tu yo del pasado
#100: A mi me pasó lo de las variables nombradas con abreviaturas, pero eso no se soluciona de una forma única y impuesta para todos. Yo personalmente prefiero los guiones bajos (mi_variable_a) y no el estilo montaña rusa (MiVariableA), y de verdad, he "forkeado" un proyecto que estaba en Python con notación montaña rusa y al final voy a tener que cambiar el nombre de las variables para que pueda verlas mejor.
No es sólo gustos, es que cada persona tiene una visión diferente al resto, salvo que sean proyectos en grupo, no tiene sentido pretender que todos escribamos igual.
#83
> ¿Y porqué hay que estandarizar nada? ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona?
Cuando llegas a un proyecto de miles de línea de código, es muy bueno saber dónde estará cada cosa y saber que algo llamado NosequéController es eso, un controlador, que algo que está bajo models/ representará una entidad en la base de datos, etc.
También viene muy bien tener un código consistente, y no que cada uno use el lenguaje como le pete: aMiMeGustaCamelCase, pero_a_mi_guiones, IPreferUseEnglishAndLongVariableNames, min_style_is_preferido....
Unos ponen la llave al final, otros al principio de cada línea, unos tabulan con TAB, otros con 4 espacios...
Para tus proyectos personales, programa como te de la gana. Para trabajar con otros, esta aproximación de "mi propio estilo" no funciona en absoluto. Hay que acordar un estándar y usarlo sacrificando preferencias personales en bien de todos.
#90: Hay que acordar un estándar y usarlo sacrificando preferencias personales en bien de todos.
Pero se acuerda entre TODOS los participantes en el proyecto, no el deseo personal del programador de Python, que es lo que se dice aquí, que como Python te fuerza el estilo mola, sin darse cuenta de que a lo mejor no te gusta ese estilo.
#95 Python te fuerza a agrupar con espaciado consistente. Si quieres usar tabuladores, 4 espacios, 8 espacios o 20 espacios es cosa tuya... y de tu jefe de proyecto.
Desde Python.org aconsejan y evangelizan una serie de convenciones porque llevan programando con el lenguaje muuuuucho tiempo y saben de qué hablan, por eso conviene seguir las convenciones de un lenguaje. Las suelen establecer personas sabias y expertas, y no en base a ningún capricho, si no a la experiencia.
Otra cosa es que no te guste la sintaxis del lenguaje. A mi sí, y como llevo programando muchos años con muchos lenguajes y entornos, afirmo con conocimiento de causa que Python es uno de los lenguajes más legibles.
#97: Las suelen establecer personas sabias y expertas
Serán todo lo listillas sabias y expertas que sean, pero cada persona tiene unos ojos y un cerebro diferente a las demás, por ello no tiene sentido pretender que todos programemos igual cuando lo hacemos de forma individual, puesto que cada uno se amoldará a lo que le parezca mejor para su forma de ver.
Lo que para unos es disperso para otros puede resultar amontonado.
A mi es que esto me recuerda a cuando se les dice a los zurdos que usen siempre la mano derecha. Creerán que usan la izquierda por capricho.
> ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona? ¿Como la combinación "traje+corbata+cero joyas+pelo corto" que se imponía por la fuerza antes y aún se sigue intentando imponer?
> A mi es que esto me recuerda a cuando se les dice a los zurdos que usen siempre la mano derecha. Creerán que usan la izquierda por capricho.
Espero que no tenga que trabajar con un ser tan libre, sensible y especial como tú en ningún proyecto. Vamos, no jodas, ni que te estuviesen obligando a hacer un sobreesfuerzo cognitivo o cuestionando tus principios morales. Estamos hablando de convenciones, cosas como poner una llave en la misma línea de la declaración o en línea nueva, tabular con 8 o 4 espacios, usar nombres CamelCase o con_guiones,... vamos, tampoco veo tan difícil ni traumático adaptarse a eso, digo yo.
(Si tienes algún tipo de disfuncionalidad te pido disculpas, en ese caso sí que entiendo que tengas unas necesidades especiales).
#95 > Pero se acuerda entre TODOS los participantes en el proyecto, no el deseo personal del programador de Python
Llega nuevo a un proyecto y les dices a todos que tabulen a 8 espacios que a ti te agobia verlo todo tan apretado cuando se tabula a 4 espacios, que es la convención que siguen en ese proyecto/empresa/loquesea.
#64: Pues yo veo bastante mejor un lenguaje donde se separen los códigos con llaves y no con espacios. Se deja muy claro dónde empieza y termina cada bloque.
#82 Llevo 15 años programando con todo tipo de lenguajes, y, con diferencia, tras una breve adaptación inicial, el más legible es Python.
Siempre hay algún gracioso que se hace el original con las llaves, espaciados, etc... con Python la claridad de escritura es obligatoria. Se pueden escribir burradas, por supuesto, pero son burradas más claras.
(One-liners originales/ofuscados escritos en Python debajo de la raya )
------------------------------------
#9 Y ya no solo con aplicaciones web. En aplicaciones de escritorio también se está utilizando HTML+JS+CSS en vez de TK/QT. Juntando eso con la aparición de NodeJS... ya no hay quien le siga!
#23 No he dicho lo contrario Simplemente digo que en muchas aplicaciones se está optando por HTML, CSS y JS, aunque luego haya de todo (QT, TK y otros que ni conoceré).
#35 comparado con C.
Node con express, comparado con Python con Django o Java con Struts no es lento.
Se podrían hacer benchmarks... pero dependerían del benchmark. Uno basado en expresiones regulares, por ejemplo, vapulearía a Java... uno con orms vapulearía a node (npi de esto último...)
Javascript es el lenguaje del presente, un lenguaje tremendamente hermoso y, francamente, más difícil de programar que otros.
Esto parece el Barrapunto de hace unos años. Qué manía de mezclar churras con merinas.
Poner Node/JS al lado de C es incorrecto e inapropiado por dos razones:
a) Node es un intérprete de un lenguaje, JS. C es un lenguaje que se traduce a código nativo. Son dos cosas totalmente diferentes y no comparables.
b) Un camión es más lento que un fórmula uno. ¿Qué sentido tiene comparar JS/Node con C, cuando su ámbito de aplicación es totalmente diferente? Nadie programaría un controlador en JS/Node y nadie programaría una API REST con C, al igual que nadie haría el reparto de mercancía en un fórmula uno o iría a un circuito con un camión de reparto.
#47 Estoy de acuerdo contigo. Lo decía precisamente por lo que tú comentas. Javascript no es lento, es lento comparado con C, pero se usan para cosas completamente distintas.
No hay que comparar javascript con C, hay que comparar los usos del lenguaje.
#21#11 Tk es residual, aunque sigue siendo el toolkit de referencia en muchos proyectos (ej: gitk).
Qt en desktop se usa muchísimo: KDE, clientes de escritorio de todo tipo (se me viene Skype a la cabeza, VirtualBox,...)
El día que se implante definitivamente en el desktop el paradigma HTML+JS+CSS, vuelvo a la terminal para siempre, no me jodas. Hay buenas ideas por ahí, como en GTK estilar los constroles con una especie de CSS, o poder poner widgets HTML en el escritorio, o "scriptear" el escritorio con JS, pero de ahí a que el escritorio en sí sea HTML+JS+CSS... que mis ojos no lo vean, por favor.
#50 ¿En qué sentido le dan mil vueltas, como afirmas? ¿Puedes ser más específico? En eficiencia, lo dudo, desde que el mismo "intérprete" de html/css/js es un componente basado en el toolkit nativo (webkit-gkt/webkit-qt, etc), ya estás metiendo una capa entre medias, y podrías estar "pintando" contenido directamente en el toolkit nativo en vez de en un canvas html.
#53 Da mil vueltas en que puedes hacer una interfaz razonablemente atractiva muchísimo más rápido y que te va a funcionar en todos lados.
En eso da mil vueltas.
En eso y en algo mucho más importante aún: hay un estándar.
#55 Ah, claro, los componentes/toolkits nativos no pueden ser atractivos ni son cross-platform. Entiendo. En realidad, ¿para qué queremos un desktop?. Que toda nuestra pantalla sea un canvas webkit y ya. Sería el ideal según lo que propones
¿Afirmas que se puede desarrollar muchísimo más rápido una "interfaz atractiva" (define 'interfaz atractiva') en HTML/CSS/JS que funcione en todos los entornos/resoluciones antes que con un toolkit multiplataforma (QT, WX,...)? Es una generalización tan burda que me asusta. Si estás haciendo un cliente de Twitter, todavía, pero vamos, a poco que tengas que interaccionar con el SO... me suena a que estás diciendo una barbaridad.
#58 Cada cosa en su sitio. Tú decías que no querías ver html/css en el escritorio y yo te digo por qué es mejor para hacer interfaces. Si tú quieres una barra de menú en una aplicación, y quieres esa barra portable a 1000 sitios, es mucho más práctico usar HTML/CSS. Si quieres una interfaz para mover mayas 3D en tiempo real no. Es obvio.
Si quieres interacción con el SO separas en capas... el menú, los iconos, los colores, etc perfectamente puede ser html/css sin problemas... el motor de colisiones hazlo en C++.
En realidad la herramienta depende del uso. Se programan muy pocas aplicaciones 3D y se programan muchísimos clientes de twitter. Es obvio lo que debes usar en cada ocasión, no?
#65 Perfecto, pero no me pongas un componente webkit-gtk, por ejemplo, a interpretar CSS para pintar las transparencias, que el toolkit directamente sea estilable por CSS (como ya se hace).
Cualquier toolkit decente hoy en día permite definir componentes en base a un layout y el motor ya pinta el componente, no se necesita HTML para eso.
Lo siento, no veo el HTML haciendo desktop. Como parte de componentes, sí, pero como base del escritorio no. Ni por rendimiento ni por tiempo de desarrollo.
#68 Lo de "permite" es un decir. Yo diría más bien "admite" y lo documenta fatal. Crear interfaces en la mayoría de toolkits es un dolor, y cuando las cambias de SO petan o aparecen descolocadas.
Tienes razón en lo que dices sobre los componentes... "Como parte de componentes sí"... sin embargo, la interfaz está hecha de componentes!
Crear interfaces en HTML/CSS no es tanto dolor, y cuando las cambias siguen funcionando.
#70 Quizás esté anticuado, no sé. Sigo viendo lagunas en este modelo. Si usas un MVC en un escritorio HTML... ¿quién es el controllador que va modificando el estado del HTML? ¿Un Apache o servidor web embebido? ¿O tiras de HTMLs predefinidos y vas pasando de uno a otro?
Me encantaría ver algún programa o proyecto hecho así (y que no sea FirefoxOS).
#46 Bueno, ya se verá en qué queda la tendencia. Igual el año que viene alguien idea u̶n̶ otro sistema revolucionario y ya no se usa HTML+CSS+JS. Sin embargo, siendo la deriva con todo web o como si fuera web...
#9#5 No es que sea imbatible como leguage más utilizado. Ojo a la metodología: "basado en la actividad (preguntas, respuestas, etiquetas y votos) de StackOverflow hasta febrero de 2016".
Es más bien una clasificación de los lenguages que más problemas provocan.
#74 Lo sé, pero si fuera solo respuestas puedo entender que sea porque no da más que problemas. Al estar involucradas también las respuestas y los votos, significa que hay gente que se toma la molestia de contestar y demás. Es decir, que hay contribución activa, la gente se interesa e intenta aprender (y aporrea el teclado en StackOverflow, sí ). En definitiva, que hay movimiento. Y ahora JavaScript está en todos lados: cliente, servidor, IoT... El día menos pensado mi tostadora corre NodeJS
#45 El que hayas tenido que aclarar eso muestra la experiencia real que tiene mucha gente que habla y habla sin saber de qué.
Todavía hay gente con los huevos pelados que confunde tipado dinámico y estático con implícito y explícito y como no lo saben demuestran su ignorancia sin pudor en los foros una y otra vez.
Hoy día sólo los inútiles se centran en un lenguaje y en un paradigma. Teniendo en cuenta que hablamos de lenguajes formales, quien se queja normalmente es porque en realidad no entiende lo que está haciendo y llora porque en cuanto le cambian la sintaxis o la semántica se pierde.
#10 O porque tienen muchos neófitos, o porque son lenguajes que son muy útiles pero sólo se tocan puntualmente (caso de muchos lenguajes de scripting en los que se hacen puntualmente pequeños programas para necesidades concretas, mantenimiento, etc.).
Al menos esa es mi experiencia. Nadie se va hacer un experto en algo que va a emplear únicamente un par de días, así que tira de stack overflow cuando surgen dudas para no perder tiempo que muy probablemente necesites.
Dicho esto, no creo que sea el caso de Javascript. Más bien de que la gente no entiende de qué va (dinámico, funcional y con prototipos) y piensa que tiene algo que ver con C o Java porque la sintaxis es similar.
#2 en realidad es cuanto aumenta la actividad en stack overflow por lenguaje, así que Javascript es el lenguaje que da más problemas y con el que nadie sabe que falla porque no debugga
#2 Si en el 2000 un viajero del tiempo me hubiese dicho que 16 años más tarde el lenguaje dominante sería JavaScript, no sé si habría estudiado informática.
De hecho, probablemente me habría ido a la casa de los abuelos en la aldea. Cultivaría la tierra y acumularía armas, munición y suministros.
stackoverpwned: ¿Por qué no ponen el cero justo en la base del gráfico? Confundiría menos en la visualización de los datos que dejando un pequeño margen para valores negativos que no se van a dar.
Siendo StackOverflow una web para solucionar problemas... claramente los lenguajes que más problemas dan son JavaScript, Java, Python, C#... y los que menos problemas dan son Perl, Ensamblador, Rust y Julia
#39 La gente de perl y asm no pregunta. Con cpan tienes todo y son veteranos. en asm pues obviamente necesitas saber la CPU y SO así q preguntar es inutil, te buscas la vida con saber usar ensamblador.
Voy a dejar este hilo de comentarios porque me estoy poniendo de mala leche. Si este es el nivel que tenemos... no me extraña que nos vaya como nos va. La de sandeces que he leído en un rato.
Lo de javascript tambien esta un poco inflado. Muchos problemas son 'javascript', pero engloban configuraciones de librerias y demas usos en los que javascript solo es tangencial. Yo mismo por ejemplo he estado preguntando dudas de una libreria para generar graficas, que esta hecha en javascript, y he utilizado ese tag. Pero la pregunta era sobre la configuracion de dicha libreria. Ni yo ni mi proyecto usamos una linea de javascript escrita por nosotros (@Deity nos libre)
Va siendo hora de que los navegadores sean compatibles con algún otro lenguaje que refuerce las debilidades de javasctript. Apple lo ha hecho con swift en ios. el wc3 o quien sea que gobierne javascript podría sacar algo adecuado a los tiempos que corren. Javascript ya no se usa para lo que se inventó, añadir algo de interactividad a tu paginilla. Ahora es el alma de muchas librerías de miles de líneas de código que son muy difíciles de mantener.
Comentarios
Esencial
#8 libro de referencia en muchas empresas de software
#8 Lección 1: https://github.com/azac/sublime-howdoi-direct-paste
#8 y que no falte el complemento:
Ayy StackOverflow, el yahoo respuestas de los programadores.
Por StackOverflow 🍺 , causa, y a la vez, solución de todos los problemas de código.
#3 Antes de SO cuando tenías un problema con una tecnología tocaba rastrear la red por foros especializados y listas de correo infinitas hasta encontrar solución.
Pillo la cita de los Simpson pero SO más que causa es consecuencia de los problemas de código. Siempre los ha habido y los habrá, pero el bien que hace tener una comunidad dedicada a concentrar todos ellos es cuantificable en tiempo ahorrado.
#17 Pues yo miraba en el manual.
#37 Y yo, pero es muy iluso pensar que con un manual vas a encontrar soluciones a todos los problemas. Los manuales siguen existiendo. Desgraciadamente no contienen todas las respuestas que cabría desear, pues solo describen las funcionalidades y algún ejemplo. Si fuera suficiente con ellos no haría falta buscar ayuda extra y SO directamente no existiría.
Supongo que criticas (como imagino que era el caso de #3) que ahora la gente pasa de pensar y va directamente a SO a copypastear la respuesta más votada. En eso estoy de acuerdo. A SO habría que ir "aprendido". Pero con los plazos tan ridículamente cortos que tenemos los programadores prefiero googlear las preguntas a ponerme a leer un manual de cientos de páginas. Y sin los plazos también, una vez sabes la base, es más ameno aprender por tu cuenta y hacer consultas puntuales que no pasar más tiempo atascado en tonterías que en el meollo del asunto por alguna suerte de purismo.
Perdón por el tocho, he escrito más de la cuenta pero también me apetecía matizar mi comentario #17 .
#40 En mi opinión es lo que hace que páginas como las de PHP tengan una documentación bien pensada (porque pueden hacerse comentarios con ejemplos y pueden votarse, que era lo más parecido a stackoverflow que había antes de la existencia de este). Imagino que era por pura necesidad, porque en sus inicios PHP era una absoluta mierda (ahora ha mejorado mucho) y sin eso no podría haberse adoptado.
Hay documentaciones por ahí que son para flipar de lo absolutamente inútiles que resultan (normalmente una descripción más o menos formal sin ejemplos y sin contexto). Es inaceptable que hoy día haya documentación en la que no se pueden poner comentarios para añadir "gotchas", notas, advertencias, funciones auxiliares, patrones, etc. por parte de los usuarios.
#37 Si tenemos que usar los manuales o la documentación de muchos proyectos por ahí que dan auténtica pena, lo llevamos claro.
Desde que se inventaron los documentadores automáticos, la documentación se ha convertido en una colección de comentarios de clases y métodos que no explican gran cosa y o bien tienes que acabar mirando el código o bien tienes que acabar haciéndote con un libro que lo explique.
Stack Overflow muchas veces rellena el hueco que ha creado la pésima documentación y las pésimas explicaciones.
#33 O simplemente que la gente que se dedica a otros lenguajes no está acostumbrada a que le den las cosas más absurdas hechas, mientras que los de javascript son unos vagos, como se demostró de forma empírica con el escándalo de npm y la función de 4 lineas de la que dependían un montón de proyectos.
Ni PHP ha llegado a niveles de tal vergüenza ajena.
#36 Y mira que PHP da vergüencita, lo digo con conocimiento de causa
#61 Menos mal que no estás comentándolo en una web realizada en ese lenguaje.
#36: Si, pero para el "programador casual" yo veo mejor JS que Python.
#5 Más que imbatible es que es tan inusable que hay que pasarse todo el día haciendo preguntas en stackoverflow para conseguir hacerlo funcionar.
#28 Jajaja, hay gente que dice eso, sí. Pero las gráficas no solo son preguntas, también incluyen respuestas y votos positivos y negativos. Por lo tanto mide toda la actividad en torno a cada lenguaje, aunque sí es verdad que si se pregunta mucho habrá más respuestas que si no se preguntara nada.
#28: O tal vez que la gente que empieza con Python lo deja por imposible y ni siquiera intenta preguntar.
A mi Python me ha dado problemas, no me resulta tan cómodo como JavaScript, y es que JS permite programar a gente que no es experta, mientras que Python requiere de más nivel y habilidad.
#33 ami python me parece una mierda.Un lenguaje desfragmentado y no tipado. Tiene su utilidad para pequeños scripts pero ami no me gusta demasiado.
de todas formas mi impresión sobre python va de la mano de los ides que probé de las librerías graficas y de mis problemas al tratar listas/diccionarios que al recoger datos nunca sabía en que formato me llegaban y iba a prueba y error. y la desfragmentacion tb es una mierda
#38 Eso es cuestión de costumbre. No de lenguaje.
Cuando estás acostumbrado al duck typing no tienes esos problemas; los tienes al cambiar a un lenguaje donde tienes que hacer casts para sumar dos números... cosa absurda donde las haya, por ejemplo.
Por cierto #33, #38, qué lenguaje recomendaríais para qué cosa?
Javascript es el único lenguaje verdaderamente multiplataforma actualmente. No hay otro lenguaje que pueda hacer lo siguiente:
Aplicaciones web, aplicaciones móviles, scripts de sistemas, aplicaciones de servidor, excepcional intercomunicación entre redes, uso de bases de datos, servicios REST...
Si yo quiero, por ejemplo, algo tan importante como una buena lista de expresiones regulares, en javascript la puedo escribir una vez y ejecutar en prácticamente todos los dispositivos.
Javascript ha hecho realidad lo que prometió Java.
#44: Y hasta puedes programar un Arduino con node.js, si bien no conozco el rendimiento o la estabilidad.
http://node-ardx.org/
Yo al menos creo que JS tendrá fallos, pero es muy versátil.
#38 Otro con lo del "no tipado". Qué atrevida es la ignorancia. ¿Desfragmentado? ¿Python desfragmentado? Pero, ¿qué entiendes tú por desfragmentación?
> de todas formas mi impresión sobre python va de la mano
> de los ides que probé de las librerías graficas
Es una amplia experiencia la tuya, está claro que te habilita para valorar un lenguaje y emitir el juicio "es una mierda".
> mis problemas al tratar listas/diccionarios que al recoger datos
> nunca sabía en que formato me llegaban y iba a prueba y error
Ah, claro, la causa de tus problemas con las estructuras de datos que manejas es el lenguaje. Bien.
#63 pues que tiene varias versiones incompatibles entre sí.
La causa de que me parezca una mierda es que saber en que formato me estaban volviendo las cosas x ejemplo de una consulta sql era a prueba y error. También es cierto que lo utilize hace años cuando estaba empezando y tal vez hoy no cometería ese error pero en Java nunca lo he cometido, asique algo habrá.
También me cuesta más montar estructuras orientadas a objetos pero esto es más unan
cuestión de aprendizaje no es una limitación del lenguaje. Pero me cuesta o costaba encontrar código python con estructura orientada a objetos.
Tampoco me gusta el tema de la tabulacion para mi dificulta la lectura(no el tabular, sino prescindir de otros simbolos)
#96
> pues que tiene varias versiones incompatibles entre sí.
¿Y? Si es un proyecto "legacy", usas la versión 2.*, si no, pues la 3. Punto. Fin del problema.
Si tienes que migrar código... pues usas 2to3 o te mantienes en la versión 2.*, que tendrá soporte y actualizaciones unos cuantos años más.
> La causa de que me parezca una mierda es que saber
> en que formato me estaban volviendo las cosas x ejemplo
> de una consulta sql era a prueba y error.
Está perfectamente documentado en la API para bases de datos:
https://www.python.org/dev/peps/pep-0249/#type-objects-and-constructors
#38 No entiendo lo de defragmentado, pero es fuertemente tipado, no "no tipado".
Edito: acabo de leer las respuestas, ni caso. Pongo un por las molestias.
#33 Pues fíjate, yo opino lo contrario, y conozco bien los dos lenguajes. Python es más ordenado, desde los mismos desarrolladores se anima a que se haga código elegante, fácil de leer, mantenible, etc. Se puede guarrear, pero ya solo el que te fuercen a indetar el código ayuda mucho.
Solo se ha tomado en serio a Javascript desde hace poco tiempo, antes era una especie de VisualBasic para la web. Desde mi punto de vista de desarrollador veterano (>15 años picando código), a JS lo que le hace falta ahora es que se estandarice un estilo, una forma de hacer las cosas y sobre todo, que la gente que programe JS lo haga con una cierta base.
#49 Angular, Ember, Meteor...
#56 Precisamente, Angular, Ember, Metor... eso son frameworks o conjuntos de utilidades, yo hablo del lenguaje en sí mismo. Tu respuesta me reafirma en lo que pienso. Hablas a alguien de un lenguaje y te responde mencionando frameworks sobre ese lenguaje. Como hace unos años que la gente se te presentaba diciendo "se programar en jQuery"
#60 El lenguaje es tremendamente expresivo. Te pongo ejemplos de frameworks porque sí hay cosas programadas muy bien en javascript. No sólo eso, sino que usarlas lleva a seguir buenas prácticas de programación.
Javascript es, sobretodo, expresivo. Es su mayor fuerza...
#49: Pues yo prefiero JS, para mi es más fácil de leer porque lo tengo separado bien con llaves, corchetes y paréntesis. Yo al menos veo mejor la separación en JS que en Python.
En cuanto a la elegancia es cuestión de gustos, y la mantenibilidad depende de lo que escribas.
le hace falta ahora es que se estandarice un estilo
¿Y porqué hay que estandarizar nada? ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona? ¿Como la combinación "traje+corbata+cero joyas+pelo corto" que se imponía por la fuerza antes y aún se sigue intentando imponer?
Precísamente lo ideal es que uno siga su propio estilo, porque si te tienes que amoldar a estilos ajenos al final sólo podrá programar a quién le siente bien esas formas. Yo haré poco código y este será "cutre", pero al menos lo que hago está ahí y es más útil que si hubiera nada.
#83 Se ve que nos has trabajado en un proyecto de desarrollo con varias personas, si cada programador usara su propio estilo el código seria casi inmantenible. En un proyecto la mayor parte de tiempo estas haciendo cambios de código ya existente, si tienes que estar adaptandote a varios estilos tu rendimiento acaba cayendo en picado.
#86: Si hay un proyecto de varias personas (en los que los "casual developers" no solemos participar), se acordarán las normas de ese grupo entre ellos salvo que el proyecto esté liderado por alguien.
Es decir, si yo hago una aplicación y alguien me quiere ayudar, preferiría que siguiera mi estilo. Si con otra persona fundamos un proyecto, acordaríamos el estilo entre los dos antes. Y por supuesto, si programo yo solo sigo mi estilo sin preguntar ni pedir permiso a nadie.
En ningún caso hay por qué seguir algún "estilo oficial", como si hubiera algún estilo mejor que los demás.
#88 Aunque lo hagas tu solo o entre poca gente, no sabes si en un futuro se pueda unir más gente y siempre es más fácil que estos se adapten a un estilo estandar que no a tu estilo particular. En los proyectos de código abierto hay unos códigos de estilo y no suelen ser muy diferentes a los estandar por eso mismo.
#94: Al que no le guste mi código que no se junte, que no es obligatorio.
Si para programar yo tengo que programar al gusto de otros, no programo y listo, que programen ellos.
#97 Yo empecé con Python hace menos de 2 años y la verdad es que, cada día que pasa, me enamora más!
Tiene muy buenas prácticas asociadas, cómo escribir el código correctamente y siguiendo unas directrices. Y tal como dice #94 no hay que tomárselo como un peñazo de "me están imponiendo algo", sino la ventaja de que si alguien retoma tu trabajo (o tú el de otra persona), vas a entender sin esfuerzo qué ha programado.
Espero que #83 lo entienda... Es más, creo que a todos nos ha pasado de volver a código escrito por nosotros mismos meses (ya no digo años) antes y preguntarte que qué coño es esa diarrea de letras sin orden ni concierto 😹 Siguiendo pautas de buena escritura te ahorras también avergonzarte de tu yo del pasado
#100: A mi me pasó lo de las variables nombradas con abreviaturas, pero eso no se soluciona de una forma única y impuesta para todos. Yo personalmente prefiero los guiones bajos (mi_variable_a) y no el estilo montaña rusa (MiVariableA), y de verdad, he "forkeado" un proyecto que estaba en Python con notación montaña rusa y al final voy a tener que cambiar el nombre de las variables para que pueda verlas mejor.
No es sólo gustos, es que cada persona tiene una visión diferente al resto, salvo que sean proyectos en grupo, no tiene sentido pretender que todos escribamos igual.
#83
> ¿Y porqué hay que estandarizar nada? ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona?
Cuando llegas a un proyecto de miles de línea de código, es muy bueno saber dónde estará cada cosa y saber que algo llamado NosequéController es eso, un controlador, que algo que está bajo models/ representará una entidad en la base de datos, etc.
También viene muy bien tener un código consistente, y no que cada uno use el lenguaje como le pete: aMiMeGustaCamelCase, pero_a_mi_guiones, IPreferUseEnglishAndLongVariableNames, min_style_is_preferido....
Unos ponen la llave al final, otros al principio de cada línea, unos tabulan con TAB, otros con 4 espacios...
Para tus proyectos personales, programa como te de la gana. Para trabajar con otros, esta aproximación de "mi propio estilo" no funciona en absoluto. Hay que acordar un estándar y usarlo sacrificando preferencias personales en bien de todos.
#90: Hay que acordar un estándar y usarlo sacrificando preferencias personales en bien de todos.
Pero se acuerda entre TODOS los participantes en el proyecto, no el deseo personal del programador de Python, que es lo que se dice aquí, que como Python te fuerza el estilo mola, sin darse cuenta de que a lo mejor no te gusta ese estilo.
#95 Python te fuerza a agrupar con espaciado consistente. Si quieres usar tabuladores, 4 espacios, 8 espacios o 20 espacios es cosa tuya... y de tu jefe de proyecto.
Desde Python.org aconsejan y evangelizan una serie de convenciones porque llevan programando con el lenguaje muuuuucho tiempo y saben de qué hablan, por eso conviene seguir las convenciones de un lenguaje. Las suelen establecer personas sabias y expertas, y no en base a ningún capricho, si no a la experiencia.
Otra cosa es que no te guste la sintaxis del lenguaje. A mi sí, y como llevo programando muchos años con muchos lenguajes y entornos, afirmo con conocimiento de causa que Python es uno de los lenguajes más legibles.
#97: Las suelen establecer personas sabias y expertas
Serán todo lo
listillassabias y expertas que sean, pero cada persona tiene unos ojos y un cerebro diferente a las demás, por ello no tiene sentido pretender que todos programemos igual cuando lo hacemos de forma individual, puesto que cada uno se amoldará a lo que le parezca mejor para su forma de ver.Lo que para unos es disperso para otros puede resultar amontonado.
A mi es que esto me recuerda a cuando se les dice a los zurdos que usen siempre la mano derecha. Creerán que usan la izquierda por capricho.
#99 Ya van dos meadas fuera de tiesto:
> ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona? ¿Como la combinación "traje+corbata+cero joyas+pelo corto" que se imponía por la fuerza antes y aún se sigue intentando imponer?
> A mi es que esto me recuerda a cuando se les dice a los zurdos que usen siempre la mano derecha. Creerán que usan la izquierda por capricho.
Espero que no tenga que trabajar con un ser tan libre, sensible y especial como tú en ningún proyecto. Vamos, no jodas, ni que te estuviesen obligando a hacer un sobreesfuerzo cognitivo o cuestionando tus principios morales. Estamos hablando de convenciones, cosas como poner una llave en la misma línea de la declaración o en línea nueva, tabular con 8 o 4 espacios, usar nombres CamelCase o con_guiones,... vamos, tampoco veo tan difícil ni traumático adaptarse a eso, digo yo.
(Si tienes algún tipo de disfuncionalidad te pido disculpas, en ese caso sí que entiendo que tengas unas necesidades especiales).
#95 > Pero se acuerda entre TODOS los participantes en el proyecto, no el deseo personal del programador de Python
Llega nuevo a un proyecto y les dices a todos que tabulen a 8 espacios que a ti te agobia verlo todo tan apretado cuando se tabula a 4 espacios, que es la convención que siguen en ese proyecto/empresa/loquesea.
#33
> [...] JS permite programar a gente que no es experta,
> mientras que Python requiere de más nivel y habilidad [...]
Quizás es por eso que se utiliza Python mucho en el entorno educativo (va sustituyendo a Pascal)...
#64: Pues yo veo bastante mejor un lenguaje donde se separen los códigos con llaves y no con espacios. Se deja muy claro dónde empieza y termina cada bloque.
#82 Llevo 15 años programando con todo tipo de lenguajes, y, con diferencia, tras una breve adaptación inicial, el más legible es Python.
Siempre hay algún gracioso que se hace el original con las llaves, espaciados, etc... con Python la claridad de escritura es obligatoria. Se pueden escribir burradas, por supuesto, pero son burradas más claras.
(One-liners originales/ofuscados escritos en Python debajo de la raya )
------------------------------------
JavaScript rulez!
#2 Malditos lenguajes no tipados!!
#4 #2 JavaScript imbatible, por mucho que nos pese a algunos
#5 No es que sea imbatible, pero con tanta aplicación web pues claro que sube
#9 Y ya no solo con aplicaciones web. En aplicaciones de escritorio también se está utilizando HTML+JS+CSS en vez de TK/QT. Juntando eso con la aparición de NodeJS... ya no hay quien le siga!
#11 "TK/QT"
¿De qué año vienes?
Por cierto, para RAD PyQT o bien FreePascal/Lazarus.
NodeJS es un cáncer más lento que yo que sé.
#21 En Linux todavía veo interfaces gráficas hechas con TK o QT
Lo de Node ya hay gente padeciendo consecuencias, y otros encantados con él. Ya veremos en qué acaba
#22 qt es moderno.
#23 No he dicho lo contrario Simplemente digo que en muchas aplicaciones se está optando por HTML, CSS y JS, aunque luego haya de todo (QT, TK y otros que ni conoceré).
#21 lento en que y comparado con que?
#35 comparado con C.
Node con express, comparado con Python con Django o Java con Struts no es lento.
Se podrían hacer benchmarks... pero dependerían del benchmark. Uno basado en expresiones regulares, por ejemplo, vapulearía a Java... uno con orms vapulearía a node (npi de esto último...)
Javascript es el lenguaje del presente, un lenguaje tremendamente hermoso y, francamente, más difícil de programar que otros.
#43 #35 #21
Esto parece el Barrapunto de hace unos años. Qué manía de mezclar churras con merinas.
Poner Node/JS al lado de C es incorrecto e inapropiado por dos razones:
a) Node es un intérprete de un lenguaje, JS. C es un lenguaje que se traduce a código nativo. Son dos cosas totalmente diferentes y no comparables.
b) Un camión es más lento que un fórmula uno. ¿Qué sentido tiene comparar JS/Node con C, cuando su ámbito de aplicación es totalmente diferente? Nadie programaría un controlador en JS/Node y nadie programaría una API REST con C, al igual que nadie haría el reparto de mercancía en un fórmula uno o iría a un circuito con un camión de reparto.
#47 Estoy de acuerdo contigo. Lo decía precisamente por lo que tú comentas. Javascript no es lento, es lento comparado con C, pero se usan para cosas completamente distintas.
No hay que comparar javascript con C, hay que comparar los usos del lenguaje.
#43 ”Javascript es el lenguaje del presente, un lenguaje tremendamente hermoso y, francamente, más difícil de programar que otros”.
No veo nada en esa frase que sea cierto.
Es popular porque hasta un mono puede programar chorradillas con él. Y estéticamente es una versión de juguete de C.
#21 #11 Tk es residual, aunque sigue siendo el toolkit de referencia en muchos proyectos (ej: gitk).
Qt en desktop se usa muchísimo: KDE, clientes de escritorio de todo tipo (se me viene Skype a la cabeza, VirtualBox,...)
El día que se implante definitivamente en el desktop el paradigma HTML+JS+CSS, vuelvo a la terminal para siempre, no me jodas. Hay buenas ideas por ahí, como en GTK estilar los constroles con una especie de CSS, o poder poner widgets HTML en el escritorio, o "scriptear" el escritorio con JS, pero de ahí a que el escritorio en sí sea HTML+JS+CSS... que mis ojos no lo vean, por favor.
#46 y cuál es el problema? He trabajado con los siguientes toolkits alguna vez:
WXwidgets, tk y GTK.
HTML+CSS da mil vueltas a esos toolkits, 1000 vueltas.
Si me hablas de "eficiencia" te recuerdo que tienes quadcores en los teléfonos...
Ni me quiero imaginar el infierno de programar comentarios enlazados con alguna de esas herramientas...
#50 ¿En qué sentido le dan mil vueltas, como afirmas? ¿Puedes ser más específico? En eficiencia, lo dudo, desde que el mismo "intérprete" de html/css/js es un componente basado en el toolkit nativo (webkit-gkt/webkit-qt, etc), ya estás metiendo una capa entre medias, y podrías estar "pintando" contenido directamente en el toolkit nativo en vez de en un canvas html.
#53 Da mil vueltas en que puedes hacer una interfaz razonablemente atractiva muchísimo más rápido y que te va a funcionar en todos lados.
En eso da mil vueltas.
En eso y en algo mucho más importante aún: hay un estándar.
#55 Ah, claro, los componentes/toolkits nativos no pueden ser atractivos ni son cross-platform. Entiendo. En realidad, ¿para qué queremos un desktop?. Que toda nuestra pantalla sea un canvas webkit y ya. Sería el ideal según lo que propones
¿Afirmas que se puede desarrollar muchísimo más rápido una "interfaz atractiva" (define 'interfaz atractiva') en HTML/CSS/JS que funcione en todos los entornos/resoluciones antes que con un toolkit multiplataforma (QT, WX,...)? Es una generalización tan burda que me asusta. Si estás haciendo un cliente de Twitter, todavía, pero vamos, a poco que tengas que interaccionar con el SO... me suena a que estás diciendo una barbaridad.
#58 Cada cosa en su sitio. Tú decías que no querías ver html/css en el escritorio y yo te digo por qué es mejor para hacer interfaces. Si tú quieres una barra de menú en una aplicación, y quieres esa barra portable a 1000 sitios, es mucho más práctico usar HTML/CSS. Si quieres una interfaz para mover mayas 3D en tiempo real no. Es obvio.
Si quieres interacción con el SO separas en capas... el menú, los iconos, los colores, etc perfectamente puede ser html/css sin problemas... el motor de colisiones hazlo en C++.
En realidad la herramienta depende del uso. Se programan muy pocas aplicaciones 3D y se programan muchísimos clientes de twitter. Es obvio lo que debes usar en cada ocasión, no?
#65 Perfecto, pero no me pongas un componente webkit-gtk, por ejemplo, a interpretar CSS para pintar las transparencias, que el toolkit directamente sea estilable por CSS (como ya se hace).
Cualquier toolkit decente hoy en día permite definir componentes en base a un layout y el motor ya pinta el componente, no se necesita HTML para eso.
Lo siento, no veo el HTML haciendo desktop. Como parte de componentes, sí, pero como base del escritorio no. Ni por rendimiento ni por tiempo de desarrollo.
#68 Lo de "permite" es un decir. Yo diría más bien "admite" y lo documenta fatal. Crear interfaces en la mayoría de toolkits es un dolor, y cuando las cambias de SO petan o aparecen descolocadas.
Tienes razón en lo que dices sobre los componentes... "Como parte de componentes sí"... sin embargo, la interfaz está hecha de componentes!
Crear interfaces en HTML/CSS no es tanto dolor, y cuando las cambias siguen funcionando.
#70 Quizás esté anticuado, no sé. Sigo viendo lagunas en este modelo. Si usas un MVC en un escritorio HTML... ¿quién es el controllador que va modificando el estado del HTML? ¿Un Apache o servidor web embebido? ¿O tiras de HTMLs predefinidos y vas pasando de uno a otro?
Me encantaría ver algún programa o proyecto hecho así (y que no sea FirefoxOS).
#78 el controlador es....... javascript!
Lo que comentas es lo que ofrece angular.
Respecto a programa, estaba bastante bien hecho popcorn time.
#65 No sabía que se podían mover mayas 3D en tiempo real. ¿Con los incas o los aztecas también se puede?
#46 Bueno, ya se verá en qué queda la tendencia. Igual el año que viene alguien idea u̶n̶ otro sistema revolucionario y ya no se usa HTML+CSS+JS. Sin embargo, siendo la deriva con todo web o como si fuera web...
#9 #5 No es que sea imbatible como leguage más utilizado. Ojo a la metodología: "basado en la actividad (preguntas, respuestas, etiquetas y votos) de StackOverflow hasta febrero de 2016".
Es más bien una clasificación de los lenguages que más problemas provocan.
#74 Lo sé, pero si fuera solo respuestas puedo entender que sea porque no da más que problemas. Al estar involucradas también las respuestas y los votos, significa que hay gente que se toma la molestia de contestar y demás. Es decir, que hay contribución activa, la gente se interesa e intenta aprender (y aporrea el teclado en StackOverflow, sí ). En definitiva, que hay movimiento. Y ahora JavaScript está en todos lados: cliente, servidor, IoT... El día menos pensado mi tostadora corre NodeJS
#75 Si te sirve de consuelo, el lenguage en el que programo diariamente es tan minoritario que ni tan siquiera está en la lista.
Por si te pica la curiosidad: programo scripts para Windows Command Shell, vamos, la línea de comandos de toda la vida
#77 Yo programo en Livecode ¿lo has oído alguna vez?
#87 Ok, bro: you win
#4 ES6 es tu hamijo.
#4 Hay lenguajes no tipados como Python, Scala y clojure que molan.
Di mejor Maldito javascript.
#7 Scala no tipado, what?! Negativo por falsedad.
#7 Python es tipado, y mucho. Otra cosa es que no lo declares.
https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
(Perdón por el negativo, quería dar a responder).
#45 El que hayas tenido que aclarar eso muestra la experiencia real que tiene mucha gente que habla y habla sin saber de qué.
Todavía hay gente con los huevos pelados que confunde tipado dinámico y estático con implícito y explícito y como no lo saben demuestran su ignorancia sin pudor en los foros una y otra vez.
Hoy día sólo los inútiles se centran en un lenguaje y en un paradigma. Teniendo en cuenta que hablamos de lenguajes formales, quien se queja normalmente es porque en realidad no entiende lo que está haciendo y llora porque en cuanto le cambian la sintaxis o la semántica se pierde.
#45 en el fondo todos son tipados, otra cosa es que para ciertos tipos de datos en javascript las operaciones estén sobrecargadas.
#2 Si está ahí arriba, es porque da tantos problemas que te tienes que pasar el día en stackoverflow para ver si tienen solución alguna.
#10 http://i.imgur.com/vv2taZY.jpg
#10: O porque el resto son tan imposibles que ni te molestas en preguntar, lo dejas y vas a lo seguro: JavaScript.
#10 O porque tienen muchos neófitos, o porque son lenguajes que son muy útiles pero sólo se tocan puntualmente (caso de muchos lenguajes de scripting en los que se hacen puntualmente pequeños programas para necesidades concretas, mantenimiento, etc.).
Al menos esa es mi experiencia. Nadie se va hacer un experto en algo que va a emplear únicamente un par de días, así que tira de stack overflow cuando surgen dudas para no perder tiempo que muy probablemente necesites.
Dicho esto, no creo que sea el caso de Javascript. Más bien de que la gente no entiende de qué va (dinámico, funcional y con prototipos) y piensa que tiene algo que ver con C o Java porque la sintaxis es similar.
#2 en realidad es cuanto aumenta la actividad en stack overflow por lenguaje, así que Javascript es el lenguaje que da más problemas y con el que nadie sabe que falla porque no debugga
#18 ok nigga
#2: Y más que va a subir según progrese el soporte de HTML5 para las funciones que antes cubría Flash.
Y ahora con node.js hasta se va a poder programar (arduamente) el Arduino en JavaScript.
Es un lenguaje con algún que otro fallo, pero lo suficientemente bueno como para poder ser de gran utilidad.
#2 Si en el 2000 un viajero del tiempo me hubiese dicho que 16 años más tarde el lenguaje dominante sería JavaScript, no sé si habría estudiado informática.
De hecho, probablemente me habría ido a la casa de los abuelos en la aldea. Cultivaría la tierra y acumularía armas, munición y suministros.
#2 You must enable JavaScript in order to visualize the ranking interactive charts.
¡Ese ránquin está amañado!
Ni siquiera Oracle ha logrado acaba con Java.
Que coño...Un día de estos me pillo un StackOverflow de esos. Y a ver quien se mete conmigo.
stackoverpwned: ¿Por qué no ponen el cero justo en la base del gráfico? Confundiría menos en la visualización de los datos que dejando un pequeño margen para valores negativos que no se van a dar.
Siendo StackOverflow una web para solucionar problemas... claramente los lenguajes que más problemas dan son JavaScript, Java, Python, C#... y los que menos problemas dan son Perl, Ensamblador, Rust y Julia
#39 La gente de perl y asm no pregunta. Con cpan tienes todo y son veteranos. en asm pues obviamente necesitas saber la CPU y SO así q preguntar es inutil, te buscas la vida con saber usar ensamblador.
¡Vaya! Esperaba ver a Go más alto.
Voy a dejar este hilo de comentarios porque me estoy poniendo de mala leche. Si este es el nivel que tenemos... no me extraña que nos vaya como nos va. La de sandeces que he leído en un rato.
#66 Ya ves amigo. Los mismo que dicen que si pagas con cacahuetes contrataras monos.
Lo de javascript tambien esta un poco inflado. Muchos problemas son 'javascript', pero engloban configuraciones de librerias y demas usos en los que javascript solo es tangencial. Yo mismo por ejemplo he estado preguntando dudas de una libreria para generar graficas, que esta hecha en javascript, y he utilizado ese tag. Pero la pregunta era sobre la configuracion de dicha libreria. Ni yo ni mi proyecto usamos una linea de javascript escrita por nosotros (@Deity nos libre)
Jó con Swift. En poco más de cuatro años ha pasado del puesto 14 al 7.
Python y JavaScript. Django, uWSGI, NGINX. EC2, RDS, S3 y CloudFront.
Venga ahora todos los comentarios sobre JS los aplicáis a Java que es el siguiente de la lista
Va siendo hora de que los navegadores sean compatibles con algún otro lenguaje que refuerce las debilidades de javasctript. Apple lo ha hecho con swift en ios. el wc3 o quien sea que gobierne javascript podría sacar algo adecuado a los tiempos que corren. Javascript ya no se usa para lo que se inventó, añadir algo de interactividad a tu paginilla. Ahora es el alma de muchas librerías de miles de líneas de código que son muy difíciles de mantener.
Yo trabajo con Intersystems Caché, un completo desconocido, principalmente destinado al sector médico.
https://en.wikipedia.org/wiki/InterSystems_Cach%C3%A9
¡Egos! ¡Egos everywhere!
¿Qué pasó entre Marzo del 2014 y Febrero de 2015 para que cayesen todos los lenguajes y luego remontasen?
Y Scala????
#12 En el apartado JVM languages. También puedes compararlo a tu gusto en Custom Ranking (abajo a la izquierda)