¿Por qué las empresas coreanas o el gobierno se enfocan en modelos de lenguaje especializados en coreano? Si pensamos en la tendencia actual de los LLM, que mejoran su rendimiento entrenándose con datos masivos a escala de internet, más bien parecería más natural que existieran modelos de propósito general sin importar el idioma, así que no entiendo bien qué ventajas tendría un LM específicamente especializado en coreano.
Si piensas unos minutos más y tecleas unas cuantas veces más, te ahorras pagar 1000 dólares y puedes usar esa plata para comprarte algo de comer. Parece más hangover-think que ultrathink.
Es una idea obvia e importante, pero en la práctica es bastante difícil llevarla a cabo y requiere mucha atención. Creo que los colegas brillantes que me rodeaban tenían una gran capacidad para descomprimir bien la información condensada.
>Lo bueno de lo aburrido (tan limitado) es que las capacidades de estas cosas se entienden bien. Pero, más importante aún, sus modos de falla se entienden bien.
En el texto original hay un enlace relacionado con boring, y por el contenido parece que boring significa = demasiado familiar.
¿No será que lo describió como un stack clásico y aburrido no porque sea tedioso de escribir, sino porque se ha usado tantísimo que ya resulta aburrido?
> Curiosidad y preguntas adicionales: quien resuelve el problema debe hacer preguntas de forma constante e intentar entender el contexto.
Creo que esta parte es la más importante.
Porque la actitud de intentar acercarse a la esencia de las cosas se convierte en la motivación para construir otras soluciones, como minimizar al máximo los handoffs, una cultura organizacional fuerte y reducir la distancia entre el cliente y el código.
Hasta hace poco me enfocaba solo en implementar los requisitos que me daban, pero después de terminar el desarrollo muchas veces sentía que el impacto real era mínimo. Últimamente, antes de discutir los requisitos, pregunto con insistencia "por qué es necesario", y creo que en ese proceso van surgiendo soluciones más cercanas a la respuesta correcta.
Creo que GeekNews está bueno en ese sentido porque tiene una alta densidad de información.
Y el hecho de que termine en estilo telegráfico de verdad parece una optimización de densidad.
Esta pila no parece tan aburrida, al menos hasta este nivel. Si de verdad fuera aburrida, me da la irreverente impresión de que al menos tendría que aparecer algo como Java 1.8 o una versión anterior, o quizá VB...
Gracias.
¿Por qué las empresas coreanas o el gobierno se enfocan en modelos de lenguaje especializados en coreano? Si pensamos en la tendencia actual de los LLM, que mejoran su rendimiento entrenándose con datos masivos a escala de internet, más bien parecería más natural que existieran modelos de propósito general sin importar el idioma, así que no entiendo bien qué ventajas tendría un LM específicamente especializado en coreano.
Si piensas unos minutos más y tecleas unas cuantas veces más, te ahorras pagar 1000 dólares y puedes usar esa plata para comprarte algo de comer. Parece más
hangover-thinkqueultrathink.Es una idea obvia e importante, pero en la práctica es bastante difícil llevarla a cabo y requiere mucha atención. Creo que los colegas brillantes que me rodeaban tenían una gran capacidad para descomprimir bien la información condensada.
Creo que tanto golang como React son lenguajes de programación empresariales “boring” de una nueva era.
Como
boring -> 지루한no se puede traducir al 100% de forma correcta, parece que a los lectores coreanos no les está llegando bien el matiz.Vale la pena verlo antes de negociar el salario.
Hay palabras más adecuadas como
experienced,verifiedoskillful, pero parece que usóboringa propósito para llamar la atención.>Lo bueno de lo aburrido (tan limitado) es que las capacidades de estas cosas se entienden bien. Pero, más importante aún, sus modos de falla se entienden bien.
En el texto original hay un enlace relacionado con
boring, y por el contenido parece queboringsignifica = demasiado familiar.El nombre del modelo de IA suena bastante inquietante, como si fuera algo que saldría en un mundo postapocalíptico o distópico jaja
¿No será que lo describió como un stack clásico y aburrido no porque sea tedioso de escribir, sino porque se ha usado tantísimo que ya resulta aburrido?
> Curiosidad y preguntas adicionales: quien resuelve el problema debe hacer preguntas de forma constante e intentar entender el contexto.
Creo que esta parte es la más importante.
Porque la actitud de intentar acercarse a la esencia de las cosas se convierte en la motivación para construir otras soluciones, como minimizar al máximo los handoffs, una cultura organizacional fuerte y reducir la distancia entre el cliente y el código.
Hasta hace poco me enfocaba solo en implementar los requisitos que me daban, pero después de terminar el desarrollo muchas veces sentía que el impacto real era mínimo. Últimamente, antes de discutir los requisitos, pregunto con insistencia "por qué es necesario", y creo que en ese proceso van surgiendo soluciones más cercanas a la respuesta correcta.
Parece que en el extranjero eso se considera una stack aburrida.
En realidad, Go es simplemente la opción más fácil para crear un servidor web...
Parece que piensan que para que no sea aburrido hay que desarrollar con algo como Rust o lenguajes del lado de FP.
Quiero vivir en el mundo aburrido de Postgres, Golang y React.
Más o menos Linux kernel 2.6.29...
Historias demasiado obvias... tan obvias que estamos pasando por alto cosas importantes...
El simple hecho de que usaron gRPC... jajaja
A mí también me vino primero a la cabeza algo como: ¿que Go es aburrido?
Diría que algo como Classic ASP sí podría considerarse aburrido.
Creo que GeekNews está bueno en ese sentido porque tiene una alta densidad de información.
Y el hecho de que termine en estilo telegráfico de verdad parece una optimización de densidad.
Esta pila no parece tan aburrida, al menos hasta este nivel. Si de verdad fuera aburrida, me da la irreverente impresión de que al menos tendría que aparecer algo como Java 1.8 o una versión anterior, o quizá VB...
Escribir código nunca fue realmente el cuello de botella