#25 PHP con algún framework tipo Laravel no parece tan malo.
Pregunta noob, ¿No creeis que el (C++ + python) para temas IOT serían lenguajes para aprender en 2020?
#63 Yo creo que para IOT tiene que ser la polla Rust, tiene muy buena pinta como lenguaje low-level. Otra cosa es que tenga la popularidad de C++...
Joder... dejé de programar profesionalmente, hace años.
Os leo ahora, en estas 3 paginas, y es para volverse gilipollas.
Cada lenguaje, framework, tool, etc... que habéis citado, le he dado un vistazo rapido en sus respectivas páginas, y solo veo una cosa: reinventar la puta rueda. Una y otra vez.
¿Cual es el objetivo de TANTO código nuevo si al final, todo Dios sigue usando: Java, JS, C++, C#, Python, Node, Ruby, PHP y Objective-C?
Lo jodido es que la posición de turno laboral a la que optar, "pida X lenguaje" como tal. Lo suyo es, que el que es developer, lo es toda la vida. Te metes en este puesto y en unos días, programas fluido.
cuál es el objetivo de tanto código nuevo si la gente sigue usando [ristra interminable de tecnologías]
Cual es el objetivo de TANTO código nuevo
Quitarte boilerplate de encima, básicamente.
¿Que cualquier programador lo podría hacer a mano sin ningún framework? Claro, y muchos a los que un framework se les queda corto lo siguen haciendo a mano, pero igual que cualquier mecánico podría abrir el capó del coche, desmontar el motor, mirar dentro y decir "ah, está fallando este pistón", es mucho más cómodo enchufar un portátil y pasar un diagnóstico.
Pues con esto lo mismo, si sólo necesito una aplicación MVC CRUD para qué voy a complicarme la vida y perder tiempo en implementar conectividad con base de datos y liarme con el driver jdbc si sólo con importar Spring me sobra.
#68Kaledros:Quitarte boilerplate de encima, básicamente.
Luego toda la mierda nueva es al final más y más boilerplate. xD
#69 Riete tú de todas las configuraciones que había que hacer con Spring 3, te pasabas más tiempo configurando que programando.
#71 No, me refiero a que con el tiempo esas cosas nuevas que paran tan limpias y tan fáciles se vuelven monstruos inmantenibles. En mi empresa tenemos algún que otro proyecto del que mi encargado se está pensando empezar de 0 porque el que estaba aquí decidió hacer de early adopter en su día y ahora es un monstruo xD
Es bastante normal leer que X librería o tecnología se ha reescrito de 0 en una nueva versión
#72 Ya, pero eso es una cagada al diseñar la aplicación, no culpa del framework (y sí, yo también he visto alguno de esos y es para meterles fuego y no mirar atrás). Por eso decía antes que mucha gente implementa sus propias soluciones, porque Spring (o el framework que sea) se queda corto para según qué proyectos grandes, pero si lo que quieres es un microservicio que exponga una API y consulte a una base de datos te facilita el 70% del trabajo.
#73 en qué sentido se puede quedar corto spring, o el framework que sea, en qué proyectos? Cuál es el contexto? Lo he escuchado muchas veces pero nunca he escuchado ningún motivo al respecto.
#76 Supongo que en targets muy específicos, como proyectos de ML, por ejemplo. Aunque claro, para un proyecto de ese tipo para que coño escogerías Spring como tecnología.
Realmente, dentro del ámbito empresarial, nunca he visto que Spring pueda quedarse corto. Que se decida usarlo o no atiende más a preferencias propias del equipo o a los requisitos del cliente; pero razones técnicas estoy como tú, nunca he escuchado ninguna.
Supongo que en targets muy específicos, como proyectos de ML
a ver claro, si quieres programar drivers o firmware, por ejempplo, spring poco hace ahí, pero si necesitas un sistema basado en servicios no entiendo en qué momento se te puede quedar corto un framework mvc/rest o toolkits modulares o como lo quieras llamar
hace x años imagino que podría pasar porque veo spring 3 o versiones viejas de .net y xd
#76 Releyéndome veo que "quedarse corto" está mal dicho, debería haber dicho "no ser lo más adecuado".
En mi experiencia, si un proyecto va a tener un ciclo de vida largo (se va a actualizar durante años con módulos nuevos, funcionalidades, otros proyectos basados en él, etc) va a ser un dolor migrar de una versión de Spring a otra, sobre todo si por el camino se han deprecado cosas, y a la larga es más viable "perder" tiempo en hacerte un framework propio que se adapte a tus necesidades (igual que muchas empresas de videojuegos hacen su motor en vez de usar uno de terceros).
Y bueno, porque debugar en Spring es un horror XDD
Vamos a ver gente, no todos los frameworks valen para todo.
Tengo entendido que, por ejemplo, tener un macroproyecto en React, es una basura inmantenible. Angular por ejemplo es más capaz para esos casos, pero a su vez, es mucho peor para proyectos pequeños, donde usar Angular no sólo es un overkill, sino que probablemente haga más mal que bien al poner demasiadas capas de complejidad para un proyecto simple.
Lo que (espero) que no me andéis defendiendo, es que un proyecto 100% limpio de frameworks vaya a ser necesariamente mejor que un proyecto que sí los tiene. No me quiero imaginar mi proyecto actual, por ejemplo, hecho con Cordova + html/css/js a pelo. Eso sí que podría ser una basura inmantenible con chorrocientosmil ficheros, mil problemas para handlear rutas y requests, muchísimos cachos de código repetidos, problemas para encapsular determinadas funcionalidades... vamos hombre, yo al menos tengo claro que para proyectos algo grandes, es mejor usar Angular que ir a pelo.
Y me imagino que a nivel de backend podríamos decir lo mismo. Un proyecto Java EE con servlets ahí a pelo a lo loco puede estar muy bien para algo que tiene un par de entrypoints y ya, pero como no te metas un framework MVC por encima, a nada que crezca el número de páginas y entrypoints, vas a terminar con un churro difícil de mantener. O lo mismo un proyecto que tenga Node al que no le metas Typescript y Express... como mínimo xDDDD, preferiblemente metiendo Parse, Leafly o algo por el estilo.
Yo creo que la gracia está en saber determinar cuándo un proyecto va mejor con algo simplón, y cuándo es necesario meter morralla. Es cierto que los frameworks ensucian mucho y añaden capas de complejidad a menudo sobrantes, pero no olvidemos que para proyectos complejos, son una ayuda cojonuda. Volviendo al ejemplo de la app que estoy haciendo ahora, no me quiero imaginar tener que hacer todo el back sin tener una herramienta como Parse. Es una herramienta por la que tengo amor-odio, porque me da problemas a veces y tiene ciertas complejidades que son un poco feíllas a mi gusto, pero si tuviera que hacer todo eso a mano (autentificación, capas de acceso a objetos, ACL, live queries, cloud hooks, cloud jobs, dashboard visual para la bbdd...), pues estaría bien jodido.
