Feda /dev/ - No Javascript allowed

#14315 De cocretas.

#14323 La verdad es que hace unas lentejas de muerte

#14313 Me lo he leido y está interesante, aunque creo que para el mundo de negocio no tiene mucho sentido. Por ejemplo la parte de no reusar nada y haverlo todo de 0, es reinventar la rueda, y poniendo de manifiesto que no tiene en consideración la rotación de la gente, que cada uno programa de una manera y tal... el artículo está alejado de la realidad.

Entiendo que el artículo se refiere a otros ámbitos, más personales y donde no hay reglas de negocio que impliquen hacer cosas complejas con recursos limitados.

Las abstracciones que tanto parecen odiarse en esta filosofía son una bendición para negocio, reducen tiempo dedicado a cosas que no tienen nada que ver con el problema a resolver (bases de datos, red, escalabilidad, renderizados, so, etc..) Lo cual se traduce en ahorro de costes por todos lados. ¿Que hay perogrullos haciendo software de mierda y vendiendolo? Por supuesto.

Fourth puede tener sentido en ciertos nichos dónde se controle el hardware y software, como sistemas embebdidos. Pero si tienes que establecer las abstracciones y/o reglas, ya puedes ser el ceo y hacertelo tu todo con pocas expectativas de delegar en nadie.

Pajeet for ever.

Pd: para las cocretas, hechar muslos de gallina a la sopa y lo haceis con la carne, divinas.

#14313 A ver lo del binding como tal lo tengo entendido, o eso creo. Al final interpreto que es resolver cosas en tiempo de compilacion, redifinir y modificar definiciones al toque a un nivel potente no habitual (AST o stack). Conozco de LISP los casos de uso de redefinir un objeto al toque y cargarlo en el REPL por ejemplo, esto lo he hecho con Clojure y se que todos lo permiten.

Mi duda era este fragmento donde da a antender que todo lo puedes hacer en tiempo de compilacion.

It is also (very mistakenly) believed by many that abstractions used in programming must have some actual presence in the object code which is produced. Tables of virtual methods from C++ and late binding/polymorphism again come to mind as manifestations of this development philosophy. Instead of developing the software in a way which conveniently processes abstractions at edit time in a metaprogramming framework, current software instead implements abstractions directly into the final object code, leading to slower runtime performance and larger memory footprints.

Y esto no me lo acabo de creer, estoy pensando contra ejemplos. Me cuesta creerme que todo (cualquier problema) se puede resolver en tiempo de compilacion y que la solucion efectiva (no solo el rendimiento y eficiencia sino considerando los tiempos de compilacion/metaprogramacion) sea mejor. No lo tengo claro. Estamos partiendo de que por ejemplo si tienes que leventar y tirar progrmas en un sistema distribuido que puede cambiar sus caracteristicas (configuracion) para obtener las mismas garantias que ahora tienes a nivel de eficiencia necesitarias tener imagenes precompiladas de todas tus soluciones. Y esto no es sotenible. Que tendras mejor rendimiento y eficiencia, obvio. Pero tenemos mas factores a valorar.

Bueno no se, es un texto viejo que no se puede aplicar a hoy en dia porque dudo que el autor tuviese en mente monolitos enormes o microservicios o monolitos modulares. A bajo orden, programacion entiendo lo que dice perfectamente, a nivel de software si se refiere a cualquier programa no lo veo claro.

#14328 exacto esa sera mi serie en el blog. pero eso de que las abstracciones son una bendicion no estoy de acuerdo. mas en el blog (R) SOON (tM)

#14334 Bendición para negocio, que no es lo mismo.

#14336 Muy 50-50. Entiendo el punto, comparto la idea pero no creo en la generalizacion.

Que entiendes como empreas/negocio exitoso?

Si yo creo hoy una empresa de blockchain, saco una IPO y me saco 2M y lo vendo todo soy un empresario de exito????
Si yo tengo a 10 becarios fp/uni picando codigo que cambio a cada temporada y voy tirando y salgo ganando dinero (yo) es un modelo de negocio exitoso?
Si yo tengo a 10 becarios fp/uni picando codigo que cambio a cada temporada y voy tirando y al final pierdo dinero (yo) es un modelo de negocio exitoso?

Reducimos el exito de un negocio al beneficio del fundador/grupo directivo?

Primero tendriamos que definir eso y luego ver si es cierto que las abstracciones y el pica codigo de mano de obra barata funciona para obtener ahorros de costes y por tanto beneficios.

Porque si en lugar de tener 10 becarios de fp por 500e tienes a 3 ingenieros por 2k a la larga sales ganando no?

Es dificil de medir, no se deberia generalizar ni para bien ni para mal, pero sobretodo no hacerlo para mal.

Ademas me parece un discurso inapropiado en la comunidad en general el encararlo de esta manera. Deberiamos hacerlo desde un punto de vista qualitativo si somos ingenieros no?

#14338 El éxito del negocio no depende directamente de la solución técnica utilizada. El fracaso si. Por eso el éxito que pueda o no tener una empresa no afecta al hecho de usar o no una tecnología u otra.

Para resolver un problema de negocio puedes usar cualquier tecnología/metodología, unas te llevarán más tiempo, o más recursos. Cuando estos aspectos son limitados, hay que elegir dónde usar o no abstraccionea/soluciones ya hechas a cada cosa que necesita la solución.
Si no hubiera ninguna abstraccion, todos tendríamos que picarnos el acceso a ficheros para guardar datos, picarnos listas, hashmaps, trees, indices, hasta el quick sort para hacer un crud de empleados y poder guardar sus vacaciones, ¿nos tenemos que picar los timezones a mano? Si ni aún con libs que resuelven el problema principal, el 80% de los devs siguen metiendo la gamba. No se ni la de veces wue he tenido que explicar los TZs... hasta a la gente de US que es un facepalm de la leche.

Si no son una bendición, ya me dirás lo que son.