Hace 5 años | Por Camilo_Chacón a medium.com
Publicado hace 5 años por Camilo_Chacón a medium.com

¿Como afecta la tecnología a la informática? Cada día aparecen nuevas herramientas, se presentan como algo nuevo, ¿Pero de verdad lo son? Este artículo intenta comprender los problemas de la avalancha de nuevas tecnologías en el mundo de la informática y como estas pueden afectar nuestro entorno.

Comentarios

EsePibe

La mayoría de esas nuevas tecnologías son lenguajes de programación basados en el paradigma "EPYPLA" que es el acrónimo de (Eramos Pocos Y Pario La Abuela).

Por ejemplo, Google se inventa el lenguaje Go y ¿para qué?. Otro lenguaje con sintaxis similar a C++/Java/Objetive C/C#.

¿Acaso creen que van a provocar una ola de entusiasmo que haga que los programadores se pasen en bloque a Go?, ¿y por qué Go y no otro de los lenguajes EPYPLA?. Quizás solvente algunos errores de C++, algo que también hacen otros lenguajes. Pero está condenado a ser un lenguaje marginal. sobre todo cuando vas a una empresa y no es el programador el que elige el lenguaje si no la empresa que te pide que lo hagas en C#, Java, PHP, Rubby, etc.

Burzum

#c-2" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3005918/order/2">#2 Cada lenguaje tiene su objetivo, su nicho de mercado y su alcance. Compararlos todos en la misma bolsa es error de novato, si me perdonas que te lo diga así. La idea es desarrollar X en un tiempo determinado y que dé respuesta a las necesidades del cliente o del público objetivo. Lo que haya en las tripas es lo de menos, siempre que se dé ese servicio con eficacia y eficiencia.

Siguiendo con tu ejemplo, Go es un lenguaje que facilita la programación concurrente y es de más bajo nivel que Java y C#. Se compila a nativo. Digamos que es una alternativa a C y C++ pero ayudando al programador a no pelearse tanto con la memoria y la concurrencia.
Sí es cierto que cuando llegas a una empresa, como programador, el lenguaje te viene dado en la mayoría de los casos. Es obvio y recomendable: será el arquitecto software el que deba elegir la mejor de las herramientas para construir el software, no el programador. Se puede dejar aconsejar, obviamente, pero es una decisión de alto nivel. Te pongo un ejemplo: Ruby (con una sola b) puede ser un lenguaje excelente y muy legible, y Ruby on Rails una maravilla (cualquier programador que conozca Ruby te lo dirá), pero si mi equipo de desarrollo tiene que empezar a aprender desde cero, pierdo un tiempo que repercutirá en los beneficios del proyecto o en el retorno de la inversión. Si me aventuro y todo el mundo se hace un excelente programador de Ruby, puedo tener el riesgo de que el lenguaje no tenga soporte suficiente, los frameworks se abandonen, no se actualice ante problemas de seguridad o rendimiento, etc etc.

Cada lenguaje tiene sus ventajas y sus inconvenientes, de ahí que haya que valorarlas para cada proyecto o equipo. Y un programador raso NO debe elegir con cuál va a trabajar. Por citarte algunos inconvenientes:
- C++: dificultad, curva de aprendizaje, gestión de memoria, para proyectos a bajo nivel, drivers o eficiencia.
- Objective C: más o menos difícil (Swift se hizo para no sufrirlo), gestión de memoria, nicho Mac.
- C#: lenguaje muy completo que me encanta, pero sufres a Microsoft. No ha tenido penetración suficiente en otras plataformas, debieron liberar antes.
- PHP: todo en sí, es una basura como lenguaje, pero tiene mucha penetración. Es el VHS de los lenguajes de programación web.

EsePibe

#c-3" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3005918/order/3">#3 Todo eso ya me lo se. Yo mismo he utilizado muchas veces la metáfora de los palos de Golf. Pero la realidad es mucho más compleja que eso.

El mundo de la informática es sobre todo un mercado, como todos los mercados es anarquista, es decir, no hay una especie de comité central soviético que decida que nuevo lenguaje de programación es necesario.

Constantemente, las empresas sacan nuevos productos, y normalmente esos productos entran en competencia con productos de características similares de otras empresas.

Los desarrolladores, somos los consumidores de esos lenguajes de programación que las empresas (o grupos de open software) lanzan al mercado.

Cuando el grueso de los consumidores nos volcamos en un producto, por ejemplo Java o C# se forma una comunidad de usuarios. Eso significa que en Internet encontraras foros con manuales, ayudas, trucos, código para hacer cosas específicas. Cualquier problema que tengas, alguien antes que tu lo ha tenido y es muy posible que encuentres la solución en Internet .

Si yo tengo un problema con C# lo busco y encuentro la solución enseguida. Si tengo un problema con MODULA II no me ayuda ni el tato por que si casi nadie desarrolla en MODULA II casi nadie puede ayudarme.

Los lenguajes de programación más usados son básicamente C, C++, Java, C#, Python, JavaScript, PHP

El lenguaje Go es prácticamente un lenguaje minoritario y yo no lo usaría para un proyecto serio. De hecho hay más desarrolladores de Object Pascal que de Go.

Los lenguajes "EPYPLA" son lenguajes que nacen para ser perdedores por que sus supuestas bonanzas no son suficientes para desplazar a lenguajes ya existentes. Para lenguaje que compile en código nativo ya tenemos a C++ entre muchos otros.

Burzum

#5 A ver, como te decía, cada lenguaje tiene su nicho de mercado y su especifidad. Me dices que no usarías Go para un proyecto serio... y sin embargo tienes ejemplos de proyectos acojonantes que están hechos con Go: Docker, Kubernetes, Openshift, InfluxDB, Terraform; o con algunas partes en Go como es el caso de Netflix, MongoDB o Couchbase.
El problema de tu afirmación es que estás viendo esto desde el punto de vista del desarrollador, cuando ha de verse desde el punto de vista arquitectónico o del proyecto. Si tengo un proyecto con requerimientos no funcionales de alta concurrencia, me iré a Go, aunque haya menos documentación o menos entradas en StackOverflow que de C++. El tiempo en desarrollar una aplicación en concurrente y el estrés en los desarrolladores sería mucho más alto en C++ que si programaran en Go, a menos que disponga de un equipo de desarrollo experto en C++.
Por ponerte otro ejemplo, si tuviéramosque mantener aplicaciones bancarias, probablemente tiraríamos de Cobol, y mira que es una tortura china. Los lenguajes son HERRAMIENTAS para llegar a un fin, no un fin en sí mismos. Que se lleven más o menos, que haya más desarrolladores o menos de un lenguaje, no es tan relevante a la hora de seleccionarlo. De hecho, tienes muchísimos desarrolladores de PHP en el sector, cuando es un lenguaje que lo único que se merece es un buen lanzallamas y fuego redentor.

D

#3 Una pregunta, tú trabajas en España? Lo digo porque todo lo que dices está muy bien, pero eso de arquitecto de software, retorno de la inversión, etc, tal vez se aplique fuera, porque yo aquí, no lo he visto nunca.

Aquí la herramienta la elige el comercial vendemotos de la empresa, que ha leído un artículo en internet y se piensa que la empresa puede con ello. Y lo de la inversión... en España la informática es un gasto, no una inversión. Formar a los programadores es un gasto y una pérdida de tiempo, mejor que se formen en su casa y por su cuenta, pero que sea al salir del trabajo. Y así nos va como nos va.

Burzum

#6 Sí, trabajo en España, aunque durante un tiempo también trabajaba para Europa. Si bien aqui te encuentras empresas de todo tipo, te aseguro que aquí se mira el retorno de la inversión y el presupuesto (principalmente a la baja). En mi experiencia, las empresas medianas hacen un mejor trabajo que las pequeñas y que las grandes. Las consultoras son entes anquilosados en el tiempo. En otros países te puedes encontrar que se aplica un mayor presupuesto para que la gente se pueda formar. Aquí en España mucho menos, de hecho si te vas a una gran consultora, las tecnologías usadas son "plenamente afianzadas en el sector", o es decir, obsoletas pero como es lo que controlan, no cambian. De ahí que te encuentres proyectos con Java EE 6 o Spring 1-3 hoy en día.

Lo de arquitecto software existe, aunque a veces es un rol, no una asignación técnica dedicada. Llámese arquitecto software, jefe de equipo o jefe de proyecto, alguien debe tomar la decisión tecnologica sobre la que sentar las bases del desarrollo: lenguajes, capas, interacción, seguridad, etc. Sí, es recomendable que sea una persona dedicada la que lo haga, pero no siempre es así. En todo caso, afianzo lo que decía: no es una decisión a tomar por parte del programador, que intentará usar el lenguaje con el que esté más a gusto o que desee aprender, en lugar del más adecuado para el proyecto.

D

#8 De ahí que te encuentres proyectos con Java EE 6 o Spring 1-3 hoy en día.

Exacto, yo tengo hasta proyectos en VB6 e incluso ASP del clásico (no .net). Y ni intención de que lo actualicen...

squanchy

La informática ha avanzado mucho. Lo que antes eran servidores, pasó a llarmarse internet, y ahora lo llaman la nube.

Cheng_Guerrero

Sí, son herramientas en constante cambio, por lo que para adaptarse a ellas hay que estar en constante aprendizaje

EsePibe

. Borrado por que he pulsado el "enter" sin querer antes de completar el mensaje .