Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Lifecasi0

#44917 pasa enlace y echo CV. Que visto el nivel...

desu

Pagina 1500 ya.

1 respuesta
Tuskus

#44942

1 1 respuesta
B

Tampoco hay que pasar el threshold de atencion que se da a gente que te causa urticaria

Tuskus

Yo solo querría ver a Desu en un equipo presidido por Gerard Romero ganando esa liga.

3
Dr_Manhattan

Os imagináis los retos de programación de esa kings league? Jajajaja imagino que la final sería picarse un foldleft en JavaScript si es que existe en ese lang, las peliazules llorando porque no saben ni para qué sirve.

Por favor midu, sé que nos lees, hazlo

1 respuesta
JuAn4k4

#44936 NPI porque se supone que es un mvp

TheBrotha

#44943 Mis propuestas de carta:

  • Deuda técnica: La proxima feature la tiene que escribir un becario sin ayuda, no se puede arreglar nada de esa PR hasta la proxima jornada

  • Multicultural: La próxima feature la tienen que escribir en turco

  • Baja paternal: El programador objetivo no programa en esta jornada

  • Scrum: El EM del equipo que la lanza se convierte en el scrum master del equipo contrario hasta acabar la jornada. Los tickets se tienen que resolver.

  • Externalizacion: 2 indios sustituyen a dos programadores del equipo contrario

  • QA: El EM del equipo que la lanza se convierte en el QA del equipo, puede sacar tantos defectos como quiera. Se tienen que resolver.

2
_Rpv

#44946 Molaría una de mv, que tengo ganas de ver @desu vs @Soltrac

Y un asalto de mods, @Fyn4r vs @Jastro

1 1 respuesta
Soltrac

#44949 Yo soy una puta mierda de programador, eso lo sabe todo dios xDDD

1 respuesta
B

#44950 tu no eres uno de los que lleva desde el paleolitico haciendo cheats para juegos? dudo que seas tan malo cabron

2 respuestas
B

#44951 lo que será es malo haciendo las típicas mierdas web, pero no tengo ninguna duda que a pesar de (quizás) ser código feo hace lo que se espera y lo tiene funcionando rápido, dudo que la mayoría del hilo pueda decir lo mismo

PaCoX

Escribis cadenas en funciones y os quedáis tan panchos xd.
Hoy en día ser buen programador es 'no generar deuda técnica', pero claro, la cosa no es tan trivial, según el contexto el objetivo será la velocidad, eficiencia o que sea fácil de leer y mantenible. No es lo mismo escribir un driver, un erp o un compilador... Pero vamos que hay básicos que se dan en primero de carrera como expresar literales como constantes, usar un único return por funcion, no usar goto, breaks, etc xd

3 respuestas
Dr_Manhattan

Cómo están los máquinas? Lo primero de todo. Estáis bien?

desu

#44953 lo de no usar gotos, breaks, single return son tonterías hoy en día.

úsalos...

El paper original de no usar gotos era de 1960 de Dijkstra, es una página, leelo, porque verás que el contexto y lenguaje del que habla murió hace 40 años. Dijkstra hablaba de programación estructurada, lo de gotos ara bad es un click bait de la época.

Luego los break y return es parecido. Tener early returns por ejemplo ayuda a tener invariantes más claras en los algoritmos. Y los break vs return era un tema de compiladores también de los 80-90... Hoy en día el compiler de un buen lenguaje te hará el mismo código optimizado en x86/arm/ir pongas breaks, gotos, mil returns.

Break vs funciones cortas con returns => syntax vs semántica
Gotos => buenos
Early returns => Buenos

Si por ejemplo estas en rust en tu main y quieres hacer un bucle sobre un slice de structs, y dentro buscas algo. Que haces un break con un flag o una función auxiliar? Te habrán dicho que los break son malos pero no es cierto, si tu escribes esa función en Rust, al ser la memoria y stack más explícitos verás que llamar esa función auxiliar cada vez tendrá un coste... A veces clonar objetos enteros... Y si no se llama cada vez es que el compilador la pone in-line. Y si.. Si hace eso tienes un break!

Sintax vs semàntic... En este caso TODOS queremos break y solo una subrutina en casos extremos.

Es como discutir si pasamos por puntero o copiamos un struct. Siempre copia excepto casos extremos. Decir que pasar punteros es malo o que pasar por copia caro. Es de fpero.

PS lo de expresar literales como constantes es un tema más de comptime vs runtime y lifetime... No entro xq es más complejo pero siempre comptime antes que runtime. Y entra el Sintax vs semàntics xq depende del lenguaje y entorno de ejecución. Además de ver si es una lib que se exporta o no... Complejo. Para nada algo básico.

2 respuestas
Soltrac

#44951 hombre.....se mapear un driver en kernel y demás.

Pero luego, escribir código limpio o implementar de memoria un algoritmo de búsqueda pues no xd. Yo he visto el advent of code que mucha gente se marca por aquí y hay que tener mucha paciencia xddd.

#44953 a mi eso siempre me ha parecido una chorrada. Muchas veces un early return deja el código mucho más legible. El goto te lo puedo medio comprar aunque hay casos en que es útil, ya los nombró desu en su día

1 3 respuestas
Soltrac

#44955 por qué copiar siempre structs vs pasar punteros?

Yo siempre paso punteros xddd, salvo que no me interese.

Me has dejado loco

1 respuesta
Slowbro

#44953 Eso me habían enseñado, luego ves el uso de gotos en el kernel de linux y es gloria. Si hasta MisraC los admite con un par de matices xD

Yo ya intento no asumir nada sin evidencias de por medio.

#44956Soltrac:

Pero luego, escribir código limpio o implementar de memoria un algoritmo de búsqueda pues no xd.

Si te vale de algo ya somos dos :(

1
B
#44956Soltrac:

advent of code

parsent of code dirás xD

3
PaCoX

Migrando legacy te das cuenta que esas pequeñas cosas son importantes, se empieza una función rápido y al cabo de los años evoluciona como pikachu

B

#44956 mira bro El CLIN COUD es un lobby de calbos con gafas k se dejan $23 en un cóctel Pa ber sise follan a la head of people de la estartar de turno no dejes k socaben tu autoestima tu pikas xeats ellos colesionan funkos Kien gana aki???

arriba makinA

pineda

sabes lo que es un puntero?
si, claro, eso de C

1 respuesta
pantocreitor

#44962 te podría haber contestado que es con lo que marca lo que está diciendo en la diapositiva cuando le explica mierdas al cliente xD

1 1 respuesta
pineda

#44963 o el clásico "eso lo di en la uni"

1 respuesta
B

#44964 "habitualmente googleo estas cosas, intento ser más de la vertiente resourceful que memorística"

ojalá me lo hubiera acabado de inventar

1 respuesta
pineda

#44965 se quedaría un hilo de puta madre de frases de product owners, project managers, bootcampers y similares

1
desu

#44957 si pasas el puntero tendrás que dereferenciar no?

Kaledros
#44955desu:

Es como discutir si pasamos por puntero o copiamos un struct. Siempre copia excepto casos extremos. Decir que pasar punteros es malo o que pasar por copia caro. Es de fpero.

Pues adivina qué me recomiendan todos los recursos de Go que llevo dos semanas viendo porque vamos a pivotar a Go en el curro. Que por eso es tan rápido, que paso por referencia siempre, etc. Y yo pensando que vale, será más rápido, pero pasar por referencia me jode la inmutabilidad completamente y tengo que hacer malabares para que no me modifiquen los modelos de dominio.

1 1 respuesta
desu

#44968 se recomienda que siempre al implementar métodos de un estructura sea por referencia.

(s *service)

Pero en funciones que usas el call stack no

1 respuesta
JuAn4k4

Si quieres speed pasa el profiler, sino, haz lo que más convenga. Pasar por copia permite inmutabilidad y que no se líe parda, es mejor para la salud mental del que programa.

Hay casos en los que tiene sentido, por ejemplo cuando hablamos de estructuras de datos royo árboles, maps, o uso interno entre métodos privados de un módulo. Aún así la estructura de datos no debería mandarse por toda la app.

¿No había de hecho un famoso blog sobre “want speed, use pass by copy” de C? aunque no siempre fuese verdad, pero me hace gracia que ahora en el curso de go sea al revés, “want speed, pass by reference”, cuando ya se discutió en C en su día que siempre depende. No se como aplicará a go.

Venga @desu márcate unos micro benchmarks

1 respuesta

Usuarios habituales