Introducción
Este es un breve ensayo sobre mi opinión sobre algunos de los lenguajes de programación modernos.
Bueno, ‘ve no ha terminado, pero decidido publicarlo tal cual y editar más tarde
Con la gran cantidad de lenguajes de programación que hay muchos de nosotros estamos confundidos sobre cuál usar para su proyecto o como idioma predeterminado de cumplir. Aquellos de nosotros que sólo comienzan su viaje por el fascinante mundo de la programación se encuentran a menudo se enfrentan a la cuestión de las eligiendo su primer idioma y yo a veces me preguntan para dar consejo.
Personalmente me gusta probar todos los otros idiomas que oigo hablar – porque me resulta fascinante imaginar de lo que sus autores estaban pensando y cómo se llegó al diseño. Además, lo que me gusta en general, en la ingeniería y es que el aprendizaje de algo nuevo es una introducción a la historia de la evolución de la industria y que te hace llegar a conocer y conocer a un montón de entusiastas increíbles. Así que pensé que había que seguir adelante y escribir una pequeña entrada en el blog acerca de los diversos idiomas que tenía experiencia y mi opinión general sobre el asunto.
TLDR:
Como de costumbre, el puesto tiene algunos enlaces para su posterior lectura en final (para que pueda desplazarse hacia abajo si estás aburrido). Si bien no considero Wikipedia una fuente fiable de información, sigue siendo muy útil, ya que permite encontrar enlaces a artículos originales y se puede obtener un conocimiento más amplio del tema con una lectura rápida a través de enlaces «relacionados».
Ahora, déjenme algunos puntos improtant digo en caso de que usted no sabía o todavía están confundidos
- Cada algoritmo o un problema puede ser resuelto en cualquier idioma.
- Algunos lenguajes permiten que usted pueda resolver algunos problemas en una forma más fácil
- Algunos idiomas traer más diversión (una positiva frente a la miseria de bug-caza) en el proceso de escribir código
- Por lo general es posible reutilizar el código escrito en otros idiomas, pero la dificultad del proceso puede variar
Popularidad . Un lenguaje popular tiene una comunidad donde usted puede hacer preguntas.
Un aspecto importante a considerar es el sistema de tipos – es decir, cómo se declaran los tipos de datos y variables y cómo el compilador / intérprete comprueba la corrección de código. Podemos clasificar los lenguajes basados en el sistema de tipificación usado de varias maneras:
- dinámico (como el rubí, que permite hacer un montón de cosas en tiempo de ejecución a través de la introspección / reflexión [obtener información de tipo como las funciones disponibles y argumentos dinámicamente] al precio de tener un enorme accidente si usted comete un error tipográfico)
- estática (haskell – donde se comprueban todos los tipos durante la compilación y hay incluso existe la opinión de que si un programa escrito en un tipo estático idioma compila, es correcto)
- débil (conversión de tipos implícita como en JavaScript y Perl que significa que puede sumar enteros y cadenas y obtener números enteros … raro)
- estricto (ni siquiera conversión de tipo explícita es posible – como en Haskell / ML, que permite evitar el abuso de la comprobación de tipos)
- explícita (como C, C + +, Java) – usted tiene que definir los tipos de variables todo el tiempo (como , «int x = 1» o «float sqrt (int x) …»)
- implícitas lenguajes de programación más funcionales (como Haskell, F # y, recientemente, C # y C + +0 x) – tipo de variable es deducida a partir del contexto [ TypeInference ]. Esto es, el compilador intenta encontrar al menos algunas de las variables para las que se puede decir del tipo de seguro. Al igual que, enteros o constantes float. Entonces se remonta sustituyendo cada vez que aparece de la variable sin tipo con el tipo de la constante que se puede utilizar allí. Algo así como funciona Hindley-Milner inferencia de tipos [ HindleyMilner ]
Ahora, vamos a repasar algunos idiomas y discutir cada uno de ellos individualmente
dos reglas de oro en la optimización de software :
- Siempre perfil el software (es decir, analizar qué parte de la computación, que lleva más tiempo de rutina ) antes de tratar de optimizar. Recuerde que la cita Knuth, «la optimización prematura es la raíz de todo mal». Eso significa que usted debe ser consciente del peligro de perder mucho tiempo optimizando la parte equivocada de la realidad el programa que tiene una influencia significativa en el rendimiento.
- Si alguna optimización le da un aumento lineal en el rendimiento, olvidar al respecto. Usted puede obtener la misma optimización por no hacer nada y simplemente esperando una próxima generación de CPUs a salir en medio año. Si realmente, realmente necesita rendimiento, empezar por tratar de disminuir la complejidad algorítmica
