273 meneos
2668 clics
En un momento crucial para la IA, Google acaba de despedir a todo su equipo de Python de EE.UU: esto es lo que sabemos
el problema de lo ocurrido no es que Google tenga pensado prescindir de Python en modo alguno (todo lo contrario, teniendo en cuenta el énfasis que está poniendo en los últimos tiempos en el desarrollo de IA), sino que la compañía del buscador está reduciendo costos a través de la contratación de mano de obra más barata fuera de Estados Unidos.
|
comentarios cerrados
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.
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.
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).
Despues hay miles que usan ese python en google.
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:
www.wheresyoured.at/the-men-who-killed-google/
Cada vez huele más a Yahoo.
¿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.
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ú.
Así se cierra el círculo.
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
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).
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... .
Yo no sé esa gente de recursos humanos qué tiene en la cabeza...
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.
La sostenibilidad no es una lucha científica ni tecnológica, es vencer los intereses de quienes se lucran de la no sostenibilidad.
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.
www.theregister.com/2016/03/23/npm_left_pad_chaos/
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.
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
Y sólo aplicables s un tipo de proyectos muy cercano a la consultoria o los proyectos cerrados
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.
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.
PEP8 recomienda encarecidamente utilizar espacios -> peps.python.org/pep-0008/#tabs-or-spaces
Si quitaran la mierda esa de usar espacios en blanco como sintáxis le tendría más aprecio.
Los que quedáis que queréis que también os haga la declaración de la renta sois minoría absoluta.
y no hay legislación que la controle aún
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.
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
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.
Toma hostia mental que te has metido, pero de las gordas.
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.
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.
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
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.
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?
Para no saber, solo estoy haciendo un cliente Gopher para Macsyma en ITS.
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.
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.
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.
>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:
www.cliki.net/performance benchmarks
Eso ya es viejo, imagina ahora:
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.
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:
blog.funcall.org//lisp psychoacoustics/2024/05/01/worlds-loudest-lisp-
>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.
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.
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.
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.
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.
Y se usa en entornos serios donde Python ni entra.
Si me dices que la fragmentación es real, ésa está en Scheme, no en CL.
Y el propio Elisp de Emacs se acerca más a CL (tiene hasta librerías de compatibilidad con CL) que Scheme.
MIra, con Scheme te doy la razón, es un pifostio. Con CL, no.
Se juntaron los dialectos de Common Lisp en su día para montar un estandar, en los 80.
Y de ahí a usar QuickLisp como el PIP de CL. No hay más.
Pero si acabas de decir que está fragmentado y no distingues compilador e implementación, melón.
Common Lisp en ANSI es como decir C99, y SBCL, CMUCL... lo mismo que cparser, clang, gcc...
Mira lo mucho que se usa C y todavía en 2023 no tenemos algo como QuickLisp o PIP... y eso que CL es mucho más limpio, subdirectorio por módulo y listo, con PIP hay que usar virtualenv y hacer chapuzas.
Como todo lo que digas de "Lisp fragmentado" se achaca a Scheme. Es otro lenguaje, otro universo. Como mezclar C y C++.
Por supuesto puedes implementar un Scheme en CL, es parte del libro de Paradigms of Artificial Inteligence, lo mismo que puedes hacer una marcianada con C++ montándote un CPP para C definiendo macros al vuelo. Pero no es el caso.
Lo que quiero decir es que CL es más compatible todavía que C++, que intentas compilar cosas de 2007 y petan. Con CL como digo el estándar manda desde hace décadas y SBCL es mucho más avanzado que Python.
Un Common Lisp lo hace DE SERIE.
Y si pasas a Lispworks (no lo recomiendo, es propietario) deja a Python en comparacion como si comparamos Basic de los PC micro de los 80 frente a Perl.
Es como comparar el DDT de ITS donde era shell y depurador y podias tomar cualquier proceso y cambiar cualquier cosa al vuelo, con un triste sh de Unix.