El codeblocks esta muy bueno, pero tene cuidado porque te deja pasar muchos errores que otros ide no, por ejemplo la memoria colgada, casi ni te avisa. Cuando hicimos el tp de algoritmos 2, lo hicimos en codeblocks y lo debugueamos con boland, ya que nuestro docente corregia con ese IDE y le saltaban muchos errores que nosotros ni enterados. Salu2
Sobre el tema de los IDEs, recomiendo eclipse. Lo que para mi es muy piola es que existen plugins para muchos lenguajes, entonces resulta muy util aprender a moverse rápidamente (F3 para ir a definiciones de cosas, alt + arriba/abajo para mover código, alt + derecha/izq para navegar tipo navegador de internet, la documentación de las clases/funciones pop-upeando, el ctrl + espacio!... etc...) porque después lo podés usar en varios entornos.
Ahora bién, por otro lado, a una persona que recién agarra un lenguaje, me parece que es importantísimo que entienda los conceptos más básicos de compilar y poner a andar un programa sin un IDE: abrir un editor de textos normal, escribir un código sencillo, ir a la consola y (en el caso de C++)
$ g++ *.cpp -o mi-progama
$ ./mi-programa
y entender qué carajo pasa, en especial en la primer linea. Una vez que se tiene claro eso, se entiende que el IDE está simplemente integrando esas cosas, pero está bueno comprender los pasos más básicos independientemente.
Una vez que se tiene esa base, en mi opinión es un golazo un IDE, por los motivos que mencioné antes (y, en algunos lenguajes, lindos refactors y generación de código automático a las chapas (cuando java (*) te dice que no existe tal variable/función/clase, ctrl+shift+1 -> creámela eclipse... con eso se puede hacer top-down programming a los gomazos)).
Además, si bien en caso de C++ soy muy limado de tener siempre un Makefile para los proyectos, pues "no dependés del IDE para compilar varias cosas, manejar dependencias, etc", un makefile medianamente complejo puede ser un dolor de huevos importante. Si todos en un proyecto usan el mismo IDE (eclipse en este caso), se puede compartir el archivo .project del proyecto y resulta super práctico/organizado el laburo, chau problemas de encoding, chau "pero ahora para compilar hay que linkear con esta otra biblioteca", chau "a alguos le anda el autocompletar y a otros no" por no compartir la configuración de los includes, chau "a mi esos warnings no me los tira", etc... todo eso va a la configuración del proyecto en el .project y todo es comaprtido/sincronizado entre la gente que labure en el proyecto.
(*) En C++ teóricamente también se podría hacer esto, pero es un lenguaje tan duro de parsear y con reglas de declaración/definición/sobrecarga/templates tan complicadas que ningún desarrollador de plugins tipo CDT se va a meter en tanto bardo. También se podría usar el compilador para ayudar en la tarea (ya que él seguro va a saber cuándo falta una variable/función/etc) pero con lo que tarda en compilar C++, y al no existir (aún) un compilador incremental eso es algo aún más improbable.
(edit, agrego último párrafo...)
Última edición por EpidemiaN el Sab Mar 06, 2010 10:58 pm, editado 2 veces
Así como Vim o Nano son estándares para GNU/Linux y no hay máquina donde no esté al menos uno de los dos... notepad es el standard para Windows.
Más allá del chiste, he tenido que programar en Notepad en servidores remotos administrados por terceros donde no había manera de transferir archivos y no quedaba otra que editar in situ.
Yo no entiendo cómo puede existir algo llamado "Windows Server", cómo las empresas pueden usarlo, y cómo puede ser tan cuadrado y lejano de lo que necesita cualquier persona que vaya a interactuar con un servidor.
El editor de textos default de una interfase gráfica debería ser mínimamente acorde a lo que el sistema resuelve. Un servidor con un editor que sólo te deja hacer deshacer una vez, es una lágrima.
En esto, tanto GEdit como KEdit son dos editores que pueden ser usados como IDE sin mayores preocupaciones (Notepad++ está en la onda de estos dos); el GEdit sé que es extendible a autocompletados de código y ese tipo de cosas por medio de plugins, el Kedit no sé.
Tomando lo que dijo EpidemiaN, el tema generación del proyecto es un punto y creo que lo toqué tangencialmente cuando mencioné lo del VS. Si vos estás programando un proyecto que sí o sí vas a desarrollar en un determinado entorno y jamás lo vas a sacar de ahí, es cómoda la cuestión de usar una herramienta integrada que te resuelva las cosas (que te las resuelva bien, porque, por ejemplo, los Makefiles que genera el Dev-C++ en modo imperfecto -default- son tétricos e incompletos).
Hay lenguajes y proyectos que cumplen esa premisa y es no sólo cómodo si no recomendable hacer uso del IDE. Muchos frameworks ni siquiera son viables de usar por fuera del IDE que traen acoplado.
El tema con Algoritmos II y C++ es que el globo se pincha cuando tu docente va a tener que lidiar con el mismo código que trabajó tu grupo de TP. Para algo de esas características, al menos yo, prefiero trabajar/compilar contra un entorno que lo más avanzado que te genere sea un makefile (ni siquiera un automake). Cualquier otra cosa por encima de eso, es para dolor de cabeza.
Si a la pregunta de "¿y cómo lo compilaste?" un alumno responde con "apretando F9" tenés un problema. Si a la pregunta de "¿y cómo lo compilo yo para probarlo?" el alumno responde "instalás el..." ya vamos para atrás.
Lo que comenta csebas es igual de lamentable. Si un docente quiere que el alumno esté en su misma sintonía, que use un programa que no haya que piratear y que sea multiplataforma.
En el mundo profesional, es lo mismo; lo que vos desarrollaste cómodo en tu máquina, tal vez tengas que ajustarlo remotamente contra una terminal. Si tu requisito para editar un fuente es "instalame una interfase gráfica y la JVM que voy a editar dos líneas y recompilar" te van a pegar una patada en el culo. Más de una vez se van a encontrar con el caso en el cual ni siquiera es viable compilar fuera de la máquina destino, porque la máquina destino puede ser de otra arquitectura o estar construida con otro compilador específico...
Por eso, cuidado; la herramienta nunca tiene que ocultar lo que se está haciendo. Nunca caigan en entornos donde no vayan a ser capaces de trabajar después por fuera del entorno... menos contra un entorno privativo; cambia la versión y se meten todo lo desarrollado en el ocote.
Edad: 34
Registrado: 07 Mar 2010
Mensajes: 74
Ubicación: R. de Escalada, Bs As, Argentina
Carrera: Informática
el code blocks es muuuuy completo, tal vez demasiado en el fondo no necesitas mas q un editor de textos, una terminal y un compilador...
ahh y algunas tazas de cafe!
suerte
_________________ In a world without frontiers, who needs Gates and Windows?
--------------------------
Edad: 36
Registrado: 11 Sep 2007
Mensajes: 1234
Ubicación: Para mi siempre será San Telmo...
Carrera: Electrónica, Informática y Sistemas
Puesto que no esta el vi no me queda otra más que elegir el Eclipse... pero realmente no puede faltarte el vi, si no programaste algo en vi en tu vida te estas perdiendo de algo doloroso y reconfortante a la vez! jajaja
Registrado: 16 Ago 2005
Mensajes: 96
Ubicación: Uqbar
Carrera: Electrónica
Lo mejor, como dijeron varios, es un buen editor y una buena consola. Hay muchas herramientas interesantes que pueden reemplazar a un Makefile para cosas complicadas, como por ejemplo SCons, etc.
Los que dicen que si el proyeto es grande es mejor tener un IDE, qué cosas que un editor no puede resolver las puede resolver un IDE mejor para proyectos grandes?
esencialmente las dependencias, un verdadero autocomplete, un buen seguimiento del debug, scripts que te permitan manejar el svn(git o lo que sea) y maven, ant o scons a gusto... que más a ver... ah si esa maravilla que te avisa cuando algo no te va a compilar (como es que se llama?) o lo de codigo duplicado, herramientas de refactor....
el manejo del proyecto y de sus paquetes, la administracion de archivos de manera ordenada y automatizada...
Si hay herramientas para todo eso, pero en un buen ide estan todas juntas al alcance de la mano.
Uuuuuuuuuuuuuuuuh. Pinta para un flamewar Emacs vs Vim.....
En fin. Yo voté C::B (por el simple hecho que no estaba Emacs XD).
De los que listas, para MI, es el mejor. No estoy hablando de un tema de configuración, hablo por un tema de recursos. Creo que actualmente esta de moda eso de: "El hard es barato, comprate algo mas nuevo". El Eclipse encaja (creo yo) en este perfil. Es un pacman de recursos. Admito que es cómodo para algunas cosas, pero el C::B no tiene nada que envidiarle en cuanto a funcionalidad.
Edad: 33
Registrado: 13 Mar 2010
Mensajes: 20
Ubicación: Balvanera, Ciudad Autónoma de Buenos Aires
Carrera: Informática y Sistemas
EpidemiaN escribió:
Sobre el tema de los IDEs, recomiendo eclipse. Lo que para mi es muy piola es que existen plugins para muchos lenguajes, entonces resulta muy util aprender a moverse rápidamente (F3 para ir a definiciones de cosas, alt + arriba/abajo para mover código, alt + derecha/izq para navegar tipo navegador de internet, la documentación de las clases/funciones pop-upeando, el ctrl + espacio!... etc...) porque después lo podés usar en varios entornos.
Ahora bién, por otro lado, a una persona que recién agarra un lenguaje, me parece que es importantísimo que entienda los conceptos más básicos de compilar y poner a andar un programa sin un IDE: abrir un editor de textos normal, escribir un código sencillo, ir a la consola y (en el caso de C++)
$ g++ *.cpp -o mi-progama
$ ./mi-programa
y entender qué carajo pasa, en especial en la primer linea. Una vez que se tiene claro eso, se entiende que el IDE está simplemente integrando esas cosas, pero está bueno comprender los pasos más básicos independientemente.
Una vez que se tiene esa base, en mi opinión es un golazo un IDE, por los motivos que mencioné antes (y, en algunos lenguajes, lindos refactors y generación de código automático a las chapas (cuando java (*) te dice que no existe tal variable/función/clase, ctrl+shift+1 -> creámela eclipse... con eso se puede hacer top-down programming a los gomazos)).
Además, si bien en caso de C++ soy muy limado de tener siempre un Makefile para los proyectos, pues "no dependés del IDE para compilar varias cosas, manejar dependencias, etc", un makefile medianamente complejo puede ser un dolor de huevos importante. Si todos en un proyecto usan el mismo IDE (eclipse en este caso), se puede compartir el archivo .project del proyecto y resulta super práctico/organizado el laburo, chau problemas de encoding, chau "pero ahora para compilar hay que linkear con esta otra biblioteca", chau "a alguos le anda el autocompletar y a otros no" por no compartir la configuración de los includes, chau "a mi esos warnings no me los tira", etc... todo eso va a la configuración del proyecto en el .project y todo es comaprtido/sincronizado entre la gente que labure en el proyecto.
(*) En C++ teóricamente también se podría hacer esto, pero es un lenguaje tan duro de parsear y con reglas de declaración/definición/sobrecarga/templates tan complicadas que ningún desarrollador de plugins tipo CDT se va a meter en tanto bardo. También se podría usar el compilador para ayudar en la tarea (ya que él seguro va a saber cuándo falta una variable/función/etc) pero con lo que tarda en compilar C++, y al no existir (aún) un compilador incremental eso es algo aún más improbable.
(edit, agrego último párrafo...)
Sebastian Santisi escribió:
Amadeo escribió:
Los machos programamos con el Bloc de Notas (?)
Así como Vim o Nano son estándares para GNU/Linux y no hay máquina donde no esté al menos uno de los dos... notepad es el standard para Windows.
Más allá del chiste, he tenido que programar en Notepad en servidores remotos administrados por terceros donde no había manera de transferir archivos y no quedaba otra que editar in situ.
Yo no entiendo cómo puede existir algo llamado "Windows Server", cómo las empresas pueden usarlo, y cómo puede ser tan cuadrado y lejano de lo que necesita cualquier persona que vaya a interactuar con un servidor.
El editor de textos default de una interfase gráfica debería ser mínimamente acorde a lo que el sistema resuelve. Un servidor con un editor que sólo te deja hacer deshacer una vez, es una lágrima.
En esto, tanto GEdit como KEdit son dos editores que pueden ser usados como IDE sin mayores preocupaciones (Notepad++ está en la onda de estos dos); el GEdit sé que es extendible a autocompletados de código y ese tipo de cosas por medio de plugins, el Kedit no sé.
Tomando lo que dijo EpidemiaN, el tema generación del proyecto es un punto y creo que lo toqué tangencialmente cuando mencioné lo del VS. Si vos estás programando un proyecto que sí o sí vas a desarrollar en un determinado entorno y jamás lo vas a sacar de ahí, es cómoda la cuestión de usar una herramienta integrada que te resuelva las cosas (que te las resuelva bien, porque, por ejemplo, los Makefiles que genera el Dev-C++ en modo imperfecto -default- son tétricos e incompletos).
Hay lenguajes y proyectos que cumplen esa premisa y es no sólo cómodo si no recomendable hacer uso del IDE. Muchos frameworks ni siquiera son viables de usar por fuera del IDE que traen acoplado.
El tema con Algoritmos II y C++ es que el globo se pincha cuando tu docente va a tener que lidiar con el mismo código que trabajó tu grupo de TP. Para algo de esas características, al menos yo, prefiero trabajar/compilar contra un entorno que lo más avanzado que te genere sea un makefile (ni siquiera un automake). Cualquier otra cosa por encima de eso, es para dolor de cabeza.
Si a la pregunta de "¿y cómo lo compilaste?" un alumno responde con "apretando F9" tenés un problema. Si a la pregunta de "¿y cómo lo compilo yo para probarlo?" el alumno responde "instalás el..." ya vamos para atrás.
Lo que comenta csebas es igual de lamentable. Si un docente quiere que el alumno esté en su misma sintonía, que use un programa que no haya que piratear y que sea multiplataforma.
En el mundo profesional, es lo mismo; lo que vos desarrollaste cómodo en tu máquina, tal vez tengas que ajustarlo remotamente contra una terminal. Si tu requisito para editar un fuente es "instalame una interfase gráfica y la JVM que voy a editar dos líneas y recompilar" te van a pegar una patada en el culo. Más de una vez se van a encontrar con el caso en el cual ni siquiera es viable compilar fuera de la máquina destino, porque la máquina destino puede ser de otra arquitectura o estar construida con otro compilador específico...
Por eso, cuidado; la herramienta nunca tiene que ocultar lo que se está haciendo. Nunca caigan en entornos donde no vayan a ser capaces de trabajar después por fuera del entorno... menos contra un entorno privativo; cambia la versión y se meten todo lo desarrollado en el ocote.
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 CrackerTracker 365 Attacks blocked.
![[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]")
