#7 Todos los que seguis programando para IE8, me compadezco de vosotros

#23 IE8 y ya es un avance...

#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.

#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

#22 qt es moderno.

#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é.

#22 qt es moderno.

#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.

#c-123" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2618471/order/123">#123 Veo que no conoces javascript.
Es normal, hay muchísimos programadores que llevan años con cosas como C# o Java que no tienen repajolera idea del lenguaje y lo critican mientras incrustan scripts en páginas aspx o jsp en el lugar más inaccesible. Odian javacript porque están obligados a usarlo y les da pereza entender, tan siquiera, el protocolo HTTP.

Desde luego, nada de versión de juguete de C, ya que es un lenguaje principalmente funcional; desde luego, no para chorradillas, ya que montones y montones de servicios web y APIs REST tiran de Javascript. Como ya se ha repetido en el hilo no se debe comparar con C, se deben comparar cosas comparables: Node con Express con java con Struts, por ejemplo.

Desde luego es hermoso, es uno de los más expresivos y, probablemente entre los lenguajes "populares", sea, con mucho, el más versátil. Qué lenguaje te gusta a ti? Bueno sí.. me dirás Haskell o Clojure (javascript es funcional... repito, javascript es funcional!), pero nadie los usa fuera de la universidad... al menos en Europa.

Respecto a los monos programando javascript... hay más monos programando Java o C# donde el IDE se lo hace todo... Más de uno y de dos he encontrado que cuando le quitas el IDE ni idea tiene de que se puede ejecutar una aplicación sin él...

#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?

#5 No es que sea imbatible, pero con tanta aplicación web pues claro que sube

#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é.

#22 qt es moderno.

#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.

#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.

#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.

#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

#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: 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 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.

#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)

#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.

#131 tiene tipado dinámico no? pensaba que se le consideraba "no tipado" no tienes que declarar las variables para usarlas. O me equivoco? Use la versión 2.7 un par de meses hace tb un par de años.

#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"

#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.

#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.

#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 )
------------------------------------

#138 No dudo que este escrito, dudo de que sea cierto. Y si es cierto dudo de que haya sido un accidente. Tu llegas te encuentras los servidores borrados a saco y de donde sacas que ha sido un bug de un rm foo/bar, ¿te sabes los scripts de memoria?. Es una historia con muchos agujeros a mi parecer.

#145 Hombre, igual ha mirado el script después (sabiendo que quizá solo sea el único "rm -rf") y habrá visto que efectivamente, las variables no estaban iniciadas y eso se traducía en un "rm -rf /".

Posible es. También es un caso harto improbable, sobre todo para alguien que se dedica profesionalmente a mantener sistemas. Quizá tengas razón, pero yo prefiero no quitarme el miedo, no vaya a ser que me envalentone y me veáis a mí de portada en Menéame

#11 no nos chupemos las pollas... pone Sr Lobo

#12 Jajaja, lo han corregido, han debido darse cuenta. Cuando lo he leído (y hecho copia-pega) me he quedado