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.
|
etiquetas: despidos , google
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).
Esto siempre me hace descojonarme, porque encima es mas verdad con cosas mas antiguas que nadie sabe que van a petar en algun momento.
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ú.
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.
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
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.
Algunos ya salís anulados de fábrica, me parece a mí.
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.
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?
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
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. Hasta tu ciego de referencia te lleva la contraria, qué cosas.
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).
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?
”No usa Bash para nada”.
Pero mira las fuentes, mendrugo. Y deja ya de mentir.
”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.
Para no saber, solo estoy haciendo un cliente Gopher para Macsyma en ITS.
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? Te llaman de los años 90, que si vuelves para cenar.
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.
Avisa cuando se te pase el efecto del porro de ego infundado que no te dejan fumarte en tu casa, Quizá entonces escribas algo que tenga que ver con la conversación, o como mínimo que le importe una mierda a alguien.
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 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.
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.
¿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ú.
>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.
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.
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.
Fíjate que si LISP hubiera usado un GIL (como Python) la nave no habría fallado. Ni deadlocks, ni race conditions... cero problemas de sincronismo. Tu chufa de lenguaje en cambio falló como una escopeta de feria, allí donde Python no puede fallar.
”Si no distingues entre Scheme y Common Lisp, mejor deja la informática”.
Precisamente porque me dedico al ramo no me interesan los cien dialectos de una chufa que lleva décadas en desuso. Si me dedicara a la arqueología, quizás...
”Y cuatro gatos, mis cojones 23, CL está en sistemas y DSP's que tu ni hueles”.
No los huelo yo ni nadie. Ésa es precisamente la definición de ”lo usan cuatro gatos”, chavalín.
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.
Y eso lo dice alguien que ni se dedica a la informática ni ha pasado de la tecnología de los 90. Sin duda habrá que hacerte caso e ignorar lo que todos vemos con vuestros propios ojos: que en los últimos veinte años LISP ha desaparecido y Python no ha parado de triunfar. Tanto en empresas como fuera de ellas, tanto en ámbito científico como industrial, tanto en software de utilidad como de usuario, etc.
”Se juntaron los dialectos de Common Lisp en su día para montar un estandar, en los 80”.
Lástima para tu credibilidad que la mayoría de dialectos surgieran después de los 80. Que tú te empeñes en que no existen no va a hacer que dejen de existir. Los 90 fueron tiempos proclives a los experimentos con gaseosa, pero los muchos intentos de arreglar la mierda que siempre ha sido LISP no lo consiguieron.
No es un dialecto lo que está fragmentado, chiquitín, es todo el lenguaje LISP. Precisamente porque hay decenas de dialectos. Y no, no se han unificado más que en tu imaginación. De hecho tú mismo has descrito perfectamente cómo necesitas setecientas herramientas y entornos diferentes según el dialecto que uses y la finalidad que persigas. Ni C tiene un caos tan grande, que ya es decir.
Para tu desgracia, para afianzar estándares hace falta una base consistente de desarrolladores. Y LISP sencillamente no la tiene. Sois cuatro gatos anclados en el pasado, nada más.
De hecho me acabo de descojonar leyéndote. ”Mira, que hay dos dialectos y sólo uno está fragmentado, pero está este tercer dialecto que...”. Léete tú mismo, anda, eres de lo más cómico.
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.
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.
Por mucho que patalees, Scheme es LISP. Punto pelota. El por qué te has puesto a hablar de C, nadie lo sabe y a nadie le importa.
Y la falta de unificación también es de LISP, como demuestra que existan chorrocientos dialectos y chorrocientos entornos de desarrollo (cada cual para una cosa). Por mucho que mientas y lo niegues están ahí, no los he inventado yo.
No te apures, en los 90 y principio de los 2000 era normal ver surgir decenas de variantes en lenguajes que no usa ni cristo. Porque cuando un lenguaje sólo lo usan cuatro gatos no se da importancia a la estandarización, y cada cual se monta su invento a su manera.
Por eso LISP es un sindiós que requiere una decena de compiladores y entornos diferentes según lo que quieras hacer, como tú mismo has ilustrado perfectamente varias veces.
Y como lo siguen usando sólo cuatro gatos trasnochados, ni se ha unificado, ni ha cuajado un estándar, ni ha evolucionado gran cosa desde hace décadas. Sigue siendo lo mismo que era, un batiburrillo de dialectos y herramientas incompatibles.
Y repito, esto lo has ilustrado tú mismo repetidas veces. Puedes releer tus propios comentarios y ver cómo cada vez que haces alusión a las ”maravillas” de LISP mencionas un mínimo de tres dialectos y una decena de herramientas incompatibles.
Sucede que tú eres limitadísimo y encima hablas de oídas. Ni siquiera conoces las herramientas de las que hablas. Joder, si hasta flipas con que un programa se pueda depurar, es para descojonarse. Pero como te suena que lo open es bueno, ahora te emperras en que eso convierte la elección que digas tú en estándar. Y hace unos comentarios estabas defendiendo otra. Por tus cojones ignorantes y embusteros, como todo lo que escribes.