Re: Среды разработки
16 октября 2012 г., 22:22 пользователь Alexander Danilov
<alexander.a.danilov@gmail.com> написал:
> On 16.10.2012 22:06, "Артём Н." wrote:
> Да какая разница, я на С++ с шаблонами такое видел, что после этого всякого,
> утверждающего что C++ - это просто, а Haskell - это сложно, считаю умственно
> неполноценным родственником Джорджа Буша младшего, на котором природа не то,
> что отдохнула, она даже и не напрягалась.
+1 Считаю лучшим способом агитации против C++ дать прочитать книгу
Александреску, а потом учебник Lisp или Haskell.
16 октября 2012 г., 22:27 пользователь Alexander Galanin
<al@galanin.nnov.ru> написал:
> При правке из отладчика рассматриваемый контекст ограничен одной
> функцией, потому годится для совсем очевидных ошибок. В других же
> случаях решает ошибку долгая медитация над кодом, по сравнению с которой
> 10 секунд на запуск gdb роли не играют.
Буквально вчера потратил полчаса на поиск ошибки возникающей очень
редко. И это при том, что я даже в C стараюсь писать исключительно
чистые (в смысле ФП) функции. Но пока я эту функцию локализовал и
медитировал над казалось бы уже 100 раз выверенным кодом...
16 октября 2012 г., 22:55 пользователь "Артём Н." <artiom14@yandex.ru> написал:
> 16.10.2012 22:27, Alexander Galanin пишет:
>> On Tue, 16 Oct 2012 21:53:38 +0400
>> "Артём Н." <artiom14@yandex.ru> wrote:
>>> Мне надо:
>>> 1. Написать. Удобно, быстро с отступами и подстановками. Создать интерфейс.
>> Хороший текстовый редактор. А их всего два.
> Вероятно.
> Тогда такой вопрос.
> Есть ли в Vim подстановка блоков кода: я пишу for, а весь цикл со скобками и
> переменной внутри мне подставляется автоматически?
Юзайте clang_comlete
> Насчёт двух, вы утрируете. Scite и прочее?
Даже близко не стоит.
>>> 2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при
>>> добавлении модуля).
> А этот пункт?
Правильно написанный Makefile не требует переписывания в таких случаях.
>
>>> 6. Проверить модуль с разными наборами данных.
>> Unit testing.
> Само собой.
> И в IDE. Абсолютно тот же самый.
> Разница лишь в том, что вызывает его IDE, а не пользователь.
Да? И как оно догадывается, что нужен unit test? Неужели через astral.dll?
> И управляет им IDE.
Управлять юнит-тестом? Это что-то новенькое! А на фига?
>>> 3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а не на
>>> warning).
>> Команда <<:номер-строки>> в виме. При компиляции из самого вима оно
>> перескакивает автоматом.
> Почему-то у меня сейчас в старом Vim (очень старый на старом Linux, но, пока
> что, пишу в нём, поскольку на той машине данные возможно разные получать) он
> перескакивает на всякие варнинги.
Варнинги вообще-то тоже ошибки. И если они так не нравятся, то может
проще их отключить совсем?
> А мне нужно, чтобы я набрал make, и он остался
> в том же файле.
Это настраивается.
> А ошибку, желательно, вообще открыл в другом окне.
И это тоже.
>>> 5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
>>> дизассемблерный листинг.
>> Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но
>> не прижился он у меня из-за неиспользуемости.
> Да, а в IDE, я всё это вижу в том же редакторе.
И сильно это помогает? Правильные ответ: нисколько.
>> При правке из отладчика рассматриваемый контекст ограничен одной
>> функцией, потому годится для совсем очевидных ошибок. В других же
>> случаях решает ошибку долгая медитация над кодом, по сравнению с которой
>> 10 секунд на запуск gdb роли не играют.
> Облегчить процесс поиска может watch. Да, в gdb есть, но как-то...
В gdb очень хороший watch. А в комплекте с print, вообще песня.
> Плюс, есть false-positives, особенно, при использовании глобальных
> переменных, которые содержат адреса.
Глобальные переменные -- глобальное зло. И не факт, что valgrind был не прав.
> О встроенной в C-Builder тулзе аналогичного назначения воспоминания приятные.
В C-Builder была проверка утечек памяти? О_о
>>> 8. Сохранить изменения и записать версию.
>> hg ci в терминале. Ну или прямо из вима. Можно и с окошком.
> Git. Тут не знаю. Пока не пользуюсь. Учу.
Тоже самое. Только команда немного иная.
>>> Да, "всё решается так". Но не слишком ли это..? Если бы всё было так славно и
>>> удобно, вообще, IDE бы придумывали?
>> То есть IDE придумали боги, а нам, простым смертным, надо в него
>> уверовать ибо постичь мы не в состоянии? Или откуда тогда следует
>> желание пользоваться чем-то только из-за того, что оно существует?
> Нет. Т.е. IDE придумали потому, что они были нужны. А нужны они потому, что
> упрощают процесс.
Я знаю только один процесс, который они упрощают: процесс выбора.
Остальное получается очень не очень.
16 октября 2012 г., 23:21 пользователь Victor Wagner
<vitus@wagner.pp.ru> написал:
> On 2012.10.16 at 18:41:05 +0400, Sciko Good wrote:
>
>> 16 октября 2012 г., 11:24 пользователь Victor Wagner
>> <vitus@wagner.pp.ru> написал:
>> > Еще очень полезно знать что стандартный виндовый интерпетатор команд
>> > cmd.exe не такой убогий, как обычно считают а практически представляет
>> > собой полноценный c-shell со встроенным awk. Синтаксис, конечно
>> > кривоватый и неудобный, но возможности есть.
>>
>> А вы точно не путаете cmd.exe с command.com или PowerShell? Просто
>> ничего даже издали похожего на awk я не нашёл вот тут:
>
> Читайте внимательно описание оператора for.
Прочитал. Больше не башевский for похоже.
16 октября 2012 г., 23:21 пользователь Alexander Danilov
<alexander.a.danilov@gmail.com> написал:
> А perl так вообще позволял и количество system("...") в разы сократить. И
> ничего быстрее ещё пока не придумали. Другое дело, что перловый код после
> написания ещё и читать бывает надо, но тут уж c++/pascal от него не отстаёт,
> одна строчка перлового кода заменяет 10-20 c++/pascal, перл тяжелее читать,
> а c++/pascal дольше читать, ибо кода больше.
Если прописать правила написания кода на Perl, то его становится
читать ничуть не сложнее, чем код на c++/pascal. Но тут теряется
основная фишка Perl -- возможность записать одно действие несколькими
способами. Это ближе к Python.
Reply to: