17.10.2012 00:35, Alexander Galanin пишет: > On Tue, 16 Oct 2012 22:55:25 +0400 > "Артём Н." <[email protected]> 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?) и многое другое. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
