choquin escribió:

Dem0 escribió:Los materiales los estuve ojeando y me resultar muy interesantes. El lunes que viene me paso por una clase de Algo I a ver que onda.

che, al final fuiste?

Siempre que me hacía una tarde nos terminabamos juntando con mi grupo para hacer un TP (los días de las clases coincidimos todos). Eso sumando a que avanza el cuatrimestre y las demás matérias me llegan hasta el cuello...

Igual estoy leyendo los apuntes con cosas nuevas en el bondi :p

Me leí todas las páginas del tema, pero se me siguen presentando algunas dudas. Por ejemplo, me contaron que en Sistemas se ve mucha programación, sin embargo leo en internet que en las charlas dicen "si quieren programar y van a sistemas, están equivocados". Por un lado, en el futuro quiero diseñar y programar o modificar software, lo que me inclina a Ciencias de la computación; pero por otro lado, me gustaría crear mi propia organización o empresa, para lo cual me serían útiles muchas materias de Ingenieria en sistemas. En fin, ¿qué opinan?
Gracias por leerme.

Cita:Por ejemplo, me contaron que en Sistemas se ve mucha programación,

El que te conto eso es un mentiroso.
(aunque talvez dice que en Ciencias se ve MUCHISIMA programacion, por lo que habria que definir el termino "mucha").

Cita:Por un lado, en el futuro quiero diseñar y programar o modificar software,

Diseñar y programar software, por lo que me enseñaron en la facu, son dos cosas totalmente distintas.

Del primero se encarga alguien de sistemas.
Del segundo, programadores, (gente de Ciencias que no consigue un trabajo mejor, gente de Sistemas que recien comienza, etc).

Entonces, si fuera ingeniero, es decir, orientado a "diseñar software", también podría programarlo sin mayores inconvenientes? Porque ambas cosas me interesan.

Para aprender a programar como dios manda... Sistemas es una cagada. Las materias integradores de esta carrera se enfocan en diseñar el sistema con diagramas y documentos técnicos que explican su funcionamiento.

O sea que si a eso le quiero sumar programación, tengo que aprender por mi cuenta.

luciano escribió:O sea que si a eso le quiero sumar programación, tengo que aprender por mi cuenta.

Vas a aprender a programar, pero no vas a aprender a hacerlo tán bien como si estudiaras CC. Obviamente también podés estudiar/practicar por tu cuenta.

¿Pero no era que te enseñaban bastantes paradigmas, como para que después vos puedas aprender tranquilamente cualquier lenguaje?

Todo depende de QUE COSAS te gustaria programar. Por ejemplo, si el dia de mañana te queres poner una empresita de SW tipica, con lo que ves alcanza, pero si pensas programar cosas de bajo nivel, onda drivers, kernels de SO, o compiladores, te conviene estudiar CC.

Thorne escribió:¿Pero no era que te enseñaban bastantes paradigmas, como para que después vos puedas aprender tranquilamente cualquier lenguaje?

Nunca dije lo contrario.

No sólo cosas de bajo nivel como dice ebric, sino también software atípico como sistemas de tiempo real donde la performance y "qué haga lo que debe hacer" son fundamentales (hay que destacar que los CCs hacen muchísimo hincapié en la eficiencia y correctitud -nada de testing barato, sino eficiencia y comprobación matemática-).
Además, la profundidad en matemática que tienen les da la posibilidad de, si se orientan a eso, de desarrollar motores gráficos, sistemas criptográficos más seguros, o soft de procesamiento de audio.

Thorne escribió:¿Pero no era que te enseñaban bastantes paradigmas, como para que después vos puedas aprender tranquilamente cualquier lenguaje?

Si Thorne, para q te des una idea, ya desde algoritmos y estructuras de datos 1 ves 1 lenguaje de Especificación Formal, 1 lenguaje de Programación Funcional (Haskell) y 1 lenguaje Imperativo (C++) (en ese mismo orden, para que aprendas a especificar de manera correcta antes de que te mandes a programar) bueno y más adelante, después de q aprobas Lógica y Computabilidad, tenes materias como Paradigmas de Lenguajes de Programación y Teoría de Lenguajes.

pablo escribió:No sólo cosas de bajo nivel como dice ebric, sino también software atípico como sistemas de tiempo real donde la performance y "qué haga lo que debe hacer" son fundamentales (hay que destacar que los CCs hacen muchísimo hincapié en la eficiencia y correctitud -nada de testing barato, sino eficiencia y comprobación matemática-).
Además, la profundidad en matemática que tienen les da la posibilidad de, si se orientan a eso, de desarrollar motores gráficos, sistemas criptográficos más seguros, o soft de procesamiento de audio.

Exacto, se ven los teoremas de correctitud, terminación e invariante, vas a ver demostraciones de que el programa cumple con la especificación matemática, o sea aprendes a demostrar que el programa es correcto, esto es muy parecido a demostrar un teorema matemático y más adelante ves complejidad algorítmica que te sirve para tener una idea teórica de performance de distintos algoritmos. :whip: :rofl:

Todo bien mientras que no te metan algo de lógica dinámica :lol:

Eso ya es demasiaaaaaaaaaa...aaaaaaaado teórico para alguien que quiere dedicarse al desarrollo de software.

Análisis y correctitud de algoritmos es bueno saberlo, aunque no sea común en la práctica. Por lo menos tener una idea del crecimiento cuando vés un código recursivo.

Que Lenguaje de Especificación Formal ven??? Que es eso???? BNF???

Saludos!

Especificar te sirve para empezar a pensar el problema sin necesidad de ver como resolverlo...

O sea, se basa en el "Que?" y no en el "Como?"

Que es lo que debería cumplir un programa para que sea correcto.

Y se basa principalmente en las Precondiciones de un problema y las Postcondiciones.

voy a poner un ejemplo clásico de algoritmos 1, de cálculo de factorial. (voy a poner el código lo más simple posible para que todo el mundo entienda, capaz es un poco ingenuo el problema y la manera en que lo escribo, pero la idea es que nadie se quede afuera )

******
Especificación

 problema factorial (x: Int) = res : Int {

     requiere: x >= 0

     asegura res == prod[1..x]

}

Bueno, lo que dice es que tenes un problema que se llama factorial, una variable de entrada x y una de salida res que pertenecen a Z, requeris que el usuario ingrese valores mayores o iguales a cero, y aseguras que el resultado va a ser la productoria de la secuencia de los números entre 1 y la variable de entrada.

Pero obviamente, esto no te dice cómo es el algoritmo que vas a usar, ni que código tenes que escribir, sino, que es lo que ese algoritmo debería cumplir.

Código en Imperativo (C++)

 int  factorial (int x) {

     int f = 1, i = 0;

     while (i<x) {

          i = i + 1;

          f = f * i;

     }

     return f;

}

Código en Funcional (Haskell)

 factorial :: Int -> Int

factorial 0 = 1

factorial n = n * (factorial (n-1))

Si bien los algoritmos son distintos y de hecho están escritos en lenguajes que pertenecen a dos paradigmas distintos, ambos cumplen con la especificación y ambos son correctos.

******

O sea, la especificación no te dice como resolver el problema... pero si la especificación es correcta y vos te inventas un algoritmo que cumpla con la especificación y haces la demostración, entonces el algoritmo es correcto.

Además, después de tanto especificar, esto te ordena la cabeza como para que ya pienses los valores que romperían el programa, cómo hacer para que no tenga errores, o al menos tenga menos etc.