16 октября 2012 г., 22:22 пользователь Alexander Danilov <[email protected]> написал: > On 16.10.2012 22:06, "Артём Н." wrote: > Да какая разница, я на С++ с шаблонами такое видел, что после этого всякого, > утверждающего что C++ - это просто, а Haskell - это сложно, считаю умственно > неполноценным родственником Джорджа Буша младшего, на котором природа не то, > что отдохнула, она даже и не напрягалась.
+1 Считаю лучшим способом агитации против C++ дать прочитать книгу Александреску, а потом учебник Lisp или Haskell. 16 октября 2012 г., 22:27 пользователь Alexander Galanin <[email protected]> написал: > При правке из отладчика рассматриваемый контекст ограничен одной > функцией, потому годится для совсем очевидных ошибок. В других же > случаях решает ошибку долгая медитация над кодом, по сравнению с которой > 10 секунд на запуск gdb роли не играют. Буквально вчера потратил полчаса на поиск ошибки возникающей очень редко. И это при том, что я даже в C стараюсь писать исключительно чистые (в смысле ФП) функции. Но пока я эту функцию локализовал и медитировал над казалось бы уже 100 раз выверенным кодом... 16 октября 2012 г., 22:55 пользователь "Артём Н." <[email protected]> написал: > 16.10.2012 22:27, Alexander Galanin пишет: >> On Tue, 16 Oct 2012 21:53:38 +0400 >> "Артём Н." <[email protected]> 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 <[email protected]> написал: > On 2012.10.16 at 18:41:05 +0400, Sciko Good wrote: > >> 16 октября 2012 г., 11:24 пользователь Victor Wagner >> <[email protected]> написал: >> > Еще очень полезно знать что стандартный виндовый интерпетатор команд >> > cmd.exe не такой убогий, как обычно считают а практически представляет >> > собой полноценный c-shell со встроенным awk. Синтаксис, конечно >> > кривоватый и неудобный, но возможности есть. >> >> А вы точно не путаете cmd.exe с command.com или PowerShell? Просто >> ничего даже издали похожего на awk я не нашёл вот тут: > > Читайте внимательно описание оператора for. Прочитал. Больше не башевский for похоже. 16 октября 2012 г., 23:21 пользователь Alexander Danilov <[email protected]> написал: > А perl так вообще позволял и количество system("...") в разы сократить. И > ничего быстрее ещё пока не придумали. Другое дело, что перловый код после > написания ещё и читать бывает надо, но тут уж c++/pascal от него не отстаёт, > одна строчка перлового кода заменяет 10-20 c++/pascal, перл тяжелее читать, > а c++/pascal дольше читать, ибо кода больше. Если прописать правила написания кода на Perl, то его становится читать ничуть не сложнее, чем код на c++/pascal. Но тут теряется основная фишка Perl -- возможность записать одно действие несколькими способами. Это ближе к Python.
