Hola, estoy aprendiendo C++ y al principio usé una línea de comandos ... luego comencé a usar Xcode (y desde entonces no pude volver a la línea de comandos) y me preguntaba algunas razones/situaciones específicas para usar Command -line en lugar de IDE ...¿Por qué las personas usan Command-line en lugar de IDE?
Más eficiente para sistemas grandes - Intente abrir una solución VS con 100 proyectos y 10.000 archivos.
Más simple para muchas tareas, edita en una ventana, ejecuta make en otra, tiene gdb en una tercera.
más fácil de automatizar tareas, a menudo más fácil de trabajar en equipo o multiplataforma si todo el mundo tiene gcc y VI (o emacs)
Utiliza la línea de comandos cuando quiere automatizar sus compilaciones de software. Esto normalmente se hace cuando está listo para lanzar su software, y necesita hacer otras cosas como el empaquetado del instalador además de la compilación del software antes de poder entregar el software a los usuarios.
Más allá de eso, siempre debe usar un IDE para fines de depuración, compilación y edición de código.
¿Siempre? Eso es un poco demasiado amplio :) Puedo pensar en muchas instancias, con productos reales, donde un IDE es excesivo (y por lo tanto innecesario) – KevinDTimm
No puedo decir que estoy de acuerdo. Puede que sea solo mi herencia UNIXy, pero soy bastante productivo con 'gdb' +' vim' + 'make' - y además, usando esos medios puedo ser productivo con nada más que una conexión SSH de ancho de banda bajo desde una netbook en quién sabe dónde. –
+1 Charles - Me encanta ver a los noobs luchar con sus errores de configuración de GUI mientras trabajo. Pero están casados con esa GUI. Mírelos pasar de un personaje a otro en algún momento (mouse/type/mouse/type/ad nauseum), es suficiente para hacer que llore. – KevinDTimm
un grande para mí es el editor. Realmente me encanta vim, y es bastante raro que un IDE tenga una buena emulación vim, especialmente porque uso dvorak y tengo que reasignar muchas de las claves. Para muchas otras personas, dirían lo mismo, excepto que elegirían emacs.
La mayoría de los editores de IDE son pálidos en comparación con los de vim o emacs. Hay funciones que te pierdes o que son mucho más difíciles de conseguir para que funcionen bien. Por ejemplo, ctags definitivamente te ayuda a saltar a las definiciones de funciones en vim, pero no es tan bueno como muchos IDE pueden hacer ya que realmente entienden el lenguaje. Y, por supuesto, la integración de depuradores y la gestión de proyectos no funcionarán tan bien en vim o emacs porque no son IDE completos (aunque puedes hacer muchas de esas cosas con ellos). Pero a menudo, el poder de vim o emacs eclipsa todo lo que el IDE tiene sobre ellos.
Además, en lo que respecta a los editores de línea de comandos, se pueden ejecutar en la línea de comandos cuando no se tiene acceso a un entorno con una GUI, por lo que hay muchas situaciones donde esa flexibilidad es grande más.
Por supuesto, sería genial si pudiera combinar todas las excelentes características de vim o emacs con un IDE completo, y hay algunos intentos para hacerlo, pero siempre hay problemas con él, e incluso los mejores intentos están lejos de ser perfectos. Por lo tanto, a menudo todavía está atrapado con la elección de vim o emacs y las características que aportan o un IDE con las características que trae.
EDITANDO: Entrando en por qué vim o emacs es mucho más poderoso en muchos aspectos de lo que su IDE típico podría ser bastante extenso, y ya hay varias preguntas sobre SO que cubren eso.
Esta es una gran respuesta en emacs: https://stackoverflow.com/questions/35809/why-are-vi-and-emacs-popular/35929#35929
Este es un buen artículo sobre vi que parece a conectarse con frecuencia: http://www.viemu.com/a-why-vi-vim.html
Para un intento rápido de mi parte para dar algunas razones por las vim es más potente:
Su IDE típico es básicamente un bloc de notas mejorado desde el punto de vista de edición de texto. Teclea el texto y usa el mouse para desplazarse (que a veces es bastante útil, pero puede ser un poco más lento que solo usar el teclado).Agregan funciones específicas de código como la finalización de código, sangría automática de código, la capacidad de saltar a definiciones de funciones, herramientas de refactorización, etc. (por lo tanto, los IDE pueden ser tan útiles). Pero sus habilidades básicas de edición de texto son bastante malas. Pueden agregar algunas características útiles como ctrl-d para eliminar una línea, pero lo que agregan es generalmente muy limitado en comparación con lo que obtendrías en vim o emacs.
Tome la eliminación (una operación muy básica) como ejemplo. En vim, puede utilizar la operación de eliminación con cualquier comando de movimiento, lo que permite una cantidad potencialmente asombrosa de eliminar cosas.
dd Eliminar una línea completa.5dd Eliminar 5 líneas.dj Mueva el cursor hacia arriba, eliminando todo a la izquierda en la línea actual y todo a la derecha en la línea superior.dG Borrar todo desde aquí hasta el final del archivo.7dgg Eliminar todo lo de aquí a la línea 7.d% Mover a éste, o que paren, que coincide con las siguientes paren o aparato ortopédico (lo que ocurra primero) y eliminar todo lo que entre aquí y allá, incluyendo el aparato ortopédico o paren que saltar adw eliminar todo lo que de aquí a la próxima principio de una palabrade Eliminar todo lo de aquí a la próxima final de una palabraD Eliminar todo lo que entre aquí y el final de la línead0 eliminar todo lo que entre aquí y el comienzo de la línead^ eliminar todo lo que entre aquí y el comienzo de la primera palabra en la líneadty eliminar todo lo que de aquí a la próxima ocurrencia de y en esta línea (o nada si no hay y entre este y el final de la línea)La lista sigue y sigue. Y eso es solo para eliminar. Lo mismo vale para una lista completa de otros comandos básicos. Y eso es solo comandos básicos. Hay muchos, muchos más comandos que son más avanzados y bastante poderosos. Vim puede hacer tanto que la mayoría de las personas que lo usan solo usa una fracción de lo que es capaz de hacer.
La mayoría de los IDE ni siquiera tienen una fracción de una fracción de dichas capacidades de edición. Tienen muchas otras funciones específicas de programación y específicas del lenguaje de las que carecen vim y emacs, o en las que son mucho más difíciles de poner en práctica, como una buena terminación del código sensible al contexto, herramientas de refactorización, administración de proyectos, etc. Pero como para las capacidades de edición de texto, la mayoría de los IDE simplemente no pueden comparar.
@Jonathan, el editor de Xcode en realidad es bastante bueno. –
@Michael Oh, puede que sea así. De hecho, nunca había oído hablar de Xcode. Puede que tenga que probarlo. Pero la mayoría de los IDE tienen una emulación de vim bastante pobre si es que tienen alguno. Y estoy tan acostumbrado a que a menos que pueda hacer que un IDE actúe exactamente igual que vim (al menos para los comandos que uso), puede ser muy frustrante. –
@Jonathan Realmente no se cuantificó cómo "la mayoría de los editores IDE palidecen en comparación con los de vim o emacs". Soy un ávido usuario de IDE y también he usado Vim e incluso Emacs en el pasado y no veo cómo los IDE son tan estándar por debajo del estándar en comparación con Vim/Emacs. Por favor explique. –
de comandos construye puede ser automatizado, y el uso de herramientas estándar, como CMake para su línea de comandos construye hacer tales construcciones de plataforma cruzada (tenga en cuenta que usted puede construir un proyecto de Xcode desde la línea de comandos usando xcodebuild, pero que sólo funciona en Mac OS X con Xcode). La automatización es increíblemente importante, porque le permite, por ejemplo, crear un "gancho" para su sistema de control de versiones para construir el proyecto y rechazar el código que no compila o tener un servidor de integración continua para construir su proyecto periódicamente, de modo que Puede ver fácilmente cuándo se han realizado cambios en el código y solucionarlos rápidamente.
Además de la portabilidad y la automatización, la línea de comandos es más rápida. Si está utilizando un proyecto Makefile o algo así como el C++ Project Template que utiliza CMake pero tiene un contenedor Makefile, entonces todo lo que necesita es el simple comando "make" para compilar. La segunda vez que compila, solo tiene que presionar la flecha hacia arriba y luego presionar ENTER para volver a ejecutar "make". Aunque los principiantes con la línea de comandos pueden no ser muy rápidos y encontrar la GUI/IDE más fácil, una vez que has usado la línea de comandos por un tiempo, se vuelve mucho más rápido que hacerlo con una GUI, y todos esos movimientos y clics del mouse parecen lento y una pérdida de esfuerzo.
Existen IDE que le permiten ejecutar comandos arbitrarios para su compilación y, por lo tanto, le permiten conservar las ventajas de compilaciones en la línea de comandos, pero también hay muchos que no lo hacen. Entonces, definitivamente depende del IDE que estés usando. –
@Michael También puedes construir una solución IDE desde la línea de comandos y también "presionar la flecha hacia arriba" la segunda vez que quieras construir, por lo que no es algo que los proyectos administrados con un IDE no puedan hacer. Además, el hecho de que tengas que editar/mantener Makefiles a mano puede ser un dolor extremo en el culo. También dijo que los movimientos y clics del mouse (por ejemplo, hacer clic en el menú de compilación en el IDE) parecen ser lentos y desperdiciar esfuerzos, pero olvidó mencionar que los IDEs también proporcionan atajos de teclado para ejecutar la compilación dentro del IDE (en caso de que mueva el mouse para el botón de compilación es demasiado difícil de hacer). –
@Miguel, reconocí que puedes construir en la línea de comandos (xcodebuild); sin embargo, no es una compilación portátil; no podría ejecutar ese comando en Windows, por ejemplo. Estoy de acuerdo en que mantener Makefiles es horrible, por eso uso CMake. –
Al menos en UNIX, las herramientas de línea de comandos son madura. Los errores con los que tengo que lidiar son muy oscuros en este punto. vi, make, gcc, gdb: estas herramientas tienen, en algunos casos, 20 años o más. Probado, probado, probado.
Además, son omnipresentes. Todos tienen vi, make, gcc. No tengo que preocuparme por no tener mi herramienta-du-joir. Puedo ir a la caja virtualmente de cualquier persona, y no hay problema, puedo compilar, escribir, depurar sin necesidad de aprender alguna herramienta elegante.
En primer lugar, existe una mayor elección. Si usa un IDE, usa las herramientas que son específicamente compatibles con él, que pueden no ser las herramientas que prefiere. Hay muchas cosas que puede obtener en un paquete integrado o como componentes, y las personas pueden hacerlo en ambos sentidos.
En segundo lugar, muchos desarrolladores se han acostumbrado a las herramientas de Unix, que son maduras, muy potentes y que deben ser utilizadas por ellos mismos. No existe una tradición como esa en Microsoft Windows, y los IDEs han gobernado allí desde Turbo Pascal. (La gran ventaja de Turbo Pascal era que, en los días anteriores a cualquier tipo de multitarea, no era necesario iniciar y detener el editor, luego ejecutar el compilador y el enlazador por separado antes de ejecutar la prueba.)
Tercero, es realmente fácil automatizar todo lo que harías desde una línea de comando. Es más difícil hacer tales cosas en una GUI de cualquier tipo, tanto en que las herramientas son mucho más difíciles de desarrollar y en eso son más difíciles de aprender. Nuevamente, hay una brecha cultural aquí, ya que la tradición de Unix es lidiar con procedimientos complicados al automatizarlos, y la tradición de Microsoft es crear GUI y asistentes.
En cuarto lugar, para el manejo de sistemas complicados, todavía no existe un método claramente mejor que una representación de texto legible por el ser humano. La sintaxis de los makefiles de Unix es mala, pero habría evitado el problema que tuve recientemente, donde la configuración de un paso posterior a la compilación en una configuración de un archivo de proyecto de Visual C++ era incorrecta en un caso, y era difícil de detectar. Usando un archivo MAKE y VIM, puedo cambiar simple y confiablemente cómo se compilará y construirá un proyecto determinado. Es mucho más difícil con Visual Studio.
+1 Exactamente, mi flujo de trabajo consiste principalmente en cambiar entre ventanas (usando [Pantalla GNU] (http://www.gnu.org/software/screen/)) y presionando uparrow-enter. –
¿Por qué pondría sus 100 proyectos en una sola solución? (No es algo que debería/debería hacer) Además, ¿cree que gestionar 100 proyectos y 10k archivos desde la línea de comandos sería más fácil? Yo creo que no.En todo caso, el IDE te haría 10 veces más productivo :-) –
@Miguel, subestimas el poder de BASH, find, grep, xargs, awk, sed y todos los demás comandos de UNIX. Claro, serás terriblemente ineficiente en la línea de comandos de Windows, lo que es absolutamente desagradable, pero en cualquier variante de UNIX, las utilidades BASH + autocompletion + UNIX vencerán a cualquier GUI en términos de potencia y velocidad. –