Portada
mis comunidades
otras secciones
#5:
Cuando tienes un poco de experiencia, el lengujae de programación se vuelve irrelevante. Lo realmente jodido es conocer toda la arquitectura, la metodología y el "framework" que tiene montado cada cliente. A estas alturas, todos tienen una serie de librerías que tienes que utilizar sí o sí, aunque tú prefieras desarrollar desde cero. Ahí es donde se nota la diferencia entre programadores que llevan tiempo trabajando para un cliente de los recién llegados.
#11:
"En busca de un solo lenguaje de programación"
"Sea como sea, hay a quien tanto lenguaje de programación le causa dolor de cabeza, por eso la NSA ya está trabajando –junto con la Universidad Carnegie Mellon– para adoptar uno políglota, el Wyvern."
xkcd: Standards - http://xkcd.com/927/
"Sea como sea, hay a quien tanto lenguaje de programación le causa dolor de cabeza, por eso la NSA ya está trabajando –junto con la Universidad Carnegie Mellon– para adoptar uno políglota, el Wyvern."
xkcd: Standards - http://xkcd.com/927/
#21:
#5 Si bien entiendo tu actitud, es un gran error pensar que el lenguaje es irrelevante; cada lenguaje tiene particularidades en cuanto a cómo se comporta, las cuales llevan a utilizar técnicas de desarrollo y prácticas habituales muy distintas de un lenguaje a otro.
Por ejemplo, en Java las instancias de las clases con recursos deben usarse siempre en un bloque `try` y cerrarse en el `finally` para asegurar que se cierran correctamente, mientras que en C++ las mismas clases deben implementar "The big three" (The big four, en mi opinión, desde que existe C++11) para conseguir el mismo objetivo.
Incluso en C/C++ puede haber pequeñas diferencias entre un compilador y otro que afecten al comportamiento general de un software; que se lo pregunten a Torvalds
.
Cuanto más grande es el software que se va a diseñar y codificar (sí, diseñar, los analistas también deben conocer el lenguaje en el se hará la implementación para poder tomar determinadas decisiones), mayor importancia adquieren todos estos detalles.
Por ejemplo, en Java las instancias de las clases con recursos deben usarse siempre en un bloque `try` y cerrarse en el `finally` para asegurar que se cierran correctamente, mientras que en C++ las mismas clases deben implementar "The big three" (The big four, en mi opinión, desde que existe C++11) para conseguir el mismo objetivo.
Incluso en C/C++ puede haber pequeñas diferencias entre un compilador y otro que afecten al comportamiento general de un software; que se lo pregunten a Torvalds
.Cuanto más grande es el software que se va a diseñar y codificar (sí, diseñar, los analistas también deben conocer el lenguaje en el se hará la implementación para poder tomar determinadas decisiones), mayor importancia adquieren todos estos detalles.
#8:
Diferentes necesidades, diferentes herramientas.
Un ejemplo claro son c y javascript, que son dos herramientas para dos necesidades absolutamente diferentes.
El problema viene cuando hay muchas herramientas para la misma necesidad.
Mi punto de vista es que es bueno que haya muchos lenguajes de programación, y que nazcan y mueran constantemente más.
Porque es la manera de probar las nuevas ideas, de las que los 6 grandes lenguajes se nutren y con las que evolucionan.
Para friquear, está muy bien aprenderse un lenguaje muy minoritario que trae una idea revolucionaria.
Pero para producción, necesitas una muy buena razón para no usar un lenguaje estable, que todo el mundo conozca y en el que te sea fácil encontrar colaboradores, librerías, documentación, ayuda...
Un ejemplo claro son c y javascript, que son dos herramientas para dos necesidades absolutamente diferentes.
El problema viene cuando hay muchas herramientas para la misma necesidad.
Mi punto de vista es que es bueno que haya muchos lenguajes de programación, y que nazcan y mueran constantemente más.
Porque es la manera de probar las nuevas ideas, de las que los 6 grandes lenguajes se nutren y con las que evolucionan.
Para friquear, está muy bien aprenderse un lenguaje muy minoritario que trae una idea revolucionaria.
Pero para producción, necesitas una muy buena razón para no usar un lenguaje estable, que todo el mundo conozca y en el que te sea fácil encontrar colaboradores, librerías, documentación, ayuda...
#14:
#12 si y no.
No es lo mismo programar montado sobre una enorme pila de capas de abstrabción que programar pegadito a la electrónica.
No creo que sea posible diseñar un lenguaje de programación compilable a código máquina que tenga todas las maravillas que nos aportan los lenguajes interpretados o los que se ejecutan en máquinas virtuales.
Simplemente el ducktyping ya debe ser todo un reto así que cosas como la metaprogramación deben ser absolutamente imposibles.
A parte que las máquinas reales no tienen recolector de basura, ni gestionan la memoria del modo que lo hacen las máquinas virtuales como la de java o la de .net
No es lo mismo programar montado sobre una enorme pila de capas de abstrabción que programar pegadito a la electrónica.
No creo que sea posible diseñar un lenguaje de programación compilable a código máquina que tenga todas las maravillas que nos aportan los lenguajes interpretados o los que se ejecutan en máquinas virtuales.
Simplemente el ducktyping ya debe ser todo un reto así que cosas como la metaprogramación deben ser absolutamente imposibles.
A parte que las máquinas reales no tienen recolector de basura, ni gestionan la memoria del modo que lo hacen las máquinas virtuales como la de java o la de .net
#18:
#17
Si y no.
Es posible que haya cosas que una sintaxis no sea capaz de expresar, o todo lo contrario que una sintaxis te obligue a expresar cosas que no necesitan ser expresadas.
Toda sintaxis es un tradeof entre potencia, legibilidad y comodidad, que se decide en función de las características del lenguaje que a su vez vienen determinadas por en entorno en el que se va a ejecutar, las necesidades que quiere resolver (y la experiencia acumulada)
Diferentes entornos, diferentes necesidades, y diferente momento histórico, generan diferentes características y a su vez diferentes sintaxis.
Si y no.
Es posible que haya cosas que una sintaxis no sea capaz de expresar, o todo lo contrario que una sintaxis te obligue a expresar cosas que no necesitan ser expresadas.
Toda sintaxis es un tradeof entre potencia, legibilidad y comodidad, que se decide en función de las características del lenguaje que a su vez vienen determinadas por en entorno en el que se va a ejecutar, las necesidades que quiere resolver (y la experiencia acumulada)
Diferentes entornos, diferentes necesidades, y diferente momento histórico, generan diferentes características y a su vez diferentes sintaxis.
#7:
echo "no";
printft ("No");
document.writte("no");
cout
printft ("No");
document.writte("no");
cout
Comentarios
Cuando tienes un poco de experiencia, el lengujae de programación se vuelve irrelevante. Lo realmente jodido es conocer toda la arquitectura, la metodología y el "framework" que tiene montado cada cliente. A estas alturas, todos tienen una serie de librerías que tienes que utilizar sí o sí, aunque tú prefieras desarrollar desde cero. Ahí es donde se nota la diferencia entre programadores que llevan tiempo trabajando para un cliente de los recién llegados.
#5
La diferencia entre programadores que llevan tiempo trabajando es con quien se bajan a comer.
Aunque #5 tiene razón, tampoco es normal que cada año salgan al menos un par de lenguajes nuevos, la mayoría tal cual nacen se mueren. Y no, no es porque hagan falta para solucionar problemas para los que no había herramientas antes. Y como muestra un botón y no estan todos
http://www.digibarn.com/collections/posters/tongues/ComputerLanguagesChart.png
#5 Si bien entiendo tu actitud, es un gran error pensar que el lenguaje es irrelevante; cada lenguaje tiene particularidades en cuanto a cómo se comporta, las cuales llevan a utilizar técnicas de desarrollo y prácticas habituales muy distintas de un lenguaje a otro.
.
Por ejemplo, en Java las instancias de las clases con recursos deben usarse siempre en un bloque `try` y cerrarse en el `finally` para asegurar que se cierran correctamente, mientras que en C++ las mismas clases deben implementar "The big three" (The big four, en mi opinión, desde que existe C++11) para conseguir el mismo objetivo.
Incluso en C/C++ puede haber pequeñas diferencias entre un compilador y otro que afecten al comportamiento general de un software; que se lo pregunten a Torvalds
Cuanto más grande es el software que se va a diseñar y codificar (sí, diseñar, los analistas también deben conocer el lenguaje en el se hará la implementación para poder tomar determinadas decisiones), mayor importancia adquieren todos estos detalles.
#21 "los analistas también deben conocer el lenguaje en el se hará la implementación para poder tomar determinadas decisiones"
ojala fuera siempre cierto.
#5 Explicalé algo tan simple a uno de recursos humanos ;-P
#5 Eso de que cuando dominas unos lenguajes los manejas todos, como que es bastante pretencioso. Los lenguajes de programación comparten un cuerpo de estructuras comunes, bucles, condicionales... pero todo lenguaje de programación se hace por alguna razón y busca resolver ciertos problemas de una manera específica, no se puede decir que se maneja ese lenguaje hasta que no se comprende esa lógica detrás del lenguaje.
Quiero decir con esto que tirar de bucles en ruby es muy cutre, por ejemplo.
#5 tu has tocado cero Haskell/Clojure/Scala, etc.
"En busca de un solo lenguaje de programación"
"Sea como sea, hay a quien tanto lenguaje de programación le causa dolor de cabeza, por eso la NSA ya está trabajando –junto con la Universidad Carnegie Mellon– para adoptar uno políglota, el Wyvern."
xkcd: Standards - http://xkcd.com/927/
En busca de un solo lenguaje de programación
https://xkcd.com/927/
#11: Vaya, te adelantaste.
#4: Exacto, si todos los tornillos fueran del 5, todo se arreglaba con una única herramienta.
Eso si, para apretar ciertas piezas tendrías que apretar muchos tornillos, y en otras sería más grande el tornillo que la pieza.
Diferentes necesidades, diferentes herramientas.
Un ejemplo claro son c y javascript, que son dos herramientas para dos necesidades absolutamente diferentes.
El problema viene cuando hay muchas herramientas para la misma necesidad.
Mi punto de vista es que es bueno que haya muchos lenguajes de programación, y que nazcan y mueran constantemente más.
Porque es la manera de probar las nuevas ideas, de las que los 6 grandes lenguajes se nutren y con las que evolucionan.
Para friquear, está muy bien aprenderse un lenguaje muy minoritario que trae una idea revolucionaria.
Pero para producción, necesitas una muy buena razón para no usar un lenguaje estable, que todo el mundo conozca y en el que te sea fácil encontrar colaboradores, librerías, documentación, ayuda...
#8 yo creo que mezclas lenguaje de programación con paradigmas de programación.
Yo estoy de acuerdo en que haya varios paradigmas, ya que no es lo mismo programar un chip casi a nivel de ensamblador que programar una herramienta de gestión con objetos, pero eso no implica que para cada paradigma haya que aprender una sintaxis completamente nueva. Sería perfectamente posible crear un único lenguaje que soportara todos los paradigmas de programación existentes, aunque luego este fuera compilado o interpretado por diferente software en función del uso que se dé.
#12 si y no.
No es lo mismo programar montado sobre una enorme pila de capas de abstrabción que programar pegadito a la electrónica.
No creo que sea posible diseñar un lenguaje de programación compilable a código máquina que tenga todas las maravillas que nos aportan los lenguajes interpretados o los que se ejecutan en máquinas virtuales.
Simplemente el ducktyping ya debe ser todo un reto así que cosas como la metaprogramación deben ser absolutamente imposibles.
A parte que las máquinas reales no tienen recolector de basura, ni gestionan la memoria del modo que lo hacen las máquinas virtuales como la de java o la de .net
#14 se puede programar con una pila de abstracción o pegado a la electrónica con la misma sintaxis, se puede programar con recolector de basura y sin él con la misma sintaxis, etc.
#17
Si y no.
Es posible que haya cosas que una sintaxis no sea capaz de expresar, o todo lo contrario que una sintaxis te obligue a expresar cosas que no necesitan ser expresadas.
Toda sintaxis es un tradeof entre potencia, legibilidad y comodidad, que se decide en función de las características del lenguaje que a su vez vienen determinadas por en entorno en el que se va a ejecutar, las necesidades que quiere resolver (y la experiencia acumulada)
Diferentes entornos, diferentes necesidades, y diferente momento histórico, generan diferentes características y a su vez diferentes sintaxis.
#18 yo no estoy de acuerdo. Puede haber una sintaxis flexible que se adapte a todos los tipos de programación. No se me ocurre ninguna excepción.
#19 A mi sí.
Ese codigo tendrá que ser ejecutado como código máquina. Si creas un lenguaje complejo es de esperar que el código sea más lento (ver Java), mientras que si lo creas sencillo el programador tendrá que escribir más lineas para lo mismo, con la pérdida de horas y posible aumento de bugs.
La mejor opción es mantenerlo como está. Quien quiera código mantenible facilmente y mucha funcionalidad se irá a Java y las mil librerías y frameworks de su mundo. Quien necesite muchas llamadas al sistema hará un script en algun lenguaje de scripting o, si programa algo que ha de ser eficiente pero con las caracteristicas de un lenguaje de programación se ira a C, y asi con todos los lenguajes.
#50 vuelvo otra vez a lo mismo, pero ya me canso porque lo he repetido cien veces: confundís todos un paradigma de programación con el lenguaje y la sintaxis. El lenguaje ni es complejo ni deja de serlo.
#60 piensa por qué todos te responden con la sintaxis y la complejidad: crear un lenguaje multiparadigma es complicado porque cada paradigma requiere cierta expresividad. Java 8 es un perfecto ejemplo de lo complicado que es añadir a un lenguaje OO sentencias propias de un lenguaje funcional. Ahora intenta pensar en añadir las capacidades de Haskell y verás que acabas teniendo un Frankenstein engorroso y poco intuitivo. En resumen: quien mucho abarca poco aprieta
#63 edito: con "funcional" te refieres a programación declarativa? Si es así puedo admitirlo, si a lo que te refieres es a un lenguaje con funciones tipo C ya existe: C++.
#64 culpa mía, hoy día "funcional" es un término ambiguo: hay quien ve a javascript como funcional porque puedes pasar las funciones como parámetro, definirlas en tiempo de ejecución... pero sí, me refiero a lenguajes como Haskell. De hecho C++ siempre ha tenido muchas críticas por ser un "parche" para añadir OO a C, que nunca tuvo eso como objetivo
#60 Para nada, hablo en los dos casos.
Si quieres un lenguaje multiparadigma tendrás un monstruo inevolucionable y que nadie sabrá explotar con propiedad. Para poner un ejemplo rápido, sería usar Java ignorando las clases y programar de forma estructurada. Se puede pero no es óptimo.
Si te refieres a un lenguaje para cada paradigma, piensa que no todos los lenguajes han sido pensados para lo mismo. Incluso en el mismo paradigma, a unos les interesa mas que sea multiplataforma, a otros que el programa no consuma demasiados recursos y a otros que cree gráficos con rapidez.
#65 utilizar Java ignorando las clases es casi C (grosso modo). De hecho, C podría considerarse C++ ignorando las clases. No veo el problema.
#18 te pongo un ejemplo para que lo entiendas. Con C++ se pueden hacer infinidad decosas: programar a nivel muy bajo, programar con orientación a objetos, programar con funciones de forma imperativa clásica, etc. Faltaría annadir ciertas cosas para la programación declarativa y puede que algún detalle en algún otro aspecto, pero a grandes rasgos, a día de hoy, se puede escribir con C++ lo que sea: un sistema operativo, una página web (JavaScript, PHP, Java...), etc. Problema: por ejemplo, los navegadores solo interpretan JavaScript, no C++. Pero si se unificara todo con una misma sintaxis se podría hacer todo con C++, por tanto es posible.
Quizá la excepción a todo esto serían los scripts para intérpretes de comandos de sistemas operativos, ya que no son realmente programas, sino secuencias de comandos y cada intérprete de comandos tiene los suyos, pero pocas más excepciones se me ocurren.
He puesto C++ solo como ejemplo, pero podría crearse un nuevo lenguaje desde cero con una sintaxis más clara. La de C++ viene de la de C, que se creó en los annos sesenta y es mejorable, claro.
#20
Te pongo un ejemplo:
La sintaxis de C++ no soporta abrir y modificar una clase en tiempo de ejecución, como en rubi; porque es necesario saber en tiempo de compilación el tamaño que tendrán los objetos.
¿tiene sentido que la sintaxis de C++ sea capaz de expresar cosas que no son compilables?
Y en el caso de querer usar C++ para scripting:
¿Y tiene sentido sufrir todas las limitaciones e imposiciones que impone un compildor, cuando el código va a ser interpretado?
#25 el primer ejemplo trata de algo con lo que nunca he trabajado, con lo que no puedo responderte. Con el caso del segundo ejemplo he trabajado muchísimo, por el contrario. A qué "imposiciones" te refieres? No se puede hacer en C++ exactamente lo mismo que en JavaScript?
#26
en javascript las funciones son objetos de primer orden.
Puedes asignar una función a una variable, puedes pasar una función como un parámetro, una función puede tener atributos como cualquier objeto...
En C++ puedes hacer algo parecido, pasando un puntero a una función, pero no es lo mismo.
Además en javascript (ni en python, rubi, php, lua...) no se declaran el tipo de datos que devuelve o acepta una función, porque no es necesario, ya que el interprete (a diferencia del compilador) cuenta con la información que tiene en tiempo de ejecución.
#26 Sí y no; sí se puede pero no se debe, pues para soportar determinadas cosas hay que abusar de hacks y macros, algo poco recomendable para mantener a largo plazo, y aún en el caso de que se consiga una implementación perfecta sin duda afectará al rendimiento del software de una forma u otra.
Por ejemplo, supongamos que queremos soportar "reflejo" (reflection) en C++, concretamente queremos poder listar todos los métodos de cualquier clase de forma genérica (esto es, iterando sobre los métodos e imprimiendo sus nombres); esto es algo que C++ no soporta de forma nativa pues no guarda la suficiente información en el ejecutable como para hacer esto, los nombres de los métodos son eliminados del ejecutable si no se compila en modo debug (-g en GCC/Clang).
Pero podríamos hacerlo si queremos, podríamos tener un hashmap global con todas las clases accesibles desde nuestro programa y guardar en él los métodos y miembros de cada clase.
Por supuesto tendríamos que crear unas cuantas macros y usarlas durante las declaraciones correspondientes:
* Una para declarar una clase, que genere el código necesario para guardar la clase en el hashmap.
* Una para declarar variables miembro.
* Una para declarar métodos miembro (probablemente varias para declarar métodos, pero esto ya es otro tema).
Imagino que vas pillando la idea.
Claro, todo esto consume memoria y ciclos de CPU, por lo que nuestro programa será un poco más lento y un poco más pesado, ¿de verdad nos merece la pena soportar reflejo?
Lo anterior es sólo un ejemplo, un lenguaje de scripting soporta esto y más pero siempre a costa del rendimiento, por eso los lenguajes de scripting son, de forma inherente, más lentos y pesados que los lenguajes compilados.
#28 agradezco el esfuerzo de la parrafada (dicho sin ironía), pero parece entendéis lo que digo: digo utilizar el mismo lenguaje para todo. La misma sintaxis. Qué tiene que ver la sintaxis para que sea más rápido o más lento? Si los navegadores pudieran interpretar C++ (con limitaciones, claro) igual que JavaScript iría igual de rápido.
#27 muy bien, pero eso es porque un sennor programó el compilador como tú describes, pero eso no tiene nada que ver con la sintaxis del lenguaje.
Como repito por enésima vez en #36, la sintaxis sería la misma, pero el paradigma de programación cambiaría si fuera interpretado por un navegador, por un compilador, etc. No sé por qué cuesta entenderlo.
#38 Los compiladores no saben lo que está sucedienno en tiempo de ejecución. Los intérpretes sí.
Por eso, hay cosas que unos lenguajes necesitan expresar y otros no.
A parte de que hay cosas que no se pueden compilar.
#37 Se dice que el 99% del rendimiento depende del 1% del código.
Lo que se hace es programar ese 1% en C(++) y el resto en lenguajes de más alto nivel.
Por otra parte, a veces es más importante el rendimiento de los programadores que el del hardware.
#43 ve a #38.
#61 hablar es gratis.
Diseña esa sintaxis y gana el premio turing.
#26 uno tiene tipado dinámico (y por ello es un puto desastre en rendimiento) y otro no.
Saber un lenguaje != saber programar
echo "no";
printft ("No");
document.writte("no");
cout
#7 TypeError: document.writte is not a function
¿existen muchas herramientas para arreglar un coche? Si , la labor del mecánico es saber que herramienta usar y saber usar esa herramienta para arreglarlo.
#4
¿existen muchas herramientas para arreglar un coche?
No.
El resto de tu comentario ya no vale nada.
#4 Para ser un experto en un entorno de desarrollo, sea Java, C, C++, .Net... se necesitan años de experiencia y participar en muchos proyectos.
Cuando un desarrollador dice que sabe programar en cualquier lenguaje y entorno, es que realmente no controla ninguno.
#4 el dilema no son las herramientas... sino saber como se desmonta y como se monta
un destornillador plano puede ayudarte para destornillar también para saltar los click de los plásticos solo es cuestión de saber manejarlo
los lenguajes de programación se agrupan en familias, en frameworks, librerías, tecnologías, puedes usar ese destornillador plano para destornillar o pegarte una puñalada si vas a lo bruto sin mesura..
odio cuando en las game jam me dicen por que uso DIV mas bien BennuGD si tengo licencias de unity3D y de gamemaker y puedes usarlas y sacar mas rendimiento .... yo les respondo, el juego en BennuGD se hace linea a linea sin opción a una rejilla la rejilla lo limitas como tu quieras como si quieres que sea al pixel, tu juego es tu expresión linea a linea, idea a idea , se podría expresar mejor ... si C o ensamblador pero no podría participar en una jam de 48 horas honestamente, que puedo sacar mas productividad en gamemaker o unity si, pero no queda mi esencia tal como quiero .... además BennuGD aprovecha mejor la maquina en juegos 2D que gamemaker
P.D. me lo dice el profesor del master de videojuego, como se nota que teme a los lenguajes desconocidos
Que lenguajes ni cuentos chinos...los programadores de verdad usamos mariposas.
Contaban la historia del chico que quiso preparar bien su futuro y decidió aprender todos los lenguajes de programación existentes...dicen que cuando por fin consiguió dominarlos ya estaban obsoletos....
es un mundo cambiante de programaciones ...
Paco Pocero y su ladrillos el otro Amancio Ortega y sus ropas que duran tres lavados; Billonarios...
programador de software; el pobre del siglo XXI, el esclavillo
Para mi lo peor es cuando a uno le toca currar en proyectos en los que se utilizan infinidad de lenguajes y frameworks a la vez para cosas simples, que podrían ir en Java Beans, PHP, o simplemente HTML. Por algún extraño motivo empiezan a aglutinar lenguajes, frameworks y bibliotecas que convierten en una pesadilla el trabajo. Al final las supuestas ventajas para simplificar el trabajo hacen que el proceso sea mucho más lento a la hora de montar los proyectos y ver los errores. Además a la hora de compilar como no se disponga de un buen equipo el desarrollo es pesadísimo y aburrido. Y si se trata de lenguajes interpretados esa lentitud y sobrecarga de la CPU se traslada al usuario.
Ese es el gran lastre de ser programador
.
Lo bonito de la programación es que es como un sistema orgánico, evoluciona, sobrevive o se muere, se adapta...
En realidad, con la experiencia, el lenguaje en sí te va dando un poco más igual, los conceptos y paradigmas son lo que vas aprendiendo.
Llevo casi 10 años y los sigo aprendiendo (y lo que me queda), y es por eso que nunca me aburre.
Otra cosa para aprender son los clientes, jefes, y deadlines; pero eso ya es otra cosa.
#42 #46 Estoy de acuerdo pero sólo hasta cierto punto. Es verdad que un buen desarrollador puede cambiar de lenguaje de programación con un periodo de adaptación muy breve, pero eso no significa que deba hacerlo frecuentemente.
Por ejemplo, alguien que esté acostumbrado a un lenguaje con recolector de basura probablemente va a meter la pata trabajando en C y asignando o desasignando memoria. O alguien acostumbrado a tipado fuerte se va a volver loco debugueando un código en ruby. O alguien que no entienda cómo funciona el recolector de basura de Java, la va a acabar liando parda si tiene que desarrollar un sistema que use la memoria y cacheado de forma intensiva y acabará añadiendo más memoria a la máquina virtual sin darse cuenta de que el fallo está en su código.
#54 Estoy de acuerdo.
Puntualizaria según lo que quise dar a entender en el otro comentario es, que en ese caso, al programador le falta por aprender un concepto: la gestión de memoria. Java la hace por el programador, (salvo en algún caso que se quiera meter a darle a caña), por tanto al pasarse a C, como C no lo tiene, la liará.
Aunque si la lía doma aún la gestión de memoria.
Sin embargo la sintaxis, los controles de flujo, compilar y los tipos de datos los tendrá más o menos claros.
Esto es como discutir si hay demasiadas distribuciones de linux. Muchos lenguajes tienen su nicho específico y su sintaxis está adaptada a resolver cierto tipo de problemas. Otra cosa es que muchos aprenden un lenguaje y quieren aplicarlo a todo tipo de problemas por no aprender otro paradigma/sintaxis.
Por ejemplo, Java no es nada óptimo para sistemas de tiempo real porque su GC congela la ejecución durante un tiempo indeterminado (hay VMs que permiten un control preciso del recolector, pero no son estándares). Y nadie hace juegos con Prolog...
@Meneante_ejemplar, mejor pon aquí lo de la pesadilla del desarrollador.
#1 Ya edité en el anterior. Fuiste rápido, pardiez.
Soy de los que opinan que tampoco son tan diferentes distintos lenguajes. Con saber algo de programación de bajo nivel, las bases de la OOP y algunos patrones de diseño, ya está. Las bases son siempre las mismas.
El murciano es el que mejor se entiende.
No entiendo de que demonios están hablando, solo existe un lenguaje de programación, el ensamblador, el resto son scripts y macros para facilitar la vida a los pseudo-programadores y que puedan hacer sus pinitos...
#41 "Código máquina" es el único lenguaje que entienden los ordenadores, el ensamblador es solo una traducción nemotécnica para que los pseudo-gurús se sientan comprendidos por algunas personas o mascotas.
#49 Perdón, creí que se daba por supuesto, mis disculpas.
El problema con los lenguajes de programación es cuando te faltan, no cuando te sobran.
Claro que hay quien prefiere un mundo simple y limitado, pero es simple pereza mental. Realmente tener pocos no es ninguna ventaja.
Y ya si alguien se plantea aprender cosillas de programación desde cero en la edad adulta (porque ahora todo el mundo debe saber programar) ya ni os cuento.
Hay demasiadas brochas para un pintor?
¿Llego tarde a la comparación de pollas?
No. No hay demasiados lenguajes. Simplemente unos evolucionan, unos se crean como sustitutivos evolutivos y otros mueren por desuso. Esta guia que expongo ayudaría a cualquier novato a encaminarse mas o menos según con qué quiera comenzar a a desarrollar. La considero muy util.
http://i.imgur.com/Bgu9QLq.jpg
Yo estudio Esperanto ++
Increíble: ¿cómo puede un artículo de esa 'pobreza' llegar a portada? No dice nada. ¡Y ni siquiera es gracioso!
¿Que es mejor, dominar un lenguaje o chapurrear varios?
Lo que faltaba, aprender un lenguaje de programación de la NSA...
¡Cuánta gente sabe programar por aquí! ¿No?
Esperanto++
"Está especializado en Java, C, C++, PHP, Javascript y Dart." Me parto de risa
Hay demasiados pseudo-desarrolladores
#3 En cambio tú eres el único desarrollador. Realmente, eres el Rey de Reyes.