| Poll :: ¿Pascal o Python? |
| Pascal |
|
27% |
[ 27 ] |
| Python |
|
60% |
[ 59 ] |
| Otro |
|
12% |
[ 12 ] |
|
| Votos Totales : 98 |
|
| Autor |
Mensaje |
Sebastian Santisi
Administrador Técnico
Edad: 42
Registrado: 23 Ago 2005
Mensajes: 17451
|
|
No te me ofendas.
Si te parece bien, podemos arrancar un nuevo hilo para informar cómo fue el curso piloto y en qué se basó.
Incluso hay varios foristas que cayeron de conejillos en los dos cuatrimestres que se dictó para 75.40 y pueden contar la experiencia.
Pero sí, no voy a hacer eso en este porque me parece que no da. De verdad.
|
|
|
|
_________________
 ![[tex] ${. \ \ \ \ \ \ \ \ \ .}$ [/tex]](images/latex/d678cf273c99d2546c259db3422b3d968b184721_0.png "[tex] ${. \ \ \ \ \ \ \ \ \ .}$ [/tex]") ![[tex] ${\Large Usá \LaTeX, no seas foro...}$ [/tex]](images/latex/1e6580e1ed9e054ddefd65c0551c670c44f57f38_0.png "[tex] ${\Large Usá \LaTeX, no seas foro...}$ [/tex]")
|
|
   |
     |
|
Izanagi
Nivel 7
Edad: 36
Registrado: 21 Ago 2008
Mensajes: 402
Ubicación: Belgrano
Carrera: No especificada
|
|
  |
   |
|
GREgO
Nivel 8
Registrado: 21 Abr 2009
Mensajes: 771
Ubicación: New Belsen
Carrera: Electrónica
|
|
OT
Lo espantaste, SS!!! 
Mirá si ahora Izanagi se cambia a Veterinaria...
/OT
|
|
|
|
_________________
El ser humano primero cree en Papá Noel,
Después en Dios,
Luego en la Izquierda,
Y finalmente advierte que la posta es Hermanos Bladimir
................
Ya salió la Bladimir Papel nº 3! Conseguila en el baño de tu Ugi's!
|
|
| |
|
|
Spike Spiegel
Nivel 9
Edad: 36
Registrado: 10 Ago 2007
Mensajes: 1507
Carrera: Informática
|
|
¿Se puede abrir el topic nuevo y conversar los cambios? Me interesa leerlo.
Por otro lado, me parece medio peligroso basarse solo en gente con BANDA de años laburando en esto. Hay muchos que son medio dinosaurios y eso no hace bien. Tiene que ser gente que, si tiene muchos años de experiencia, uno pueda estar seguro que se mantuvo fresca con el paso de los años y avanzó al ritmo que avanzó la ciencia.
Más que nada tiene que ser gente con mucho panorama y visión. Si bien la experiencia ayuda a ampliar esas cosas, también puede ayudar a cerrarlas. O puede directamente no ser influyente: el que sabe, sabe.
Sí estoy de acuerdo con que la opinión de alguien joven es para tomar con pinzas, pero tampoco para desestimarla.
|
|
|
|
_________________
![[tex]\mbox{Detrás de todo 'tengo hambre' hay un gran 'comete esta'}[/tex]](images/latex/8abc5691357a123d82fd07cae688fd7767bf6633_0.png "[tex]\mbox{Detrás de todo 'tengo hambre' hay un gran 'comete esta'}[/tex]")
|
|
 |
 |
|
DiegoNC
Nivel 4
Registrado: 17 Sep 2005
Mensajes: 86
Carrera: Informática
|
|
Agrego otro link que esta medio perdido en el hilo de iinfo.
Grupo del curso piloto
Ahí se puede encontrar un apunte de los temas que se dieron en el curso.
|
|
|
|
|
|
| |
|
|
Izanagi
Nivel 7
Edad: 36
Registrado: 21 Ago 2008
Mensajes: 402
Ubicación: Belgrano
Carrera: No especificada
|
|
| Cita:
|
OT
Lo espantaste, SS!!!
Mirá si ahora Izanagi se cambia a Veterinaria...
/OT
|
wow, sos tan gracioso.
| Cita:
|
¿Se puede abrir el topic nuevo y conversar los cambios?
|
Por favor.
|
|
|
|
_________________
[Campaña]Revivamos el Chat Fiuba
|
|
| |
|
|
Sebastian Santisi
Administrador Técnico
Edad: 42
Registrado: 23 Ago 2005
Mensajes: 17451
|
|
| Spike Spiegel escribió:
|
|
¿Se puede abrir el topic nuevo y conversar los cambios? Me interesa leerlo.
|
Claro que se puede.
| Spike Spiegel escribió:
|
|
Por otro lado, me parece medio peligroso basarse solo en gente con BANDA de años laburando en esto. Hay muchos que son medio dinosaurios y eso no hace bien. Tiene que ser gente que, si tiene muchos años de experiencia, uno pueda estar seguro que se mantuvo fresca con el paso de los años y avanzó al ritmo que avanzó la ciencia.
|
Nadie dijo se se hubiera basado sólo en eso.
| Spike Spiegel escribió:
|
|
Más que nada tiene que ser gente con mucho panorama y visión. Si bien la experiencia ayuda a ampliar esas cosas, también puede ayudar a cerrarlas. O puede directamente no ser influyente: el que sabe, sabe.
|
En ese caso, deberías sacar un juicio en base a las personas concretas.
| Spike Spiegel escribió:
|
|
Sí estoy de acuerdo con que la opinión de alguien joven es para tomar con pinzas, pero tampoco para desestimarla.
|
Cuando la opinión se trata en comparar dos lenguajes sin tener ni las herramientas ni la madurez correspondiente, y es una opinión meramente subjetiva, sí, es desestimable. Distinta es una opinión de esa misma gente jóven de "me comí un embole tremendo cuando daban X tema", "no entendí para qué servía", "perdí mucho tiempo intentando hacer X cosa", etc., que son opiniones de las que todo docente debería realimentarse. Pero, en particular, la enseñanza básica de cualquier tema es algo para gente avanzada. ¿Por qué?; porque el que está en un nivel básico va a juzgar sólo desde la perspectiva de cómo se lo enseñaron a él sin conocimientos a más largo plazo. En una materia básica hay cosas que se enseñan que sirven de cimientos para cosas que vienen detrás, hay cosas que no tienen utilidad pero se enseñan para fijar conceptos o para estimular metodologías de pensamiento, etc.; ergo, la planificación de un curso de esas características, tiene que hacerse desde más lejos, planteándose un objetivo de qué es lo que tiene que llevarse el alumno y orientado de qué forma. En una materia avanzada, donde el alumno sabe qué fue a buscar a la misma, y para qué está ahí; la opinión del alumno tiene incluso te diría que tanto o más peso que la del docente, en caunto a qué contenidos dar.
Algoritmos I por sí sola no es nada, es una materia meramente introductoria que articula luego con al menos 5 materias básicas más. Los conocimientos que veas o dejes de ver en Algoritmos I (Informática / Sistemas) no van a incidir en nada en tu formación final como Ing. en Informática o Lic. en Sistemas. (hago el paréntesis porque 75.02 es justamente el caso diametral opuesto: es la única materia obligatoria de programación de alto nivel; lo que se dé o deje de darse va a ser el 100% de las formación mínima del profesional.)
|
|
|
|
_________________
|
|
| |
|
|
Izanagi
Nivel 7
Edad: 36
Registrado: 21 Ago 2008
Mensajes: 402
Ubicación: Belgrano
Carrera: No especificada
|
|
| Cita:
|
Cuando la opinión se trata en comparar dos lenguajes sin tener ni las herramientas ni la madurez correspondiente, y es una opinión meramente subjetiva, sí, es desestimable. Distinta es una opinión de esa misma gente jóven de "me comí un embole tremendo cuando daban X tema", "no entendí para qué servía", "perdí mucho tiempo intentando hacer X cosa", etc., que son opiniones de las que todo docente debería realimentarse. Pero, en particular, la enseñanza básica de cualquier tema es algo para gente avanzada. ¿Por qué?; porque el que está en un nivel básico va a juzgar sólo desde la perspectiva de cómo se lo enseñaron a él sin conocimientos a más largo plazo. En una materia básica hay cosas que se enseñan que sirven de cimientos para cosas que vienen detrás, hay cosas que no tienen utilidad pero se enseñan para fijar conceptos o para estimular metodologías de pensamiento, etc.; ergo, la planificación de un curso de esas características, tiene que hacerse desde más lejos, planteándose un objetivo de qué es lo que tiene que llevarse el alumno y orientado de qué forma. En una materia avanzada, donde el alumno sabe qué fue a buscar a la misma, y para qué está ahí; la opinión del alumno tiene incluso te diría que tanto o más peso que la del docente, en caunto a qué contenidos dar.
Algoritmos I por sí sola no es nada, es una materia meramente introductoria que articula luego con al menos 5 materias básicas más. Los conocimientos que veas o dejes de ver en Algoritmos I (Informática / Sistemas) no van a incidir en nada en tu formación final como Ing. en Informática o Lic. en Sistemas. (hago el paréntesis porque 75.02 es justamente el caso diametral opuesto: es la única materia obligatoria de programación de alto nivel; lo que se dé o deje de darse va a ser el 100% de las formación mínima del profesional.)
|
¿Y si en vez de seguir bardeando alegremente creas el thread como corresponde para a los que si les interesa puedan informarse?
Pido nuevamente, por favor, cierren el thread.
|
|
|
|
_________________
[Campaña]Revivamos el Chat Fiuba
|
|
| |
|
|
Sebastian Santisi
Administrador Técnico
Edad: 42
Registrado: 23 Ago 2005
Mensajes: 17451
|
|
| Izanagi escribió:
|
|
¿Y si en vez de seguir bardeando alegremente creas el thread como corresponde para a los que si les interesa puedan informarse?
|
No estoy bardeando. Si te sentís bardeado por ese comentario, es un drama tuyo. Estaba contestándole un punto específicamente a Spike, el cual está relacionado con la planificación de un contenido curricular.
Yo conozco la información, y no tengo ningún motivo para ponerme a escribir un reporte si no sé qué es lo que quieren saber. Invité ya tres veces a que abrieran un thread y pregunten. Si te interesa: crealo. Yo no voy a hacerlo por mí mismo.
Al respecto de cerrar el thread: Sólo se hace con threads desubicados. No cerramos threads porque sí en este foro.
|
|
|
|
_________________
|
|
| |
|
|
Sid Bernard
Nivel 9
Edad: 35
Registrado: 20 Jul 2008
Mensajes: 1287
Ubicación: Al lado del Sub Esp. $ = <(TT,0,2+3i)(3,18,4)(0,0,e)>
Carrera: Electrónica y Informática
|
|
Sigo con la idea de que [75.40] Tiene que seguir dandose en Pascal...
Ya se que muchos de uds no se bancan a este lenguaje xq no sirve para una mierda... blablablabla
ok pero fijense que para mi como comienzo es espectacular, sigo sosteniendo q es lo mejor para aprender una programacion estructurada para [75.40] es PASCAL
Python para los temas de [75.40] no me parecen adecuados... ya que terminas haciendo codigos de 10 lineas como mucho y sin mucha idea de lo q es la programacion estructurada...
si quieren meter Python al dpto de computacion haganlo con la materia [75.01] total... mucho no les importa la computacion salvo para Analisis Numerico I pero dsp...
en fin si tengo q opinar esta todo claro que estoy totalmente en contra de que introduzcan Python
|
|
|
|
_________________
![[tex]\ll[/tex]](images/latex/18b0ee03b28e763622221fda561df49104e1b3e8_0.png "[tex]\ll[/tex]") ![[tex]${\Large \definecolor{forestgreen}{rgb}{0.13,0.55,0.13} \color{forestgreen} [S]iD [B]eRnArD!}$ [/tex]](images/latex/6c26715c673b69707083d47474a370e7efaea3c0_0.png "[tex]${\Large \definecolor{forestgreen}{rgb}{0.13,0.55,0.13} \color{forestgreen} [S]iD [B]eRnArD!}$ [/tex]") ![[tex]\gg[/tex]](images/latex/0e111618adc71d5c5a3da3b35e41887d8078d70d_0.png "[tex]\gg[/tex]") ![[tex] ${. \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ .}$ [/tex]](images/latex/3ab0ca99025a1273576a70bba37de38367369007_0.png "[tex] ${. \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ .}$ [/tex]") ![[tex]\color{blue} "\mathbf{\mathit{The\, Music\, Rules\, The\, World}}" [/tex]](images/latex/977817249ec7b4599126eef9d7046fe801e615ed_0.png "[tex]\color{blue} \"\mathbf{\mathit{The\, Music\, Rules\, The\, World}}\" [/tex]")
SOY ACERISTA Y QUE!!!!!
|
|
 |
|
|
EpidemiaN
Nivel 7
Edad: 35
Registrado: 28 Ago 2007
Mensajes: 402
Carrera: Informática
|
|
En un principio me abstuve de opinar en este thread por alún motivo que ahora, siendo mas de las 4am, ya no recuerdo...
En general, coincido con SS y los otros que opinaron sobre que lo importante de las materias de programación son los conceptos y no las herramientas que se usan para ponerlos en práctica.
Discutir sobre qué lenguaje usar en un curso de programación es como discutir sobre si usar la notacion de Leibniz o la de Lagrange para derivadas en un curso de análisis matemático.
Pero es interesante discutir sobre notación de derivadas -yo defiendo la de Laibniz a full- asi que no tiene nada de malo discutir un poco sobre lenguajes/herramientas/plataformas de programación.
En particular, sobre Pascal vs Python, no me declaro a favor ni en contra de ninguno, pero podría mencionar algunas cosas:
- Escuché gente argumentar sobre que en Python no existe diferencia entre value types y reference types, y que esa es una cosa que se debería aprender claramente desde un pincipio. Coincido en parte con esto, pero dejaría ese "desde un principio" abarcar a algo2, donde creo que este tema debería ser tratado.
Para los temas que se ven en algo1 no importa si las variables estan asociadas al valor de un dato o son una referencia a éstos. Importa, sí, la diferencia semantica en el pasaje de perametros por referencia o por valor(la tipica frase "las estructuras pasarlas siempre por referencia").
En este aspecto creo que ninguno de los dos lenguajes lleva una ventaja. Sí opinaría en contra, por ejemplo, de C, que para pasar algo por referencia es necesario usar punteros, teniendo que introducir sintaxis nueva y la noción "le paso la dirección de memoria de esa cosa", cuando ésto creo que no debería importar a un alumno de algo1.
- Sobre tipado dinámico vs tipado estático (tratando de no entrar en una discución sobre qué mejor o peor como caso general y acotando sólo a algo1).
Algo que recuerdo que recuerdo muy frustratante sobre la forma de implementar cosas en Pascal en algo1, era la falta de concepto de genericidad. Es decir, no está bueno tener que hacer dos funciones, una para ordenar (por bubble-sort  ) un vector de enteros y otra para ordenar un vector de vacas. Eso huele feo hasta en algo1 para alguien que nunca había visto progrmación en su vida.
Con la ayuda del tipado dinámico esto podría resolverse de manera natural (sin tener que mencionar la idea de polimorfismo ni nada por el estilo =P). En este sentido, +1 punto para Python.
- El hecho de que para programar en Python no se necesite mas que un editor de textos corriente y el intérprete es un cómodo punto a favor (por Diós, qué fiero que era el Turbo Pascal!).
- Por otro lado, a mi personalmente me gustó el sentimiento de "wow, qué fiero que era Pascal, C++ es mucho mas groso" cuando hice algo2 y "Java >>> C++" en algo3. Creo que podría llegar a ser medio frustrante hacer a la inversa =P.
Como comentario anecdótico, obiamente que la idea de aprender programación en la facu debería implicar aprender a programar bien. Pero la verdad es que hay personas que, incluso habiendo estudiado formalmente, terminan progrmando como el traste. Tuve la desgracia de tener que trabajar con programadores mochos (pero mochos mochos he!) en lenguajes estaticamente tipados (Java) y dinámicamente tipados (actionscript/javascript) y la verdad es que, a la hora de código inentendible e inmantenible, creo que nada supera a los destrozos que puede llegar a hacer un progrmador super-mocho en un lenguaje de tipado dinámico.
Asi que, en este sentido, siendo algo1 la primer materia de programcion; la materia que toda persona que hizo algo de ingeniería informática cursó; quizá la única materia de progrmación que necesite un mocho para sentirse suficientemente confiado para animarse a currar de progrmador... No me parece del todo buena idea que se les de la herramienta para poder ser un mocho cancer-de-proyectos en un lenguaje actual y más aún con la flexibilidad (flexibilidad que puede ser usada para transformar la simpleza y elegancia en bosta) que permite el tipado dinámico =P.
Eso es todo... (no pensé que me iba a salir tan largo el post...)
|
|
|
|
|
|
 |
|
|
Sebastian Santisi
Administrador Técnico
Edad: 42
Registrado: 23 Ago 2005
Mensajes: 17451
|
|
Un par de comentarios descolgados:
| EpidemiaN escribió:
|
|
- Escuché gente argumentar sobre que en Python no existe diferencia entre value types y reference types, y que esa es una cosa que se debería aprender claramente desde un pincipio. Coincido en parte con esto, pero dejaría ese "desde un principio" abarcar a algo2, donde creo que este tema debería ser tratado.
|
Python tiene el concepto y es algo que está presente todo el tiempo (o al menos es algo que se comporta similarmente). Lo que no te deja es a vos decidir cuándo usar uno u el otro-
La nomenclatura en Python de esto es "mutable" e "inmutable"; las cosas mutables se comportan como si vinieran por referencia, las cosas inmutables se comportan como si vinieran por valor.
Extrapolando a, por ejemplo, C#; si bien C# no tiene este mecanismo de mutabilidad, los tipos básicos y las estructuras se manejan siempre por valor (salvo que le pongas un ? a la definición, y ahí tenés un puntero a dato) y luego hay objetos como String donde por más que el pasaje sea por referencia, porque es un objeto, no hay que ser muy observador para darse cuenta de que no hay un sólo método de String que permita modificar un String. ¿Por qué las Strings el lenguaje las maneja como "inmutables"?; porque, obviamente, la VM para optimizar recursos, tiene un caché de cadenas y si tuvieras dos veces una cadena idéntica, sería una referencia al mismo objeto (tampoco es un singletone ni nada por el estilo, está implementado a un nivel mucho más bajo en el CLI).
La inmutabilidad de Python tiene una fuente similar a la de la inmutabilidad de las cadenas de C#; pero a la larga el comportamiento que se siente es similar a la del pasaje por valor de C# de los tipos básicos. En realidad en Python TODO son instancias de objetos, la inmutabilidad sirve para poder armar cachés. En Python son inmutables los números, las cadenas y las tuplas (que si son tuplas de objetos mutables, el que cambia es el contenido pero la tupla se mantiene). (Esto es una diferencia atroz con Java, C# y compañia donde tenés cosas que están en memoria real y otras que son objetos; acá el número 3 es una instancia de la clase Int con el valor 3, y si alguna vez te enfrentás con la interface C de Python, te vas a encontrar con que para usar el 3, tenés que incrementarle el contador de referencias del GC y al terminar de usarlo tenés que decrementarlo... lo mismo si tu función va a retornar None, ¡no te olvides de incrementar el contador de None! )
Entonces:
| EpidemiaN escribió:
|
|
Para los temas que se ven en algo1 no importa si las variables estan asociadas al valor de un dato o son una referencia a éstos. Importa, sí, la diferencia semantica en el pasaje de perametros por referencia o por valor(la tipica frase "las estructuras pasarlas siempre por referencia").
|
Sí, tenés los dos tipos. Y por más que en el pasaje de inmutables también se está pasando la referencia, para saber que se implementa con una referencia y no con un pasaje por valor tenés que hilar muy fino. A los efectos prácticos de uso, no notás la diferencia. Si una función recibe un parámetro el cual es una referencia pero que no podés modificar de ningún modo hacia afuera sin reasignarla, a los efectos prácticos, se siente igual a que el pasaje hubiera sido por valor.
| EpidemiaN escribió:
|
|
En este aspecto creo que ninguno de los dos lenguajes lleva una ventaja. Sí opinaría en contra, por ejemplo, de C, que para pasar algo por referencia es necesario usar punteros, teniendo que introducir sintaxis nueva y la noción "le paso la dirección de memoria de esa cosa", cuando ésto creo que no debería importar a un alumno de algo1.
|
Estoy de acuerdo. Por eso la incompatibilidad entre 75.02 y 75.40 que la CC de Electrónica quiere abolir como si fuera tan fácil. A un tipo de Informática no le aporta en nada una introducción de punteros como se da en C donde a la 3er clase estamos metiéndole un ampersand a scanf().
(Como apunte, vale decir que también evaluamos D como lenguaje, por ese tipo de cosas. En este caso lo descartamos no por el lenguaje en sí, sino porque todavía no está ni muy standarizado ni muy difundido y tampoco hay un compilador que mande como el GCC.)
| EpidemiaN escribió:
|
- Sobre tipado dinámico vs tipado estático (tratando de no entrar en una discución sobre qué mejor o peor como caso general y acotando sólo a algo1).
Algo que recuerdo que recuerdo muy frustratante sobre la forma de implementar cosas en Pascal en algo1, era la falta de concepto de genericidad. Es decir, no está bueno tener que hacer dos funciones, una para ordenar (por bubble-sort ) un vector de enteros y otra para ordenar un vector de vacas. Eso huele feo hasta en algo1 para alguien que nunca había visto progrmación en su vida.
|
Acá el problema no es con Pascal sino con el TurboPascal... o sea, están usando una poronga no standard de 16 bits con todos los vicios de usar una bilioteca privativa.
Ahora que la mayor parte de los cursos migraron a FreePascal, es posible resolver este problema como se resuelve en cualquier lenguaje que no tenga objetos. No hacen falta objetos para hacer un método de ordenamiento genérico. Con punteros a funciones te sobra.
En abstracción dentro de lenguaje sin objetos a C no tenés con qué darle por ningún lado. Es elegante y sencillo por donde se lo mire. Con punteros a void más punteros a funciones, la única razón por la cual te puede hacer falta un lenguaje con objetos en tu vida es si necesitás herencia o si te cansás de tener las funciones sueltas y no podés usar la notación de punto.
| EpidemiaN escribió:
|
|
Con la ayuda del tipado dinámico esto podría resolverse de manera natural (sin tener que mencionar la idea de polimorfismo ni nada por el estilo =P). En este sentido, +1 punto para Python.
|
En realidad... en el curso piloto de 75.40 también resolvimos este tipo de cosas, primariamente mediante punteros a funciones. La diferencia ahí con C es que para Python los objetos pueden ser callables o no-calleables. Es totalmente natural pasar un puntero a función, con una sintaxis que no está contaminada por el tipado; cosa que en C es algo horrendo de dar.
De todos modos, es lamentable que haciendo determinadas elecciones de cátedras en Informática/Sistemas, un flaco pueda llegar a Algoritmos III sin haber visto un puntero a función en su vida, y crea después que necesitás objetos para manejar algo así (ojo, dada la susceptibilidad de este thread, aclaro que no quiero decir que vos lo hayas dicho sino que he visto muchísima gente que lo dice). Es muy notorio el prejuicio que tiene mucha gente en la carrera con el ADT en un lenguaje estructurado, que es sólo por haber aprendido a los ponchazos y mal (algo similar me pasa a mí con C++, por ejemplo, que es resultado de una frustración total).
| EpidemiaN escribió:
|
|
- El hecho de que para programar en Python no se necesite mas que un editor de textos corriente y el intérprete es un cómodo punto a favor (por Diós, qué fiero que era el Turbo Pascal!).
|
Eso es un problema exclusivo del TurboPascal.
Si vamos a hablar de cosas que necesita el TurboPascal, lo que te pongo en primer lugar es: Windows.
Es importantísimo que en todos los cursos de cualquier materia se utilicen en la medida que sea posible y existan herramientas multiplataforma y portables. Y, con igual importancia, herramientas libres. Hay que observar que el TurboPascal es privativo y que lo están pirateando.
Igualmente, hoy en día casi todos migraron a FreePascal.
Al respecto de la consola de Python: Sí, es un golazo. Fue una de las cosas que inclinaron mucho la balanza en torno a la elección.
| EpidemiaN escribió:
|
|
- Por otro lado, a mi personalmente me gustó el sentimiento de "wow, qué fiero que era Pascal, C++ es mucho mas groso" cuando hice algo2 y "Java >>> C++" en algo3. Creo que podría llegar a ser medio frustrante hacer a la inversa =P.
|
Algo que creo que les quedó muy en claro en el curso es que hay lenguajes para cada necesidad y no es que Python sea bueno y C sea malo (Pascal o BASIC, por ejemplo, son definitivamente malos, los estudies por donde los estudies). En las últimas semanas del curso, los introducimos a C como segundo lenguaje, para que puedan conocer las diferencias entre trabajar con un lenguaje dinámico con manejo de memoria automático, versus un lenguaje tipado estático (débil) con memoria estática (si bien hablamos de la gestión de memoria, no introducimos la sintaxis). C lo aprenden como segundo lenguaje, y te sorprenderías de lo rápido que se fija C cuando sabés un lenguaje previamente y simplemente mirás las diferencias y similitudes. En 2 semanas de C, el nivel que adquieren es bastante interesante para lo que es la curva de aprendizaje de C como primer lenguaje (cosa que sufro en 75.02).
| EpidemiaN escribió:
|
Como comentario anecdótico, obiamente que la idea de aprender programación en la facu debería implicar aprender a programar bien. Pero la verdad es que hay personas que, incluso habiendo estudiado formalmente, terminan progrmando como el traste. Tuve la desgracia de tener que trabajar con programadores mochos (pero mochos mochos he!) en lenguajes estaticamente tipados (Java) y dinámicamente tipados (actionscript/javascript) y la verdad es que, a la hora de código inentendible e inmantenible, creo que nada supera a los destrozos que puede llegar a hacer un progrmador super-mocho en un lenguaje de tipado dinámico.
Asi que, en este sentido, siendo algo1 la primer materia de programcion; la materia que toda persona que hizo algo de ingeniería informática cursó; quizá la única materia de progrmación que necesite un mocho para sentirse suficientemente confiado para animarse a currar de progrmador... No me parece del todo buena idea que se les de la herramienta para poder ser un mocho cancer-de-proyectos en un lenguaje actual y más aún con la flexibilidad (flexibilidad que puede ser usada para transformar la simpleza y elegancia en bosta) que permite el tipado dinámico =P.
|
Mi conclusión es exactamente la contraria a la tuya: El alumno recibe un montón de directivas boludas en lenguajes estáticos (no variables globales, no gotos, no...) y termina haciendo códigos que son cualquiera, pero como compilan y cumplen con las reglas de estilo que pide el corrector de turno, funcionan.
Cuando pasa a un lenguaje dinámico, sigue haciendo las mismas porquerías, probablemente respetando las mismas reglas, y el hecho de que sea una cagada se nota más.
Lo que está faltando es más materias básicas donde se utilicen alternadamente los dos paradigmas, para poder limpiar vicios que no son más que una consecuencia de haber estudiado en otro paradigma. Un tipo que viene de Java y lo metés en Python, es incapaz de comprender que cosas como las clases abstractas, las clases wrapper, los getters y los setters, las interfaces y un montón de esas cosas NO SON cosas del paradigma de objetos, sino que son limitaciones propias de Java (lo triste de todo esto, es que Fontela lo tiene clarísimo, tiene clarísimo que Java no es un lenguaje muy bueno, y lo dice, lo remarca todo el tiempo; pero sin embargo prevalece el: Si me lo enseñaron es porque es lo más, y si el lenguaje lo tiene es porque depende del paradigma).
Los lenguajes de tipado dinámico (lo cual no necesariamente implica que el lenguaje sea dinámico. Ejemplo: Haskell, que tiene una inferencia de tipos en tiempo de compilación), permiten una mayor abstracción. Si no podés abstraerte, no podés entender cómo diseñar con duck typing. Esto en un lenguaje tipo Java o C# se camoufla, pero en un lenguaje como Python o Ruby queda totalmente expuesto. Ambas cosas están denunciando una persona que no sabe programar. Ahora bien, no podemos en FIUBA estar capacitando a gente para desarrollar en "lenguajes para boludos" como lo es C# (y la expresión no es bardera en lo más mínimo, la inexpresividad de C# es consecuencia inmediata de querer ser un lenguaje que pueda programar un boludo; es el reemplazo de VB de MS, y el objetivo es que cualquiera "se crea" que sabe programar); hay que enseñar a programar, independiente del lenguaje.
|
|
|
|
_________________
|
|
| |
|
|
EpidemiaN
Nivel 7
Edad: 35
Registrado: 28 Ago 2007
Mensajes: 402
Carrera: Informática
|
|
| Sebastian Santisi escribió:
|
Un par de comentarios descolgados:
|
Y un par mas...
| Sebastian Santisi escribió:
|
La nomenclatura en Python de esto es "mutable" e "inmutable"; las cosas mutables se comportan como si vinieran por referencia, las cosas inmutables se comportan como si vinieran por valor.
|
Si, a fines de pasaje de parametros, tener cosas inmutables es lo mismo que tenerlas por valor. El tema que no me convence es que, por ejemplo en Python si querés definir un objeto inmutable, tenés que hacer la clase inmutable... pero esto no es siempre lo deseado, a veces uno quiere tener objetos "normales", mutables, y pasárselos a funciones, pero asegurarse de que estas funciones no les van a hacer nada.
Y esta una de las pocas cosas que me parece que están bien buenas de C++: poder definir referencias const. Si bien me parece parece muy malo lo engorroso de tener que especificar uno mísmo qué métodos son const y qué métodos no (el compialdor debería poder darse cuenta si un método está tocando el objeto, joder!), y que la palabra "const" no es la mas feliz ("val" para cosas por inmutables y "var" para mutables es la posta IMHO), es una herramienta que me parece util desde el punto de vista de diseño de interfases ("estos parámetros son input (val) y estos son output (var)"). (y aclaración: no me refiero a interfases como interfases en java =P)
| Sebastian Santisi escribió:
|
Extrapolando a, por ejemplo, C#; si bien C# no tiene este mecanismo de mutabilidad, los tipos básicos y las estructuras se manejan siempre por valor (salvo que le pongas un ? a la definición, y ahí tenés un puntero a dato) y luego hay objetos como String donde por más que el pasaje sea por referencia, porque es un objeto, no hay que ser muy observador para darse cuenta de que no hay un sólo método de String que permita modificar un String. ¿Por qué las Strings el lenguaje las maneja como "inmutables"?; porque, obviamente, la VM para optimizar recursos, tiene un caché de cadenas y si tuvieras dos veces una cadena idéntica, sería una referencia al mismo objeto (tampoco es un singletone ni nada por el estilo, está implementado a un nivel mucho más bajo en el CLI).
|
Curioso que menciones a C#, que además, en este tema de valor vs referencia, tiene sus super structs para definir "tipos primitivos". La idea no es mala para mi. Pero se arma un mejunje copado cuando de repente la asignación ya no es "ahora esta variable referencia al mismo objeto que la otra" sino que las cosas se copian (y es una diferencia semántica grosa).
Me parece una idea copada por parte de C# ésta porque, si bien está bueno por lo general vivir en una nube de pedos abstractos y tener toda la magia de las refencias, a veces uno necesita bajar a la tierra y decir "quiero que los objetos en este vector esten en un trozo continuo de memoria carajo!", y poder hacerlo =P.
Y en este sentido, la forma en que lo implementaron en C# me parece correcta, ya que, limitando a que los objetos tipo valor (structs) a que no sean objetos heredables y polimárficos, uno safa de las cagadas de C++ en que si uno tiene un vector<Mamifero> y le mete un Delfin, te recorta al pobre delfín para sacarle sólo su parte mamífera (y creo que no hace falta explicar porqué está mal mutilar un pobre delfín). En C# es mas bonito porque no tenés la posibilidad de mandarte ese moco: si querés herencia, usá clases.
| Sebastian Santisi escribió:
|
Sí, tenés los dos tipos. Y por más que en el pasaje de inmutables también se está pasando la referencia, para saber que se implementa con una referencia y no con un pasaje por valor tenés que hilar muy fino. A los efectos prácticos de uso, no notás la diferencia. Si una función recibe un parámetro el cual es una referencia pero que no podés modificar de ningún modo hacia afuera sin reasignarla, a los efectos prácticos, se siente igual a que el pasaje hubiera sido por valor.
|
Estamos de acuerdo.
| Sebastian Santisi escribió:
|
(Como apunte, vale decir que también evaluamos D como lenguaje, por ese tipo de cosas. En este caso lo descartamos no por el lenguaje en sí, sino porque todavía no está ni muy standarizado ni muy difundido y tampoco hay un compilador que mande como el GCC.)
|
Nuuu... Muy groso hubiese sido eso!
D no estará muy difundido, pero más vivo que Pascal está seguro!
Igual, no entendí lo de "un compilador que mande como el GCC"...
| Sebastian Santisi escribió:
|
De todos modos, es lamentable que haciendo determinadas elecciones de cátedras en Informática/Sistemas, un flaco pueda llegar a Algoritmos III sin haber visto un puntero a función en su vida, y crea después que necesitás objetos para manejar algo así (ojo, dada la susceptibilidad de este thread, aclaro que no quiero decir que vos lo hayas dicho sino que he visto muchísima gente que lo dice).
|
De hecho, la mayoría de gente que conosco, llega a Algo3/Taller, sin haber usado punteros a función, y sale de estas materias sin haberlo hecho .
En mi caso, aprendí a progrmar en C, con punteros a función y toda la linda genericidad, por mi cuenta y después de haber cursado Algo3.
Si, es una lástima que sea casi cosa general ese prejuicio de "Hacer este algoritmo genérico sólo se puede hacer con OO"...
| Sebastian Santisi escribió:
|
Es muy notorio el prejuicio que tiene mucha gente en la carrera con el ADT en un lenguaje estructurado, que es sólo por haber aprendido a los ponchazos y mal (algo similar me pasa a mí con C++, por ejemplo, que es resultado de una frustración total).
|
Jajaja. Si, yo con C++ también tuve mis frustraciones y mis reconciliaciones. Es un lenguaje con una grán capacidad de ser odiado/amado .
| Sebastian Santisi escribió:
|
Si vamos a hablar de cosas que necesita el TurboPascal, lo que te pongo en primer lugar es: Windows.
Es importantísimo que en todos los cursos de cualquier materia se utilicen en la medida que sea posible y existan herramientas multiplataforma y portables. Y, con igual importancia, herramientas libres. Hay que observar que el TurboPascal es privativo y que lo están pirateando.
|
Totalmente de acuerdo.
Aclaro que en mi caso, algo1 fue un fiasco. Creo que cursé con la peor cátedra posible: García. Lo peor es que me contaron que volvió! (en forma de fichas!!)
| Sebastian Santisi escribió:
|
Lo que está faltando es más materias básicas donde se utilicen alternadamente los dos paradigmas, para poder limpiar vicios que no son más que una consecuencia de haber estudiado en otro paradigma. Un tipo que viene de Java y lo metés en Python, es incapaz de comprender que cosas como las clases abstractas, las clases wrapper, los getters y los setters, las interfaces y un montón de esas cosas NO SON cosas del paradigma de objetos, sino que son limitaciones propias de Java (lo triste de todo esto, es que Fontela lo tiene clarísimo, tiene clarísimo que Java no es un lenguaje muy bueno, y lo dice, lo remarca todo el tiempo; pero sin embargo prevalece el: Si me lo enseñaron es porque es lo más, y si el lenguaje lo tiene es porque depende del paradigma).
Los lenguajes de tipado dinámico (lo cual no necesariamente implica que el lenguaje sea dinámico. Ejemplo: Haskell, que tiene una inferencia de tipos en tiempo de compilación), permiten una mayor abstracción. Si no podés abstraerte, no podés entender cómo diseñar con duck typing. Esto en un lenguaje tipo Java o C# se camoufla, pero en un lenguaje como Python o Ruby queda totalmente expuesto. Ambas cosas están denunciando una persona que no sabe programar. Ahora bien, no podemos en FIUBA estar capacitando a gente para desarrollar en "lenguajes para boludos" como lo es C# (y la expresión no es bardera en lo más mínimo, la inexpresividad de C# es consecuencia inmediata de querer ser un lenguaje que pueda programar un boludo; es el reemplazo de VB de MS, y el objetivo es que cualquiera "se crea" que sabe programar); hay que enseñar a programar, independiente del lenguaje.
|
En esos dos párrafos tiraste demasiada cantidad de posta. No tengo nada más que agregar a eso.
|
|
|
|
|
|
| |
|
|
Sebastian Santisi
Administrador Técnico
Edad: 42
Registrado: 23 Ago 2005
Mensajes: 17451
|
|
| EpidemiaN escribió:
|
|
Si, a fines de pasaje de parametros, tener cosas inmutables es lo mismo que tenerlas por valor. El tema que no me convence es que, por ejemplo en Python si querés definir un objeto inmutable, tenés que hacer la clase inmutable... pero esto no es siempre lo deseado, a veces uno quiere tener objetos "normales", mutables, y pasárselos a funciones, pero asegurarse de que estas funciones no les van a hacer nada.
|
Sí, igual, esto ya se va del punto...
Más allá de eso, ahí tenés algo que es parte de practicamente todos los lenguajes, salvo C++. Si no querés que te modifiquen el objeto, no te queda mucho más que pasar los valores útiles y no pasar la instancia, o pasar un clon. Más no vas a poder hacer en ningún lado que no implemente el const.
| EpidemiaN escribió:
|
|
Si bien me parece parece muy malo lo engorroso de tener que especificar uno mísmo qué métodos son const y qué métodos no (el compialdor debería poder darse cuenta si un método está tocando el objeto, joder!), y que la palabra "const" no es la mas feliz ("val" para cosas por inmutables y "var" para mutables es la posta IMHO), es una herramienta que me parece util desde el punto de vista de diseño de interfases ("estos parámetros son input (val) y estos son output (var)").
|
El tema es que C++ hereda y aplica la filosofía que lleva a que C implemente dicho modificador. En C, el const servía (entre otras cosas) en el pre-ANSI para que el pasaje de estructuras, que tenía que ser obligatoriamente por puntero, poder discriminar que no iba a modificarse nada adentro.
El const es una documentación hacia dos lados distintos: por un lado para el tipo que va a consumir tu interfaz, y por el otro lado para el programador, que tiene un debugueo. El const le dice al compilador que no te deje modificar, pero no funciona al revés.
En objetos, me parece que es mucho más difuso el asunto. Porque, en realidad, el const te molesta más de lo que te ayuda. Si vos tenés una clase determinada que hace algo, y querés un día agregarle herramientas de profiling; cagaste, no vas a poder incrementar nada desde ninguno de los métodos const. Para poder modificar la implementación en algo que no afectaba al objeto, no te queda otra que alterar la interfase.
Fijate que si el compilador adivinara si es const o no en base al comportamiento; jamás podrías armar una interfase que prevea que algún día podés llegar a modificar adentro. En ese contexto, es una feature el tener que ponerlo explícito (tampoco me parece tan tedioso, comparado con otras cosas horrendas de overhead de sintaxis que trae C++ que hacen engorroso el armar cualquier cosa).
| EpidemiaN escribió:
|
Curioso que menciones a C#, que además, en este tema de valor vs referencia, tiene sus super structs para definir "tipos primitivos". La idea no es mala para mi. Pero se arma un mejunje copado cuando de repente la asignación ya no es "ahora esta variable referencia al mismo objeto que la otra" sino que las cosas se copian (y es una diferencia semántica grosa).
Me parece una idea copada por parte de C# ésta porque, si bien está bueno por lo general vivir en una nube de pedos abstractos y tener toda la magia de las refencias, a veces uno necesita bajar a la tierra y decir "quiero que los objetos en este vector esten en un trozo continuo de memoria carajo!", y poder hacerlo =P.
|
No te fíes, C# tiene un montón de cosas que cuando las leés en la especificación suenan re copadas, pero cuando las vas a usar te das cuenta de que pinchan por todos lados (por ejemplo los punteros).
El problema grosero que tiene esto, es que las estructuras SIEMPRE se pasan por copia, y no hay manera de cambiarlo.
Ejemplo en lo cual esto ya no cierra (y es justamente el mismo ejemplo que acabás de tirar). Metiste un array de estructuras adentro de un objeto. Querés sobrecargar el método [] de tu objeto para poder acceder a los elementos del arreglo...
¡Cosas como:
objetoquetienearraydeestructuras[i].miembrodelaestructura++;
no funcionan! Lo rompiste. Porque para poder hacer eso, necesitás un getter y un setter por referencia. La única manera en la que podés imlementar un comportamiento así es haciendo público tu arreglo (sí, dije eso  ) y accediendo a lo bruto:
objetoquetienearraydeestructuras.elarray[i].miembrodelaestructura++;
(Una vez tuve que escribir un motor gráfico que laburaba con DirectX en C#. Usar referencias no era opción dada la cantidad de nodos... creeme que ahí descubrí que las estructuras de C# no servían mucho más que para representar un DateTime .)
| EpidemiaN escribió:
|
|
(y creo que no hace falta explicar porqué está mal mutilar un pobre delfín)
|
Salvo que el delfín no fuera inteligente y hubiera gastado toda su plata en el casino...
| EpidemiaN escribió:
|
|
Igual, no entendí lo de "un compilador que mande como el GCC"...
|
En C el GCC es practicamente el standard de facto para todo lo que sea implementaciones libres (no necesariamente lo hace El mejor compilador, pero sí es de los mejores). Podés decir: si anda en GCC, ya anda.
En D, hay diferentes proyectos de compilador, diferentes proyectos de GC, y todavía ninguno es EL proyecto por lo que no puede tomarse uno como parámetro de qué está bien.
(Ya nos fuimos de tema mal.)
|
|
|
|
_________________
|
|
| |
|
|
SAn
Nivel 4
Registrado: 16 Ago 2005
Mensajes: 96
Ubicación: Uqbar
Carrera: Electrónica
|
|
Al final ya no se qué se está discutiendo, pero, de la gente que votó, los votos para pascal son votos bronca, nulos o impugnados?
Fuera de joda, si la votación fuese de verdad, si no importara nada más que el lenguaje, me interesaria saber las opiniones pro Pascal de los que votaron.
Espero no meter mas ruido...
|
|
|
|
|
|
| |
|
|
|
|
Ir a página Anterior 1, 2, 3, ... 11, 12, 13 Siguiente
|
Ver tema siguiente
Ver tema anterior
Podés publicar nuevos temas en este foro
No podés responder a temas en este foro
No podés editar tus mensajes en este foro
No podés borrar tus mensajes en este foro
No podés votar en encuestas en este foro
No Podéspostear archivos en este foro
No Podés bajar archivos de este foro
|
Todas las horas son ART, ARST (GMT - 3, GMT - 2 Horas)
Protected by CBACK CrackerTracker365 Attacks blocked.
|
