Cuál es tu lenguaje de programación preferido?

Elige opción

  • C / C++

    Votos: 165 23,3%
  • Java

    Votos: 95 13,4%
  • Javascript

    Votos: 45 6,4%
  • PHP

    Votos: 63 8,9%
  • Python

    Votos: 153 21,6%
  • Ruby / Rust / Scala

    Votos: 10 1,4%
  • Fortran

    Votos: 20 2,8%
  • Ensamblador

    Votos: 42 5,9%
  • Perl / Pascal / Ada

    Votos: 15 2,1%
  • Otros (C#, D, F# y etc.)

    Votos: 99 14,0%

  • Total de votantes
    707
Con este hilo se me acordó el otro donde se ponía el índice tiobe. La eche una ojeada y por lo visto últimamente C está de capa caída mientras que Python se desmadra:

Tienes que estar registrado para ver este contenido
 

Adjuntos

Archivo oculto para usuarios no registrados
Con este hilo se me acordó el otro donde se ponía el índice tiobe. La eche una ojeada y por lo visto últimamente C está de capa caída mientras que Python se desmadra:

Tienes que estar registrado para ver este contenido


Gracias cerdito, por la gráfica, la guardo para mis clases.

saludos.
 
Como caso extremo mirad este módulo para el Casio F-91W:


Lleva un procesador ARM Cortex M0+. Su juego de instrucciones incluye:
-Thumb-1 (most), missing CBZ, CBNZ, IT
-Thumb-2 (some), only BL, DMB, DSB, ISB, MRS, MSR
-32-bit hardware integer multiply with 32-bit result
En este caso supongo que igual se programa todo o una parte en ensamblador por eficiencia de consumo (este reloj se alimenta con una pila de botón CR-2016 no recargabl).
Es bastante raro ver a gente programando asm thumb. Las MCUs Cortex se diseñaron con la idea de poder programarlas en C, y eso es lo mas habitual...
Hoy en dia se ve poco asm, lo interesante de conocer asm es que te sirve para programar un buen c/c++ con la mirada puesta en la eficiencia. Muy poca gente baja a asm para hacer nada...algunos trozos cortos de gestion de interrupciones y poco mas.
 
Project Loom aun no lo verás en la gran mayoría de empresas, salvo muy muy punteras. Piensa que el mundo corporate, que ees donde Java triunfa, es lento de agallas. En donde curro, que no es precisamente de las empresas más lentas adoptando cosas, todavía estamos migrando cosas a Java 17

En un banco por ejemplo, no es nada raro ver todavía muchas cosas del core en JBoss xD
En un banco puede ser una hazaña actualizar a java8.
 
Thumb fue creado con la idea de que pudiera usarse en C, con mayor densidad de código que los ISA normales de ARM, pero la cuestión clave para mencionarlo aquí es que es muy asequible: tiene muy pocas instrucciones y muy claras, así que es fácil de asimilar y usar por un humano, no como otras arquitecturas modernas que incluyen cientos y cientos de instrucciones y donde los nemotécnicos elegidos no están pensados para ser memorizados ni usados por un humano sino que están pensados para que los "use" otra máquina (por medio de compiladores, o lo que sea).

Thumb es bastante mas complejo que la ISA original con opcodes de 32 bits de ARM. No se si has trabajado con ella, pero es una ISA muy regular que con muy pocas excepciones, y muy potente. Para mi Thumb fue claramente una marcha atras, una ISA rara y retorcida para ganar un simple 30% en el footprint del ejecutable...


El Thumb-1 por ejm me recuerda, en su sencillez, al MOS 6502 de los años 70-80: un procesador sencillo, muy claro y con pocas instrucciones. Lo que es el ensamblador en sí del Thumb-1 incluye como 36 nemotécnicos (que pueden dar lugar a algunos opcodes más, o sea a más intruccones de código máquina), y son claros, es fácil de asimilar por un humano en poco tiempo. De hecho diría que es un procesador que se aprende a programar en mucho menos tiempo del que requiere por ejm el Zilog Z80, el otro gran procesador de 8 bits de los años 70-80. Claro que el Z80 es un "churro" en ese sentido: a nivel de código es como un Intel 8080 (compatible a nivel de código ejecutable) expandido con más instrucciones y registros, lo cual lo hace complicado, habiendo hasta instrucciones que requieren un prefijo en su código máquina (lógicamente el ensamblado de Z80 se encarga de poner ese prefijo, pero es una muestra de lo de ser un churro, además de que incurre en penalizaciones a la hora de la ejecución).

Por lo que estas contandome entiendo que no has trabajado con procesadores RISC. Aprender MIPS o el actual RISC-V es mucho mas facil que aprender 6502 o Z80, con sus direccionamientos psicodelicos. Para la mayor parte de la gente, Z80 y 6502 no son sencillos...
El aprendizaje de asm lleva el estigma de ser infernal por culpa precisamente de las ISAs CISC antiguas, y por la desgracia del x86 actual.
Yo en clase enseño ARM porque se que si enseñara x86 perderia a una buena parte de los alumnos. Con ARM consigo que todos adquieran cierta soltura programando asm.
 
Vamos, que no sabes.

hice ing informatica, cuando eran 5 años, y un master de 2

llevo 15 años trabajando en it para banca, desde migracion de sistemas, apps y bbdd, cloud, he pasado por la moda de las apis, el infierno de gdpr o hasta desarrollo de erps a medida

los informaticos son para negocio como minions. no pintan nada
 
se ve que sabes de esto.
Gracias.
Solo he leído algo y tengo algo de experiencia, y una ideas sobre fundamentos sólidas y fuertes.
(¿Taliván informático, anciano? ¡Dejad de pisar mi dcespéd mocosos descreídos¡) sonrisa:

Yo no soy programador, sino un científico que programa por necesidad.
La mayor parte de programadores son X (otra cosa) que programan por necesidad.

Te he leído que Python es una cochambre.
Lo es.
Pero con matizaciones y po rmotivos que explicaré más adelante en este post.

Yo lo uso para lo relacionado con deep learning.
Está muy fuerte ahí, por las librerías y frameworks.
De hecho, diría que es insustituíble.

Tengo un ojillo puesto en Julia, pero no acabo de verlo.
Yo lo miré en su momento.
Ví que era demasiado sofisticado (léase complejo y complicado) para ser un lenguaje de script y lo deseché.
Continué con matlab/octave.

En ciertas áreas de la matemática parece que Julia es muy usado.
Pero son áreas nicho me temo.

En lo que comentas de C estoy de acuerdo, hace muchos años empecé con C++ y al tiempo reculé y reprogramé todo en C.
Muchos hemos hecho ese camino.
Y no es que esté en contra de C++, es una virguería conceptual.
Es solo que luego es demasiado complejo y sutil para hacer grandes aplicaciones/sistemas o incluso para programar cosas prácticas/reales.

Sí, ya se, "si eres lo bastante inteligente programar en C++ no es problema" (dicen).
Pero, ya sabes, programar com si fueras listo, te va a morder en el pandero en el futuro, porque tú mismo vas a decir de tú codigo "jorobar, ¿qué y cómo hace esto?".
Con C++, o tienes una descripción conceptual gráfica del entramado conceptual de detrás, o bang bang, you're dead.

Sí, ya se, Windows está (o estaba) programado en C++.
No lo veo como un mérito.
Nunca sabremos si Windows es como es (de malo) por los malos programadores de Microsoft, por el C++ o por una mezcla de ambos.
sonrisa:

Pero estas moderneces como Python tienen muchas librerías, funcionan en Linux
Muchas librerías.
Esta es la fortalezo de Python.

y yo soy un puro matemático vago, que sí puedo, prefiero no pasarme el tiempo programando.
Vago.
sonrisa:
Pero compensible, soy de tu grupo de vagos (pero no matemático).
Yo soy de los que usaba Tcl/Tk.

En fin, la pregunta es: ¿por qué Python es una cochambre, y cuáles son las alternativas para programación científica como usuario que hace prototipos, no producción?
Respondo en orden contrario.

Python a día de hoy es INSUSTITUÍBLE, por la cantidad de librerías.
Hasta yo voy a prender Python de una estropead vez.

Es una cochambre por dos motivos.

El primero y más grave, e imperdonable:
Usa caracteres no-visibles como parte de la puntuación.
Que use el tabulador en vez de las llaves para indicar el nivel sintáctico es un pecado digno de condenar al infierno eterno a Guido Van Rossum y a todos los que parieron ese engendro.
La cosa se agrava con editores de texto, entornos, etc que cambien automáticamente el tab a 2/4/6/8 espacios, la que se puede liar ahí es fuerte.
De hecho se lía.
Al quitar las tabulaciones por espacios, se pierde el significado sintáctico, Y NO HAY FORMA DE RECUPERARLO.
No se a qué demente se le ocurrió eso.
Tan solo brainfuck es un lenguaje más enfermo.
Pero Brainfuck no está diseñado para ser usado de verdad, y no ha surgido una comunidad de talibanes promoviéndolo.
Que eso siempre em escamó, cómo surgió uan comunida tan activa DE NINEGÚN SITIO LITERALMENTE generando código e semejante guano conceptual.
Y mientras el tcl/Tk languidecía y moría... lloroso:lloroso:

El segundo, y soslayable/convivible:
Es un dolido lenguaje de script, cuya sintaxis (capacidades dicen) ha crecido tanto hasta el punto de un lenguaje "modelno" y sofisicado como C.
Pero con la "ventaja" de que no se compila (así es más fácil jijijijiji).
Así que se tiene los problemas de programación de un lenguaje de sintaxis de alto nivel (C) sin las ventajas de la compilación (escaneo sintaćtico previo y deteción de errores ANTES de la ejecución) y con las desventajas de un lenguaje de script (falta de estructura) y las suyas propias (sitaxis con tabulador).
Maravilla de maravillas.
Lo malo de los dos mundos, lo complicado de los dos mundos, y una complicación propia INVISBLE

Y se ha construído sistemas enteros con eso.
No me cabe en la cabeza.
Y esa comunidad salida de ningún sitio programando como fieras...

Respecto de su uso y/o alternativas
A día de hoy es necesario/impresdincible, sobre todo para fruta matemática y RRNN (redes neuronales) y difíclmente nos libraremos de él.
No hay alternativa.
Ni creo que la haya.
Hay que aprenderlo y usarlo.

Eso no quita que se le critique para evitar que haya engendros similares en el futuro.

Como curiosidad observa que soy un fundamentalista práctico o pragmático:
  1. Python esté roto de nacimiento.
  2. Es imposible no usarlo.
Espero haberte respondido con esto (y siento la extensión de la respuesta).
🙂

Y para el que quiera saber más sobre brainfuck:

Curiosida lo de la abiogénesis simulada:

Simulation of abiogenesis​

In 2024, a Google research project used a slightly modified 7-command version of Brainfuck as the basis of an artificial digital environment. In this environment, they found that replicators arose naturally and competed with each other for domination of the environment.

Estos informáticos siempre me sorprenden con sus cosas.

Gracias, veo que pensamos muy parecido y que en lo más importante, la decisión de seguir con Python en deep learning, me indicas que seguir con Python es correcto. Al final yo hago prototipos de investigación, y necesito paralelizar algunas cosas , y me apaño. Para matemáticas simbólicas me voy al Mathematica y vuelvo, o bolígrafo y cerebro si no queda otra, pero en mi caso, la chicha está en definir modelos y deducir las fórmulas. La programación no es excesivamente complicada en general, aunque sí debe correr rapidito. Pero por ejemplo, si desarrollo un modelo de represe texto nuevo, necesito acceder a las herramientas de la competencia a efectos comparativos, y suelen encontrarse las librerías en Python. Luego también tienes Dask y Ray para paralelizar y distribuir.

Julia es una bala y tiene ciertas ventajas a la hora de paralelizar, ya iremos viendo. La verdad es que yo estoy mentalmente anclado en "el pasado", montándome mis ordenadores con sus propias gpu y usando esos lenguajes conocidos. Veo que ahora la gente usa "contenedores", dock era, herramientas de Google en las que pagan espacio y tiempo de fruta, y me pierdo un poco. Como uso ordenadores con dos gpu y ram elevada, 64 y 128, de momento me apaño. Pero toda sugerencia es bienvenida.
 
Gracias, veo que pensamos muy parecido y que en lo más importante, la decisión de seguir con Python en deep learning, me indicas que seguir con Python es correcto. Al final yo hago prototipos de investigación, y necesito paralelizar algunas cosas , y me apaño. Para matemáticas simbólicas me voy al Mathematica y vuelvo, o bolígrafo y cerebro si no queda otra, pero en mi caso, la chicha está en definir modelos y deducir las fórmulas. La programación no es excesivamente complicada en general, aunque sí debe correr rapidito. Pero por ejemplo, si desarrollo un modelo de represe texto nuevo, necesito acceder a las herramientas de la competencia a efectos comparativos, y suelen encontrarse las librerías en Python. Luego también tienes Dask y Ray para paralelizar y distribuir.

Julia es una bala y tiene ciertas ventajas a la hora de paralelizar, ya iremos viendo. La verdad es que yo estoy mentalmente anclado en "el pasado", montándome mis ordenadores con sus propias gpu y usando esos lenguajes conocidos. Veo que ahora la gente usa "contenedores", dock era, herramientas de Google en las que pagan espacio y tiempo de fruta, y me pierdo un poco. Como uso ordenadores con dos gpu y ram elevada, 64 y 128, de momento me apaño. Pero toda sugerencia es bienvenida.
Gracias,
Gracias a ti por leer mis desvarios filosóficos.

veo que pensamos muy parecido
Los hechos objetivos(físicos/materiales o conceptuales/inmateriales) son los mismos.
Mentes orientadas a objeto/proceso suelen otener resultados similares.

y que en lo más importante, la decisión de seguir con Python en deep learning, me indicas que seguir con Python es correcto.
Es que no hay otra.
Es todo Python, por aborrecible que sea.

Al final yo hago prototipos de investigación, y necesito paralelizar algunas cosas , y me apaño.
Pues ahí lo tienes.
Una cosa es montarte algo especial para una aplicación o investigación especial, pero si necesitas velocidad de hacer churrros, pues se usa la churrera digooo Python.

Para matemáticas simbólicas me voy al Mathematica y vuelvo, o bolígrafo y cerebro si no queda otra,
Hay varios programas por ahí incluso libres.
No se qué tal iráan.
En mi caso le tengo manía Mathematica y a Wolfram.

pero en mi caso, la chicha está en definir modelos y deducir las fórmulas.
Usa lo que más rápdio te permita garrapatear pruebas y lo que más libreráis tenga.
O sea, Python.
Es inevitable (incluso para mí, el infierno se los lleve a todos los pythonistas).

La programación no es excesivamente complicada en general, aunque sí debe correr rapidito.
Eh no.
O desarrolla rápido, o corre rápido.
Ambos no.

pero por ejemplo, si desarrollo un modelo de represe texto nuevo, necesito acceder a las herramientas de la competencia a efectos comparativos, y suelen encontrarse las librerías en Python.
Claro.
Es uno de los motivos de usar Python.
Casi seguro que si desarrollaras en C,se puede acceder a las librerías de Python desde C.
El esfuerzo para hacer prototipos inciales no merece la pena.

Luego también tienes Dask y Ray para paralelizar y distribuir.
¿Esto es solo para deep learning (DL) o para todo?
Tendré que echarle un vistazo, ni sabía que era
Mi campo no es el DL

Julia es una bala y tiene ciertas ventajas a la hora de paralelizar, ya iremos viendo.
Lo será.
Pero por lo que ví en su momento es nicho de facultades de matemáticas.
Creo que se basaba en C++ y la sintaxis se hipercomplica digooo, es sofisticada como C++.
(El diablo os lleve a todos los matemáticos shishi, dejad en paz la teoría de categorías y aplicarla al C++) sonrisa: 😉

La verdad es que yo estoy mentalmente anclado en "el pasado",
El pasado siempre fue mejor.
Pero ahora de verdad.

montándome mis ordenadores con sus propias gpu y usando esos lenguajes conocidos.
Anda, como DotCSV.
Igual eres él y todo.

Veo que ahora la gente usa "contenedores", dock era,
Usan Docker porque patata.
NINGUNO te podrá razonar el motivo.
NINGUNO ha hecho el análsis.
TODOS te dirán "tengo al impresión de".
Impresiones, sensaciones.
Seguir la corriente, peces perecid.

herramientas de Google en las que pagan espacio y tiempo de fruta,
En la nube en la nube, todo en la nube.
¿Por qué?
Porque en la nube (y ya).

Kamala Harris: We all the cloud is all above us.
(O una sandez así dijo)

Realidad:
La nube es el ordenador de otra persona.

Y el análsis de costes y esas cosa que hacemos los hombres heterosenshetero hombrista facinerosos para luego si eso.

Vuelvo a ejercer machismofascismo heteropartiarcal, lo siento

y me pierdo un poco.
Los perdidos por abducción son ellos, pero no lo saben.
Son disfuncionales con un título.

Como uso ordenadores con dos gpu y ram elevada, 64 y 128, de momento me apaño.
Si te sirven adecuadamente para mi gusto preferible a la nube.
Pero yo solo soy un anticuado demodé.

Pero toda sugerencia es bienvenida.
Se poco.
Solo filosofar.

Pero me gusta dialogar y debatir.

Ya habrás visto por el hilo, que Python frente a C es 75 veces más lento y con mayor consumo de energía.
Es decir, DOS ÓRDENES DE MAGNITUD peor.

Así que tienes dos variables para elegir:
  1. Prototipos.
  2. Tiempo de ejecución/entrenamiento.

La seleción es:
  1. Prototipos:
    1. Muchos: Python te permite desarrollar más rápido para garrapatear algo.
    2. Pocos: C te dará mejor rendimiento.
  2. Tiempo de ejecución/entrenamiento:
    1. Corto: Python no te hace esperar mucho sobre el total.
    2. Largo: C te aporta dos órdenes de magnitud menos (de 2 horas a 1 minuto de espera).

Si hacemos la matriz de caso y decisión:

CortoLargo
MuchosPythonPython/C
PocosPython/CC


Y se me olvida si se han de liquidar/entrenar MUCHAS veces.
Pero casi seguro que con esto puedes motnarte esa matriz de selección en cada caso.

Pero repito, hablo desde la barra del bar con un cubata en la mano y no es el primero ni el segundo.
Es decir, no me dedico a esto como tú.
Si me pasé de listo no me detestes mucho.
🙂
 
Última edición:
Gracias,
Gracias a ti opr leer mis desvarios filosóficos.

veo que pensamos muy parecido
Los hechos objetivos(físicosmaterialeso conceptuales inamteriales) son los mismos.
Mentes orientadas a obejeto/proceso suelen otener resultados similares.

y que en lo más importante, la decisión de seguir con Python en deep learning, me indicas que seguir con Python es correcto.
Es que no hay otra.
Es todo Python, por aborrecible que sea.

Al final yo hago prototipos de investigación, y necesito paralelizar algunas cosas , y me apaño.
Pues ahí lo tienes.
Una cosa es montarte algo especial para uan aplicación o investigación especial, pero si necesitas velocidad de hacer churrros, pues se usa la churrera digooo Python.

Para matemáticas simbólicas me voy al Mathematica y vuelvo, o bolígrafo y cerebro si no queda otra,
Hay varios programas por ahí incluso libres.
No se qué tal irñan.
EN mic aso le tengo manía Mathematica y a Wolfram.

pero en mi caso, la chicha está en definir modelos y deducir las fórmulas.
Usa lo que más rápdio te permita garrapatear pruebas y lo que más libreráis tenga.
O sea, Python.
Es inevitable (incluso para mí, el infienro se los lelve a todos los pythonistas).

La programación no es excesivamente complicada en general, aunque sí debe correr rapidito.
Eh no.
O desarrolla rápido, o corre rápido.
Ambos no.

pero por ejemplo, si desarrollo un modelo de represe texto nuevo, necesito acceder a las herramientas de la competencia a efectos comparativos, y suelen encontrarse las librerías en Python.
Claro.
Es uno de los motivos de usar Python.
Casi seguro que si desarrollaras en C,se puede acceder a las librerías de Python desde C.
El esfuerzo para hacer prototipos inciales no merece la pena.

Luego también tienes Dask y Ray para paralelizar y distribuir.
¿Esto es solo para deep learning (DL)o para todo?
Tendré qeu echarl eun vistazo, ni sabía que era
Mi campo no es el DL

Julia es una bala y tiene ciertas ventajas a la hora de paralelizar, ya iremos viendo.
Lo será.
Pero por lo que ví en su momento es nicho de facultades de matemçaticas.
Creo que se basaba en C++ y al sintaxis se hipercomplica digooo, es sofisticada como C++.
(El diablo os lleve a todos los matemáticos shishi, dejad en paz la teoría de categorías y aplicarla al C++) sonrisa: 😉

La verdad es que yo estoy mentalmente anclado en "el pasado",
El pasado siempre fue mejor.
Pero ahora de verdad.

montándome mis ordenadores con sus propias gpu y usando esos lenguajes conocidos.
Anda, como DotCSV.
Igual eres él y todo.

Veo que ahora la gente usa "contenedores", dock era,
Usan Docker porque patata.
NINGUNO te podrá razonar el motivo.
NINGUNO ha hecho el análsis.
TODOS te dirán "tengo al impresión de".
Impresiones, sensaciones.
Seguir la corriente, peces perecid.

herramientas de Google en las que pagan espacio y tiempo de fruta,
En la nube en la nube, todo en la nube.
¿Por qué?
Porue en al nube (y ya).

Kamala Harris: We all the cloud is all above us.
(O una sandez así dijo)

Realidad:
La nube es el ordenador de otra persona.

Y el análsis de costes y esas cosa que hacemos los hombres heterosenshetero hombrista facinerosos para luego si eso.

Vuelvo a ejercer machismofascismo heteropartiarcal, lo siento

y me pierdo un poco.
Los perdidos por abducción son ellos, pero no lo saben.
Son disfuncionales con un título.

Como uso ordenadores con dos gpu y ram elevada, 64 y 128, de momento me apaño.
Si te sirven adecuadamente parammi gusto preferible a la nube.
Pero yo solo soy un anticuado demodé.

Pero toda sugerencia es bienvenida.
Se poco.
Solo filosofar.

Pero me gusta dialogar y debatir.

Ya habrás visto por el hilo, que Python frente a C es 75 veces más lento y con mayor consumo de enetgía.
Es decir, DOS ÓRDENES DE MAGNITUD peor.
En tiempo de ejecución.

Así que tienes dos variables para elegir:
  1. Prototipos.
  2. Tiempo de ejecución/entrenamiento.

La seleción es:
  1. Prototipos:
    1. Muchos: Python te permite desarrollar más rápido para garrapatear algo.
    2. Pocos: C te dará mejor rendimiento.
  2. Tiempo de ejecución/entrenamiento:
    1. Corto: Python no te hace esperar mucho sobre el total.
    2. Largo: C te aporta dos órdenes de magnitud menos (de 2 horas a 1 minuto de espera).

Si hacemos la matriz de caso y decisión:

CortoLargo
MuchosPythonPython/C
PocosPython/CC


Y se me olvida si se han de liquidar/entrenar MUCHAS veces.
Pero casi seguro que con esto puedes motnarte esa matriz de selección en cada caso.

Pero repito, hablo desde la barra del bar con un cubata en la mano y no es el primero ni el segundo.
Es decir, no me dedico a esto como tú.
Si me pasé de listo no me detestes mucho.
🙂

Está bien. Lo de los dockers y la nube, aclarado, no voy tan mal. ¿De qué son los cubatas?
 
Ahora estoy tocando javascript y no está nada mal, también php, vengo de c/c++ y es otro mundo.
 
Gracias,
Gracias a ti opr leer mis desvarios filosóficos.

veo que pensamos muy parecido
Los hechos objetivos(físicosmaterialeso conceptuales inamteriales) son los mismos.
Mentes orientadas a obejeto/proceso suelen otener resultados similares.

y que en lo más importante, la decisión de seguir con Python en deep learning, me indicas que seguir con Python es correcto.
Es que no hay otra.
Es todo Python, por aborrecible que sea.

Al final yo hago prototipos de investigación, y necesito paralelizar algunas cosas , y me apaño.
Pues ahí lo tienes.
Una cosa es montarte algo especial para uan aplicación o investigación especial, pero si necesitas velocidad de hacer churrros, pues se usa la churrera digooo Python.

Para matemáticas simbólicas me voy al Mathematica y vuelvo, o bolígrafo y cerebro si no queda otra,
Hay varios programas por ahí incluso libres.
No se qué tal irñan.
EN mic aso le tengo manía Mathematica y a Wolfram.

pero en mi caso, la chicha está en definir modelos y deducir las fórmulas.
Usa lo que más rápdio te permita garrapatear pruebas y lo que más libreráis tenga.
O sea, Python.
Es inevitable (incluso para mí, el infienro se los lelve a todos los pythonistas).

La programación no es excesivamente complicada en general, aunque sí debe correr rapidito.
Eh no.
O desarrolla rápido, o corre rápido.
Ambos no.

pero por ejemplo, si desarrollo un modelo de represe texto nuevo, necesito acceder a las herramientas de la competencia a efectos comparativos, y suelen encontrarse las librerías en Python.
Claro.
Es uno de los motivos de usar Python.
Casi seguro que si desarrollaras en C,se puede acceder a las librerías de Python desde C.
El esfuerzo para hacer prototipos inciales no merece la pena.

Luego también tienes Dask y Ray para paralelizar y distribuir.
¿Esto es solo para deep learning (DL)o para todo?
Tendré qeu echarl eun vistazo, ni sabía que era
Mi campo no es el DL

Julia es una bala y tiene ciertas ventajas a la hora de paralelizar, ya iremos viendo.
Lo será.
Pero por lo que ví en su momento es nicho de facultades de matemçaticas.
Creo que se basaba en C++ y al sintaxis se hipercomplica digooo, es sofisticada como C++.
(El diablo os lleve a todos los matemáticos shishi, dejad en paz la teoría de categorías y aplicarla al C++) sonrisa: 😉

La verdad es que yo estoy mentalmente anclado en "el pasado",
El pasado siempre fue mejor.
Pero ahora de verdad.

montándome mis ordenadores con sus propias gpu y usando esos lenguajes conocidos.
Anda, como DotCSV.
Igual eres él y todo.

Veo que ahora la gente usa "contenedores", dock era,
Usan Docker porque patata.
NINGUNO te podrá razonar el motivo.
NINGUNO ha hecho el análsis.
TODOS te dirán "tengo al impresión de".
Impresiones, sensaciones.
Seguir la corriente, peces perecid.

herramientas de Google en las que pagan espacio y tiempo de fruta,
En la nube en la nube, todo en la nube.
¿Por qué?
Porue en al nube (y ya).

Kamala Harris: We all the cloud is all above us.
(O una sandez así dijo)

Realidad:
La nube es el ordenador de otra persona.

Y el análsis de costes y esas cosa que hacemos los hombres heterosenshetero hombrista facinerosos para luego si eso.

Vuelvo a ejercer machismofascismo heteropartiarcal, lo siento

y me pierdo un poco.
Los perdidos por abducción son ellos, pero no lo saben.
Son disfuncionales con un título.

Como uso ordenadores con dos gpu y ram elevada, 64 y 128, de momento me apaño.
Si te sirven adecuadamente parammi gusto preferible a la nube.
Pero yo solo soy un anticuado demodé.

Pero toda sugerencia es bienvenida.
Se poco.
Solo filosofar.

Pero me gusta dialogar y debatir.

Ya habrás visto por el hilo, que Python frente a C es 75 veces más lento y con mayor consumo de enetgía.
Es decir, DOS ÓRDENES DE MAGNITUD peor.
En tiempo de ejecución.

Así que tienes dos variables para elegir:
  1. Prototipos.
  2. Tiempo de ejecución/entrenamiento.

La seleción es:
  1. Prototipos:
    1. Muchos: Python te permite desarrollar más rápido para garrapatear algo.
    2. Pocos: C te dará mejor rendimiento.
  2. Tiempo de ejecución/entrenamiento:
    1. Corto: Python no te hace esperar mucho sobre el total.
    2. Largo: C te aporta dos órdenes de magnitud menos (de 2 horas a 1 minuto de espera).

Si hacemos la matriz de caso y decisión:

CortoLargo
MuchosPythonPython/C
PocosPython/CC


Y se me olvida si se han de liquidar/entrenar MUCHAS veces.
Pero casi seguro que con esto puedes motnarte esa matriz de selección en cada caso.

Pero repito, hablo desde la barra del bar con un cubata en la mano y no es el primero ni el segundo.
Es decir, no me dedico a esto como tú.
Si me pasé de listo no me detestes mucho.
🙂

Bueno, lo de Docker porque patata es discutible

Trata de montar una arquitectura distribuida autoescalable sin Docker
 
Bueno, lo de Docker porque patata es discutible

Trata de montar una arquitectura distribuida autoescalable sin Docker
Bueno, para un post tan largo como el mío y que solo me saques eso no está mal.
Te daré la razón.
Pero puntualización
No quise decir "docker porque patata" siempre.
Quizás no quedó claro, me refería a en el escenario de prototipar LLM's como creo que hace el compañero forero.

Obviamente, tiene su aplicación en otros escenarios.
En este sigo pensando que "porque patata".

¿Así mejor? ¿Estasmo de acuerdo?
Espero que sí.
🙂
 
El mejor lenguaje es el que está más lejos. Ya lo aprenderéis por las malas.
 

Estadísticas del foro

Temas
2.049.611
Mensajes
58.153.110
Miembros
190.834
Último miembro
Xxtoxicxx

El blog de burbuja.info

Volver