Re: Среды разработки
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();» с кучей повторяющихся слов.
> >> 2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при
> >> добавлении модуля).
> А этот пункт?
Это к юнит-тестам. Ах, да, makefile может генериться каким-нибудь cmake.
> >> 6. Проверить модуль с разными наборами данных.
> > Unit testing.
> Само собой. И в IDE. Абсолютно тот же самый. Разница лишь в том, что
> вызывает его IDE, а не пользователь. И управляет им IDE.
А что там делает IDE? Выводит дерево с тестами и с него позволяет
перепругнуть на код теста? Ну да, удобно, но не критично.
> >> 3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а не на
> >> warning).
> > Команда «:номер-строки» в виме. При компиляции из самого вима оно
> > перескакивает автоматом.
> Почему-то у меня сейчас в старом Vim (очень старый на старом Linux, но, пока
> что, пишу в нём, поскольку на той машине данные возможно разные получать) он
> перескакивает на всякие варнинги. А мне нужно, чтобы я набрал make, и он остался
> в том же файле. А ошибку, желательно, вообще открыл в другом окне.
> И?
Так настрой инструмент, если знаешь, что тебе от него нужно. Например,
не говори компилятору -Wall.
> >> 4. Посмотреть переменные в этом месте. Посмотреть подсказки (не просто
> >> Segmentation fault).
> Нету.
Где нет? В gdb есть. В clewn в том числе и гламурные всплывающие окошки
с значением переменной показываются.
> >> 5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
> >> дизассемблерный листинг.
> > Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но
> > не прижился он у меня из-за неиспользуемости.
> Да, а в IDE, я всё это вижу в том же редакторе.
Не в том же редакторе, а в соседнем окне. Ровно так же, в соседнем окне,
можно смотреть на gdb в терминале.
> > Кстати, очень грустно выглядит программист, который в отладчике ловит
> > ошибку, проявляющуюся не ранее 135-й итерации цикла. Столько лишних
> > нажатий на клавиши.
> Кажется, даже в старом GDB есть условные брэкпоинты?
Ну вот смотри, тебе надо знать три разных приёма работы:
1. ставить обычный breakpoint
2. ставить условный (как показывает практика, дети IDE этим долго не
могут научиться пользоваться)
3. делать отладочную печать на случай, когда условие останова
сформулировать сложно или надо набрать статистику.
А без подстраивания себя под 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 раза больше информации.
3. Про брейкпоинты я уже писал выше.
Итого мы видим, что для сложной разработки с помощью IDE знать надо
гораздо больше, чем для того же с помощью редактора и компилятора. Зато
порог входа ниже и hello world-ы легко пишутся, ага.
--
Alexander Galanin
Reply to: