Cita:Un ejemplo en el que conviene que este todo junto ? No se, pero me parece idiota pensar en absolutismos.
La idea de paradigmas, es meterte en la cabeza lo que es "politicamente correcto". El flaco no te va a enseñar los casos en los que deberías de hacer excepciones, porque son cosas hiper especificas, y no son cosas que se pueden enseñar, si no que es un criterio que vos tenes que formar. Para mi, si te conviene que esté todo junto, definitivamente la estas errando de paradigma.
Puede ser que te veas obligado a hacerlo por algun motivo. Lo cual no significa que esté bien, si no que simplemente no tengas escapatoria.
Cita:Vos mismo lo dijiste, te reprobaron porque pusiste que devuelva 1 o -1
Y eso me parece reverendamente pelotudo, y quien te lo corrigio, de nuevo mi opinion, es un forro resentido de mierda.
Mira, el "no nos gusta que lo hagas asi", no es un malentendido, te dicen en la cara "No nos gusta que lo hagas asi: REPROBADO". Es mala leche.
A mi me parece que no es una pelotudez por lo de 1 o -1. Porque si bien es una linea re boluda:
A ) No estás siendo expresivo.
B ) No estás respetando el paradigma. Entre tantas cosas, encasillarte en las buenas practicas de un paradigma, hace que tu codigo sea mas legible.
Ponele que en el codigo en el que yo pongo 1 o -1, viene un programador de C y hace que su funcion sea 0 = false, 1 = true. Despues viene uno que mamó qbasic, y hace que -1 = false y 0 = true. Viene uno y hace que devuelva true o false. Por ultimo, viene otro y no te retorna nada si está todo bien (void), y si hubo error, tira una excepción. Al final, termina siendo un caos. Podrás decir que la gente que programa es pelotuda.... pero es algo que, desgraciadamente, veo en el dia a dia en mi laburo, y es una reverenda cagada. Un paradigma te da convenciones, generalmente justficadas bajo alguna perspectiva en particular.
En el caso del 1 o -1, se prefiere otra cosa porque 1 o -1, primero que es un numero magico
, y despues, que no es lo suficientemente expresivo. Una de las ideas, es que el codigo sea entendible de una, y que no tengas que acceder a documentación.
Al igual que con lo de 1 y -1, la mayoría de los casos tienen una justificación, y no es simplemente "me levanté, y dije que hay que hacer las cosas de X manera"
Cita:Ahora, en funcional, como rompes el paradigma ? si son todas funciones !
En funcional, no podes. En haskell, si. Si mal no recuerdo, tenes el Do. Podes escribir codigo como si estuvieses programando en imperativo.
Cita:En logico, como rompes el paradigma ? si lo que haces es consultar a la nube magica de prolog !
Puede ser un tema de convenciones. Conozco muy poco prolog como para poder decirte.
Cita:En objetos... bueno, muy amplio, asi que: En smalltalk, como rompes el paradigma ?
Escribis una clase enorme que tenga todo el procesamiento. No delegas cuando deberías. Y un enooorme etcétera.
El tema es que, que el lenguaje permita hacer algo, no significa que esté bien. Hay ciertas reglas, ciertas normas que conviene respetar. Una vez que tengas en claro eso, es ahi recien cuando podes evaluar "romper el paradigma" o no, dependiendo del contexto. Por eso hay cosas que todavía siguen existiendo.
Cita:Un ejemplo en el que conviene que este todo junto ? No se, pero me parece idiota pensar en absolutismos. No recuerdo un ejemplo, y no se si en mi vida me voy a topar con uno. Pero pensar que jamas es viable, disculpa, pero me parece idiota.
El tema es que el paradigma está pensado para otra cosa. Si queres tener todo junto, y es algo que te conviene vaya a saber porqué, es muy probable que tengas que usar otro paradigma y no ese.
Te repito el caso de los scripts. Es mil veces mas conveniente abrir perl y tirar lineas, a usar java o smalltalk. También es mas sano, es mas mantenible, lo podes utilizar en más lugares, etc...
Te doy este caso, porque es el que me tocó, haciendo scripts que configuraran routers para telmex. En un ataque, quisieron pasar todo a java, y realmente nos dimos cuenta que era mejor hacer todo en un lugar, con un script. Haberlo hecho con objetos "bien", hubiese sido laburo al pedo. Y haberlo hecho con objetos "mal", hubiese sido un codigo bastante inmantenible. El paradigma no se acoplaba a lo que necesitabamos. Luego, cambiamos de paradigma.
Cita:Supongamos el paradigma estructurado: usar break esta mal porque cortas el ciclo de ejecucion y salteas lineas. El if no hace eso ? Evalua una sentencia y ejecuta el bloque (o no) que deba ? Entonces el if tambien rompe el paradigma.
Si te interesa, te explico porqué está mal.
Cita:Casi.El if es distinto de usar un break.Para empezar esa una construccion estructurada estándar. En todos los lenguajes tenes un if,no se si esto es asi con el break.
La idea es que todo bloque tenga solo un punto de salida, para hacer mas legible y predecible el código.
El if respeta eso.
Cita:Si tenes un programa que usa if,podés verificar que es correcto (respecto de una especificacion) usando metodos formales (no me preguntes como se hace,no tengo ni idea).
Con algebra de boole, miniterminos y maxiterminos.
Cagate de risa, jajaja. Un compa de laburo que estudió un par de años Ciencias en la UNC me quiso explicar.... es un re bardo
.
.gif "=)")
) se preguntaran que paso ? En menos de 30 segundos la mina se fue enojada con el 2.