…open source]. JetBrains ha publicado los resultados de su más reciente encuesta anual en la que examinan en estado del ecosistema de desarrollo actual encuestando a miles de programadores alrededor del mundo
#6 Una moda que lleva mas de 20 años en sistemas "como unix" con núcleo linux.
Hoy día todo administrador, sysop, etc.. debe conocerlo porque infinidad de herramientas y librerías del sistema base "como unix" están realizadas en python. Como lenguaje de scripts no tiene competencia y su portabilidad es insuperable.
Igualmente para pruebas de concepto es una de las herramientas mas productivas.
En el campo científico y estadístico, gracias a sus librerías esta ganando una tremenda reputación.
Evidentemente no es perfecto y el rendimiento de las aplicaciones sin utilizar módulos en C es pobre. Tipos dinámico.... etc, etc...
#1 Los que están sobrevalorados son los "webdevelopers" Python y sobre todo los "datascientist" Python.
Un lenguaje cojonudo, probablemente lo puto mejor que se ha hecho en computación los últimos 30 años, por encima de Java en mil cosas (y más antiguo que Java, algo que muy poca gente sabe), fácil de aprender y rápido de usar. Evidentemente no sirve para absolutamente todo (es demasiado lento para tratamiento de determinados datos en tiempo real) pero resuelve millones de proyectos en tiempo récord y de forma estable, segura, mantenible y duradera. Cosa que no se puede decir de muuuuchos otros lenguajes.
Python hizo fácil lo difícil, cosa que prácticamente ningún otro lenguaje ha hecho.
Ahora bien, hay programadores no ya mediocres sino directamente malos e inútiles que no saben programar ni tienen noción alguna de patrones de diseño, de cómo testear un proyecto, de cómo aprovecharte del potencial de una buena base de datos SQL... y que por consiguiente hacen puta mierda que revienta por los cuatro costados. Esa gente inútil es la que luego te dice "Python es una mierda porque fíjate qué lento es", después de haber escrito el muy cerdo 5 bucles for anidados con consultas a base de datos y construcción de listas y diccionarios en todos ellos para resolver algo que yo envío a la base de datos con una simple consulta JOIN. Son esos mismos guarros que luego te "solucionan" el "problema" de que Python es "muy lento" metiendo a tu empresa en un contrato con MongoDB, el mayor montón de mierda creado para almacenamiento de datos en los últimos 100 años lo menos.
Así que no, Python no está sobrevalorado. Quienes sí lo están son cientos de miles de "webdevelopers" y "datascientists" que vienen con su cursito de Udemy hecho y los ponen a hacer aplicaciones para las que no tienen conocimientos suficientes, ni nunca los tendrán porque sólo saben leer Hacker News e instalar la fumada de la semana en la empresa "a ver si así va más rápido". Y de esta gente hay en todas partes: España, Alemania, USA, Rusia, ...
En cuanto a Jetbrains, sinceramente las demás alternativas es que ni las miro. Sólo Visual Studio (el de verdad, el de pago, el de C++) está a la altura del pepinazo de herramientas que son todos los productos de Jetbrains. Las alternativas libres son un chiste en comparación, eso lo sabe cualquiera que haya tenido que programar en Java, Python o C++ cualquier cosa más que un "Hola Mami".
Python es una moda. Pasará. Dice que todos quieren aprenderlo pero no saben ni para qué. Mucha noticia flipada de IA mágica y la peña se cree que va a crear Skynet y Matrix escribiendo con gafas de sol mientras Trinity le hace un masaje.
La encuesta tiene muchos meses ya. Llevo meses leyendo lo mismo. Sino lo mismo casi, veo un claro intento de manipulación.
Creo que Python es una profecía auto-cumplida: si todos creemos que será el lenguaje del futuro, lo será.
Personalmente, no me parece mal que sea así, porque aunque tiene carencias, me parece bastante digno. Lo que necesitamos hoy en día es tender hacia un lenguaje "central" que conozcamos todos, aunque para usos especializados siempre existan otros. Es insostenible lo que está pasando ahora, que si una persona quiere entrar en el mundo de la programación, no se le pueda recomendar un lenguaje con una mínima previsión de continuidad. Tiene que haber uno, y si tiene que ser Python que lo sea.
#10 ultimamente estoy enamorado de "visual studio code" (que no tiene nada que ver con el visual studio de toda la vida) es lo mas cercano a tener un ide completo sin sentir que llevas un tanque encima. Luego hay editores de texto como sublime que pueden funcionar bien con los complementos adecuados, pero me sigo quedando con vsc.
Python es fácil, lo que hay que aprender es lo que hay detrás: ciencia de datos, automatización, desarrollo web, lo que sea. Es como lo de que los programadores cobol ganan todos sueldos de 6 cifras. No es por programar en cobol, que es un lenguaje trivial, sino por conocer arquitecturas mainframe, buenas prácticas de procesamiento batch, etc. Así que si, ahora hay muy buenos trabajos que requieren python, pero esa no es la parte importante del trabajo.
#8 ctrl+K, ctrl+D en mi Visual Studio, y te formatea el documento actual, tabulaciones incluidas. Pero si alguna parte no quiero formatearla por el motivo que sea, compila.
#5 soy el primero al que no le gustan los tabuladores como marcadores de ámbito, pero la realidad es totalmente contraria a lo que tú dices. Python usa tabuladores precisamente para obligar a los programadores a tabular bien el código y que este sea más legible.
Y por poner la puntilla, por supuesto que se ven los tabuladores, que sean representados por los IDEs y editores de texto como espacios en blanco no significa que no se vean, para la vista humana son espacios horizontales, y para la máquina es el carácter "t".
#12 Porque en el reino de los ciegos el tuerto es el rey. ¿Habiendo sido torturados durante décadas con esos lenguajes de shell, cshell, bash etc quien no ve a python como cristo salvador? Pero para hacer cosas mas complejas que borrar archivos caducados no mola mucho.
#13 Yo uso Visual Studio a diario y que vaya a 32 o 64 bits es algo que me da absolutamente igual.
Eso de que va lento y es inestable... igual es que usas los complementos que no debes como "Resharper" que se come la ram de tu equipo y a día de hoy no aporta una mierda a los atajos de serie de VS, por cierto también es de JetBrains.
He programado en c, c++, visual basic, python, PHP, JavaScript, matlab, Scala y en lenguajes específicos para autómatas......
Esta claro que todo depende del contexto que se requiere ( hay muchos) y creo que de todos python es el más flexible y completo. Lo cierto es que una vez que el volumen de datos ha aumentado también han crecido los sistemas basados en python precisamente por su versatilidad. No es el mejor para todos los tipos de proyectos, pero es el único bueno en casi todos los casos.
#100el que tira mucho de JOIN sabe mucho de SQL pero ni tiene ni puta idea de BD
Pues imagínate la puta idea que tendrá el menda que lo mete todo en una "document database" y luego me escribe 5 for loops en el código para resolver una consulta.
Confundes "eficiencia en consultas" con "diseño de base de datos". Claro que un Join te puede tumbar la app, pero eso es si la BD está mal diseñada o si la consulta está mal hecha.
#100 Entiendo que te refieres al modelo relacional, el más típico. La operación de unión es básica en el modelo relacional. Más que prescindir de ella, lo que hay que hacer es hacerla bien: el tipo de join que corresponde, cuando corresponde, como corresponde y con los campos que corresponde. Esto incluye que los campos estén indexados si corresponde.
Por lo que dices, entiendo que planteas la alternativa de subconsulta, múltiples consultas u otras soluciones. Si analizas el plan de ejecución, verás que muchas veces da igual cómo escribas la consulta, el motor de base de datos genera el mismo plan -que incluye joins- sin importar qué alternativa hayas elegido. Otras veces la forma en que escribes la consulta sí modifica el plan y existen unas formas más eficientes de hacerlo que otras -especialmente en consultas complejas-, pero esto no puede generalizarse porque cada sistema es distinto y hay que analizarlo al detalle para encontrar la forma más eficiente.
Si, por el contrario, estás hablando de otros modelos de datos (documentales, grafos, etc) entonces te doy la razón en que el join es una operación "artificial" en dichos modelos, que se ha incluído probablemente por la prevalencia del relacional, y no siempre es eficiente.
#6 No es tan fácil. El ecosistema que tiene Python detrás es brutal. No hay ningún solo lenguaje de programación que pueda hacerle sombra ahora mismo. No hay ninguna alternativa.
(sin acentos)
Veo mucho sectarismo en general. Lenguajes, IDEs, frameworks, librerias... todo son herramientas y, el problema, es si uno se obceca en usar un martillo para todo o bien cree que la navaja suiza es la herramienta definitiva.
En cuanto a IDEs (pero es que aplicaria a todo):
- Que estoy en un proyecto (o feature especifica) solo de Python, tengo el hardware adecuado y, por ejemplo, necesito usar un profiler? pues utilizo Pycharm.
- Que estoy en un proyecto (o feature especifica) con TypeScript, Vue.js (y Python)? pues utilizo VS Code.
- Que quiero testear rapidamente un smart contract en Solidity, pues utilizo Remix online o VS Code.
No se, son solo ejemplos de adaptacion al proyecto/objetivo.
Deberiamos de estar agradecidos de la cantidad de recursos open source y/o gratuitos de los que disponemos a dia de hoy.
#79"Son esos mismos guarros que luego te "solucionan" el "problema" de que Python es "muy lento" metiendo a tu empresa en un contrato con MongoDB, el mayor montón de mierda creado para almacenamiento de datos en los últimos 100 años lo menos."
#142 Otro que no pasa la entrevista. Fuera de aquí, coño, no me hagas llamar al segurata. Y vuelve a dejar esa calderilla en el cenicero de la entrada, que he visto cómo te la guardabas, sinvergüenza.
#23 Bueno, pero tus problemas son una particularidad del desarrollo que haces. Yo hago aplicaciones webs y a mí me va todo perfectamente y desde que desterré el Resharper más.
#13 De Visual Studio no hablo, pero del VS Code, ojito... Estoy convencido que le ha tenido que quitar un buen bocado a IntelliJ. En cualquier caso IntelliJ sigue siendo el mejor IDE para lenguajes de JVM, sobre todo con la versión Ultimate, la Community... ñe
Filosofía de python: Haz lo que te de la gana, es muy potente. Si te dicen que mires el código de otra persona, huye, que la otra persona habrá hecho lo que le ha dado la gana.
#23 Por lo que veo que escribes, me da que lo realmente inestable es lo que programas, a mí me funciona perfectamente y conozco a varios amigachos que también lo usan y va bin
#8 Pues yo tengo la teoría de que Python usa los tabuladores porque los paréntesis, llaves y corchetes ya los tenía pillados y no tenía otro separador disponible, y que lo de obligar a "tabular bien" es una excusa que se buscó a posteriori
#132 cierto por 90€ al año está versión personal. 53€ a partir del tercer año. Me parece un regalo para lo que ofrece.
Y si, si has estado suscrito al menos durante un año te dan una licencia perpetua para la versión con la que iniciaste el año de suscripción. Pero por menos de 4'5€ al mes me parece ridículo no querer pagarlo y conformarte con una versión obsoleta.
Como opción para almacenamiento de datos, Mongo lo tengo en el puesto 1394, exactamente 1390 puestos por detrás de "escribir en fichero en texto plano y leer puto fichero secuencialmente"
Python no es la panacea y para concurrencia a saco desde luego no es mi primera ni mi segunda opción, pero estoy harto de ver gente que me dice "Python es una mierda porque es muy lento" y luego vas a ver su código y lo último en tener la culpa es el lenguaje que han usado (Python) e incluso los muy subnormales reescriben un servicio en Go y sigue dando el mismo asco pero arañan un par de segundos y dicen "oh, era por culpa de Python quesques mulento". Malditos sean. Seguridad, porfavor, acompáñelos a la puerta, ya les mandaremos sus pertenencias y la foto de sus hijos del escritorio por DHL si acaso, gracias. Fuera de mi empresa porfavor, gracias.
#79 No soy programador pero muchos me han dicho que lo soy, por lo menos no me considero programador.
Cuando pregunto a alguien de mi equipo sobre los detalles exactos de un determinado cálculo “datascientist” o desarrollador, no saben contestarme con datos exactos. Siempre generalidades.
Como director general de la empresa, no quiero ningún dato que no entienda su fórmula exacta sobre cómo se calcula. Pero muchas otras empresas les da igual y presentan informes que no entienden, cuando pase algún problema serio no sabrán que tecla tocar.
Prefiero un programador señor (aunque me cueste mas de 4.000€ al mes en valencia) pero con criterio y control absoluto sobre todo lo desarrolla.
Solo es mi opinión, no significa que esté en lo correcto.
#8 y no está nada mal hasta que empizas a refactorizar, mover código de un sitio a otro, o directamente copias código de stackoverflow (tú también lo haces, no lo niegues) y falla porque algo no está bien tabulado.
No es una buena idea ni para un proyecto mediano. Como ya han comentado otros, los IDEs ayudan a tabular el código correctamente. Para eso están, y si pones una configuración adecuada, todo tu equipo de trabajo tabulará igual.
¿Es aquí donde salen las ofertas de empleo que piden expertos en mil lenguajes de programación?
Gilipollas, nadie es experto en mil lenguajes de programación, más vale que seas muy bueno en UNO, y que sea un lenguaje versátil, que toquetear varios como un borracho.
#79 bueno hombre, mongo puede ser muy util para segun que cosas. El problema es meterlo con calzador en bbdd que deberian ser relacionales, solo porque es nosql y eso es guay y blablabla
Python tiene la gran ventaja de que casi para cualquier cosa que se te ocurra suele ser la segunda/tercera mejor opcion (a menos que necesites concurrencia a saco, en cuyo caso...buena suerte )
#206 es que un buen (y un mal) programador lo suele ser en cualquier lenguaje que use. Y para que hacer un poco de autocritica con tu propio codigo si puedes echarle la culpa al lenguaje
Por que te gusta tan poco mongo? Quiero decir, mas alla de los problemas que tiene inherentemente por ser nosql.
#12 En el campo científico y estadístico R le está comiendo bastante terreno.
Lo peor de Python es que los mismos que empiezan una "investigación" pretenden crear también un producto final con lo que van obteniendo porque "como es el mismo lenguaje, es lo mismo" (frase real que he oído de un supuesto gurucillo de ciencia de datos), con el resultado de que el producto final es una mierda que va a pedales.
Luego se comparan los resultados de ese mismo proyecto pasado a Scala y...
Menudo argumento mas tonto, hay cosas mucho mas criticables en Python como concurrencia/GIL quel el hecho de usar tabuladores para indicar los contextos.
Lo de usar tabuladores/espacios para indicar los contextos es para que se prime el hecho de que el codigo sea leyible. Cualquien programador escribe codigo que entiendan los ordenadores, los buenos programadores escriben codigo que entiendan las personas
#250 Pues mira, ya que estamos, te cuento: mi mujer, doctora en simulación de proteinas en supercomputación, postdocs varios en varias universidades en Europa, etc., lo hace todo en python, y sus scripts dan (literalmente) pena. Lo que pasa es cuando algo se jode, me viene a mi preguntando que "por qué el script no va?" y no hay manera que entienda lo importante que es para la salud mental (almenos la mía) lo de hacer un método que haga una cosa, y que por cada pocas líneas haya un comentario explicando qué hacen esas líneas.
Lo jodido es que hemos intercambiado impresiones con compañeros de su curro... y todos hacen lo mismo No veas la que se lió cuando les explique que si a mi me llega una Pull Request con dicha mierda, les monto un cristo que o ellos o yo acabamos despedidos... porque es una puta vergüenza.
Hace años dímos un curso introductorio de debugging, profiling, optimización etc, para doctores y doctorandos en un proyecto europeo. Cada día les dábamos esqueletos de programas que ya tenían bugs, y dejamos el módulo de debugging para el final. Cuando llegamos les dije "Bien señores, cuantos errores habeis visto en vuestros códigos?" Se los miraron y no habían visto ni uno... pasamos el GDB y valgrind.... y lo encontraban gracioso... hasta que les dije que pensaran la cantidad de doctorados que se habrían dado con datos de simulación con errores... luego ya no les hizo tanta gracia, claro, alguno palideció y todo
#71 PHPStorm es de pago, y como bien dices no es barato. El primer años 200€, el segundo 160€ y a partir del tercer 120€, 10€ al mes. Lo normal es que sea la empresa que se haga cargo de este gasto, pero si no es el caso en mi opinión vale la pena pagar 10€ al mes por la que puede ser la herramienta más importante de mi trabajo.
Si no quieres pagar, una opción para tenerlo gratis, aunque no es legítima, es conseguir acceso a un email de alguna universidad, si tienes algún conocido que esté en la universidad y te haga el favor, es solo darse de alta en el programa "for Students" en la web de Jetbrains y te da un año de licencia de todos los IDEs
Yo que ya voy para talludito he programado profesionalmente en buen puñado de lenguajes. Desde Cobol a Python pasando por Visual Basic (pero el 6.0, eh!), php, C, C#, Scala, Go y mucho, mucho Java con Spring. Ahora me he pasado a Kotlin (en backend, que hay mucho Kotlin más allá de Android). Y si puedo no volveré a tocar Java ni con un palo. Kotlin es una puta maravilla. Si de verdad os gusta este oficio, deberías darle una oportunidad. Sobre todo los javeros. La interoperabilidad con Java es total, lo que te permite introducir Kotlin incluso en proyectos ya existentes sin apenas fricciones.
(Prometo que JetBrains no me paga ni un euro. Ya me gustaría a mí)
#25 yo reconozco que he usado poco VS, pero he tenido compañeros que lo han usado bastante y la opinión es la misma que la de #23, traga recursos de forma desmedida y da problemas e inestabilidad por todos lados. Y esto sumado a mi corta experiencia con él me lleva a descartarlo de plano. Además de que no es multiplataforma.
Lo poco que lo probé me bastó para ver que la gestión de Git de VS es una broma de mal gusto, nada intuitiva y le sobran 3/4 de los botones. La de IntelliJ y derivados por el contrario es lo mejor que he visto con diferencia. Dos simples botones para hacer push y pull, cuando hay conflictos te muestra a triple pantalla, por un lado tu fichero, por el otro el remoto y en medio el resultante, te permite cambiar fácilmente entre la vista de diferencias y ficheros completos, etc, etc. Una gozada.
Otra de las grandezas de los IDEs de Jetbrains es su gestión de bases de datos incorporada, con soporte para todos los sistemas de gestión de BBDD populares, soporte para backups, exportación de definiciones de tablas, etc, etc. Simplemente sublime.
#3 es puta magia, pruebalo, yo he pasado por C, C++, Java, C#, y he sufrido PL/SQL, COBOL, VB y mil mierdas más y puedo decir sin temor a equivocarme que Python es puta magia
#185 Tienes unas opiniones muy fuertes y haces unas afirmaciones exageradas en este tema, que no respaldas con ningún argumento.
El JOIN no es malo per se. ¿Cómo va a serlo siendo la base del modelo relacional? Piénsalo por un instante. El modelo relacional tampoco es malo. Ni está limitado a conjuntos de datos pequeños. ¿Cómo era el mundo antes de bases de datos NoSQL? ¿Un mundo de subconsultas? No demuestras tener mucho criterio.
#244 Si alguien necesita más pruebas para identificar que el problema no está en otro sitio más que en Contratación, es que merece también ser acompañado a la puerta por Seguridad junto con el developer
Pues eso lo he visto yo. Y los tíos diciendo que "mira cómo es culpa de Python, que al menos Go tarda X segundos menos". Luego dicen que suben los votos de Vox, siesque no me extraña
Cada vez que oigo un JOIN en una BD empiezo a afilar el hacha ..... no te digo que el JOIN no te puede sacar de algún problema de vez en cuando pero por lo general ... el que tira mucho de JOIN sabe mucho de SQL pero ni tiene ni puta idea de BD y cuando el conjunto de datos crece te revienta las máquinas.
#133 Yo te recomendaría que pensarás en lo qué quieres hacer más que en el lenguaje, que al final es una herramienta. Lo que nos pasa a muchos es que empezamos con el lenguaje que nos dicen que es más adecuado para principiantes (típicamente Python) pero nos acabamos quemando porque no entendemos cuando empezaremos a hacer algo "tangible". Si te gusta el desarrollo web, considera Javascript. Es muy versátil y casa bien con lo que sabes ahora mismo.
Otra cosa es que no te gusten los IDEs y prefieras un editor de textos por simplicidad y ligereza, pero eso ya son gustos.
IntelliJ tambien.
Hoy día todo administrador, sysop, etc.. debe conocerlo porque infinidad de herramientas y librerías del sistema base "como unix" están realizadas en python. Como lenguaje de scripts no tiene competencia y su portabilidad es insuperable.
Igualmente para pruebas de concepto es una de las herramientas mas productivas.
En el campo científico y estadístico, gracias a sus librerías esta ganando una tremenda reputación.
Evidentemente no es perfecto y el rendimiento de las aplicaciones sin utilizar módulos en C es pobre. Tipos dinámico.... etc, etc...
Un lenguaje cojonudo, probablemente lo puto mejor que se ha hecho en computación los últimos 30 años, por encima de Java en mil cosas (y más antiguo que Java, algo que muy poca gente sabe), fácil de aprender y rápido de usar. Evidentemente no sirve para absolutamente todo (es demasiado lento para tratamiento de determinados datos en tiempo real) pero resuelve millones de proyectos en tiempo récord y de forma estable, segura, mantenible y duradera. Cosa que no se puede decir de muuuuchos otros lenguajes.
Python hizo fácil lo difícil, cosa que prácticamente ningún otro lenguaje ha hecho.
Ahora bien, hay programadores no ya mediocres sino directamente malos e inútiles que no saben programar ni tienen noción alguna de patrones de diseño, de cómo testear un proyecto, de cómo aprovecharte del potencial de una buena base de datos SQL... y que por consiguiente hacen puta mierda que revienta por los cuatro costados. Esa gente inútil es la que luego te dice "Python es una mierda porque fíjate qué lento es", después de haber escrito el muy cerdo 5 bucles for anidados con consultas a base de datos y construcción de listas y diccionarios en todos ellos para resolver algo que yo envío a la base de datos con una simple consulta JOIN. Son esos mismos guarros que luego te "solucionan" el "problema" de que Python es "muy lento" metiendo a tu empresa en un contrato con MongoDB, el mayor montón de mierda creado para almacenamiento de datos en los últimos 100 años lo menos.
Así que no, Python no está sobrevalorado. Quienes sí lo están son cientos de miles de "webdevelopers" y "datascientists" que vienen con su cursito de Udemy hecho y los ponen a hacer aplicaciones para las que no tienen conocimientos suficientes, ni nunca los tendrán porque sólo saben leer Hacker News e instalar la fumada de la semana en la empresa "a ver si así va más rápido". Y de esta gente hay en todas partes: España, Alemania, USA, Rusia, ...
En cuanto a Jetbrains, sinceramente las demás alternativas es que ni las miro. Sólo Visual Studio (el de verdad, el de pago, el de C++) está a la altura del pepinazo de herramientas que son todos los productos de Jetbrains. Las alternativas libres son un chiste en comparación, eso lo sabe cualquiera que haya tenido que programar en Java, Python o C++ cualquier cosa más que un "Hola Mami".
La encuesta tiene muchos meses ya. Llevo meses leyendo lo mismo. Sino lo mismo casi, veo un claro intento de manipulación.
Personalmente, no me parece mal que sea así, porque aunque tiene carencias, me parece bastante digno. Lo que necesitamos hoy en día es tender hacia un lenguaje "central" que conozcamos todos, aunque para usos especializados siempre existan otros. Es insostenible lo que está pasando ahora, que si una persona quiere entrar en el mundo de la programación, no se le pueda recomendar un lenguaje con una mínima previsión de continuidad. Tiene que haber uno, y si tiene que ser Python que lo sea.
Y por poner la puntilla, por supuesto que se ven los tabuladores, que sean representados por los IDEs y editores de texto como espacios en blanco no significa que no se vean, para la vista humana son espacios horizontales, y para la máquina es el carácter "t".
Eso de que va lento y es inestable... igual es que usas los complementos que no debes como "Resharper" que se come la ram de tu equipo y a día de hoy no aporta una mierda a los atajos de serie de VS, por cierto también es de JetBrains.
Esta claro que todo depende del contexto que se requiere ( hay muchos) y creo que de todos python es el más flexible y completo. Lo cierto es que una vez que el volumen de datos ha aumentado también han crecido los sistemas basados en python precisamente por su versatilidad. No es el mejor para todos los tipos de proyectos, pero es el único bueno en casi todos los casos.
Pues imagínate la puta idea que tendrá el menda que lo mete todo en una "document database" y luego me escribe 5 for loops en el código para resolver una consulta.
Confundes "eficiencia en consultas" con "diseño de base de datos". Claro que un Join te puede tumbar la app, pero eso es si la BD está mal diseñada o si la consulta está mal hecha.
Por lo que dices, entiendo que planteas la alternativa de subconsulta, múltiples consultas u otras soluciones. Si analizas el plan de ejecución, verás que muchas veces da igual cómo escribas la consulta, el motor de base de datos genera el mismo plan -que incluye joins- sin importar qué alternativa hayas elegido. Otras veces la forma en que escribes la consulta sí modifica el plan y existen unas formas más eficientes de hacerlo que otras -especialmente en consultas complejas-, pero esto no puede generalizarse porque cada sistema es distinto y hay que analizarlo al detalle para encontrar la forma más eficiente.
Si, por el contrario, estás hablando de otros modelos de datos (documentales, grafos, etc) entonces te doy la razón en que el join es una operación "artificial" en dichos modelos, que se ha incluído probablemente por la prevalencia del relacional, y no siempre es eficiente.
Veo mucho sectarismo en general. Lenguajes, IDEs, frameworks, librerias... todo son herramientas y, el problema, es si uno se obceca en usar un martillo para todo o bien cree que la navaja suiza es la herramienta definitiva.
En cuanto a IDEs (pero es que aplicaria a todo):
- Que estoy en un proyecto (o feature especifica) solo de Python, tengo el hardware adecuado y, por ejemplo, necesito usar un profiler? pues utilizo Pycharm.
- Que estoy en un proyecto (o feature especifica) con TypeScript, Vue.js (y Python)? pues utilizo VS Code.
- Que quiero testear rapidamente un smart contract en Solidity, pues utilizo Remix online o VS Code.
No se, son solo ejemplos de adaptacion al proyecto/objetivo.
Deberiamos de estar agradecidos de la cantidad de recursos open source y/o gratuitos de los que disponemos a dia de hoy.
Grandes palabras.
El problema no es pasar a Python 3, sino si en algún momento tendrás que actualizar todo a Python 4.
He visto a IntelliJ cargar proyectos que eclipsarían a Eclipse.
Así sí.
Y si, si has estado suscrito al menos durante un año te dan una licencia perpetua para la versión con la que iniciaste el año de suscripción. Pero por menos de 4'5€ al mes me parece ridículo no querer pagarlo y conformarte con una versión obsoleta.
sales.jetbrains.com/hc/en-gb/articles/207240845-What-is-perpetual-fall
cc #71
Como opción para almacenamiento de datos, Mongo lo tengo en el puesto 1394, exactamente 1390 puestos por detrás de "escribir en fichero en texto plano y leer puto fichero secuencialmente"
Python no es la panacea y para concurrencia a saco desde luego no es mi primera ni mi segunda opción, pero estoy harto de ver gente que me dice "Python es una mierda porque es muy lento" y luego vas a ver su código y lo último en tener la culpa es el lenguaje que han usado (Python) e incluso los muy subnormales reescriben un servicio en Go y sigue dando el mismo asco pero arañan un par de segundos y dicen "oh, era por culpa de Python quesques mulento". Malditos sean. Seguridad, porfavor, acompáñelos a la puerta, ya les mandaremos sus pertenencias y la foto de sus hijos del escritorio por DHL si acaso, gracias. Fuera de mi empresa porfavor, gracias.
Cuando pregunto a alguien de mi equipo sobre los detalles exactos de un determinado cálculo “datascientist” o desarrollador, no saben contestarme con datos exactos. Siempre generalidades.
Como director general de la empresa, no quiero ningún dato que no entienda su fórmula exacta sobre cómo se calcula. Pero muchas otras empresas les da igual y presentan informes que no entienden, cuando pase algún problema serio no sabrán que tecla tocar.
Prefiero un programador señor (aunque me cueste mas de 4.000€ al mes en valencia) pero con criterio y control absoluto sobre todo lo desarrolla.
Solo es mi opinión, no significa que esté en lo correcto.
No es una buena idea ni para un proyecto mediano. Como ya han comentado otros, los IDEs ayudan a tabular el código correctamente. Para eso están, y si pones una configuración adecuada, todo tu equipo de trabajo tabulará igual.
Pero vamos, por lo general las máquinas de bbdd están muettas del asco en comparación con los servidores de aplicaciones
Gilipollas, nadie es experto en mil lenguajes de programación, más vale que seas muy bueno en UNO, y que sea un lenguaje versátil, que toquetear varios como un borracho.
¡blasfemo! ¡lávate la boca antes de hablar de ksh (y de su copia amariconada, bash)!
Python tiene la gran ventaja de que casi para cualquier cosa que se te ocurra suele ser la segunda/tercera mejor opcion (a menos que necesites concurrencia a saco, en cuyo caso...buena suerte
Por que te gusta tan poco mongo? Quiero decir, mas alla de los problemas que tiene inherentemente por ser nosql.
Lo peor de Python es que los mismos que empiezan una "investigación" pretenden crear también un producto final con lo que van obteniendo porque "como es el mismo lenguaje, es lo mismo" (frase real que he oído de un supuesto gurucillo de ciencia de datos), con el resultado de que el producto final es una mierda que va a pedales.
Luego se comparan los resultados de ese mismo proyecto pasado a Scala y...
Empezando por los gestores de paquetería y pasando por virtualizacion, nubes, etc... python es el mas utilizado como scripts de sistemas
APT está escrito en Perl, hablando de Ubuntu. En OpenBSD pkg_add está escrito en Perl. De hecho hay scripts para compilar Linux que dependen de Perl.
Buena suerte.
Lo de usar tabuladores/espacios para indicar los contextos es para que se prime el hecho de que el codigo sea leyible. Cualquien programador escribe codigo que entiendan los ordenadores, los buenos programadores escriben codigo que entiendan las personas
Lo jodido es que hemos intercambiado impresiones con compañeros de su curro... y todos hacen lo mismo
Hace años dímos un curso introductorio de debugging, profiling, optimización etc, para doctores y doctorandos en un proyecto europeo. Cada día les dábamos esqueletos de programas que ya tenían bugs, y dejamos el módulo de debugging para el final. Cuando llegamos les dije "Bien señores, cuantos errores habeis visto en vuestros códigos?" Se los miraron y no habían visto ni uno... pasamos el GDB y valgrind.... y lo encontraban gracioso... hasta que les dije que pensaran la cantidad de doctorados que se habrían dado con datos de simulación con errores... luego ya no les hizo tanta gracia, claro, alguno palideció y todo
Si no quieres pagar, una opción para tenerlo gratis, aunque no es legítima, es conseguir acceso a un email de alguna universidad, si tienes algún conocido que esté en la universidad y te haga el favor, es solo darse de alta en el programa "for Students" en la web de Jetbrains y te da un año de licencia de todos los IDEs
(Prometo que JetBrains no me paga ni un euro. Ya me gustaría a mí)
Lo poco que lo probé me bastó para ver que la gestión de Git de VS es una broma de mal gusto, nada intuitiva y le sobran 3/4 de los botones. La de IntelliJ y derivados por el contrario es lo mejor que he visto con diferencia. Dos simples botones para hacer push y pull, cuando hay conflictos te muestra a triple pantalla, por un lado tu fichero, por el otro el remoto y en medio el resultante, te permite cambiar fácilmente entre la vista de diferencias y ficheros completos, etc, etc. Una gozada.
Otra de las grandezas de los IDEs de Jetbrains es su gestión de bases de datos incorporada, con soporte para todos los sistemas de gestión de BBDD populares, soporte para backups, exportación de definiciones de tablas, etc, etc. Simplemente sublime.
El JOIN no es malo per se. ¿Cómo va a serlo siendo la base del modelo relacional? Piénsalo por un instante. El modelo relacional tampoco es malo. Ni está limitado a conjuntos de datos pequeños. ¿Cómo era el mundo antes de bases de datos NoSQL? ¿Un mundo de subconsultas? No demuestras tener mucho criterio.
Pues eso lo he visto yo. Y los tíos diciendo que "mira cómo es culpa de Python, que al menos Go tarda X segundos menos". Luego dicen que suben los votos de Vox, siesque no me extraña
xkcd.com/378/
Cada vez que oigo un JOIN en una BD empiezo a afilar el hacha ..... no te digo que el JOIN no te puede sacar de algún problema de vez en cuando pero por lo general ... el que tira mucho de JOIN sabe mucho de SQL pero ni tiene ni puta idea de BD y cuando el conjunto de datos crece te revienta las máquinas.
Si una JOIN te tira la DB la culpa es la JOIN y de quien la hizo, no de la BD.
O optimizar la BD para la JOIN añadiendo lo que haga falta o no a hagas ... pero no le eches la culpa a la BD porque un idiota no sabe lo que hace.