¿Qué lenguaje elegir para aprender a programar?

Pues eso, me encantaría aprender a programar soft y no se con que lenguaje empezar.
Sé HTML y un poco de PHP.
Saludos!
quizá para aprender lo mas fácil sea algo así como pascal o C.
una vez cojas soltura prueba java o C++
Gracias :-)
Me estoy mirando C++ y como a todo se le tiene miedo jeje.
Hay mucha diferencia entre C y C++?
Pascal lo descarto de momento y me interesa bastante java por su integración en las distintas plataformas.
MrCell escribió:Gracias :-)

Hay mucha diferencia entre C y C++?



Dos signos de +.........

Si ,es malo,pero lo tenia que decir..... [jaja] [jaja] [jaja]
MrCell escribió:Gracias :-)
Me estoy mirando C++ y como a todo se le tiene miedo jeje.
Hay mucha diferencia entre C y C++?


La mayor diferencia es que C++ está orientado a objetos (clases)

PD: En la universidad programamos en C++ principalmente, pero antes de nada se empieza haciendo algoritmos en pseudocódigo para entrenar la capacidad de abstracción y evitar vicios.
maponk escribió:

Dos signos de +.........

Si ,es malo,pero lo tenia que decir..... [jaja] [jaja] [jaja]

jjajajajjaa muy buena [beer]
Empezaré primero por C y luego C++
MrCell escribió:jjajajajjaa muy buena [beer]
Empezaré primero por C y luego C++


Sip, me parece la trayectoria correcta. Como C++ es (casi) totalmente compatible con C, puedes verlo como una extensión una vez sepas C.
python me parece bastante bueno para empezar, es muy sencillo. Mucha gente suele empezar con C (yo mismo hace años), en mi universidad lo primero que enseñan es Ada (a los informáticos, pascal a los industriales, teleco y demás), luego nos meten C, luego C++, etc. Ahora se tiende a enseñar java en muchas universidades, o eso nos dicen.

Si tuviera que elegir un lenguaje ahora para empezar, elegiría python o C.
Yo, como bien a dicho amuchamu empezaría por python, que no es muy quisquilloso en principio, luego cuando tengas claras las estructuras básicas pasa a C, y cuando tengas claro C, empieza con C++ y las ventajas (y dolores de cabeza) que ofrece.

Si quieres obtener desde un principio resultados mas "vistosos" no descartaría por empezar con Visual Basic, que tampoco es complicado y verás ventanitas y eso.
Yo empezaría con C, ya que va a ser con el que más aprendas y con el que luego tendrás menos problemas para pasar a otros lenguajes.

Yo en la uni empecé con ADA, y después en varias asignaturas hemos dado C y Java.

Si quieres un libro para aprender C, comprate "The C Programming Language (Second Edition)" de Brian Kernighan y Dennis Ritchie, yo lo compré en Amazon por 30€ o así en inglés.

Agur.
Yo usaba "Programacion Estructurada en C" de James Antonakos y me vino muy bien en l primer año en la universidad.

Salu2
Yo te recomiendo C++ directamente, all principio no te tendras que pelear con cosas memoria dinamica (vector, string...) ni con punteros para el paso de parametros

Tambien esta bien java (aunque lo he tocado muy poco), tiene un cierto parecido a C++, pero no te permite tantas guarradas

Python no te lo recomiendo para nada para aprender, primero por que la sintaxir es muy "debil" y luego con cualquier, aunque te obliga a indentar bien el codigo (error bastante comun en la gente que empieza a programar) pero especialmente por que no tiene tipos, ni es necesario declarar variables y eso puede hacer que cojas muy malos habitos
d34th escribió:Yo te recomiendo C++ directamente, all principio no te tendras que pelear con cosas memoria dinamica (vector, string...) ni con punteros para el paso de parametros

Tambien esta bien java (aunque lo he tocado muy poco), tiene un cierto parecido a C++, pero no te permite tantas guarradas

Python no te lo recomiendo para nada para aprender, primero por que la sintaxir es muy "debil" y luego con cualquier, aunque te obliga a indentar bien el codigo (error bastante comun en la gente que empieza a programar) pero especialmente por que no tiene tipos, ni es necesario declarar variables y eso puede hacer que cojas muy malos habitos

Creo que te haré caso jeje.
Empezaré directamente con C++ aún que sea duro [toctoc]
Me he mirado manuales y seguramente me compraré algun libro.
Muchas gracias a todos [barret]
MrCell escribió:Creo que te haré caso jeje.
Empezaré directamente con C++ aún que sea duro [toctoc]
Me he mirado manuales y seguramente me compraré algun libro.
Muchas gracias a todos [barret]


Si vas a empezar por C++ (cosa que no recomiendo, pero bueno...) mira que el libro te enseñe a programar desde 0, ya que muchos dan por hecho que sabes algo de C o de programación en general.
Empieza por c y cuando lo controles pasate a c++ si quieres. Si sabes programar en c vas a aprender cualquier otro idioma mas facil.

Saludos
Hay alguna razón en especiall por las que recomendar C sobre C++?

Evidentemente no creo que sea lo mas sensato empezar metiendose ocn orientacion a objetos, y demas, pero C++ puedes hacer las cosas "al estilo C" sólo que hay algunas cosas "mas limpias" aunque lo mismo estoy pasando algo por alto
En mi opinión es mejor empezar con lo "dificil" (gestión dinámica de memoria, punteros, etc...).
Por ejemplo, si empiezas con C, entiendes por que a una función le pasas una dirección de memoria o simplemente el contenido, y luego cuando pases a otros lenguajes lo entenderás a la primera.

En cambio, si lo haces al revés, luego te va a costar entender por que en C a veces tienes que pasar un punto y otras veces no.

Sobre C++ no puedo opinar, ya que no tengo ni idea de él.

Agur
La verdad es que visto de esa manera es verdad

Piensa que yo empece con C++ y por eso lo veo completamente logico, pero es cierto, casi mejor empezar con C y cuando cojas cierto nivel pasar a C++ por la orientación a objetos y tal

Aqui tienes un curso bastante bien para empezar (esta incompleto, pero para empezar te servira)
http://www.matados2k.es/?q=taxonomy/term/7&page=1

Cuando te veas con ganas de meterle mano a C++ te recomiendo "Thinking in C++", de Bruce Eckel, ahi tambien te enseña algo de diseño modular y de que va toda la orientación a objetos y demas
Yo empece con Java (primer lenguage de programacion) en la Uni este año y de puta madre :-P
Te iba a decir que empezaras con Basic, para mí un paso recomendable para todo programador novel. Como veo que ya has tocado PHP, te recomiendo empezar por Turbo Pascal, lenguaje totalmente didáctico y muy fácil de aprender.

Después pasa a los lenguajes orientados a Objetos como C++ o Java.
C es un coñazo. Su sintaxis, sus punteros, su rigidez, su -no- manejo de la memoria dinámica, en fin, todo. Potente, rápido, cojonudo, todo lo que querais, sí; pero un coñazo.

Con python casi te puedes olvidar de las cosas propias del lenguaje de forma que puedes centrarte en programar. Es cómodo, el código sale bonito. Para aprender aritmética de punteros y operadores de desplazamiento de bits siempre hay tiempo.
Aquí cada uno opina una cosa, pero lo que está claro es lo que dijo amuchamu:

A los ingenieros de teleco se les enseña Pascal. A los ingenieros de informática, ADA.
Y luego ya se da el paso a C, Java, ensamblador, .. y todo lo demás.
Es porque Pascal y ADA te estructuran la cabeza, y se aprende a programar de manera correcta con ellos.

BASIC, que fue un Dios en su época, ahora resulta que es un ejemplo de cómo no hay que programar.


De todas maneras MrCell, como me imagino que lo que quieres es empezar ya a hacer tus cosas chulas para Windows, y no te quieres pegar 2 años estudiando programación para ser un programador profesional, ¿por qué no empiezas con un Visual Basic, Visual C, o Delphi?
Hay tutoriales muy sencillos, y aunque no sea el método correcto de aprender a programar, en 10 minutos ya habrás compilado un programa con sus ventanas y botones y tó. ^^


Saludos.
Yo soy (casi) ingeniero y en la carrera en primero me enseñaron Python... luego C, ensamblador, C++ y PHP entre otros, pero el primero para los novatillos es Python, que como dije en posts atras, es menos quisquilloso.

Pero que para gustos los colores :D
Yo soy (casi) ingeniero y en la carrera en primero me enseñaron Python... luego C, ensamblador, C++ y PHP entre otros, pero el primero para los novatillos es Python, que como dije en posts atras, es menos quisquilloso.


Je,je... tu estudias en la UJI xD

Mi experiencia con Python fue muy buena, pues con el es fácil aprender a programar. Además siempre es muy útil para maldecir a los sucesivos lenguajes que vayas aprendiendo por no tener una sintaxis tan estupenda como este.

Un saludo!!
Razorblade escribió:Aquí cada uno opina una cosa, pero lo que está claro es lo que dijo amuchamu:

A los ingenieros de teleco se les enseña Pascal. A los ingenieros de informática, ADA.
Y luego ya se da el paso a C, Java, ensamblador, .. y todo lo demás.
Es porque Pascal y ADA te estructuran la cabeza, y se aprende a programar de manera correcta con ellos.


Pues sí. Yo veo que un buen lenguaje para aprender a programar desde cero, es Pascal/Modula 2. No tiene el tremendo coñazo del manejo de punteros de C, y no tiene tampoco orientación a objetos, por lo que te "obliga" a aprender a programar con el paradigma imperativo. Es un lenguaje muy didáctico, no en vano como te dicen, hace unos años era lenguaje típico de enseñar programación en 1º de ingeniería (yo soy teleco).

Luego una vez que ya controles el tema, puedes seguir con C++/Java para la orientación a objetos. Es bueno que pilles las 2 formas de pensar por separado, sin mezclar cosas. Quiero decir, creo que es necesario el "shock" que se produce cuando vienes de la programación imperativa y pasas a ver orientación a objetos XD esa sensación de decir: pero pero pero! qué me estás contando! XD

Por cierto, si python es menos quisquilloso... precisamente será menos recomendable para principiantes, no? No se, yo pienso que al principio todo lo que sea forzarte a estructurar las acciones, es buena cosa.

Ah, y una cosa que veo útil también, sobre todo al principio, es que el lenguaje sea compilado, y no interpretado (como java y python). Por aquello de tener una idea de lo que hace un compilador. Y usa un debugger, que la verdad es que es muy interesante ver la ejecución paso a paso de un programa cuando tienes algún error, luego ya podrás aprender la forma de pensar que necesitas tener, y hacerlo de cabeza.
Yo empezaría, si quieres aprender a programa bien y sabiendo lo que haces, con c++. No es tan abstracto ni permisivo y es más complejo que otros, pero te obligará a saber lo que estás haciendo que es mucho más importante. Y aprenderás punteros y gestión de memoria, que es básico. De hecho es tan importante que en Java y C#, básicamente lo único que usas son punteros, aunque traten de ocultártelo.

Python y demás programas son muy bonitos y fáciles, pero puede hacer que cojas muy malos hábitos, que es lo que suele pasar con lenguajes de tipado débil. Además es mucho más fácil vienes, por ejemplo de c++, con la ventaja de que ya sabrás en realidad lo que hace por dentro.
MrCell escribió:jjajajajjaa muy buena [beer]
Empezaré primero por C y luego C++

Yo optaría por empezar con C y continuar con C#.
JAPosti escribió:Yo optaría por empezar con C y continuar con C#.

Y ese cambio? Para eso empiezas con c++ haciendo algo de prog estructurada y clases, y luego ya vas a lo fácil.
zheo escribió:Y ese cambio? Para eso empiezas con c++ haciendo algo de prog estructurada y clases, y luego ya vas a lo fácil.

Ya... siempre me ha gustado ir a lo fácil desde un primer momento... aunque efectivamente, no siempre es lo mas recomendable...
zheo, python tiene tipado fuerte.

lo que en realidad hace por dentro también puedes investigarlo en python... si te interesa. Con C estás obligado a ello aunque sea tu primer día de clase. En C++ por suerte existen las referencias y los iteradores, que te abstraen un poco de todo eso.
Nulukkizdin escribió:zheo, python tiene tipado fuerte.

He querido decir tipado estático, para no poder hacer inadvertidamente cosas como esta

a = "hola amigo"
b = ", que tal?"
c = 34.56

print (a+b)

b = c
print (a+b)

Y tenemos un pete ;)

lo que en realidad hace por dentro también puedes investigarlo en python... si te interesa

Interesar interesa
;)
El problema no es que te interese, el problema es que es algo que se debe saber, al menos a un nivel básico. Y estos lenguajes te lo ocultan. No son buenos para el principiante.

Edito (malinterpretación mía)
En C++ por suerte existen las referencias y los iteradores, que te abstraen un poco de todo eso.

Pues no se cómo vas a mínimamente entender las referencias y los iteradores sobre todo, sin saber lo que son los punteros...
Java es realmente intuitivo, todo son objetos. Todo es a base de 'news', olvidandote de rollos de punteros, direcciones de memoria, etc.
Es ideal para los n00bs :)
AuRoN344 escribió:Java es realmente intuitivo, todo son objetos. Todo es a base de 'news', olvidandote de rollos de punteros, direcciones de memoria, etc.
Es ideal para los n00bs :)


Eso es, olvidate de lo que es un puntero, total, en Java los objetos no son más que punteros...

Por eso en mi opinión lo mejor es empezar con C.
En java todo son punteros, si, pero no hay que declararlos de la misma manera que en C. Si el autor del post se lia con C con tanto '*' y '&' siempre puede empezar con java, que como he dicho, todo se reduce a news (que si, que un new no es mas que un puntero al heap, pero vamos, es mas intuitivo que C).

Que peña mas borde...
Solo estoy dando mi opinión, más bien repitiéndola, que ya la he puesto unos post más arriba.

En mi opinión, es mejor empezar con los * y &, así sabes lo que haces, así cuando luego vas a otro lenguaje, entenderás mejor las cosas.

Agur
No si llevas razon, claro. Aprendiendo C aprendes mucho mas y te familiarizas con la mecanica que realmente se lleva en muchos lenguajes de programacion. Yo lo decia por si al autor del post le costaba mucho C y no lo entendia, si lo que queria era programar, que siempre podia 'desviarse a otras ramas' como Java.
AuRoN344 escribió:En java todo son punteros, si, pero no hay que declararlos de la misma manera que en C. Si el autor del post se lia con C con tanto '*' y '&' siempre puede empezar con java, que como he dicho, todo se reduce a news (que si, que un new no es mas que un puntero al heap, pero vamos, es mas intuitivo que C).

...

No si llevas razon, claro. Aprendiendo C aprendes mucho mas y te familiarizas con la mecanica que realmente se lleva en muchos lenguajes de programacion. Yo lo decia por si al autor del post le costaba mucho C y no lo entendia, si lo que queria era programar, que siempre podia 'desviarse a otras ramas' como Java.

Es que si te cuesta aprender las cosas como son o no tienes las ganas de aprenderlo, no te dediques a programar. Es tan simple como eso.

Que a mi me parecen muy bien estos lenguajes que esconden complejidad en donde no es necesario (sin ir más lejos en el curro uso C# y estoy encantado, porque todo lo que tengo hecho en 3 meses en c++ no lo hubiera hecho ni de coña, y lo se por experiencia propia) Pero eso no quita que no debas SABER qué es lo que hacen.
zheo escribió:He querido decir tipado estático

ah.
a = "hola amigo"
b = ", que tal?"
c = 34.56
print (a+b)
b = c
print (a+b)
Y tenemos un pete ;)

no, eso da un error sintáctico, no un error en tiempo de ejecución. te dirá cannot concatenate str and int objetcs. Y es bueno que lo de, ¿no crees? ¿O ahora defiendes el tipado débil?
El problema no es que te interese, el problema es que es algo que se debe saber, al menos a un nivel básico.

Al contrario, hay que saberlo a un nivel avanzado, cuando ya sabes programar.
Y estos lenguajes te lo ocultan. No son buenos para el principiante.

Estos lenguajes te lo ocultan. Son buenos para el principiante. Te abstraen de peculiaridades del lenguaje sin importancia PARA LO QUE QUIERES EN ESE MOMENTO, que es aprender a programar. He visto docenas de alumnos dejar Introducción a la Programación frustrados por este motivo. Podían aprender a programar pero se quedaron en sumar direcciones de memoria.
Pues no se cómo vas a mínimamente entender las referencias y los iteradores sobre todo, sin saber lo que son los punteros...

Por su interfaz. Se llama abstracción. Es como si dijeras "pues no sé cómo vas a usar la clase map si no sabes cómo está hecha internamente". Sé usarla porque tiene una interfaz que me da lo que necesito para trabajar y no más. Si quiero más, ya me preocuparé de mirarlo... si me apetece. Es lo bueno de la abstracción, te permite centrarte en lo que interesa.
No domino mucho de python aún, pues acabo de empezar no hace ni dos días, Pues hijo, yo pongo ese código en el intérprete de comandos o en un IDE y le doy a run, y peta cuando llega a esa línea, pero lo anterior lo ejecuta todo.

Al contrario, hay que saberlo a un nivel avanzado, cuando ya sabes programar.

Y para saber lo que estás haciendo y cómo lo haces, es necesario saber como funcionan. No es un nivel avanzado. Es básico.

Estos lenguajes te lo ocultan. Son buenos para el principiante. Te abstraen de peculiaridades del lenguaje sin importancia PARA LO QUE QUIERES EN ESE MOMENTO, que es aprender a programar. He visto docenas de alumnos dejar Introducción a la Programación frustrados por este motivo. Podían aprender a programar pero se quedaron en sumar direcciones de memoria.

Para aprender a programar no necesitas sumar direcciones de memoria. Tampoco para aprender a usar punteros y lo que significan. Y si se frustran por eso, pues a lo mejor es que no sabían dónde se metían en realidad.
Me ha encantado lo de "particularidades del lenguaje". Supongo que referido al tema que tratamos, punteros.
Como ya se ha dicho unas cuantas veces, los punteros no son particularidades del lenguaje. Son básicos en programación y siempre estás ahí, aunque te los maquillen.

Por su interfaz. Se llama abstracción. Es como si dijeras "pues no sé cómo vas a usar la clase map si no sabes cómo está hecha internamente". Sé usarla porque tiene una interfaz que me da lo que necesito para trabajar y no más. Si quiero más, ya me preocuparé de mirarlo... si me apetece. Es lo bueno de la abstracción, te permite centrarte en lo que interesa.

Me parece que yo estoy hablando de programar y tú estás hablando de picar código. Yo me refiero a saber lo que estás haciendo. Si no sabes lo que hace por dentro la clase map (y no me refiero a saber implementarla), es decir, si no sabes lo que es un diccionario y las particularidades que tiene, entonces será dificil que puedas elegir una estructura de datos óptima para el problema

Y ahora si lo puedo decir: no hace falta que uses un tono condescendiente.
zheo escribió:yo pongo ese código en el intérprete de comandos o en un IDE y le doy a run, y peta cuando llega a esa línea

pues eso, un error sintáctico. si fuera un error en tiempo de ejecución, no te saldría ningún mensaje, petaría el programa y ya está. No veo qué problema hay con eso. ¿No es bueno que dé un error sintáctico cuando intentas sumar datos de distinto tipo? Es muy lógico. Las variables son eso, variables. Como en matemáticas. Ahora le meto un entero, ahora una cadena, ahora una lista. Bien. El problema viene cuando intentas sumar cosas que no se pueden sumar porque esa operación no existe. Como mínimo, igual de lógico que el tipado estático.

Y para saber lo que estás haciendo y cómo lo haces, es necesario saber como funcionan.

Pues no. Yo no tengo ni idea de cómo estan implementados los iteradores. Me dijeron que son como punteros, pues vale. Tampoco tengo idea de cómo procesa mysql una sentencia, ni me importa. No lo necesito. Yo hago:

select * from tabla;

Y me da igual en qué tablespace esté la tabla, en qué agrupamiento, qué índices utiliza, en qué fichero está almacenada, qué estructura de datos usa mientras la tiene en memoria... joder qué martirio si tuviera que preocuparme de todo eso cada vez que hago una consulta.

¿Cuándo tengo que preocuparme de eso? Cuando yo administre la base de datos y me lleguen quejas de que los informes tardan en salir. Ahí ya me tengo que preocupar de la eficiencia y de muchos más parámetros... pero en esa fase yo ya conozco el lenguaje.

Para aprender a programar no necesitas sumar direcciones de memoria. Tampoco para aprender a usar punteros y lo que significan.

Para hacerlo en C sí lo necesitas. Y más cosas aún, como los famosos *, & y ->. ¿Cómo vas a recorrer un vector sin sumar punteros? ¿Usando los corchetes? Pues los corchetes te están abstrayendo de la representación interna del vector, eso que tú dices que no se debe hacer.
Y si se frustran por eso, pues a lo mejor es que no sabían dónde se metían en realidad.

¿Cómo lo van a saber? Es su primer día de clase. Vienen a aprender programación estructurada y lo primero que ven son directivas del preprocesador.
los punteros no son particularidades del lenguaje.

Sí lo son. La prueba es que en pseudocódigo no hay.
Me parece que yo estoy hablando de programar y tú estás hablando de picar código.

Al contrario, python se parece más a como enseñarías a programar con pseudocódigo. Es un nivel de abstracción mayor.

pregunta sobre programación:

- me he dado cuenta de que tengo este código repetido en varios sitios, ¿debería separarlo en una función aparte?

pregunta sobre picar código:

- por qué me peta el programa cuando le meto el número? ah, joder, que se me había olvidado poner el & en el scanf.
Yo me refiero a saber lo que estás haciendo.

Yo sé lo que hago yo. No me importa cómo se las apañe el SGBD ni el compilador, con tal de que haga lo que dice la interfaz.
Si no sabes lo que hace por dentro la clase map (y no me refiero a saber implementarla), es decir, si no sabes lo que es un diccionario y las particularidades que tiene

Para saber lo que es un diccionario y sus particularidades no necesito saber lo que hace por dentro. Sólo necesito su interfaz. ¿Has usado la STL alguna vez? A mí casi me da un patatús de la alegría cuando me la enseñaron.
Nulukkizdin escribió:pues eso, un error sintáctico. si fuera un error en tiempo de ejecución, no te saldría ningún mensaje, petaría el programa y ya está. No veo qué problema hay con eso. ¿No es bueno que dé un error sintáctico cuando intentas sumar datos de distinto tipo? Es muy lógico. Las variables son eso, variables. Como en matemáticas. Ahora le meto un entero, ahora una cadena, ahora una lista. Bien. El problema viene cuando intentas sumar cosas que no se pueden sumar porque esa operación no existe. Como mínimo, igual de lógico que el tipado estático.

Un error sintáctico se da ANTES de ejecutar el programa, al compilar, paso que no existe si python es interpretado (no se si se compila a un bytecode) Si se ejecuta el programa todas las líneas hasta la que peta, momento en el que falla, es que petó cuando llegó a ella. Es decir, en tiempo de ejecución. No puedo creer que me estés discutiendo eso.

Pero bueno si a tí te parece permisible dejar que gente que no sabe de programación pueda asignar variable que contenían cualquier tipo entre ellas es una buena manera de eneñarles a hacer las cosas bien, perfecto. Yo opino que es una buena manera de no dejarles las cosas claras.

Pues no. Yo no tengo ni idea de cómo estan implementados los iteradores. Me dijeron que son como punteros, pues vale.

Lo que quiere decir que si no sabes lo que son los punteros estás jodido.

Tampoco tengo idea de cómo procesa mysql una sentencia, ni me importa. No lo necesito. Yo hago:

select * from tabla;

Y me da igual en qué tablespace esté la tabla, en qué agrupamiento, qué índices utiliza, en qué fichero está almacenada, qué estructura de datos usa mientras la tiene en memoria... joder qué martirio si tuviera que preocuparme de todo eso cada vez que hago una consulta.

Confundes, por mucho, los términos de la conversación. No estamos hablando de conocer todas las implementaciones de todas las cosas. Repasa el hilo.

¿Cuándo tengo que preocuparme de eso? Cuando yo administre la base de datos y me lleguen quejas de que los informes tardan en salir. Ahí ya me tengo que preocupar de la eficiencia y de muchos más parámetros... pero en esa fase yo ya conozco el lenguaje.

Momento en el que perderás tiempo en cambiar cosas que se podrían haber hecho bien desde el principio. ;)

Para hacerlo en C sí lo necesitas. Y más cosas aún, como los famosos *, & y ->. ¿Cómo vas a recorrer un vector sin sumar punteros? ¿Usando los corchetes? Pues los corchetes te están abstrayendo de la representación interna del vector, eso que tú dices que no se debe hacer.

Y no se debe hacer. Pero tampoco es necesario que el primer día de programación se aprendan punteros. Y de nuevo, puedes pasar sin hacer aritmética de punteros para explicar lo que es un puntero.

¿Cómo lo van a saber? Es su primer día de clase. Vienen a aprender programación estructurada y lo primero que ven son directivas del preprocesador.

Se me olvidaba que aprendes a programar sólo con lo que ves el primer día de clase. El resto es irrelevante. :-|

Sí lo son. La prueba es que en pseudocódigo no hay.

Ah vale, como no están en pseudocódigo es algo del lenguaje. Claro claro.
El pseudocódigo es para algoritmos. El problema lo tiene el IMPLEMENTAR en una máquina real. Ahora que si tu conoces máquinas que no utilizan memoria para guardar el estado de las variables tú me dirás. Por que eso es un puntero ni más ni menos.

Las preguntas que haces son de picar código ambas. De programación serían más bien:

pregunta sobre programación:

Tengo el problema x ¿qué estructura de datos sería la óptima para este problema?

pregunta sobre picar código:

- ¿Cómo puedo implementar dicha estructura de datos con este lenguaje, si no está disponible?.

Para saber lo que es un diccionario y sus particularidades no necesito saber lo que hace por dentro.Sólo necesito su interfaz.

Nadie te ha dicho que tengas que saber lo que hace por dentro. Te especifiqué que no me refería a la implementación, a ver si leemos. Por alguna razón intentas derivar la conversación a que se necesita saber cómo funciona todo por dentro, algo que no se ha dicho.

¿Has usado la STL alguna vez? A mí casi me da un patatús de la alegría cuando me la enseñaron.

Que si he usado la STL juas. No se cuánto la habrás usado tú pero resulta que tira de iteradores para muchísimas operaciones (por no decir todo), y da la casualidad de que un iterador es ... una abstracción de un puntero, esas cosas que no son necesario saber lo que son XD XD
vaya hombre, te saltas medio mensaje porque "es irrelevante"... pues cojonudo...

ahora resulta que los errores en tiempo de ejecución no existen en los lenguajes interpretados... para qué tendrá python las excepciones, digo yo... será para que la gente que viene de C++ no se traumatice.

Va, pongamos que estás en línea de comandos. Un error sintáctico no se puede interpretar porque la evaluación falla. Es lo que pasa en tu ejemplo. El programa no se puede ejecutar.

En cambio, prueba a poner esto:
def rec(x):
   rec(x)


sintácticamente es correcto, así que lo evalúa y lo interpreta. Si el resto del programa también es correcto sintácticamente (imagínate que eso forma parte de un programa más grande), no hay ningún problema en lanzarlo. Si durante la ejecución del programa no llamas a rec, éste terminará sin más, sin errores. Sólo dará el error cuando la función rec se ejecute: se lanzará la excepción "maximun recursion depth excedeed". Espero que se vea la diferencia.

Lo de las variables... ¿y por qué no va a poder tener una variable cosas de distinto tipo? al venir de bachillerato, de matemáticas, ven el tipado estático como una restricción absurda (da igual que lo sea o no realmente: hablamos de lenguajes para aprender). Y más aún cuando un año después tienes que explicarles el chanchullo de las plantillas de C++ para conseguir precisamente la funcionalidad del tipado dinámico.

iteradores... for(i = v.begin(); i != v.end(); ++i) { //... }
¿punteros? ¿qué es un puntero? a mí no me líes, yo sólo uso iteradores... ah espera, que si no sé lo que son los punteros ese bucle no funciona. El compilador comprueba mi estado cerebral antes de evaluar esa expresión que no requiere en absoluto conocer lo que es un puntero... aunque en realidad prefiero una sintaxis tal que así:

for elemento in vector
//...la vida es bella de esta manera.

coño, ahora tampoco se deben usar los corchetes en C... en qué estaría pensando ritchie cuando los incluyó. Puedo pasar sin aritmética de punteros para explicar lo que es... pero entonces los estoy abstrayendo de su funcionamiento real, de modo que los utilizarán sin conocer realmente qué están haciendo, ¿eso no era malo, decías...?

perder tiempo cambiando cosas que podría haber hecho bien desde el principio... bonita forma de llamar al desarrollo incremental, al ciclo de vida evolutivo, en definitiva, cosillas sin importancia de ingeniería del software que en realidad sólo son "picar código". Muy, muy útil, enseñar bases de datos empezando desde el principio, ahí, como debe ser: almacenamiento físico. Los clusters. Pedagogísimo. A propósito, "desde el principio" quiere decir desde el primer día...? O tampoco.

Como en pseudocódigo no están, son cosas del lenguaje. pues... sí, mira. No veo muy lógica la frase "como en pseudocódigo no están, son cosas del pseudocódigo", la verdad.

No conozco máquinas que no usen la memoria para guardar variables, pero conozco lenguajes que te permiten centrarte en los algoritmos y dejarle al traductor que él gestione esas cosas accesorias que te alejan de tu objetivo, que es aprender a implementar algoritmos. No aprender truquitos específicos de C.

Por alguna razón intento desviar la conversación... ah, ya descubriste mis "motivaciones ocultas"...

un iterador es una abstracción de un puntero, y por ese motivo no es necesario saber lo que son, como ya te he demostrado con el bucle de antes. Es prácticamente la definición de abstracción.

Por mi parte lo dejo... di tú la última palabra :) un saludo y perdona si te he sonado condescendiente en el mensaje de antes.
Nulukkizdin escribió:vaya hombre, te saltas medio mensaje porque "es irrelevante"... pues cojonudo...

Lo qué?

ahora resulta que los errores en tiempo de ejecución no existen en los lenguajes interpretados... para qué tendrá python las excepciones, digo yo... será para que la gente que viene de C++ no se traumatice
Va, pongamos que estás en línea de comandos. Un error sintáctico no se puede interpretar porque la evaluación falla. Es lo que pasa en tu ejemplo. El programa no se puede ejecutar.

En cambio, prueba a poner esto:
def rec(x):
   rec(x)


sintácticamente es correcto, así que lo evalúa y lo interpreta. Si el resto del programa también es correcto sintácticamente (imagínate que eso forma parte de un programa más grande), no hay ningún problema en lanzarlo. Si durante la ejecución del programa no llamas a rec, éste terminará sin más, sin errores. Sólo dará el error cuando la función rec se ejecute: se lanzará la excepción "maximun recursion depth excedeed". Espero que se vea la diferencia.

Vamos progresando. Al menos ya has reconocido que era un error en tiempo de ejecución. Error que no se habría cometido en un lenguaje como c++ o C# y Java con correcto uso de tipos (o ni falta, porque tendrías que tirar de castings), ya que daría un error en tiempo de compilación gracias a que son tipos diferentes. Un error menos que descubrir en el momento más inoportuno.
El ejemplo de recurrencia que pones no tiene nada que ver con lo que estábamos hablando, que te recuerdo era una cosa como esta:
a = "hola amigo"
b = ", que tal?"
c = 34.56

print (a+b)

b = c
print (a+b)

Era de ese tipo de error del que estábamos hablando, no de errores por que si.Ahora que puedes ponerme mil ejemplos donde cualquier lenguaje falla, hacer recursiones infinitas sabemos todos. El problema es que no era de lo que estábamos hablando. De hecho ese ejemplo que pones, bajo las mismas condiciones funciona en C++. Eso no es un error en tiempo de ejecución, es un bug, porque es un fallo total del diseño de la función.

Lo de las variables... ¿y por qué no va a poder tener una variable cosas de distinto tipo?
Por lo que pongo arriba.

al venir de bachillerato, de matemáticas, ven el tipado estático como una restricción absurda (da igual que lo sea o no realmente: hablamos de lenguajes para aprender).

Ya bueno, pero como ya dije, la programación no es fácil, y es un error pretender que si lo es.

Y más aún cuando un año después tienes que explicarles el chanchullo de las plantillas de C++ para conseguir precisamente la funcionalidad del tipado dinámico.

Las plantillas de C++ ni se acercan a la funcionalidad del tipado dinámico ni lo pretenden. A no ser que puedas hacer, por obra y gracia de tu compilador:
vector a;
vector b;
b = a;

Que lo dudo por que las plantillas generan código compilado (son por ello más eficientes) y en realidad lo que tienes ahí no son dos vectores que almacenan tipos de datos distintos, sino que son dos tipos completamente distintos por si mismos.

iteradores... for(i = v.begin(); i != v.end(); ++i) { //... }
¿punteros? ¿qué es un puntero? a mí no me líes, yo sólo uso iteradores... ah espera, que si no sé lo que son los punteros ese bucle no funciona. El compilador comprueba mi estado cerebral antes de evaluar esa expresión que no requiere en absoluto conocer lo que es un puntero... aunque en realidad prefiero una sintaxis tal que así:

for elemento in vector
//...la vida es bella de esta manera.

¿Y ese bucle qué hace, cuenta números? Porque algo tendrás que decirle a la gente cuando dentro del bucle que has puesto aparezcan cosas como
i->Metodo()
Porque digo yo que -por lo general- si quieres abstraer el recorrido de algo con un iterador, será para usarlo por dentro del bucle, sino usarías un int.
:-|

Pero hey, no necesitas conocer que los iteradores son una abstracción de puntero, para nada. El -> se pone así por que si y punto. ¿y por qué en otros lugares se pone .Metodo() en vez de ->Metodo()? Estooo, pasemos al siguiente tema...

coño, ahora tampoco se deben usar los corchetes en C... en qué estaría pensando ritchie cuando los incluyó. Puedo pasar sin aritmética de punteros para explicar lo que es... pero entonces los estoy abstrayendo de su funcionamiento real, de modo que los utilizarán sin conocer realmente qué están haciendo, ¿eso no era malo, decías...?

Has tenido un pequeño malentendido. Lo que digo que no se debería hacer es usar los corchetes en un array sin saber lo que en realidad abstraen.
Sin embargo, y adelantándome a los acontecimientos, que deba saberse, no significa que deba saberse el primer día.

perder tiempo cambiando cosas que podría haber hecho bien desde el principio... bonita forma de llamar al desarrollo incremental, al ciclo de vida evolutivo, en definitiva, cosillas sin importancia de ingeniería del software que en realidad sólo son "picar código". Muy, muy útil, enseñar bases de datos empezando desde el principio, ahí, como debe ser: almacenamiento físico. Los clusters. Pedagogísimo. A propósito, "desde el principio" quiere decir desde el primer día...? O tampoco.

Disculpa, pero lo que has dicho es que a tí cómo funciona un lenguaje para su eficiencia sólo te importa cuando tengas que meterle mano. Revisa lo que tú mismo has escrito.

Como en pseudocódigo no están, son cosas del lenguaje. pues... sí, mira. No veo muy lógica la frase "como en pseudocódigo no están, son cosas del pseudocódigo", la verdad.

En pseudocódigo yo puedo hacer esto:

1 function Kruskal(G)
2 for each vertex v in G do
3 Define an elementary cluster C(v) ← {v}.
4 Initialize a priority queue Q to contain all edges in G, using the weights as keys.
5 Define a tree T ← Ø //T will ultimately contain the edges of the MST
6 // n es el número total de vértices
7 while T has fewer than n-1 edges do
8 // edge u,v is the minimum weighted route from/to v
9 (u,v) ← Q.removeMin()
10 // previene ciclos en T. suma u,v solo si T no contiene una arista que una u y v.
11 // Nótese que el cluster contiene más de un vértice si una arista une un par de
12 // vértices que ahn sido añadidos al árbol.
13 Let C(v) be the cluster containing v, and let C(u) be the cluster containing u.
14 if C(v) ≠ C(u) then
15 Add edge (v,u) to T.
16 Merge C(v) and C(u) into one cluster, that is, union C(v) and C(u).
17 return tree T


Ahora cualquier parecido entre esto y la implementación en realidad es pura coincidencia. El pseudocódigo es una SIMPLIFICACIÓN para hacer más legibles los algoritmos. No me puedo creer que alguien me esté diciendo que acceder a datos por direcciones de memoria son "particularidades del lenguaje".

No conozco máquinas que no usen la memoria para guardar variables, pero conozco lenguajes que te permiten centrarte en los algoritmos y dejarle al traductor que él gestione esas cosas accesorias que te alejan de tu objetivo, que es aprender a implementar algoritmos. No aprender truquitos específicos de C.

Empieza a dar gracias a esos programadores de C, que permiten que existan esos lenguajes que abstraen los punteros y esas "cosas accesorias que te alejan de tus objetivos"...

Como descubras que las MV de Java están hechas en C++ te puede dar un patatús.

Por alguna razón intento desviar la conversación... ah, ya descubriste mis "motivaciones ocultas"...

Si, que cada uno barre para donde más le interesa. Lo de "por alguna razón" era un eufemismo.
joer, si es que me obligan... justo cuando creía que estaba fuera, ellos me vuelven a meter...glglgl.

yo digo...
Un error sintáctico no se puede interpretar porque la evaluación falla. Es lo que pasa en tu ejemplo.

a lo que tú respondes...
Al menos ya has reconocido que era un error en tiempo de ejecución

surrealista vamos... pf... tío, tú ejemplo NO SE PUEDE EJECUTAR. No llega a tiempo de ejecución. ¡No llega a ejecutarse! Haz la prueba. Escríbelo en el gedit y luego lánzalo con $ python programa.py. No sale. El primer print tampoco sale. El error se detecta ANTES de la ejecución.

Obviamente si estás en línea de comandos y pones primero un print y luego esa asignación, el print se imprime, porque en línea de comandos el intérprete ejecuta cada línea que le llega independientemente de las demás, como si cada sentencia fuera un programa completo. Esto lo digo por lo que dijiste antes de "se ejecutan todas las líneas hasta que llega a esa". El comportamiento sería tal que así:

espero entrada...
me llega un print...
lo evalúo... es correcto... lo ejecuto... termino la ejecución...
espero entrada...
me llega una asignacion... vale, correcta... la ejecuto... termino la ejecución... espero entrada...
me llega una asignación...
la evalúo... tiene un error de asignación de tipos... muestro un mensaje de error... NO INTENTO EJECUTAR PORQUE HAY UN ERROR SINTACTICO...
espero entrada...

y tal.

La recursividad infinita "funciona" en C++ porque C++ le deja la responsabilidad de lanzar la excepción al programador, mientras que python la lanza para no quedarse eternamente calculando.

La programación puede ser tan satisfactoria o tan frustrante para el estudiando como el profesor quiera. Si a final de cuatrimestre quieres tener a seis alumnos en tu clase, enseña las cosas "como debe ser, desde el principio, sentando las bases, bla bla". Primer día: primer programa: primera línea: las directivas del preprocesador. Seguimos: los ficheros de cabecera. Luego, la función main, con sus argumentos. Por fin llegamos a la función que hace lo que queremos, imprimir hola mundo (idea del estudiante: joder, ¿y por qué no puedo poner sólo printf, que es lo que hace que imprima el letrero?). La orden return. Y así hasta fin de curso. O bien explicar el printf y decir "las otras seis o siete líneas las veremos el mes que viene".

vector a;
vector b;
b = a;

¿otra vez? Que python tiene TIPADO FUERTEEE. Eso no se puede hacer en python, da un error SINTACTICO (recordatorio: en los lenguajes interpretados TAMBIEN existen los errores sintácticos). Me desespero, ¿eh? Me desespero.

Lo del punto y la flecha. ¿No recuerdas que fue una de las cosas que puse como PEGAS en un mensaje anterior? ¿Y no has visto el segundo tipo de bucle, el que prefiero, mucho más sencillo e intuitivo, más cercano al pseudocódigo, y por tanto mejor para aprender?

Lo que digo que no se debería hacer es usar los corchetes en un array sin saber lo que en realidad abstraen.

Y por tanto, les enseñas que v[5] es *(v+5). Pero eso no es aritmética de punteros, es un bug.

Veo tu ejemplo de pseudocódigo y lo primero que veo es:
for each vertex v in G do

vaya hombre, si es un bucle al estilo python, php y otros... implementemos eso en python:
for vertex in g:

conciso, directo al grano... aunque, si quieres, también puedes hacerlo al estilo C. Tú eliges. En C no. De hecho, Kruskal en C es lo más coñazo que puedes echarte a la cara. En python los algoritmos son más legibles y fáciles de programar.

Gracias, programadores de C, por permitir que otros hagan lenguajes que me permiten abstraerme de cosas accesorias para mi objetivo, que es aprender (y enseñar) a programar.
Nulukkizdin escribió:...
No copio de nuevo lo que pones porque vuelves al estúpido tono condescendiente explicándome lo que es un intérprete de comandos, y a la par demostrando que no leíste la parte en que decía que lo COMPILÉ DESDE UN IDE (IDLE concretamente)

Pero nada nada, aquí tienes la secuencia de comandos:
main.py

a = "hola"
b = 13

print a
print b
print a + b

Y la ejecución:
C:\> C:\desarrollo\Python25\python.exe main.py
hola
13
Traceback (most recent call last):
File "main.py", line 8, in
print a + b
TypeError: cannot concatenate 'str' and 'int' objects

C:\>

Ostias!!!! ¿Qué es ese hola y ese 13 que aparecen antes del error de tipado?
:-| :-| :-| :-| :-| :-| :-| :-| :-| :-| :-| :-| :-| :-| :-|

La recursividad infinita "funciona" en C++ porque C++ le deja la responsabilidad de lanzar la excepción al programador, mientras que python la lanza para no quedarse eternamente calculando.

Ehhh no. En c++ funciona porque el programa se ejecuta hasta que alcanza el límite de pila o se funde la memoria que puede utilizar el proceso y peta. No hay que lanzar una excepción. Las excepciones son controladas, un fallo al hacer un algoritmo recursivo en teoría es algo inesperado.

En python lanza una excepción porque detrás hay una maquinita cuidando de todo para que no hagas el gambas ni la puedas cagar. Lógicamente comiendo recursos, que no vive del aire.

Además es que me estás dando la razón, confundes muchos temas. Las excepciones se lanzan en tiempo de ejecución, así que son el ejemplo menos apropiado en este contexto.

La programación puede ser tan satisfactoria o tan frustrante para el estudiando como el profesor quiera. Si a final de cuatrimestre quieres tener a seis alumnos en tu clase, enseña las cosas "como debe ser, desde el principio, sentando las bases, bla bla". Primer día: primer programa: primera línea: las directivas del preprocesador. Seguimos: los ficheros de cabecera. Luego, la función main, con sus argumentos. Por fin llegamos a la función que hace lo que queremos, imprimir hola mundo (idea del estudiante: joder, ¿y por qué no puedo poner sólo printf, que es lo que hace que imprima el letrero?). La orden return. Y así hasta fin de curso. O bien explicar el printf y decir "las otras seis o siete líneas las veremos el mes que viene".

Espero que no seas profesor de c o c++ , porque sería la peor clase de programación que vi en mi vida. Y he visto muchas malas.

Y vamos, si el alumno no entiende para que son las primeras líneas, se le explica. Ese es el fallo. Y si le parece un coñazo o se dedica a otra cosa o se pregunta por qué ha de ser así. Pero vamos, vero que se lleva mucho que los alumnos no se lleven traumas, pobrecicos ellos.

Si es verdad que eres profesor dios nos asista. Además de engañar a los alumnos pretendiendo simplificar algo que no es sencillo. Por otro lado ese tipo de alumnos te preguntaran cosas como "por qué hay que pulsar tabulador en python dentro de un bucle" y entonces es cuando le tienes que explicar cosas 'complicadas' como el ámbito...

vector a;
vector b;
b = a;

¿otra vez? Que python tiene TIPADO FUERTEEE. Eso no se puede hacer en python, da un error SINTACTICO (recordatorio: en los lenguajes interpretados TAMBIEN existen los errores sintácticos). Me desespero, ¿eh? Me desespero.

Seguro que sabes python? Porque yo para llevar dos días con él, resulta que hago esto:

a = 15
b = "hola"
print a
print b
b = a
print a
print b

y funciona sin dar ni un sólo error, ni sintáctico ni de ejecución ni nada. No me extraña que te desesperes, debe ser acojonante que de momento todo lo que hayas dicho de python sea erróneo.

Lo del punto y la flecha. ¿No recuerdas que fue una de las cosas que puse como PEGAS en un mensaje anterior? ¿Y no has visto el segundo tipo de bucle, el que prefiero, mucho más sencillo e intuitivo, más cercano al pseudocódigo, y por tanto mejor para aprender?

Si es una cosa que pones como pegas, entonces un iterador NO TE SIRVE DE NADA. Me parece a mi que la STL la has visto MUY DE LEJOS.
No te vuelvas a desviar del tema que estoy empezando a pensar que no sabes ya dónde meterte.
Si me dices que un iterador es una abstracción de un puntero y que por eso es más sencillo un iterador que un puntero, pero que no te hace falta saber lo que es un puntero, bueno la frase ya es incoherente de por si. Pero si te digo que por mucho que al ser una abstacción necesitas usar -> y me dices que eso es peor porque lo complica, es que no te aclaras.

Por otro lado te gusta mucho hablar de abstracción, y debes pensar que abstracción es un sinónimo de simplificar. Y no tiene por qué ser así.

De hecho los iteradores no simplifican los punteros. Simplemente abstraen la forma de tratarlos para que, con un mismo código, puedas por ejemplo recorrer de manera uniforme TADs tan variados como colas, listas, diccionarios, conjuntos o grafos.


Y por tanto, les enseñas que v[5] es *(v+5). Pero eso no es aritmética de punteros, es un bug.

En fin, me molesté en avisarte pero sigues entrando al trapo.
No pienso discutir con alguien que está claro que ni siquiera lee lo que se le pone. Así que te daré la razón como a los tontos:
sisisisisisi hay que saber aritmética de punteros desde el primer día para saber lo que son los punteros y saber c...


Veo tu ejemplo de pseudocódigo y lo primero que veo es:
for each vertex v in G do

vaya hombre, si es un bucle al estilo python, php y otros... implementemos eso en python:
for vertex in g:

conciso, directo al grano... aunque, si quieres, también puedes hacerlo al estilo C. Tú eliges. En C no. De hecho, Kruskal en C es lo más coñazo que puedes echarte a la cara. En python los algoritmos son más legibles y fáciles de programar.

Ahora impleméntame esto en python:
3 Define an elementary cluster C(v) ← {v}.
4 Initialize a priority queue Q to contain all edges in G, using the weights as keys.

¿Un poco más complicado no? Sin embargo, como eso existe en pseudocódigo, debería existir en un lenguaje :-|

De nuevo derivas la conversación sin venir a cuento. Te lo pondré en grande:
NADIE DICE QUE PYTHON NO SEA MÁS CONCISO O CLARO PARA VER LOS ALGORITMOS, DE LO QUE ESTÁMOS HABLANDO ES QUE EL PSEUDOCÓDIGO ES UNA SIMPLIFICACIÓN, Y POR TANTO NO TIENE LAS CARACTERÍSICAS DE UN SISTEMA REAL, QUE SON NECESARIAS PARA LA PROGRAMACIÓN EN UNA MÁQUINA FÍSICA, POR LO QUE ESAS CARACTERÍSTICAS QUE FALTAN EN POS DE DICHA SIMPLIFICACIÓN NO PUEDEN CONSIDERARSE "PECULIARIDADES DEL LENGUAJE"
Pillamos ya o tengo que recurrir a la etiqueta size?

Gracias, programadores de C, por hacer lenguajes que me permiten abstraerme de cosas accesorias para mi objetivo, que es aprender (y enseñar) a programar.

Fixed!


Bueno voy a dormir y a leer otro capítulo más de python. Te recomiendo lo mismo. Porque tiene delito que mirándolo dos días ya sepa discutirte lo que puedes hacer y lo que no con el lenguaje.
Bueno haya paz... cada uno tiene su opinion y es dificil hacerla cambiar ^^. Zheo te garantizo k eso se aprende los primeros dias de clase de Introducción a la programacion xD (al menos a mi y a Nulukkizdin que fue compañero mio de clase, ahoar no se como estará con eso del proyecto piloto, evaluación continua y demas se ta pasando mucho la mano a los alumnos), el bajon que pega la clase durante el curso en cuanto al número de alumnos es una maravilla visual xDDDD.

En fin, yo opino que primero hay que enseñar C por lo que comentas... pa saber el por qué de las cosas... esto conllevará horas de sufrimiento (qué digo horas.... meses o mas!) y luego somos "apremiados" por conocer otros lenguajes más versátiles y más abstractos que nos facilitan las cosas... pero somos conscientes de ello porque valoramos dicha abstracción.

En cambio aprender de primeras algun lenguaje abstracto... el que no ha dao programación en su vida pues si... seguira adelante y motivado... pero no se lo merece XDDDDDD se merece el castigo cruel de aprender C, punteros, direcciones de memoria, punteros a funcion, etc, etc xDDDD

Además... así nos ahorramos intrusismo, habrá pocos programadores (pero buenos ^^) y seguiremos teniendo trabajo sin que se nos cuele el tipico listillo de turno por haberse leio un manual XDDD

saludos y buen royo ;)!
ercea escribió:En cambio aprender de primeras algun lenguaje abstracto... el que no ha dao programación en su vida pues si... seguira adelante y motivado... pero no se lo merece XDDDDDD se merece el castigo cruel de aprender C, punteros, direcciones de memoria, punteros a funcion, etc, etc xDDDD

Jústamente hoy discutía lo mismo con unos compañeros, ya que uno también defendía que en nuestro plan de estudios aprender c++ es una tontería. Uno opinaba que tendríamos que dar Java desde el principio y los otros 3 que no, que se empieza con c++ y luego se debería dar Java. Sim embargo lo que hacemos es empezar con c++, seguir con c++ y punto, lo que también está fatal, ya que lo del Java va porque soy de Asturias, y aquí piden muchísimos puestos de trabajo con Java (por ahí les ha dado). De hecho hay varios cursos y masters gratuitos para aprender el "framework del principado", un framework de trabajo en Java que se usa en las administraciones de aquí.
Y en nuestra carrera no hueles java en ningún momento (excepto en redes para hacer sockets ya ves), así que struts, beans o cualquier cosa te lo tienes que mirar tú. .NET también te lo tienes que mirar rú por supuesto... de lenguajes como python o Ruby sólo oyes hablar si conoces a alguien que a su vez los conoce... supongo que sabes cómo va esto.

Además... así nos ahorramos intrusismo, habrá pocos programadores (pero buenos ^^) y seguiremos teniendo trabajo sin que se nos cuele el tipico listillo de turno por haberse leio un manual XDDD
Es más por el tema de no intentar hacer creer que algo complejo como es la programación, se puede volver sencillo, y no es así.

saludos y buen royo smile_;)!
Si yo buen rollo lo tengo. El problema viene es cuando me dicen burradas, como confundir errores en tiempo de ejecución con errores de sintaxis, o intentar compara éstos últimos con una construcción del lenguaje como es una excepción, o decir que en un lenguaje no puedes hacer x y resulta que en mi entorno yo puedo hacerlo. En esos casos suelo creer más a lo que veo, y si el lenguaje me dice que es posible, pues me creeré eso antes que al que me intenta decir que no. A fin de cuentas la probabilidad de que yo me haya bajado una versión distinta del lenguaje que permite hacer cosas que otros no pueden es bastante bastante pequeña, has de reconocérmelo ;)
zheo escribió:Jústamente hoy discutía lo mismo con unos compañeros, ya que uno también defendía que en nuestro plan de estudios aprender c++ es una tontería. Uno opinaba que tendríamos que dar Java desde el principio y los otros 3 que no, que se empieza con c++ y luego se debería dar Java. Sim embargo lo que hacemos es empezar con c++, seguir con c++ y punto, lo que también está fatal, ya que lo del Java va porque soy de Asturias, y aquí piden muchísimos puestos de trabajo con Java (por ahí les ha dado). De hecho hay varios cursos y masters gratuitos para aprender el "framework del principado", un framework de trabajo en Java que se usa en las administraciones de aquí.
Y en nuestra carrera no hueles java en ningún momento (excepto en redes para hacer sockets ya ves), así que struts, beans o cualquier cosa te lo tienes que mirar tú. .NET también te lo tienes que mirar rú por supuesto... de lenguajes como python o Ruby sólo oyes hablar si conoces a alguien que a su vez los conoce... supongo que sabes cómo va esto.

Es más por el tema de no intentar hacer creer que algo complejo como es la programación, se puede volver sencillo, y no es así.


Veo que estudiaste en Gijón o en Oviedo con el plan viejo, porque ahora en Oviedo nos meten Java en todas las asignaturas menos an una cuatrimestral de segundo donde se ve C y C++. Python, Ruby, la plataforma .NET, sabemos que tienen que ver con la programación porque el profestor de TcP los nombra en sus clases, supongo que intentando que nos interesemos nosotros por ello (cosa que debe funcionar para un 0.01% del alumnado).

A mi me parece un error, porque empiezas con Java, que es muy fácil, y no te tienes por que preocupar de nada de lo que pasa cuando das a compilar y ejecutar, y cuando te pones a aprender C es una cuesta arriba tremenda, porque aunque "sabes programar" nunca te has molestado de lo que pasa a un nivel más bajo, y cuesta mucho.

Personalmente, después de haber estudiado así, preferiría que fuera al revés: Que nos enseñasen casi todo en C++ (con una pequeña introducción en C) y una asignatura para Java, porque sabiendo C y C++, Java es relativamente fácil.

De todas maneras, nos forman para ser ingenieros, por lo que (en teoría), si estamos bien formados no debería suponer ningún problema el pasarnos de un lenguaje a otro, si podemos conocer cómo funciona.

Quiero advertir que hablo desde una corta experiencia, aún no he acabado la carrera y aún no he trabajado en el sector del desarrollo de software, así que no me lapidéis si he pueso algo "muy burro".

Un saludo!
Yo ahora es cuando aprenderé Java (por fin!), en una optativa (Programación en Entornos Cliente/Servidor), y es en el 2º Ciclo... tambien en la técnica había una optativa que nos enseñaba Java (Programación Concurrente y Distribuida)... pero cambiaron de profesor y el de ahora tiene una filosofía un tanto peculiar... tanto k puedes aprobar si haber aprendido java xDDD. Aquí es C y C++ y java de manera opcional (sin embargo hay un tribunal de PFC que como no esté en Java ya les caes mal xD). Ruby, Python, PHP, y demás... todavía no se nada pero me gustaría, ya que son cosas que he oído mucho que se necesita y la verdad me gustaría aprenderlos.

He de decir que empezar con C tiene un problema (que al menos fue el que tuve yo), que C es programación estructurada... y pasar de la programación estrucutrada a la orientada a objetos... al principio costó xD, ya luego cuando te das cuen de to, hasta adoras la orientación a objetos xD, pero cuesta.

saludos!
resakosix escribió:
Veo que estudiaste en Gijón o en Oviedo con el plan viejo, porque ahora en Oviedo nos meten Java en todas las asignaturas menos an una cuatrimestral de segundo donde se ve C y C++. Python, Ruby, la plataforma .NET, sabemos que tienen que ver con la programación porque el profestor de TcP los nombra en sus clases, supongo que intentando que nos interesemos nosotros por ello (cosa que debe funcionar para un 0.01% del alumnado).
Efectivamente, estudié en Gijón :)
Es cierto que en Oviedo daban Java, que conozco a uno que fue profesor
Aunque por lo que me cuentan en Ing Soft de gestión ahora usan .NET.

A mi me parece un error, porque empiezas con Java, que es muy fácil, y no te tienes por que preocupar de nada de lo que pasa cuando das a compilar y ejecutar, y cuando te pones a aprender C es una cuesta arriba tremenda, porque aunque "sabes programar" nunca te has molestado de lo que pasa a un nivel más bajo, y cuesta mucho.

Bingo!

De todas maneras, nos forman para ser ingenieros, por lo que (en teoría), si estamos bien formados no debería suponer ningún problema el pasarnos de un lenguaje a otro, si podemos conocer cómo funciona.

Correcto, pero yo también soy de la opinión de que si no sabes como programar, poco vas a diseñar. Y luego además, si conoces un lenguaje de forma extensa, quizá exista la posibilidad que de acuerdo a cada caracterísitica de cada lenguaje el diseño pueda quedar influenciado por ese conocimiento :)

Yo ahora es cuando aprenderé Java (por fin!), en una optativa (Programación en Entornos Cliente/Servidor), y es en el 2º Ciclo... tambien en la técnica había una optativa que nos enseñaba Java (Programación Concurrente y Distribuida)

Por ejemplo, java con su soporte en el lenguaje de mecanismos de computación paralela es muchísimo más adecuado para aprender programación paralela que c++. Pero de cojones que más oigas :P

(sin embargo hay un tribunal de PFC que como no esté en Java ya les caes mal xD).

Je, si eso es cierto, pues qué te puedo decir: hay mucho ignorante en la universidad aunque no lo parezca.
49 respuestas