Portada
mis comunidades
otras secciones
#3:
El equipo de Python, que operaba desde Sunnyvale (California), tenía menos de diez miembros
Dudo mucho que el "equipo de Python de Google" tenga menos de 10 miembros. Menuda gilipollez de noticia clickbait de mierda. Genbeta en su línea subnormaloide, para variar.
Dudo mucho que el "equipo de Python de Google" tenga menos de 10 miembros. Menuda gilipollez de noticia clickbait de mierda. Genbeta en su línea subnormaloide, para variar.
#1:
Eso es que su IA ya programa mejor en python que los sacos de carne y huesos
#25:
#c-13" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/13">#13 he programadp c# durante 8 años y llevo otros 8 programando proyectos de gran escala en python.
Python es un arma de doble filo. Por un lado su sintaxis es mucho menos verbosa, aparte de que el hecho de que sea un lenguaje dinámico te permite tomar ciertos atajos y aplicar ciertos patrones que no serían posibles o tan triviales con lenguajes estáticos como Java o C#. De hecho considero que soy mucho mejor y más rápido programando con python que con C# ya que me permite centrarme más en el dominio que en la sintaxis.
Por otro lado esa libertad es su maldición. Si no sabes lo que haces, en equipos grandes sin una buena disciplina de anotaciones y testing acabas teniendo un proyecto superacoplado e ilegible con miles de referencias circulares, y con hetereogeneidad en el estilo de programar, por muchas herramientas de corrección de estilo que uses.
Te recomiendo el libro de Oreilly "Python architecture" (tiene una serpiente en su portada).
Python es un arma de doble filo. Por un lado su sintaxis es mucho menos verbosa, aparte de que el hecho de que sea un lenguaje dinámico te permite tomar ciertos atajos y aplicar ciertos patrones que no serían posibles o tan triviales con lenguajes estáticos como Java o C#. De hecho considero que soy mucho mejor y más rápido programando con python que con C# ya que me permite centrarme más en el dominio que en la sintaxis.
Por otro lado esa libertad es su maldición. Si no sabes lo que haces, en equipos grandes sin una buena disciplina de anotaciones y testing acabas teniendo un proyecto superacoplado e ilegible con miles de referencias circulares, y con hetereogeneidad en el estilo de programar, por muchas herramientas de corrección de estilo que uses.
Te recomiendo el libro de Oreilly "Python architecture" (tiene una serpiente en su portada).
#13:
Pero .. a ver, y no quiero que me caigan las collejas... Python siempre me ha parecido un poco como Basic en los 80. Es practico, pero es simple. Es ... como un Bash, pero con mas chorradas. Lo empeze a usar para asuntos de pen-test, pero cuando lo empece a ver en ML y Data Science, no se, es muy util por Pandas, NumPy, pero he estado en proyectos con miles de clases en Java, y Python no tiene la semantica para manejar esa complejidad, o yo no la he visto, o quizas no la necesita porque tienen cosas como los Jupyter.
Pero me he leido algunos libros como "Object Oriented Python", pero no da la talla para sistemas muy complejos. Y eso que Java es una version capada de C++. Un lenguaje que no puedes ver las interfaces en un .H.
Agradezco libros y referencias en contra de mi argumento.
Pero me he leido algunos libros como "Object Oriented Python", pero no da la talla para sistemas muy complejos. Y eso que Java es una version capada de C++. Un lenguaje que no puedes ver las interfaces en un .H.
Agradezco libros y referencias en contra de mi argumento.
#38:
#6 De hecho tienes razón. En una operación interna en 2019 echaron a Ben Gomes, el anterior jefe de buscador de Google, para reemplazarlo por Prabhakar Raghavan, que se empeñó en mezclar más la publicidad con las búsquedas (primando el beneficio y el spam sobre la usabilidad y la experiencia de usuario) y con el que desde entonces el buscador está empeorando a pasos agigantados. Pero es que Prabhakar Raghavan estuvo años antes en Yahoo en un puesto equivalente, que terminó de hundir su buscador.
Más info en inglés. Es interesante porque explica también el papel en esta historia de una consultora como McKinsey adicta a los despidos:
https://www.wheresyoured.at/the-men-who-killed-google/
Más info en inglés. Es interesante porque explica también el papel en esta historia de una consultora como McKinsey adicta a los despidos:
https://www.wheresyoured.at/the-men-who-killed-google/
#10:
#7 https://xkcd.com/2347/
Esto siempre me hace descojonarme, porque encima es mas verdad con cosas mas antiguas que nadie sabe que van a petar en algun momento.
Esto siempre me hace descojonarme, porque encima es mas verdad con cosas mas antiguas que nadie sabe que van a petar en algun momento.
#22:
#11 Ha sido una decisión empresarial, la idea es que tengas que hacer más búsquedas para encontrar lo que necesitas y así tener más oportunidades para mostrarte anuncios...
https://www.wheresyoured.at/the-men-who-killed-google/
https://www.wheresyoured.at/the-men-who-killed-google/
#24:
#9 El “too big to fail” era más una abreviatura de “too big to let them fail” ya que estábamos obligados a rescatarlos ya que su quiebra podía colapsar nuestras sociedades. Nos vendieron esa moto para rescatar los bancos, pero era mentira. Google caerá, como en su momento cayeron otras empresas, y no pasará nada.
#6:
Cuanto hace que Google no saca un producto con impacto?
Cada vez huele más a Yahoo.
Cada vez huele más a Yahoo.
Comentarios
El equipo de Python, que operaba desde Sunnyvale (California), tenía menos de diez miembros
Dudo mucho que el "equipo de Python de Google" tenga menos de 10 miembros. Menuda gilipollez de noticia clickbait de mierda. Genbeta en su línea subnormaloide, para variar.
#3 El equipo que gestiona el python interno de google. Con sus parches, sus librerias, ...
Despues hay miles que usan ese python en google.
#7 https://xkcd.com/2347/
Esto siempre me hace descojonarme, porque encima es mas verdad con cosas mas antiguas que nadie sabe que van a petar en algun momento.
#10 En nodejs un desarrollador de una libreria en npm se cabreo y dec idio borrar su proyecto. Esa libreria era muy tonta pero la usaba todo el mundo. Todos los deployments a nivel mundial empezaron a fallar.
#15 Eso me pilló en la ofi y menudo día nos pasamos! no podíamos hacer build de nuestro proyecto. Lo bueno que no teníamos ningún deployment programado.
https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
#15 https://www.explainxkcd.com/wiki/index.php/2347:_Dependency
Siempre me acuerdo de esta tira.
Me acuerdo que cuando el log4j, les propuse a mi empresa que hicieramos un fork y lo mantuvieramos nosotros por lo menos parcialmente o que nos dejaran contribuir. Pues no... .
#3 Oye, un respeto a Genbeta, que se han esmerado en meter la IA de forma forzada en la noticia cuando no tiene nada que ver.
#3 Igual deberías leer la noticia. Así como idea loca.
Eso es que su IA ya programa mejor en python que los sacos de carne y huesos
#1 ¡qué programen las IA!
#2 y que gobiernen pronto...
#4 ya buscan defraudadores de hacienda.
#5 IAs inspectoras de Hacienda persiguiendo a las IAs defraudadoras
#1 pues con lo hijos de puta que son, me apuesto la polla a que es por eso
#1 No es cuestión de si programan mejor o peor (ya te digo yo que aún no nos mejoran). Las IA necesitan programadores que verifiquen e integren el código y eso puede ser más barato que pagar a un ingeniero y su equipo por hacer todo. El tema es que se busca mano de obra más barata. ¿Por qué pagarle 200k /año a un ingeniero de EEUU, más lo que cobre su equipo, cuando le puedes pagar 10k /año a un equipo de Bangladesh?
El tema es ese: abaratar costes. Y la manera más común que se conoce de incrementar la facturación es abaratando costes y, para la empresa, los salarios son coste.
Pero .. a ver, y no quiero que me caigan las collejas... Python siempre me ha parecido un poco como Basic en los 80. Es practico, pero es simple. Es ... como un Bash, pero con mas chorradas. Lo empeze a usar para asuntos de pen-test, pero cuando lo empece a ver en ML y Data Science, no se, es muy util por Pandas, NumPy, pero he estado en proyectos con miles de clases en Java, y Python no tiene la semantica para manejar esa complejidad, o yo no la he visto, o quizas no la necesita porque tienen cosas como los Jupyter.
Pero me he leido algunos libros como "Object Oriented Python", pero no da la talla para sistemas muy complejos. Y eso que Java es una version capada de C++. Un lenguaje que no puedes ver las interfaces en un .H.
Agradezco libros y referencias en contra de mi argumento.
#13 Python es para hacer juegetes...
Y scriptkids.
En IA se ha puesto de moda como interfaz para no programadores invoquen librerías C++ doble están realmente los algoritmos IA
#19 Puedes argumentar semejante parida quitándote el palillo de la boca o con ese comentario crees que es suficiente?
#20 En meneame hay mucho informático cuñao que se cree que sabe de todo cuando en realidad a duras penas saben de lo suyo.
#19 Sin poner el dial de "Faltonería" al máximo, como lo has puesto tú, podríamos decir que Python se usa como código pegamento entre bibliotecas binarias, y no estaríamos faltando a la verdad.
No es solo para eso, pero sí, es más un lenguaje de scripting (de sistemas, de IA, de utilidades), que de programación de sistemas (como podría ser C/C++, Rust, Zig, etc).
#19 Python no me gusta pero se ha comido a Perl en scripting de sistemas (por desgracia), y en ciencia de datos es impepinable.
Si quitaran la mierda esa de usar espacios en blanco como sintáxis le tendría más aprecio.
#30 ¿Te refieres a la indentación? Más que espacios en blanco se trata de una tabulación. A mi me parece menos cargante y más compacto que la infinidad de llaves que genera Java
#35 Soy más de common lisp; no tengo ese problema.
#35 Se pueden usar tanto espacios como tabuladores (sin mezclar).
PEP8 recomienda encarecidamente utilizar espacios -> https://peps.python.org/pep-0008/#tabs-or-spaces
#44 Si, pero si trabajas desde IDE/Jupyter no tiene mucho sentido indentar con espacios cuando con un golpe de tabulador lo tienes todo perfectamente estructurado.
#45 En IDLE o Jupyter nobsé, pero en otras IDE cuando le das al tabulador lo convierte en 2 ó 4 espacios, y al borrar, borra tales espacios. No me extrañaría que también lo hicieran esas IDE
#30 A mí la indentación obligatoria me parece una solución fácil e ideal para hacer legible el código y su estructura.
Ojalá todos los lenguajes obligaran a utilizar algo parecido. Se acabaría para siempre la tontería de perder el tiempo buscando bloques de código mal cerrados, o tener que dejarse los ojos interpretando código que visualmente está delimitado como el culo.
#52 Para copiar y pegar, o para usar editores para ciegos, es una pesadilla.
Que se lo digan al creador de edbrowse, ciego.
En el caso de otros, tienes gofmt que lo hace por tí.
Para mi Python es una porquería que rompe con muchas herramientas de Unix.
#67 Pues lo tienes bien jodido en herramientas Unix, si odias la organización por indentación. Intenta (por ejemplo) configurar una red a pelo, sin usar herramientas configuradas con YAML, y me cuentas cuán sencillo te resulta.
Por lo demás, que me digas que un lenguaje de programación es una porquería porque no está pensado para CIEGOS... ¿Tú no has dicho que te molaba LISP, cacho hipócrita, que es un millón de veces peor para ciegos y para todo el mundo?
Es más, si algo tienen los estándares de estilo Python es que intentan que el código sea aproximadamente legible en lenguaje natural. Tus ciegos deberían estar contentos, esas normas de estilo para humanizar la legibilidad no las tiene ningún otro lenguaje habitual.
¿Y qué demonios te impide copiar y pegar código en Python, si se puede saber? ¿Necesitas que alguien venga y pulse la tecla por ti para convertir tabs/espacios? Sabes además que permite usar diferente formato en diferentes módulos, ¿verdad?
#70 > ¿Tú no has dicho que te molaba LISP, cacho hipócrita, que es un millón de veces peor para ciegos y para todo el mundo?
Toma hostia mental que te has metido, pero de las gordas.
https://emacspeak.sourceforge.net/
Colega, el creador de Emacspeak (T.V. Raman) es ciego y el código es todo ELISP.
Manda cojones, siendo el software para ciegos por excelencia al lado de NVDA.
Con Paredit para Lisp en Emacs, T.V. Raman programa mejor que tú y yo juntos.
Y con Emacspeak puedes desde leer libros a programar, configurar el sistema, leer correos, webs y casi hasta hacer el desayuno.
https://tvraman.github.io/emacspeak/applications.html
Casi nada, oye. Desde calculadora con álgebra simbólica, a sudokus, correos, LaTeX, dictado a voz de fórmulas... nada, joder, no se puede hacer nada con Lisp y Emacspeak
Me has puesto el peor ejemplo de lejos.
#72 ¿Y qué cojones tiene que ver nada de eso con Python?
Hasta tu ciego de referencia te lleva la contraria, qué cosas.
Está claro que tú has venido a churrimerinear y a contar tu película. El tema del meneo y de la conversación te la sopla. Me parece genial, pero cuéntaselo a quien le interese.
-------
De paso, y aunque no venga a cuento de nada, todo tu comentario es un ”non sequitur” y una falacia que te cagas.
No sólo porque un programa hecho por un ciego no quita que LISP es de los peores lenguajes en cuanto a legibilidad (pero de calle), para ciegos y para videntes. Tu comentario viene a decir que una mosca que come mierda demuestra que la mierda está riquísima.
Pero lo que cuentas es una falacia sobre todo porque el invento que enlazas es sólo un servidor TTS para acceder a aplicaciones ya existentes. Toda la funcionalidad que has enumerado no la implementa ese proyecto, mentirosillo, son programas externos y por supuesto ya estaban accesibles desde emacs. Lo único que hace ese invento es tirar de TTS y STT para cosas que ya existen.
Además el proyecto incluye contribuciones de terceros a punta pala.
Y para postre ni de coña está todo en LISP. Gran parte del proyecto son gateways a aplicaciones externas programados en bash, e incluso JavaScript para node.
La única parte en LISP son los scripts para emacs, que no pueden programarse en otro lenguaje porque GNU emacs sencillamente no soporta otro. Vamos, que ese ”mérito” no es de tu ciego, que no pudo elegir lenguaje, sino de Richard Stallman que le obligó.
Como curiosidad, la documentación del proyecto (que no es una parte trivial, es para ciegos), se revisa en Python utilizando un guión en YAML.
Ojo, no le quito mérito al proyecto. Sólo constato que no es ni de coña lo que tú has descrito ni como tú lo has descrito. Y la presencia de LISP no sólo no se lleva el mérito como tú pretendes, sino que además es incidental.
Resumiendo, que has venido a hablar de tu libro sin venir a cuento de nada y encima mientes bastante (o no tienes ni idea de qué hablas, es otra opción).
#76 Yo no he mentido. El 70% del código de Emacs es Elisp, y Emacspeak como mucho llama debajo a Speech Dispatcher para dictado, y éste a Espeak, Flite, Festival. No usa Bash para nada.
Lo único que usa para Speech Dispatcher es para enviarle la cadena de texto de forma asíncrona.
De hecho ELisp soporta llamar a comandos externos via funciones Elisp, sin tocar la shell. El resto de módulos como Eww, Nov.el, Calc... son puro Elisp.
Lo sé por que he tocado SHR de Eww (navegador webs de Emacs) para convertir imágenes a Braille Art, ahí sí, con programas externos como ImageMagick, cosa que Emacs soporta de base para formatos que se salgan de PNG, Tiff, Webm, GIF, XPM y el resto de formatos no conocidos...
Es lo que tiene hablar sin tener ni puta idea, eh?
#82 Emacs fue elegido solamente por ser versátil como ejecutor de scripts y utilidades externas, un requerimiento del que ese proyecto no puede escapar. Ergo el uso de ELISP en dicho proyecto es meramente incidental. No fue elegido sino que vino impuesto por la herramienta necesaria.
Y deja ya de mentir.
”No usa Bash para nada”.
Pero mira las fuentes, mendrugo.
”ELisp soporta llamar a comandos externos via funciones”.
De hecho LISP no lo soporta. Sólo el dialecto de Emacs.
Ni siquiera sé qué quieres decir con eso. Cualquier lenguaje compilado y la mayoría de lenguajes interpretados incluyen esa prestación. Prácticamente todos los que permitan crear aplicaciones locales lo hacen. No es ninguna cualidad diferencial.
Pero es que encima para hacerlo en LISP necesitas Emacs. Vaya puta mierda, chico.
”Es lo que tiene hablar sin tener ni puta idea, eh?”
Pues sí, estás quedando como el culo. Porque no paras de repetir que tu invento hace maravillas cuando sólo es un puente entre Emacs y aplicaciones externas. Y para más guasa nadie eligió hacerlo en LISP, eso viene impuesto por Emacs. Fliparte como te estás flipando efectivamente es no tener ni puta idea.
Y toda tu película sigue sin tener NADA que ver con el tema de la conversación, que no ha dejado de ser Python. Tu paja mental es tremenda.
#83 Que lisp no puede? Comon lisp, maclisp en ITS...llamando a Emacs con (inf-mode) en un puto PDP10. O Macsyma a la impresora y hoy Maxima a Gnuplot.
Para no saber, solo estoy haciendo un cliente Gopher para Macsyma en ITS.
#87 Cada vez lo pintas peor. Ya no sólo necesitas usar como intérprete un editor de 100 megas, ahora además necesitas emuladores. Lo estás mejorando, ¿eh?
Te llaman de los años 90, que si vuelves para cenar.
Y por si no te das cuenta, la conversación en ningún momento iba de funcionalidades. Ninguna de las irrelevantes pajas que te estás montando borra el hecho de que LISP es y siempre ha sido un infierno tirando a ilegible, que era la cuestión que pretendías discutir de Python.
P.D.: Si te sigues yendo del tema para hablarme de chuminadas que sólo te interesan a ti y no vienen a cuento de nada, voy a empezar a pensar que te hacen muy poco casito en tu trabajo. Por cierto, ¿quién coño usa gopher hoy en día?
#88 Si la estás cagando... el Emacs de ITS era un ejemplo, y escrito en TECO, no Lisp. Ese Maclisp podía llamar a Emacs desde el REPL para editar cómodamente y evaluar de vuelta el resultado. GNU Emacs integró un Lisp tipo Maclisp y editor en una sola cosa, pero en C, 25%, el resto Elisp. En Unix.
Hoy en Common Lisp se hacen cosas que ni con Python llamando a numpy+CUDA lo logran.
Sobre ser ilegible, Emacs + Slime + SBCL se folla a Jupyter. Y ya Lispworks deja a Python de juguete.
Cosas como resolución vía sistemas expertos ya existían en CL de cuando Python era aún propietario y Linux casi ni estaba en 0.1.
#89 Ni una puta coma que tenga que ver con el tema.
Lo único que estás dejando claro que tú necesitas el Emacs hasta para cagar. Hasta confundes lenguaje con IDE, no tienes ni idea.
Quizá entonces escribas algo que tenga que ver con la conversación, o como mínimo que le importe una mierda a alguien.
Avisa cuando se te pase el efecto del porro de ego infundado que no te dejan fumarte en tu casa,
#90 Como confundo IDE con lenguaje? Te estoy hablando de Common Lisp con Slime, el que tenga REPL en Emacs via Slime no lo hace superior a Python, es el resto de cosas en el que hacian tareas que Python no olió hasta 2020.
Ya quisiera Python tener un depurador/decompilador como el de SBCL, o las librerías para resolver cosas que solo te lo hacía un doctorado hoy con el backend de CUDA para Python.
El ámbito donde estaba Common Lisp estaba a años luz de un picateclas con Python.
Y el problema del paréntesis te lo resuelve Emacs con Paredit, incluído en Slime; o sin él, ya que Elisp es primo hermano de CL y ya tiene sus poquitas cosas (pero cojonudas) de base para tratar automáticamente con la sintaxis. MIra, cero problemas para un ciego, Emacspeak y Slime están más que tratados para que lo maneje un invidente. Mientras tanto, Python sigue siendo un desastre en usabilidad.
#91 Has comparado explícitamente Lispworks con Python. Viene a ser como decir que tu taller es mejor que mi coche. No tienes ni puta idea.
Y está clarísimo que te has quedado anclado en los 90. Aludes a versiones de lenguaje hace 30 años como si demostrasen algo hoy, y hasta te montas clientes de protocolos que hace décadas que ya nadie usa. Eres un dinosaurio, chico, asúmelo.
Por lo demás, no conoces Python ni en postal. Que tú no tengas ni idea es una cosa, pero pretender que tu chufa de LISP se ha impuesto a Python ya es montarse una fantasía drogadicta. Empezando por que tú mismo has ilustrado profusamente que LISP no sirve para nada sin mil añadidos pesados. No hay frase en la que no necesites añadirle un prefijo dialectal y sumarle varias herramientas, sólo para intentar darle una apariencia que otros lenguajes ya implementan por definición.
Y además LISP es ilegible, siempre lo ha sido y seguirá siéndolo. Es una de sus características distintivas e inherentes a su sintaxis. Que necesites varias herramientas para adecentar el código ya es una prueba de ello, ¿o no lo entiendes?
Al contrario que Python, que está pensado para ser lo más legible posible. De eso va la conversación. Todo lo demás eres tú intentando hablar de ti mismo porque en tu entorno no te hacen casito, supongo.
#92 CL es ilegible si te quedas tu anclado en los 90, la gente normal o usa Emacs+Slime o paga miles de euros por Liskworks por proyectos que se hablan de UD con Python+CUDA.
Y Python es tan inútil por sí solo como CL o más.
Python te da un IDLE y gracias.
De memomento necesitas llamar a BLAS/Lapack para cosas gordas o medio básicas en álgebra/cálculo. CL lo tiene de base.
#93 ”Python te da un IDLE y gracias”.
¿Ves cómo no tienes ni zorra y no paras de confundir lenguaje con IDE? Yo mismo facturo una burrada haciendo aplicaciones estadísticas e industriales en Python y uso UN PUTO EDITOR DE TEXTO, melón. Y huyo de librerías externas porque raramente las necesita. Python es un intérprete y un lenguaje con framework incorporado, jamás ha necesitado las cien mil mierdas que tú necesitas para hacer funcional tu carraca de lenguaje de los 90 (que si nunca ha despegado es por algo).
Por mucho que te mientas a ti mismo inventándote que hace algo que los demás no hacen, LISP también es sólo un lenguaje (con una sintaxis que es pura mierda, eso sí). Pero lejos de aportar ninguna ventaja, ni siquiera tiene un framework incorporado como Python (y como casi todos los lenguajes con cara y ojos). De modo que LISP por sí solo no hace NADA de lo que dices. Pero como no tienes ni puta idea de qué hablas, no paras de confundir el lenguaje con las herramientas y las librerías externas. La simple realidad es que si Emacs no lo hubiese conservado en formol, esa basura desestructurada que es LISP ya no la usaría ni dios, igual que tu gopher. Sencillamente porque a todos los niveles que se te ocurran hay infinidad de cosas mejores que las basurillas experimentales que surgieron a patadas en los años 90.
La prueba es que hasta las herramientas estrella de LISP (como LispWorks) apestan a rancio. Sólo sirven para puentear desarrollos antiguos, bien porque usan estándares antiguos (p.ej. CORBA), o lenguajes antiguos (p.ej. Prolog), o herramientas antiguas (p.ej. Emacs). Joer, hasta prácticamente ayer los mejores compiladores de LISP ni siquiera soportaban cosas tan elementales como concurrencia (que por cierto es un punto fuerte de Python, sin necesidad de añadidos, y eso que es un puto intérprete y no un compilador).
Al contrario que otros lenguaje a los que el uso intensivo de la comunidad ha obligado a evolucionar, tu cacareado LISP sigue siendo un lenguaje de los 90 en todos los sentidos. Y no, eso tampoco significa que en los 90 fuese mejor que otros, nunca lo ha sido. Por algo no ha despegado nunca y se ha quedado en el pasado, donde también estás tú.
#94 Hasta tocado Common Lisp con QuickLisp (uno libre decente como SBCL) o sigues diciendo cuñadeces?
>Concurrencia
20 años para quitar un GIL, no me toques los cojones. Python es un puto juguete. Bordeaux-threads desde QL (multiplataforma) o de serie en SBCL, a tirar millas.
SBCL para tu información trae hasta decompilación/compilación nativa a nivel de FUNCIÓN y cosas como establecmiento de varios niveles de optimización *AL VUELO:
https://www.cliki.net/performance%20benchmarks
Eso ya es viejo, imagina ahora:
https://lispcookbook.github.io/cl-cookbook/performance.html
En el mundo Elisp, Emacs es una mierda monohilo, ok, pero ahora tiene JIT; y el de Guile (Scheme, nada que ver con CL, es el hermano bastardo) no es moco de pavo. El de Guile, para tu información está hecho por la gente que está con el V8 de JS en BLink/Webkit, algo saben.
#95 ¿Me acabas de enlazar unos benchmarks DE HACE MÁS DE VEINTE AÑOS?
¿No encuentras nada más reciente de tu antigualla de lenguaje, pobrete?
¿Pero eres tonto o qué te pasa? ¿No te das cuenta de que acabas de describir prácticamente el 99% de los compiladores, como si el tuyo fuese la gran cosa?
Y mira que es algo que añadieron hace doce años (tarde, pero hace una eternidad). Menuda mierda de compiladores te tienes que tragar por usar tecnología de hace décadas, jomío.
¿Y me acabas de explicar lo que es un compilador con tabla de símbolos?
De hecho sigues con lo mismo, nombrando cien dialectos y herramientas que demuestran que LISP es una chufa incompleta. A tenor de tus explicaciones, tu mierda de lenguaje es incapaz de hacer absolutamente nada si no le añades un entorno elefantiásico (que encima será uno u otro según lo que necesites hacer).
De hecho lo que estás explicando es aún peor. Si te emperras en usar LISP, resulta que para hacer X necesitas un compilador concreto de un dialecto concreto, pero para hacer Y necesitas usar otro diferente, luego para hacer Z has de tirar de un tercero y una librería externa, etc. Y si necesitas hacer X, Y, Z, te jodes y no puedes, porque ninguna de tus herramientas aúna todas las prestaciones. Son amalgamas de parches para un lenguaje del siglo pasado que apenas ha evolucionado, y encima tiran de herramientas y librerías externas.
Fíjate que no sabía que el multihilo en LISP también requiere de una librería externa.
Lo que estás describiendo es sencillamente un infierno. Cada prestación que mencionas implica elegir un dialecto y un compilador diferente, es para cagarse.
Ni siquiera tienes un compilador que puedas considerar estándar de facto: ABCL, Allegro CL, Clasp, Clozure CL, CLISP, CMUCL, ECL, LispWorks, MKCL, SBCL, Scieneer CL...
Y encima tienes que lidiar con sopotocientos dialectos: Arc, AutoLISP, Clojure, Common Lisp, ELisp, EuLisp, Franz Lisp, GOAL, Hy, Interlisp, ISLISP, LeLisp, LFE, Maclisp, MDL, newLISP, NIL, Picolisp, Portable Standard Lisp, Racket, RPLm Scheme, SKILL, Spice Lisp, T, Zetalisp...
Si eso no te dice claramente que tu lenguaje es un frankenstein cojo, debes andar fatal de entendederas. Con LISP siempre te faltan partes del todo, uses lo que uses, jamás tienes el conjunto de prestaciones completo. Por mucho que fantasees y te pajees. Tú mismo lo estás dejando bien clarito.
Con Python sucede lo contrario. UN lenguaje, no uno diferente para cada cosa. UN intérprete, con TODO incorporado ”out of the box”. Con todo y más que la inmensa mayoría de lenguajes, de hecho.
Y ahora voy a desarrollar un poco eso, que el meneo va de Python y no de tu puñetera película del siglo pasado.
Y a ver si te das cuenta de que voy a hablar SÓLO DEL LENGUAJE. No necesito nombrar ni una sola herramienta o librería externa porque Python no las necesita (al contrario que LISP).
El ”juguete” que dices que es Python permite cositas que tú ni sueñas. Por poner ejemplos:
- Reflexión a niveles inigualados en ningún otro lenguaje. Esto lo explico mejor después. Es una obvia ventaja de los lenguajes interpretados y no compilados, pero en Python va más allá de la imaginación.
- Multiherencia. Sólo por esto ya os vais a tomar por culo tú y la mayoría de lenguajes, incluso los más utilizados. En la vida he conocido nada que ahorre más trabajo de programación que usar mixins en lugar de interfaces, y Python es el amo.
- Tipado múltiple. Si un objeto navega como un barco y vuela como un avión, es ambas cosas y así lo reconoce el lenguaje. Y no hablo de interfaces, hablo de tipos, incluidos los propios del lenguaje. La de virguerías que permite esto es imposible de describir.
- Millares de clases prefabricadas ”out of the box”, sin necesidad de añadidos ni librerías externas. ¿Cuántos lenguajes pueden arrancar un servidor web plenamente funcional con una sola línea de código, por ejemplo?
En cuanto a optimización, un intérprete tiene ciertas ventajas en eso también. Python precompila bytecodes JIT y el motor que los ejecuta es nativo. Lo que haya hecho el programador se optimiza al precompilar en tiempo de ejecución, y el motor nativo que lo ejecuta obviamente está 100% optimizado y es el mismo para todos los programas.
De hecho si Python ha triunfado especialmente en cálculos masivos y computación paralela es porque su rendimiento está por encima de lo habitual, a medio camino entre el C y los lenguajes de alto nivel convencionales.
De paso, un intérprete como Python permite que el programa en ejecución disponga de su propio código. Esto en Python se ha explotado hasta sacar un provecho que no tiene parangón en ningún otro lenguaje:
- Reflexión a niveles de ensueño. Desde los módulos hasta el propio código todo son objetos que se pueden no sólo analizar, sino también alterar en tiempo de ejecución, algo que muy pocos lenguajes permiten.
- Incluso las clases de objetos son objetos. El uso más común de esto es programar metaclases cuyas instancias son clases. Generación de código en tiempo de ejecución y a medida de las circunstancias.
- Se puede hacer no sólo decoración declarativa como en otros lenguajes, sino también decoración funcional y programable. De clases, métodos, funciones, propiedades... Esto no conozco ningún otro lenguaje que lo soporte, y permite desde adaptar código preexistente sin esfuerzo hasta estandarizar modificaciones funcionales en clases diferentes.
- Se pueden ir más allá de la reflexión de tu propio código e impersonar incluso métodos y propiedades de las clases y objetos propios del lenguaje mismo. Teniendo en cuenta que en Python TODO es un objeto, las posibilidades que esto da son infinitas. Por ejemplo se puede (yo lo he hecho) trampear objetos propios de Python para que una librería o funcionalidad cerrada se ejecute con fines para los que no estaba pensada, por pura conveniencia.
- Todo bloque de código tiene asociado un descriptor que funciona como getter/setter/deleter. Puedes coger cualquier función, convertirla en método o propiedad y engancharla al objeto o clase que quieras, simplemente haciendo un ”bind” usando su descriptor. Métodos automágicos, propiedades programables y otras virguerías que son el súmum en otros lenguajes, en Python son moneda absolutamente corriente. Y encima los descriptores también son objetos programables, de nuevo posibilidades infinitas.
Y esto son sólo pinceladas, sin una biblia de ejemplos no te haces ni remota idea de lo que suponen estas características en potencia y comodidad. Y no las vas a encontrar en casi ningún otro lenguaje. De hecho la reflexión ni siquiera existe en lenguajes compilados.
”20 años para quitar un GIL”.
¿Quién dice que se vaya a quitar? El GIL permite programas multihilo sin caer internamente en problemas triviales de sincronía (bloqueos, inconsistencias...). Entre otras cosas eso permite que hasta un mono con dos dedos pueda programar una extensión útil del framework de Python que se integre de forma robusta y cero problemática. En parte por eso Python goza de un repositorio estándar de librerías prácticamente inacabable.
Pero tú, desde tu completa ignorancia, contrapones el GIL a la concurrencia. Porque no sabes que en Python la concurrencia no se implementa con hilos sino con pools de procesos. La programación concurrente y asíncrona en Python tampoco se parece a nada que veas en ningún otro lenguaje, sencillamente es diferente. Y ha sido uno de los factores primordiales de su gran éxito, por si no lo sabes (que es evidente que no).
No conoces Python y no tienes ni puñetera idea de qué hablas, acéptalo. Tú sólo sabes de lenguajes del siglo pasado que tuvieron un breve uso hace treinta años y quedaron desfasados hace mucho tiempo.
#96 Estás mezclando Lisps sin ton ni son. Scheme y Common Lisp son lenguajes diferentes.
Habla con propiedad.
>- Reflexión a niveles de ensueño. Desde los módulos hasta el propio código todo son objetos que se pueden no sólo analizar, sino también alterar en tiempo de ejecución, algo que muy pocos lenguajes permiten.
Common Lisp hace eso desde hace 30 o 40 años sin despeinarse. Es un Lisp, homoicónico, no me hagas reír comprando ESA función con Python, que CL se lo folla vivo con defmacro y decompilando, sí, DECOMPILANDO cada función al vuelo si le da gana, hasta el punto de corregir un error al VUELO, tocar una variable o función como si fuera GDB y después continuar SIN VOLVER A EMPEZAR.
Eso lo intentas en Python y el intérteprete se va a tomar por culo.
Me hace gracia que comentes esa feature de introspección en Python. Como decir que sabes hacer toques con el balón a Messi.
MIra, cosas serias:
https://blog.funcall.org//lisp%20psychoacoustics/2024/05/01/worlds-loudest-lisp-program/
>ABCL, Allegro CL, Clasp, Clozure CL, CLISP, CMUCL, ECL, LispWorks, MKCL, SBCL, Scieneer CL...
El estandar ANSI es de hace 40 años. Lo implementan TODOS. Para el resto, Quicklisp es como PIP pero mil veces mejor. UIOP para E/S y compilas desde ARM hasta IBM Power.
Si quieres más o menos rendimiento o portabilidad, SBCL está guay para empezar.
>Y encima los descriptores también son objetos programables, de nuevo posibilidades infinitas.
Ajam. Cosas que hacía CL desde hace 30 años. En serio, tío, que todo eso me lo montaba SBCL en el Athlon cuando Python2 era mediocre.
Todo lo que me vendas de Python sobre metaprogramación obviamente CL se lo va a follar.
La NASA acaba de arreglar un cacharro a chorropotocientos años luz gracias a correr Lisp. Eso nunca lo hará Python. No puede.
Todo lo que sea cambiar el programa *en tiempo de ejecución* sin reiniciar en absoluto o dejar de operar en lo que estaba, CL gana en esto. Por goleada.
Sobre Scheme, es otra cosa. Es al Lisp clásico lo que Oberon a Pascal. Hijo de familia española, pero se ha ido a Francia de bebé y apenas chapurrea español. Por poner un símil.
#97 Hay que ser pero que muy burro para pretender que la reflexión consiste en decompilar o depurar.
Es más, si optimizas compilando a binario nativo no vas a tener ni reflexión ni decompilación ni siquiera depuración, has de elegir. Ya has dejado bien claro que no tienes ni idea de qué es reflexión, pero como mínimo aprende qué es compilar y qué es una tabla de símbolos, coño.
Para postre mencionas la homoiconicidad, que en el caso de LISP se reduce a que todo, absolutamente todo, sea una lista. Su mayor fracaso, un mar caótico de paréntesis que mantiene a todos los programadores alejados de ese pestiño desde hace un largo cuarto de siglo.
¿Y en qué universo los cien dialectos de LISP son ”lenguajes diferentes”? ¿Porque lo dicen tus huevos? Todos son el mismo frankenstein cojo, melón, sucede que ni siquiera tiene un estándar de facto porque sólo lo usan cuatro gatos anticuados.
Por cierto, Common Lisp no es una implementación, sino una especificación. Así que hacer, lo que se dice hacer, no hace nada. No paras de confundir el lenguaje con las herramientas en todos tus ignorantes comentarios, absolutamente en todos.
Y tu mención a ”Deep Space” (que ni sabes el nombre, por lo visto) es el colmo de intentar darle la vuelta a las cosas para mentir. Porque lo que falló en la nave fue precisamente un programa en LISP. Todo un éxito de LISP, según tú. La aportación más notoria de LISP a la misión ”Deep Space” ha sido un fallo cuasi catastrófico por ”race condition”, ya ves tú.
Obviamente un cacharro que se construyó hace casi 30 años no podía optar a lenguajes fiables como los de hoy. Por suerte LISP se abandonó hace mucho y hoy las misiones espaciales ya no se cuelgan miserablemente.
Y por muchas pajas embusteras que te inventes, claro que hubo que reiniciar el programa. No es que hubiese que pararlo, es que ya llevaba tiempo tieso, colgado e inoperativo. La ”depuración” con la que te llenas la bocaza se redujo a ver qué puto programa había provocado el desaguisado y utilizar el agente remoto instalado exprofeso para reiniciar o ignorar componentes que fallan. Pero tú eres tan ”flipao“ y mentiroso que te inventas que accedieron al código del programa fallido y lo corrigieron. Ni siquiera eres consciente de las tremendas gilipolleces que escribes.
Pero es que encima esgrimes este fallo como si fuese un hito de la programación reflectiva. Hay que ser merluzo. Ahora resulta que la finalidad de la reflexión no es adaptar la ejecución a conveniencia sino arreglar cagadas de programación en LISP.
La verdad es que es admirable. Después de leerte, no hay ni una sola frase en la que no mientas, o te inventes, o sueltes chorradas ignorantes, o todo junto.
#98 Y otro montón de basura inútil que no interesa a nadie ni tiene que ver con el tema. Definitivamente llevas treinta años necesitado de casito.
¿No sabes absolutamente nada del tema del meneo y de la conversación? ¿Algo que decir de Python, más allá de negar idiotamente que puede hacer cosas que todos sabemos que sí hace?
Lo pregunto porque hasta ahora lo único que has transmitido es que si alguna vez fuiste programador llevas más de dos décadas hibernando en una cueva. Si no tienes nada que aportar más allá de tu embustero fanatismo por las antiguallas, obviamente voy a dejar de molestarme en leer tus ridículas trolas.
#100 CL es una especificación.
Bien, pero HOY Common Lisp, como mínimo, ha de soportar el estandar ANSI y QuickLisp junto con hilos.
>La nave...
Ya. Ahora mira los recursos de cuando se lanzó la nave y hablamos.Me parece un puto logro. Punto pelota.
>¿Y en qué universo los cien dialectos de LISP son ”lenguajes diferentes”? ¿Porque lo dicen tus huevos? Todos son el mismo frankenstein cojo, melón, sucede que ni siquiera tiene un estándar de facto porque sólo lo usan cuatro gatos anticuados.
Si no distingues entre Scheme y Common Lisp, mejor deja la informática.
Y cuatro gatos, mis cojones 23, CL está en sistemas y DSP's que tu ni hueles.
#96 Por cierto, sabes por qué digo esto? Common Lisp viene de MacLisp corriendo en ITS, del MIT. Filosofía opuesta a Unix. Unix son herramientas pequeñas usadas ortogonalmente. Nació en un PDP11, muy inferior a un PDP10 de la época. Eso se refleja incluso después, compara Emacs con Vi y el tener que lanzarlo en máquinas modestas.
En Unix lo que buscas, digamos, poniendo un similar en el época, un kernel pelado con Busybox, AWK y cosas ligeras comparado con un bicho gordo con Maclisp y Emacs haciendo cosas avanzadísimas sin parar la máquina.
En Unix cuanto menos tocases la CPU, mejor. Automatizar y reutilizar, la norma. En ITS/MacLisp/Emacs, los recursos chorreaban features cual grifo, así que hacían cosas increíbles para la era, como reparar errores al vuelo y seguir sin reiniciar. Unix no, Unix era falla rápido con SIGABRT y si todo va bien, sé parco en salida.
El sueño del hacker en ITS vs el de sysadmin automatizador con scripts ligeros en Cron en Unix. ITS también tenía demonios y su cron, pero es otra cosa.
En ITS, el DDT era mezcla de sh y gdb a la vez. No había permisos. La peña cambiaba cosas al vuelo, sin restricciones. Un sistema donde nació la IA, los chatbots y las redes conectadas y la colaboración abierta.
Por eso duele leer cosas como 'novedades', como funciones lambda. Bienvenido a Maclisp a 1979.
Te recomiendo probar SBCL con Slime/Sly. O si no te gusta Emacs, Gvim también tiene Slimv. Es otro mundo, y muy divertido.
#96 Emacs precisamente te ayuda a eso desde 1985 por lo menos, ya que al venir con Elisp es su puta tarea desde el pleistoceno. Así que encanchar Common Lisp a Elisp para sintaxis y ayuda y depurar todo desde el REPL para Emacs está tirado. Paredit evita que te vuelvas loco con parentesis.
Por poder puedes agregarle hasta colorines por par...
En serio, al principio yo también odiaba Lisp, pero tras usarlo semanas, cambió bastante mi visión.
PD: Con CL casi te olvidas de las listas. No es tu tarea, pero nunca viene mal saber como opera a mano. Tienes iota, loop, length y demás para que no te vuelvas loco.
Odiar Common Lisp por cosas ya obsoletas es como odiar Perl pesando que son todo oneliners, cuando medio Debian usa Perl internamente para debconf, apt, herramientas de crear debs...
Y repito, todo CL ha de portar ANSI CL, Quicklisp e hilos. Si no, no sirve para nada, y de toda esa lista el 90% va bien.
También hay diferentes implementaciones de Python. Cuantos funcionan aparte del de Guido? Exacto. Yo puedo tomar un proyecto con FASD, importarlo con QuickLisp y funcionarme en SBCL del tirón.
Hoy migrar de Python2 a 3 ya te da dolor de cabeza, incluso con algunas ramas de 3.8 a la 12.
#96 Por cierto, antes de que la cagues, hablar de Clisp, CMUCL y SBCL es como hablar de Clang, GCC, TCC y Cparser diciendo que son 'dialectos' de ANSI C.
Y el 99% del grupo de Common Lispers te va a usar ANSI+ el gestor QL, que es casi como C99 y POSIX con un pkgsrc universal (no existente ahora) que por norma se hayan adscrito desde Android hasta OSX y Ubuntu dejando atrás cualquier sistema de manejo de dependencias.
#96 >No vas a poder depurar en binario...
Abre SBCL y cágate. Empezando por (decompile 'cdr) y las opciones de velocidad y compilación a imágen nativa.
#106 Demasiado subnormal hay que ser para recortar mis frases intentando que parezca que dicen otra cosa. Y tú pareces bastante aficionado a intentarlo.
Encima lo cuelgas de otro comentario donde no he escrito nada parecido. Hasta parece que tienes obsesión por mi comentario #96, ya llevas cinco sartas de estupideces citándolo que ni tienen que ver con lo que yo digo ahí. Sencillamente no te funciona la cabeza.
¿Tú te crees que no sé lo que he escrito y dónde, animal?
Por lo demás, estás describiendo CUALQUIER COMPILADOR que tenga un depurador asociado, melón ignorante. Todos ellos pueden guardar la tabla de símbolos en el binario compilado para que la use el depurador, mendrugo. Todos son capaces de compilar una variante depurable y decompilable del binario. No es ningún invento de LISP, por mucho que tú acabes de descubrirlo (cuarenta años tarde).
Y hasta en eso gana Python, porque al ser interpretado el depurador no necesita tabla de símbolos alguna.
Por lo demás, eres tan tontaina que no entiendes que tener opciones de velocidad/optimización en el compilador significa que cualquier optimización que no sea la máxima por definición no es la mejor. Es tan evidente que hasta da vergüenza ajena tener que aclarártelo.
Y entre otras cosas eso implica que o depuras u optimizas, no puedes tener ambas cosas por muchas pajas de fantasía que tú te inventes.
También implica que o bien mientes a sabiendas o bien eres un completo ignorante en informática básica.
#13 Sólo por la herencia múltiple y la facilidad para implementar polimorfismos, Python le da bastantes vueltas a casi todos los lenguajes orientados a objetos.
Y si le añades que tiene unas facilidades asombrosas para aplicar reflexión, los supera.
#19 Claro que sí, campeón, un lenguaje donde todo es un objeto sólo debe servir para hacer scripts y juguetitos. A ti te enseñó a programar una manada de lobos.
#c-13" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3933900/order/13">#13 he programadp c# durante 8 años y llevo otros 8 programando proyectos de gran escala en python.
Python es un arma de doble filo. Por un lado su sintaxis es mucho menos verbosa, aparte de que el hecho de que sea un lenguaje dinámico te permite tomar ciertos atajos y aplicar ciertos patrones que no serían posibles o tan triviales con lenguajes estáticos como Java o C#. De hecho considero que soy mucho mejor y más rápido programando con python que con C# ya que me permite centrarme más en el dominio que en la sintaxis.
Por otro lado esa libertad es su maldición. Si no sabes lo que haces, en equipos grandes sin una buena disciplina de anotaciones y testing acabas teniendo un proyecto superacoplado e ilegible con miles de referencias circulares, y con hetereogeneidad en el estilo de programar, por muchas herramientas de corrección de estilo que uses.
Te recomiendo el libro de Oreilly "Python architecture" (tiene una serpiente en su portada).
#25 Vale. Me lo apunto. Habia cogido en la biblioteca "Object Oriented Python", pero... a ver. Tambien es que me tirado mas de 20 anios haciendo proyectos en JAVA, y tenia mas idea de C++. Pero en Python solo he hecho scripts para cosas de redes y seguridad, y clases de ML con Jupyters.
Me he tragado codigo en JAVA de cientos de clases para telecomunicaciones o el SACTA, pero Python solo lo he usado para tontas personales. Tambien es falta de ver sistemas reales grandes.
#79 el libro es éste: https://www.oreilly.com/library/view/architecture-patterns-with/9781492052197/
Posiblemente el mejor libro de python que he tenido en mis manos. Te enseña a crear un sistema distribuido con Api REST desde cero con tests y todo.
#11 Ha sido una decisión empresarial, la idea es que tengas que hacer más búsquedas para encontrar lo que necesitas y así tener más oportunidades para mostrarte anuncios...
https://www.wheresyoured.at/the-men-who-killed-google/
#22 Te me adelantaste. Muy recomendable Edward Zitron.
Cuanto hace que Google no saca un producto con impacto?
Cada vez huele más a Yahoo.
#6 Google ha llegado a tal tamaño que es "too big to fail" ... Gmail, Google Ads, Google Adsense, Google Maps, Google Cloud, Google Suite, Google Chrome, YouTube, Android, y el buscador en si mismo.
#9 El “too big to fail” era más una abreviatura de “too big to let them fail” ya que estábamos obligados a rescatarlos ya que su quiebra podía colapsar nuestras sociedades. Nos vendieron esa moto para rescatar los bancos, pero era mentira. Google caerá, como en su momento cayeron otras empresas, y no pasará nada.
#24 el "“too big to fail" es mas referido a que son "elementos" critica de la sociedad. A dia de hoy. muchos de los servicios de Google son críticos para el correcto funcionamiento de nuestra economía tanto como un banco. Y mas si pensamos en la infraestructura que google tienen (e.g., fibra optica, data centers, etc)
#6 Su buscador se ha vuelto inútil. Como un competidor haga algo aceptable se van a la mierda.
#11 wishful thinking
#11 Los jóvenes ya usan la IA como buscador.
#14 la IA usa TikTok como buscador
#18 y tikrok usa a los jóvenes.
Así se cierra el círculo.
#14 no tiene peligro eso... Madre mia
#11 sí, es una puta mierda que, literalmente, va cada mes peor... pero es que los demás son peores!
#11 Yandex.com funciona como Google hace años.
#21 con imágenes incluso mejor. Pero en productos todavía no.
#11 El Chrome es perfectamente útil para gente que lo usa para buscar cosas y acceder a webs sin pretensión alguna.
Los que quedáis que queréis que también os haga la declaración de la renta sois minoría absoluta.
#11 Ya hay un competidor que arroja muy buenos resultados de búsqueda:DuckDuckGo.
#49 pero no tan buenos como google en su momento
#11 Los buscadores van camino de extinguirse, por la IAs.
#6 De hecho tienes razón. En una operación interna en 2019 echaron a Ben Gomes, el anterior jefe de buscador de Google, para reemplazarlo por Prabhakar Raghavan, que se empeñó en mezclar más la publicidad con las búsquedas (primando el beneficio y el spam sobre la usabilidad y la experiencia de usuario) y con el que desde entonces el buscador está empeorando a pasos agigantados. Pero es que Prabhakar Raghavan estuvo años antes en Yahoo en un puesto equivalente, que terminó de hundir su buscador.
Más info en inglés. Es interesante porque explica también el papel en esta historia de una consultora como McKinsey adicta a los despidos:
https://www.wheresyoured.at/the-men-who-killed-google/
#38 desconocía este hecho. Gracias.
#38 Y adicta al dinero a costa de causar una crisis de opiáceos con el asunto del oxytocin en eeuu . Crear yonkis da buenos resultados empresariales trimestrales “literalmente”. La verdad que da para apostar a corto en Google después de leer el artículo.
#38 Uhm, vamos a fichar al tipo que hundió el buscador de Yahoo para que gestione nuestro buscador... ¿qué puede salir mal?
Yo no sé esa gente de recursos humanos qué tiene en la cabeza...
Para los cándidos, inocentes y engañados asiduamente que nunca las ven venir; entended lo que significa el teletrabajo y los nómadas digitales que tanto os venden por medios de comunicación, anuncios de TV (cuenta bancaria nómada digital) e incluso los comunities que tanto abundan por meneame.
Teletrabajo significa esto:
reduciendo costos a través de la contratación de mano de obra más barata fuera de Estados Unidos
Ya sabéis; en Latinoamérica hay millones de personas que hablan tú mismo idioma y cobran mucho menos que tú. En la India hay cientos de millones que hablan inglés y cobran mucho menos que tú.
#42 Verás las risas que se van a pegar algunos directivos con la mano de obra barata y el resultado final del producto.
En cierta consultora española "líder en su sector" me contaron que habían subcontratado un desarrollo en Argentina y uno de los programadores se llevó el código fuente, pidiendo un rescate por el mismo. Lo necesitaban porque tenía un bug grave que le generaba pérdidas económicas a un cliente extranjero importante. Eso les pasa por explotar gente en otros países para ahorrarse hasta el último céntimo.
#42 pues yo, años después de teletrabajar, aún no lo veo
En la mayoría de ofertas en países europeos pone "dentro de España", "dentro de la UE", casi nunca quieren a gente de muy lejos y/o con una cultura muy diferente
el clasico plan sin fisuras
#75 yo pienso que si lo es pq se ha demostrado como bueno, ha repartido riqueza y llevado progreso por todo el mundo.
La sostenibilidad no es una lucha científica ni tecnológica, es vencer los intereses de quienes se lucran de la no sostenibilidad.
#77 si no te niego sus virtudes, el problema es producir lejos y tener que transportarlo, hoy por hoy sigue cargándose el planeta. Me refiero a sostenibilidad ecológica.
Espero que los buques de carga puedan electrizarse o usar otro combustible pronto pero hasta donde yo he visto no está la tecnología lista aún. Lo única alternativa que conozco es la nuclear, pero me da cosica
Como bien comentas antes, si fuésemos civilizados esto se habría resuelto desde el primer informe del impacto del CO2 (entre otros). Pero como no interesaba hemos perdido décadas frenando el desarrollo.
Mientras USA se enfoca absurdamente en una guerra tecnologica con China, dejan la puerta de atrás abierta que se les cuelen todos los CEOs indios desde Bangalore. ¡Buena suerte!
#61 y yo haciendote caso en otro comentario...
#64 Y has hecho minería en mi perfil para meterte en mis conversaciones en otros meneos. Porque no eres un pedazo de troll de baja estofa, qué va.
Genmierda
#_31 Tu marca de desodorante no interesa a nadie.
ya veréis cuando las apps desaparezcan y sea la IA quien haga todo el trabajo, hasta anularnos
y no hay legislación que la controle aún
#47 Ya veréis cuando los caminos desaparezcan y sea el coche el que haga todo el trabajo, hasta anularnos. Y no hay legislación que lo controle aún.
Algunos ya salís anulados de fábrica, me parece a mí.
#55 es la opinión de otro anulado que se cree importante en la copia del sistema
#57 ¿Te has dado un golpe en la cabeza? ¿Necesitas un médico?
¿O realmente eres así de ”flipao” e incoherente?
#58 perdona, me conoces de algo?, debo ser clónico y opinar lo mismo que tú?, tendré que ser coherente como tú, pero coherente a que? y dejar de ser "flipao" para ser nulo?.
Se agradecen los consejos pero yo se cual es mi vida, la experiencia y la capacidad que tengo, así que, si quieres moralizar, seguro que tu y tu vida tenéis mucho campo para ello.
Ah, gracias por la preocupación: no me he dado ningún golpe en la cabeza
#60 Creo que te confundes, tu vida y tus ideas no le interesan una mierda a nadie. Sólo he preguntado si sufrías algún traumatismo cerebral por lo incoherente de las gilipolleces que escribes.
¿Más claro así?
#61 si solo sabes insultar, vuelve a primaria creo que lo necesitas de verdad
tus razonamientos son éstos en la vida? enhorabuena, tienes mucho futuro en el planeta deshumanizado donde solo gana quien más grite y más pisotones de
Suerte en tu vida
#_63 En cuatro comentarios ha sido incapaz de escribir nada más que gilipolleces sin sentido. Verte hablar sobre los razonamientos de los demás es como ver a un cura intentando dar lecciones de sexualidad.
A llorar a casa, niño. Si no te dedicases a responder sistemáticamente en tono faltón igual no te pisarían tanto. A ver si te entra que los demás no tenemos por qué aguantar desplantes gratuitos porque tú seas un puñetero amargado.
(Viene de #61)
La burbuja de los informáticos.
La verdad es que en europa la productividad es muy baja y en todo el mundo igual. Lo que queda es la cadena de externalizaciones... Los alemanes contratan en España, los españoles en Hispanoamérica y así. De esa forma se palia los elevados costes improductivos del personal de ese sector.
Pq se diga lo que se diga, yo que miro bastante por el trabajador, no puedo lidiar con determinadas situaciones, como que un junior que tienes que revisarle todo tres veces, que produce hiper lento no puede costarte 35k. Necesitas al final para un proyecto de mierda que necesite un equipo de 5 unos costes por encima de los 300k solo en personal. No es productivo pq no puedes competir con tres chavales que se juntan y hacen un programa como el tuyo con la cuarta parte de costes que tú.
#26 en europa la productividad es muy baja
¿Y dónde es alta? Porque no me digas EEUU cuando luego criticas los salarios europeos, que el que se levanta 35k en España se lleva 100k en EEUU fácilmente.
#33 es lo que te explico. En EEUU contratan fuera del país.
A mí me aumenta la productividad casi el doble contratando equipos en Perú y argentina. Ahí por 45 tienes un muy buen coordinador de proyecto, aquí no tienes ni un junior.
Realmente es lo que dices. Yo no puedo competir con un alemán que con lo que factura allí te paga 80k y se ahorra costes donde yo te pago 55k y no soy competitivo.
El es más competitivo, pq te paga 80k en vez de los 120k y yo si pago en argentina un buen programador con experiencia por el precio de un junior aquí tb gano productividad.
Se que es jodido, pero los que defendéis lo de las empresas alemanas, holandesas, de UK o francesas que os contratan en España sois parte de esa búsqueda de productividad buscando personal en lugares con otra divisa o media salarial más baja.
#36 Esa cadena de subcontractaciones que comentas son vasos comunicantes que se compensan en pocos años.
Y sólo aplicables s un tipo de proyectos muy cercano a la consultoria o los proyectos cerrados
#85 en mi caso es desarrollo de producto. Por un lado investigación y nuevos proyectos para nosotros y por otro lado desarrollo de mejoras de producto. No hablo de soporte ni gestión de incidencias.
#26 Opino que con las externalizaciones vamos a sufrir lo mismo que "fabricar fuera porque es más barato". Estamos regalando todo el know-how a parte del capital.
Esto en mi opinión debería estar penalizado taxativamente o fuertemenete revisado, como si fueran aduanas. Después vendrán los lloros de que nos adelantan por la derecha con nuestra propia tecnología y el I+D de nuestras universidades.
#56 vas tarde. Las patentes y los papers científicos ya no son nuestros.
El proteccionismo es basura, el cáncer de occidente es que el poder lo tienen las empresas en lugar de los estados.
Las energías verdes son más baratas y rentables, el coche eléctrico igual y no lo vamos a tiempo con ello y perdimos la carrera ahí porque a algunas empresas prefieren seguir facturando sin invertir ni dejar paso a competencia. Dan unos sobres y te montan un impuesto al sol hecho a medida. Y así en toda europa y en todos los campos. Estás en un mundo en el que los avances en medicina se frenan si van a tener menos costes para el enfermo, se intentan cronificar enfermedades y se fuerzan listas infinitas de espera en atención medica especializada para que pagues un seguro privado. Esa es la decadencia de occidente. Estúpidos que sostienen eso con su voto. El libre mercado es progreso,no es necesario producir aquí el caso es progresar y derribar las oligarquías y monopolios. Hacen falta empresas fuertes pero nunca en contra de los intereses de los estados.
#71 Estoy de acuerdo contigo casi en todo, mis dos matices:
Yo considero que el libre mercado no será bueno y no se puede llamar progreso hasta que no sea sostenible.
En empresas que trabajan con la última tecnología los papers, patentes y know how sí están en manos de ese grupo de trabajadores ya que son quienes lo crean y mejoran, externalizarlo me parece un error.
Es solo mi opinión