Re: Среды разработки
Тема слегка затянулась.
В итоге:
1. Предложили много^3 раз vim+make/gcc,
несмотря на изначальное "Vim/Emacs+make+gcc не предлагать."
2. Обозвали не ТруЪ и троллем.
3. Предложили вернуться на винду или перейти на MacOS.
Денег на Mac, к сожалению, не предложили.
4. Предложили примерить платье.
5. Обматерили C++ со всех сторон. Не забыли и Java.
6. Советовали "всё бросить и перейти на ...": Tcl+Tk, Perl, Haskell, ML, Lisp,
Python и т.д.. Короче - стандартный набор.
7. Предлагали отказаться от GUI.
Ну, как всегда, в общем.
Вернусь к изначальной постановке вопроса: какие инструментальные средства вами,
на практике, используются для кроссплатформенной разработки прикладного ПО под
Linux и Windows, независимо от языка, используемого для написания кода?
Далее опишу, что мне надо, подробно и детально, поскольку возникает непонимание
и мне отвечают не на те вопросы, которые я задаю.
Потому дальше многа лишних букафф.
Мною под разработкой ПО понимается:
1. Сбор, организация и хранение требований. Затем, тестирование на соответствие.
2. Проектирование. Автоматизированное. Наглядное. Текст - это хорошо.
Но не очень наглядно. Известный факт: большинством людей легче
воспринимается информация, представленная в графическом виде
(акцентирую внимание потому, что кто-то постоянно норовит предложить
"чёрный экран, Vim и уютненькую консоль").
3. Создание интерфейса и его проверка, написание кода,
его компиляция, сборка, отладка, проверка, переработка.
4. Ведение версий и отслеживание ошибок.
5. Интеграция всех компонент в целях удобства и ускорения работы.
Вопрос возник, потому что у меня имеются неоднозначности и рассогласования:
1. Я познакомился с инструментами для разработки, но всё это - _отдельные_
инструменты.
2. Удобно, когда все инструменты вызываются последовательно и автоматически. Это
убирает потери времени на их вызов, настройку перед вызовом и прочее.
3. Интегрированная среда позволяет вызывать эти инструменты не задумываясь о
параметрах и последовательности и, затем, использовать результат одного
инструмента в другом (или комбинировать их результат в пользовательском выводе).
К примеру, игнорирование вывода make и установка курсора в Vim на строку с
ошибкой, указанной в выводе gcc - это удобно. С этим, вроде никто не спорил.
Также удобно - нажатие F8 в среде Embarcadero RAD Studio для пошагового
выполнения инструкций. Кому-то это не нравится, и они считают, что запускать
отладчик отдельно - это гораздо лучше. Это странно.
Вроде, - мелочь, но, в сумме мелочей, получается много лишних действий.
4. Операционная система - не интегрированная среда. Даже, если она имеет мощные
средства для автоматизации.
5. Мне предлагают написать скрипт. В целом, я согласен, что это вариант.
Несомненный плюс - всё настраивается под себя намного более гибко, чем в IDE.
Не нравится мне это потому, что:
1. Как правило, скрипт не переносим. В случае с готовой IDE, разработчики
уже позаботились о её портировании. И портировании её окружения.
2. Обычно скрипт зависит от языка и прочего.
3. Надо знать какие инструменты вызывать.
4. Сложно получить такую же тесную интеграцию инструментов, как в IDE.
5. Все инструменты, при написании скрипта, как правило, надо изучить
подробнее, чем для обычного использования (это много времени).
6. Скрипт свободный от большей части этих недостатков весьма сложен и уже
может называться IDE.
7. Предполагаю, что IDE уже написаны, так что написание такого превратится
в изобретение велосипеда, что мне кажется не очень разумным.
Плюс ещё имеются недостатки.
Поэтому я считаю, что графические IDE, создаются не потому, что требуется
кому-то их продать (а если это NetBeans и Eclipse?), а потому, что они делают
более удобным процесс.
Естественно, у них много недостатков.
И я не зацикливаюсь, как может показаться, именно на графической IDE a-la Deplhi
(кстати, был же Kylix, но как-то - не то...), а хочу найти нечто удобное,
переносимое, универсальное и автоматическое.
Думаю, более разумно и более производительно нажать одну кнопку (или набрать
команду, не суть), получив в итоге, готовый результат и подробный, удобный для
анализа результата отчёт (интерактивный, в том числе), чем набирать кучу команд,
ставить много галочек или править десяток строчек в скрипте?
Кратко, суть вопроса: что использовать практично?
Reply to: