¿Cómo os soltasteis programando?

Merkury

#90 Sin querer meterme en ninguna discusion, tecnicamente hablando no tienes que dividir, tienes que hacer mod, que mod es una division, si, pero eso... que es tonteria discutir sobre esto.

Yo creo que lo mejor seria correr un estupido velo en todo esto y no hacer sangre XD

El pseudocodigo como bien ha dicho Soltrac, si en vez de pretender hacer un mod haces una division, no hay nada que te salve, ahi es cuando el paso de la abstraccion a la codificacion es cuando dices, ostia necesito el resto y ya haces lo que tengas que hacer.

El pseudocodigo no es una panacea, no es la solucion universal a todos los problemas, es una herramienta, puedes usarla o no, hay quien piensa que es inutil (totalmente respetable) y quien pensamos que al reves es muy util, no creo que haya que discutir por esto.

B

Pseudocodigo es como enseñar a contar a un niño. Al principio usara los dedos para contar, cuando sepa escribir usara números y cuando lo haya memorizado, lo hará mentalmente.

No puedes empezar la casa por el tejado si no sabes. Al final todo se resume en hacer los ejercicios una y otra vez, no quedarte con hacerlos una vez o dos porque no sirve (salvo que seas un prodigio).

Yo aprendí con java a hacer el típico programa de gestion de datos y muestreo en pantalla. Y era llegar a casa y ponerme a hacer uno con todos sus métodos. Al principio te saltabas cosas y/o no lo hacias en un orden correcto. Al cabo de días ya lo tenías medio controlado y se te escapaban cosas pero lo básico ya estaba implementado.

Luego llegas al examen y aunque cambiase de ser un dentista, a ser una libreria o un almacen de piezas de mecánica te daba igual, porque la gestión de los datos manejados era la misma. Y claro sólo debías cambiar las piezas que eran diferentes que al final era la UI, texto de muestreo y algún metodo diferente.

1 respuesta
dabolbi

El pseudocódigo es algo conceptual, yo lo interpreto como una "explicación por pasos" para resolver el problema.

Entiendo lo que queréis decir, para hacer un pseudocódigo "estándar" como los que enseñan en el fp/uni, para eso, mejor directamente hacerlo en el lenguaje.
Pero el pseudocódigo es algo que tienes que entender tú, con la nomenclatura que te salga de la polla (si sólo lo vas a utilizar tú, claro, que es el caso), y que te tiene que ayudar a resolver el problema, digamos, "por capas", primero con lo principal que hay que hacer, y después, detallando.

Del ejemplo que habéis puesto, una solución que haría yo rápidamente (seguro que las hay más óptimas xd):

  1. Convertir la lista de entrada en dos listas: una de impares y una de pares. O sea que recorremos la lista de la entrada y cada elemento lo vamos añadiendo a la lista correspondiente (la de pares o la de impares).

  2. Ordenamos las dos listas (una descendente y otra ascendente)

  3. Concatenamos las dos listas

Entonces el pseudocódigo sería:

lista L_ENTRADA
lista L_PARES
lista L_IMPARES
lista L_FINAL

Para cada elemento de L_ENTRADA  [
    Si esImpar(elemento) entonces add(L_IMPARES, elemento) SINO entonces add(L_PARES, elemento)
]

ordenar(L_PARES, ASCENDENTE);
ordenar(L_IMPARES, DESCENDENTE);

L_FINAL = concatenar (L_PARES, L_IMPARES)

Cómo véis, de momento no he tocado nada de divisiones ni mods ni pollas en vinagre... ¿por qué? porque primero necesito saber qué hacer conceptualmente, ya me encargaré luego de ver cómo hacerlo.

Ahora ya sí, tendré que ver cómo hago por dentro las funcionalidades de esImpar(elemento), add(lista, elemento), ordenar(lista, orden) y concatenar(lista1, lista2). Ahora ya es cuando entra en juego el lenguaje, porque hay lenguajes que tienen bibliotecas que te ordenan ya las listas, y otros que lo tienes que hacer tú, pero lo importante es que hemos resumido el problema en 3 pasos.

Por lo tanto, yo creo que para soltarte programando tienes que prácticar mucho, sí, pero lo importante es descomponer el problema conceptualmente, y luego ya lo implementas. Cuando te hayas "soltado", lo que he puesto ahí arriba no lo necesitarás, porque lo tendrás en la cabeza.

1
B

#81 En el caso de 2 puedes hacerlo con &1. De hecho el GCC traduce las divisiones y modulos en potencias de 2 en bitwise shits. Sigues dividiendo y haciendo módulo porque son equivalentes, pero no necesitas recurrir a ninguna instruccion de la familia DIV o MOD.

Si quieres saber n % (2k) puedes hacer n & ((1 << k) - 1). Por ejemplo n % 16 = n & (( 1 << 4 ) - 1) = n&15 = n&0b1111. Es el equivalente binario a sacar los residuos de 10k quedándote sólo con los últimos dígitos.

eXtreM3

#92 pero ni por esas. La repetición no hace que consigas una capacidad de abstracción suprema.

Ya que has hablado de matemáticas, las divisiones con decimales podrías hacerlas a cabeza? 24,62/13,97. Imposible para mentes normales.

La programación es igual, ya puedes ser el amo que cuando te venga un problema complejo no te van a quedar más cojones de tirar de papel y lápiz.

1 respuesta
Merkury
#95eXtreM3:

La repetición no hace que consigas una capacidad de abstracción suprema.

De hecho, si tomamos en cuenta que el limite de la abstraccion lo pondra la capacidad de cada uno, para alcanzar dicho limite, vas a tener que practicar y practicar no es mas que repetir una y otra vez...

varuk

#5 Donde estén los "print("Pasa por aquí puta ya!")" que se quiten todos los debugger :P

Ya en serio, a mi me ayudaba mucho tener un folio y lapiz al lado. Sobre todo en esos inicios... donde muchos ejercicios eran recorridos por vectores y cosas así. Luego hacía la simulación en papel como dice #25 . Mano de santo.

2 1 respuesta
Starshow

#97 todavía recuerdo mi examen de C en la carrera con los printf( "todavía estoy suspendido" ) , que tiempacos aquellos, eso era depurar a pelo :qq:

wineMan

#72 Llevo 16 años en el mundo dev. Te aseguro que todo ese tipo de herramientas UML son sólo "útiles" para comunicar y/o documentar a personal técnico. Yo apenas las utilizo puesto que no se me requieren en mi puesto de trabajo y para mí mismo ni de coña me hacen falta. Sólo las uso (y no sigo el estándar) si tengo que comunicar a un ejecutivo algún proceso complejo y que lo entienda. Y por eso digo que no sigo el estándar, porque los ejecutivos suelen ser bastante retrasados y no entienden un diagrama técnico.

Por otra parte, llevo años trabajando con metodología XP (me río de los métodos ágiles) y los diagramas con cajitas son una pérdida de tiempo IMO. Prefiero invertir ese tiempo en un código de alta calidad y mil pruebas. No digo que no sean útiles, pero es como plantearse la utilidad de pesar todos los alimentos en miligramos a la hora de cocinar una receta. ¿Posible? Sí, ¿Relación beneficio-coste? Pésima. ¿Recomendable? Si te sobra el tiempo y estás muy aburrido, ok. Pues con las cajitas lo mismo.

Edit: Además, el UML es sólo útil para un boceto global de una arquitectura compleja, pero andar ahí con un diagrama de secuencia para ilustrar un puto login, perdonad... pero es de ser inútiles. Y lo voy a ilustrar:

El siguiente diagrama, si el código está bien escrito, no haría falta porque leyendo el código se vería claramente:

Ahora, si el programador es tan inútil de perder media hora dibujando eso para luego implementar un código de mierda con dos funciones de 500 líneas cada una.... Pues esto es lo típico que suele suceder en el mundo real. Yo huyo de cajitas.

4 respuestas
B

#99 ¿Qué lleves 16 años en el mundo dev te da la razón o como va esto?

2 respuestas
wineMan

#100 No sé si me da la razón o no. Peor que que no te hayas leído o hecho referencia a mi argumentación y te hayas quedado en los 16 años que llevo en el mundo dev.... mejor me reservo mi opinión. Ya sé con quién no voy a debatir en el hilo.

Merkury

#99 #100 Nadie ha hablado ademas de UML. Estabamos hablando de pseudocodigo...

UML esta claro que no es para ayudarte a entender conceptualmente nada cuando estas picando codigo, es para crear documentacion que pueda ser entendida, como bien dices, tanto por tecnicos como por no-tecnicos.

Ojo que si un analista te trae todo el analisis de un proyecto antes de picar, pues oye, tampoco va mal eh.

1 respuesta
varuk

#99 No estoy de acuerdo... cuando hay proyectos grandes creo que es muy importante, aunque nadie lo haga, crear diagramas como los que tú has hecho, al menos de las partes más engorrosas.

Por ejemplo, un diagrama siempre del punto de entrada del programa y por donde comienza todo creo que es básico si sabes que en el futuro otra persona va a continuar ese proyecto.

wineMan

#102

#72Merkury:

Vamos que no entiendes la utilidad del pseudocodigo... imagino que tampoco haras diagramas de flujo, etc?

...

Joder, vuelve uno a mv/dev después de años y se encuentra este nivelazo. nothingtodohere
Qué época aquella de PiradoIV, eisen, itnas, kaoD...

Hasta la próxima década. Saludos cordiales.

1 respuesta
Merkury

#104 A ver vayamos por partes:

Lo que tu has puesto de ejemplo no es un diagrama de flujo, es un diagrama de secuencia.

UML tiene distintos flowcharts, pero no me referia a invertir tiempo utilizando UML, perdon por la confusion.

#104wineMan:

Joder, vuelve uno a mv/dev después de años y se encuentra este nivelazo. nothingtodohere
Qué época aquella de PiradoIV, eisen, itnas, kaoD.

Lo dices por confundir un diagrama de flujo con un diagrama de secuencia o como va esto?

freshnco

#99 ha dejado de considerarse XP como metodología ágil recientemente?

Dejando de lado discusiones que no parecen llevar a nada útil, creo que os estáis desviando de la pregunta de #1

Como han dicho varios, en los primeros pasos de la programación (que es el punto en el que está el OP), es fundamental el uso del pseudocódigo.
Poner por escrito que debe resolver antes de tirar una sola línea de código ayuda muchísimo cuando empiezas en esto (y más adelante hay muchas situaciones en las que también).

Yo diría a #1 que, para empezar, paciencia, leer mucho, practicar mucho y ánimo, la programación es en cierta medida como el tan de moda "running", tiene una curva de aprendizaje muy agradecida, y, una vez te vas soltando, todo va saliendo de forma mucho más natural, eso si, hay que dedicarle tiempo.

1 1 respuesta
Merkury

#106 Como consejo tambien una vez que te conoces la sintaxis del lenguaje, leer codigo de proyectos varios que siga standars, que este bien planteado, etc, ayuda tambien mucho.

Mewtwo

Sinceramente decir que pseudocodigo y uml no sirve o es solo para hacer sufrir a la gente hace llorar al niño jesus muchas veces.

Pseudocodigo y sobretodo al principio es muy util y necesario , te ayuda a dividir el problema en pasos sin estar pendiente de la sintaxis que algunos ya se que dominais de lujo pero uno que no tiene ni puta idea se vuelve loco si tiene que estar mirand otodo el rato la sintaxis.

Los uml cuando llegas el primer dia a un proyecto nuevo una minima estructura de un diagrama de clases sobre como realizar las cosas para poder abordarlas como que no viene mal y no vas inventando las cosas sobre la marcha

1 1 respuesta
eXtreM3

#108 y aunque conozcas la sintaxis de un lenguaje a la perfección, es un suicidio -hablando en coste de tiempo- ponerte a picar algo complejo directamente.

Postmortem

El primer "salto" que di a nivel de programación fue con el anidamiento de dos bucles para recorrer un Array de 2 dimensiones, eso para mi fue un mundo

El segundo y definitivo salto fue hacer una práctica entera de 2 dias de programación sin hacer ni 1 prueba de si lo que iba escribiendo funcionaba o no, finalmente el código me decia "Null Pointer Exception" y yo "Mandé?", eso me llevó a mi y a mi compañero 2 días de debug intensivo con el que aprendí definitivamente a programar

No sé si estas experiencias te pueden ayudar de algo, pero lo único que puedo aconsejar es que darte la ostia con el error y meterte de ostias con el hasta que por tus cojones lo sacas es la mejor forma de aprender, puede ser sufrida, puede costar tiempo, puede ser ingrato y puede ser frustrante, pero ese error no te volverá a ocurrir.

EDIT: para aportar algo a lo que discutís, nunca he tenido ganas de hacer pseudocódigo, nunca lo he hecho y las veces que lo he hecho no creo que me aportaran mucho valor, esa mierda al final no compila, y quitando esa obviedad, a no ser que una persona haya estudiado matemáticas no sé como quitarle el tema de la sintaxis le va a ayudar a programar mejor si está aprendiendo precisamente a eso, yo creo que lo mejor es tener las restricciones del lenguaje porque al final te apoyas en ellas, haces burradas y luego descubres que X estructura de control te facilita la vida antes que X mierda que has hecho

1 respuesta
Mewtwo

#110 por que una cosa es saber programar y otra saber programar en el lenguaje x, el primero te puede programar en cualquier cosa , el segundo de su lenguaje no le sacas.

Tambien no es lo mismo programar en c , pascal , en java , en haskell etc. El pseudocodigo te permite hacer un algoritmo que luego solo te tienes que preocupar en adaptar a la sintaxis que uses. Es un paso que si nunca has programado te ayuda a ver y simplificar mucho las cosas. Luego ya veras con el lenguaje que estructura de datos te vienen mejor y que usar. Pero lo primero saber por donde van los tiros

1 respuesta
Postmortem

#111 Si nunca has programado, como vas a saber programar en Pseudocódigo así de primeras? tendrás que saber lo que te ofrece el ordenador?

Se que todo se puede declarar con algoritmia blaublau y blaublau pero yo creo que el 99% de aqui aprendemos a programar a base de ostias contra el ordenador

3 respuestas
Mewtwo

#112 yo he aprendido a base de ostias con x lenguaje por lo especifico o las manias que sea , pero a pensar el algoritmo no me enseño a base de que el compilador me salga una declaracion invalida o un puntero que va a donde no debe xD

Son dos cosas totalmente distintas , yo no tenia ni repajolera idea de programar y aprendi con pseudocodigo y luego pase a pascal por que era un calco clavado de pseudocodigo.

Si me hubiera pasado a c o java me hubiera tirado muchooooo de los pelos por las manias de esos lenguajes.

B
#112Postmortem:

Se que todo se puede declarar con algoritmia

No entiendo eso

Merkury
#112Postmortem:

Si nunca has programado, como vas a saber programar en Pseudocódigo

:psyduck: :psyduck: :psyduck:

Por curiosidad, lo de pegarte dos dias programando sin probar te parece lo mas efectivo para aprender? XD

Las restricciones del lenguaje que tu llamas, te limitan enormemente, porque no piensas en resolver un problema, piensas en hacer un codigo que funcione y ese enfoque imagino que a quien le valga, guay, pero esta bien abstraerte del lenguaje y dise;ar soluciones aplicables a cualquier lenguaje.

Soulscx

además que yo sepa el pseudocodigo es distinto para cada persona. No sé si hay un estandar para ello.
He visto cosas como
Hacer N veces
codigo
fin hacer

para 1 hasta 10
codigo
fin para

quiero decir que es como hacer el algoritmo en sucio, y no tienes porq saber nada de un lenguaje especifico, solo las instrucciones basicas de cualquier lenguaje. Es worth utilizarlo ( sobretodo cuando estas empezando a programar).

1 respuesta
Merkury

#116 Efectivamente, el pseudocodigo no tiene unas reglas formales a seguir.

1 respuesta
eXtreM3

#117 hay alguna herramienta que te convierta código a pseudocódigo?

1 respuesta
Merkury

#118 Yo desarrolle una que te convertia pseudocodigo en diagramas de flujo como PFC

Y creo que si, pero no le veo mucha utilidad.

1 respuesta
eXtreM3

#119 hombre, te ayudaría a ver qué hace todo el código de otra persona por ejemplo.

1 respuesta