Чем рабочий процесс CLI-ориентированного программиста отличается от GUI-ориентированного?

Я много слышал о преимуществах меньшего количества работы по программированию в приложениях с графическим интерфейсом и использовании большего количества инструментов командной строки (особенно в том, что касается более эффективной работы). Однако, так как я не понимаю , как мой рабочий процесс будет отличаться , если я зависел больше инструментов командной строки, я не могу легко оценить , есть ли достаточно откуп лично для меня , чтобы тратить время и усилие обучения нового набора инструментов и меняющееся мой рабочий процесс.

Сейчас:

• Я кодирую некоторые побочные проекты на таких языках, как C / C ++ / D / C # / Java / Python, используя Visual Studio, Eclipse и т. Д., И запускаю их, устанавливая параметры сборки и нажимая клавишу F5 для сборки / запуска.

• Я разрабатываю веб-программу на работе, которая включает использование Django для настройки сервера, подключения к базе данных и т. Д. ... почти все в текстовом редакторе SciTE.

• Для запуска обычных программ я использую Launchy ... до сих пор нет терминала. :)

• Для копирования файлов и прочего я использую обычный поиск / перемещение в графическом файловом менеджере (Windows Explorer, Nautilus).

• Отладка: я использую либо Visual Studio, либо средства отладки для Windows (если я в Windows). Я не делал много отладки в Linux, но для всего, что я сделал, я использовал Eclipse (также для Java в Windows).

• На работе: чтобы подключиться к системе сборки и настроить проект, я просто использую инструменты, которые были интегрированы в Eclipse для моего использования - мне не нужен терминал или что-то еще (хотя я, конечно, могу использовать терминал, если я очень хочется)

Каково это делать в CLI? Какие части становятся более / менее эффективными? Какие аспекты моего рабочего процесса необходимо изменить, чтобы получить наибольшее преимущество от перехода к работе в основном в CLI? Другими словами ... Если бы вы волшебным образом превратили меня в гуру командной строки, чем бы мой новый рабочий процесс кодирования отличался от моего текущего ориентированного на GUI способа ведения дел?

Я не думаю, что это больше так. У CLI есть определенное преимущество: если вы заранее знаете, что ищете, вы можете набрать его быстрее, чем переходить к нему в меню. Это означает, что если вы явно хотите давать команды программе, которые имеют небольшой контекст, то это в основном быстрее. Однако есть две проблемы.

Во-первых, программы с графическим интерфейсом могут определить контекст для вас. Например, функция «Перейти к определению» в Visual Studio и Intellisense. Как вы могли бы воспроизвести эти функции в CLI?

Во-вторых, программы с графическим интерфейсом могут показать вам гораздо больше. Например, Visual Studio Parallel Profiler, который представляет собой график использования ЦП для нескольких ядер с течением времени. Как вы можете отобразить это в CLI? Это просто не имеет смысла. Как только ваши данные будут лучше выражены как текст, CLI мгновенно теряется. Другой простой пример - точки останова. В Visual Studio вы щелкаете по краю строки, которую хотите разорвать. Что вы собираетесь делать в CLI, попытаться найти файл и номер строки и ввести эту команду? Это займет у вас относительное десятилетие. Это даже не считая некоторых новых нововведений графического интерфейса, таких как Debugger Canvas.

Графический интерфейс может быть медленнее, если вы хотите тратить свое время на повторную отладку Debug, но как только варианты использования становятся более сложными, CLI не может идти в ногу.

Я думаю, что самая большая разница не в отдельных задачах, а в двух вещах:

В первую очередь, автоматизация. CLI по своей сути является сценарием, который обычно сложнее в Windows. Я слышал, что что-то улучшилось с PowerShell, но я не использовал его.

Во-вторых, философия UNIX «разделения интересов». Я могу написать небольшой интерфейс, основанный на readline, и использовать оболочку emacs Mx, используя его в emacs GUI. Это упрощает использование других инструментов и существующих функций.

Для отладки GDB работает хорошо, но я обычно предпочитаю VS отладчик. Вероятно, это лучшее программное обеспечение, которое когда-либо делал Microsoft.

Для сборки и запуска вещей: сделать. Или Баш. Где бы.

Для разработки: emacs (последнее преобразование из vi, о, позор!). Ви если делать работу через ssh.

Я действительно не могу привыкнуть к Затмению. Я думаю, что это проблема "формы ума": она не подходит мне.

Для меня переход на рабочий процесс CLI из Visual Studio включал запоминание множества команд * nix. Это также включало некоторые головные боли всякий раз, когда я испортил регистрацию SVN.

Но самая большая разница в рабочем процессе для меня заключалась в том, что я лучше понял, как работает операционная система . При работе с графическим интерфейсом пользователь просто нажимал кнопки и ждал ответа программы. В мире командной строки я чувствую, что говорю напрямую компьютеру что-то делать.

Другими словами, рабочий процесс с графическим интерфейсом пользователя - это компьютер, с которым вы общаетесь, в то время как рабочий процесс с интерфейсом командной строки больше походил на то, что вы общаетесь непосредственно с компьютером.

Одно не лучше, чем другое, но переключение с полностью графического интерфейса на терминал было непростой задачей.

Вот больше наблюдений от программиста, который жил в обоих мирах. Я не буду повторять пункты, уже сделанные в других ответах:

Разработка на основе CLI имеет тенденцию использовать множество программ, каждая из которых выполняет одну функцию. Разработка на основе GUI имеет тенденцию использовать 1 большую программу (IDE), которая выполняет десятки различных функций. Это различие имеет несколько последствий:

Поскольку IDE предназначена для того, чтобы быть вашим «домом», где вы работаете все время, они могут использовать собственный формат (возможно, двоичный) для хранения ваших данных. Совместимость не является большой проблемой, потому что они не ожидают, что вы будете работать в двух разных IDE в одном проекте. Инструменты CLI, с другой стороны, обычно работают только с простыми текстовыми файлами.

С помощью разработки на основе CLI вы можете постепенно переключать инструменты или легче интегрировать новые инструменты в рабочий процесс. Выбор IDE более универсален, а переключение IDE более болезненно.

Использование сценария сборки CLI, а не встроенного меню IDE «Построение», повышает вероятность того, что вы сможете на несколько лет отказаться от своего кода, вернуться к нему и собрать его без суеты. С разработкой на основе GUI, вполне вероятно, что к тому времени вы используете совершенно другую IDE. Возможно, тот, который вы использовали при написании кода, даже не работает в вашей текущей ОС.

В среде IDE создание собственных инструментов означает изучение (возможно, большого) API подключаемого модуля и, возможно, использование определенного языка. При использовании CLI ничего особенного не требуется для создания пользовательских инструментов.

С другой стороны, преимущество IDE состоит в том, что она, в общем-то, «интегрирована». Таким образом, вы можете щелкнуть в окне редактора, чтобы установить точки останова отладчика и так далее.

Еще один момент: ваш выбор также будет зависеть от платформы разработки, ОС и языка (ов), которые вы используете. На определенных платформах разработка на основе IDE глубоко укоренилась в преобладающей культуре разработки. В других, развитие на основе CLI распространено. Если вы используете платформу, где преобладает разработка на основе IDE, вполне вероятно, что инструменты CLI будут плохо развиты и будут плохо поддерживаться. Обратное также верно.

Большую часть моего детства я не проводил за компьютером, поскольку у нас даже был интернет на ферме. Я начал программировать поздно в старшей школе и в основном работал в графическом интерфейсе. В колледже я встретил парня, который вырос на CLI и делал все так. Поэтому я решил настроить сервер Linux, а не слушать проф. Через несколько лет мой приятель наблюдал, как я пишу какой-то встроенный код, и не мог поверить, как я написал.

Я в основном использую половину CLI, половину GUI. Есть некоторые вещи, которые окружающие GUI среды делают намного быстрее и эффективнее. И то же самое верно для CLI. Большая часть моего редактирования текста выполняется в VIM, поскольку расширенные редакторы CLI VIM / EMACS (здесь нет войн, пожалуйста) делают обработку текста наиболее эффективной. С другой стороны, такие вещи, как встроенная отладка с использованием GDB, так же болезненны, как редактирование текста без клавиатуры. Конечно, он мощный и уверен, что с достаточным количеством времени вы найдете нужную информацию, но наличие красивого графического окна с мгновенным доступом к любому блоку памяти неоценимо, особенно при попытке сравнить его с другим блоком памяти.

В любом случае, я действительно хочу сказать, что это должен быть не GUI против CLI, а то, в чем лучше CLI и в чем GUI лучше. Потому что в конце концов, если ваш ввод-вывод медленнее, чем ваш мыслительный процесс, возникает проблема.

"превратился в гуру CLI за ночь?" Да, есть руб. Хорошо спроектированные графические интерфейсы, как правило, более открыты, чем интерфейсы командной строки, и более щадящие для новичка.

Мой рабочий процесс, недавно улучшенный оконным менеджером листов (dwm), состоит из множества операций ввода. Мой ноутбук теперь можно использовать без подключения мыши (трекпад подходит для того, что осталось от наведения). Я держу множество приложений открытыми и переключаюсь с помощью alt-tab. Я не трачу время на перемещение и изменение размеров окон.

Большую часть времени я использую браузер, vim и несколько терминалов. SSH дает мне большую гибкость в отношении того, где я работаю (физически). Удаленные рабочие столы могут предложить лучший опыт, когда у всех нас есть 10-гигабитная труба к сети, но я не буду задерживать дыхание.

Я недостаточно хорошо изучил vim, чтобы воспользоваться его сложными функциями, но я склоняюсь в этом направлении - я хочу, чтобы vim перешел на правильную линию # после неудачной попытки. (Технически vim - это визуальный интерфейс, хотя он работает в терминале, но я управляю им с помощью клавиатуры, а не мыши.)

Настоящая проблема - плохо спроектированные интерфейсы. Хорошо продуманные интерфейсы сложно создать, поэтому они не часто встречаются в обоих лагерях. Но поскольку сегодня больше не-ux-волшебников разрабатывают GUI, чем CLI, ....

(Моя другая большая любимая мозоль - раздувание. Когда требуется программа размером 19 МБ, чтобы помочь мне выполнить ту же задачу, что и программа размером 200 КБ, что-то не так. XTree Gold для DOS повысила мою производительность больше, чем любой современный файловый менеджер. Windows 2.11 использовала только плиточный Windows. Turbo C была отличной IDE. Почему мой Nook работает медленнее, чем классика Mac? Почему одно ядро ​​теперь занимает больше места на диске, чем вся система?)

С помощью графических пользовательских интерфейсов вы вынуждены многократно взаимодействовать с программой, чтобы выполнять одну и ту же операцию снова и снова. С помощью оболочки вы можете с большей готовностью автоматизировать вещи и заставить программы работать вместе с помощью конвейера, который, например, может использоваться для вывода совпадений с регулярными выражениями в виде набора файлов или сетевых пакетов. Как сказано, это быстрее для многих операций.

Программирование в терминале, возможно, не намного лучше, чем в графическом редакторе, если только вы не используете SSH.

Лично я обнаружил, что оболочка unix гораздо более доступна, чем обычная командная строка Windows, и теперь я очень погружен в нее в системе Linux с оконным менеджером плитки и множеством терминалов.

Все ваши примеры в значительной степени одношаговый процесс. В большинстве сред с графическим интерфейсом, если вы хотите переместить файл, который не имеет ничего общего с текущим приложением, вы можете сделать это из меню файлов, не выходя из приложения. Нет смысла идти в командную строку. Если вы хотите скопировать файл и дать ему другое имя, в командной строке вы можете сделать все это сразу. Чтобы поместить это в пакетный файл, вам, по крайней мере, нужно знать, как это сделать, но затем вы можете выполнить пакетный файл из графического интерфейса, если хотите.

У меня были подобные дебаты по командам клавиатуры против мыши.

То, как я работаю, безусловно, благоприятствует GUI.

Типичное использование:

• Три IDE для трех разных платформ. Также окно Notepad ++ для некоторых скриптов. Я просто не смог бы запомнить команды для всех этих систем сборки. Проблема с CLI заключается в том, что вам нужно знать много деталей, только для того, чтобы заставить сборку работать. Современные IDES обычно имеют некоторые подходящие опции по умолчанию. Вы всегда можете присмотреться, когда придет время.
• SVN или Git интегрированы. Есть так много вариантов для программы, которая является вспомогательной для программирования, и большую часть времени я делаю только коммит или обновление.
• Сетевые вещи: К счастью, я могу выполнить все настройки сети в нашем офисе. Большинство сетевых плат дадут вам множество команд CLI, но если есть одна вещь, где вам нужен обзор состояния, это брандмауэр и маршрутизация. Что касается маршрутизации, я могу просто жить с командной строкой, но брандмауэры усложняются, и если есть что-то, что GUI хороши, это отображает много информации.
• Как правило, есть много переходов от одного к другому. Переключение контекстов проще с визуальным контекстом.

Что касается основного преимущества CLI, сценариев, я почти никогда не делал этого. Повторяющиеся задачи, которые мы имеем, - это просто приложения для работы cron, которые мы создали в c # и не часто меняли. У нас действительно есть способы запустить что-то в Linux, но в основном это портировано (boost), поэтому возиться с файлами и свести к минимуму такие вещи. И если дела пойдут не так, как надо, есть и хорошие IDE для Linux.