Re: Среды разработки

["Артём Н." <artiom14@yandex.ru>]

17.10.2012 00:35, Alexander Galanin пишет:
> On Tue, 16 Oct 2012 22:55:25 +0400
> "Артём Н." <artiom14@yandex.ru> wrote:
> 
>>> Ага, кнопки справа в окошке дизайнера, анчоры — слева в object
>>> inspector-е. Вот и крути головой туда-сюда, высматривая соответствия.
>>> Неудобно.
>> Да, есть такое. Не очень продуман интерфейс. С другой стороны, его возможно
>> настроить под себя, а такой по умолчанию, думаю, он потому, что к нему привыкли
> Какими настройками можно поставить кнопку и её anchor-ы в одно место на
> экране? Полагаю, что никакими.
В смысле, диспетчер возможно перетащить вправо.

>>>>>> Но, при сложной форме, в текстовом описании интерфейса ещё проще запутаться.
>>>>> Разбивай построение интерфейса на отдельные небольшие функции с внятными
>>>>> названиями. Рисовалка такой возможностив принципе не предоставляет.
>>>> Ну, думаю, предполагается, что пользователь может удержать не очень большое
>>>> число элементов в фокусе внимания. И надо создавать интерфейс так, чтобы он не
>>>> был перегружен. Он сам разбивается на отдельные компоненты.
>>> То ты говоришь про сложную форму, то говоришь, что они не нужны.
>>> Определись.
>> Сложная может состоять из групп блоков.
> А блок — это что? CGroupBox с накиданными на него виджетами или что-то
> иное?
Любой группирующий логически элемент. Самый простой - групбокс или панель.

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

>> Есть ли в Vim подстановка блоков кода: я пишу for, а весь цикл со скобками и
>> переменной внутри мне подставляется автоматически?
> Необходимость вбивать постоянно одни и те же куски кода говорит только о
> том, что язык программирования под задачу выбран неправильно.
Так почти на любом нормальном языке возможно построить код так, что вбивать не
придётся. Вопрос в сложности кода.

> Подходящий
> язык лаконичен и не требует длинных конструкций вида «public Borsch
> borsch = new Borsch();» с кучей повторяющихся слов.
Подходящий для чего?
Ada - не подходящий?

>>>> 2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при
>>>> добавлении модуля).
>> А этот пункт?
> Это к юнит-тестам. Ах, да, makefile может генериться каким-нибудь cmake.
Из чего генериться (не копал CMake)?

>>>> 6. Проверить модуль с разными наборами данных.
>>> Unit testing.
>> Само собой. И в IDE. Абсолютно тот же самый. Разница лишь в том, что
>> вызывает его IDE, а не пользователь. И управляет им IDE.
> А что там делает IDE? Выводит дерево с тестами и с него позволяет
> перепругнуть на код теста? Ну да, удобно, но не критично.
Не критично. Но удобно. Так из маленьких "удобно" всё и складывается: соль в
деталях...

>>>> 3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а не на
>>>> warning).
>>> Команда «:номер-строки» в виме. При компиляции из самого вима оно
>>> перескакивает автоматом.
>> Почему-то у меня сейчас в старом Vim (очень старый на старом Linux, но, пока
>> что, пишу в нём, поскольку на той машине данные возможно разные получать) он
>> перескакивает на всякие варнинги. А мне нужно, чтобы я набрал make, и он остался
>> в том же файле. А ошибку, желательно, вообще открыл в другом окне.
>> И?
> Так настрой инструмент, если знаешь, что тебе от него нужно. Например,
> не говори компилятору -Wall.
Я хочу видеть все варнинги. Но я не хочу, чтобы редактор автоматически на них
переходил. В IDE, например, возможно выбрать в окне снизу и перейти. Это удобно.

>>>> 4. Посмотреть переменные в этом месте. Посмотреть подсказки (не просто
>>>> Segmentation fault).
>> Нету.
> Где нет? В gdb есть. В clewn в том числе и гламурные всплывающие окошки
> с значением переменной показываются.
А что вам в clewn не понравилось?
Раньше я не слышал о нём.
Посмотрю, может поставлю.

>>>> 5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
>>>> дизассемблерный листинг.
>>> Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но
>>> не прижился он у меня из-за неиспользуемости.
>> Да, а в IDE, я всё это вижу в том же редакторе.
> Не в том же редакторе, а в соседнем окне. Ровно так же, в соседнем окне,
> можно смотреть на gdb в терминале.
Я могу выделить мышкой нужный кусок или просто кликнуть в конт. меню
"Disassemble" и увидеть то, что нужно.
Как это сделать в GDB?

>>> Кстати, очень грустно выглядит программист, который в отладчике ловит
>>> ошибку, проявляющуюся не ранее 135-й итерации цикла. Столько лишних
>>> нажатий на клавиши.
>> Кажется, даже в старом GDB есть условные брэкпоинты?
> Ну вот смотри, тебе надо знать три разных приёма работы:
> 1. ставить обычный breakpoint
> 2. ставить условный (как показывает практика, дети IDE этим долго не
> могут научиться пользоваться)
Почему? Во всех нормальных IDE есть условные брейки.

> 3. делать отладочную печать на случай, когда условие останова
> сформулировать сложно или надо набрать статистику.
Да, здесь правда. К тому же, не всегда возможно поставить условный брейкпоинт:
watch ограничен.

> А без подстраивания себя под IDE достаточно уметь только последний пункт,
> так как он покрывает оба предыдущих. Банально меньше знаний надо держать
> в голове.
Больше других знаний. В итоге, примерно одинаково (если с IDE не меньше
лишнего). И никто не мешает делать отладочную печать в IDE.

>> Да, есть. Использую Valgrind. Показывает не самые внятные сообщения. Потом
>> приходится бегать по километровому логу, периодически переключаясь между ним и
>> редактором. Плюс, есть false-positives, особенно, при использовании глобальных
>> переменных, которые содержат адреса.
>> О встроенной в C-Builder тулзе аналогичного назначения воспоминания приятные.
> Ну и? Как из того, что неизвестная мне тулза от билдера работает лучше
> valgrind следует, что любое IDE рулит?
Нет.
"Рулит" интеграция тулзы со средой.

>>>> Да, "всё решается так". Но не слишком ли это..? Если бы всё было так славно и
>>>> удобно, вообще, IDE бы придумывали?
>>> То есть IDE придумали боги, а нам, простым смертным, надо в него
>>> уверовать ибо постичь мы не в состоянии? Или откуда тогда следует
>>> желание пользоваться чем-то только из-за того, что оно существует?
>> Нет. Т.е. IDE придумали потому, что они были нужны. А нужны они потому, что
>> упрощают процесс.
> Тебе уже целый день пытаются показать, что IDE не всё улучшает.
Я согласен, что не всё.

> Снижается только порог входа и самые шаблонные задачи. А с усложнением
> задачи растёт и сложность написания кода с помощью IDE. Например:
> 1. С помощью CBuilder можно легrо набросать формочку с пароф кнопок и
> прявязать к ним какие-то действия. При этом сохраняется файлик (.dfm,
> если не ошибаюсь), в котором лежит описание фырмы (а не код, что
> существенно).
> Далее нам требуется создавать интерфейс динамически. И знания,
> полученные в предыдёщем абзаце, нам никак не помогают, так как кода для
> создания виджетов мы не видим. Приходится открывать учебник и смотреть
> там, как динамически создавать виджеты и описывать геометрию.
> // Хотя замечу, что GUI-дизайнеры от Visual Studio и компилятор форм от
> // Qt всё-таки дают на выходе сишный код.
> В Tk же динамическое создание GUI ничем не отличается от «обычного»
> режима работы.
Возможно, это плюс.

> Пусть надо добавить собственный виджет. Опять приходится открывать
> учебник и смотреть в нём, как оформить компонент для CB, как добавить
> его на панель инструментов, как плюхнуть на форму, что потом надо
> настраивать, чтобы это дело собиралось на другой машине. Тут силы
> тратятся именно из-за изначальной заточки под IDE.
Да, из-за модели компонентов. Но она даёт простое использование сложных
элементов в дизайнере. Никто не заставляет разработчика делать свой компонент,
тут вообще спорный вопрос (устанавливать кучу компонентов, чтобы собрать проект,
- не очень приятно).

> 2. Компиляция тоже выполняется нажаьтием одной кнопки. Тут IDE вроде как
> даёт выигрыш.
> Но стоит озаботиться автоматической сборкой, как приходится снова лезть
> в учебник за новыми знаниями о том, как собирать проект без IDE. В итоге
> в голове приходится держать в 2 раза больше информации.
Думаю, что современные IDE позволяют настроить автоматическую сборку без лазания
в учебник. К тому же, имеют интегрированную документацию. И контекстную справку,
чего тоже нет в "IDE" из редактора и Makefile.

> 3. Про брейкпоинты я уже писал выше.
> Итого мы видим, что для сложной разработки с помощью IDE знать надо
> гораздо больше, чем для того же с помощью редактора и компилятора. Зато
> порог входа ниже и hello world-ы легко пишутся, ага.
Года три назад писал на С-быдлере программку размером около 15k строк. Со своим
интерфейсом. Пришлось частично отказаться от редактора форм и местами исправлять
ошибки стандартной библиотеки. Тут уже IDE начал мешать. Но, всё-таки, удобства
больше: легко переходить между файлами проекта, искать объявления, переходить в
библиотеку, когда надо посмотреть, например интерфейс класса (как в Vim сделать
это без tags?) и многое другое.