Здравствуйте, landerhigh, Вы писали:

L>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?)

А серьезно, зачем?
Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, The Lex, Вы писали:

TL>>>>"Уорда" Вы тоже не знаете...
L>>>Ага... да и незачем.

L>>>Порисуйте в Уорде формулы, к примеру (это первое, что вспомнилось).

TL>>И таки шо? В свое время рисовал очень активно — еще и за деньги — 3-4 работы за ночь — там этот ихний ActiveX еще и клавиатурой полнофункционально управляется — не говоря уже о том, что все импортится и биндится, скажем, из MathCAD — и даже, насколько я помню, из любимого математиками MathLab. В чем была фишка?
L>Ну, насчет "полноценно управляется клавиатурой" это прогон.
L>Ради интереса, посмотрел бы, как это делает LaTeX и как выглядит результат его работы.

Я смотрел — не ради интереса. А Вы смотрели как это делает Word?

Здравствуйте, landerhigh, Вы писали:

C>>>>VisualStudio+VAssist работают уже с программой — они понимают структуру кода. Это уже совершенно другой уровень.
L>>>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?) Да и при программировании шаблонов толку от них маловато.

TL>>Ну если так — то конечно. Правда в комментариях и подсветки синтаксиса нет... Лично я тупо пишу код, а потом нужное комментирую...
L>А позвольте спросить, когда происходит это "потом" и как определяется, что есть "нужное"?

Ну как же? Я внимательно смотрю на разноцветные гуйовые символы на белом фоне и жду прихода, после чего бью в бубен и выдыхаю "Ахххм!" — и тут же вожу мышкой по, а она уже, пользуясь всеми новейшими наработками мелкософта, комментирует "нужное". Именно так и только так и происходит программирование в среде "неиксоидов"!

TL>>"Иксоиды" — это все же реально "клан высших" — ну по крайней мере по их мнению. Правда не все "иксоиды" его придерживаются — встречаются и обычные люди, наплевательские относящиеся к "незнанию команд vim" каждым первым незнакомым или даже знакомым человеком.
TL>>А вот с первыми, с "несущими Слово Его" — общаться действительно трудно...
L>О, да, в общении с отдельными индивидууами иногда думаешь, что им сам Билли платит за проповеди

Я вот тоже думаю, что есть определенный заговор, с целью поддержать "кастовость" "иксоидов", и тем самым предотвратить приход "обычного пользователя" в их сферу — пусть их, лохов, мелкософт имеет, а в "иксах" им, гуйовым мышевозилам, делать нечего!

Здравствуйте, landerhigh, Вы писали:

C>>Собственно, после работы с GDB я понял, почему люди считают отладочную печать лучше, чем использование отладчика. Просто она действительно намного удобнее GDB.
L>Если только что написанный код надо отлаживать отладчиком, то таких "программистов" надо гнать в дворники ссаными тряпками.
Видимо, ты не работал с большими проектами. У меня очень часто при изменении твоего кода ломается какая-то другая библиотека.

L>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.
Юнит-тест позволяет диагностировать регрессии. С ними проблем нет, проблемы с новыми ошибками.

Например, у меня в проекте есть бибилиотека, которая занимается созданием прозрачного распределенного графа объектов, автоматически синхронизируемого с базой. Код почти на 100% покрыт юнит-тестами. Тем не менее, именно с этой библиотекой у меня всегда больше всего проблем — очень часто натыкаюсь на непредусмотреный в библиотеке частный случай. При этом приходится долго отлаживать код и следить почему именно структура объектов не так как надо получается. При этом, нужно одновременно отлаживать клиентскую и серверную части.

После того, как ошибка найдена — для нее пишется юнит-тест, но саму ошибку-то надо сначала найти. Отладочная печать для этого жутко неудобна — приходится перекомпилировать и перезапускать приложение, если нужно добавить новую точку наблюдения.

Здравствуйте, AndrewJD, Вы писали:

AJD>ИМО, странная аналогия. Т.е. если в хорошем IDE есть мощные средства автоформатирования, рефакторинга (а в хорошем IDE они должны быть), то это приводит к плохому коду?

Ни в коем случае. Это приводит к тому, что привлекает больше людей с плохим стилем программирования. В итоге среднестатистическая температура по больнице оказывается хуже.

Здравствуйте, The Lex, Вы писали:

TL> Надо в байки занести — оно того стоит!
TL>А какие такие "различные графические навороты" можно в коде использовать вообще?

Например подсветка не только ключевых слов, но и имён пользовательских типов.

A>>Аналогично с бейсиком — язык слишком простой, не создаёт барьера использования. Как результат код пишут часто неопытные программисты.

TL> Аналогия неверная — бейсика вы тоже не знаете...

Я не отношу себя к знатокам бейсика, никогда его не учил, но разбираться в коде приходилось. Каких-то особых сложностей не возникло.

Здравствуйте, alzt, Вы писали:

A>Я не отношу себя к знатокам бейсика, никогда его не учил, но разбираться в коде приходилось. Каких-то особых сложностей не возникло.
А ты на нем что-нидь серьезное попиши — тогда и посмотрим, какой знаток. Уверяю, это будет сложнее, чем на С++ на порядок.
А так — я в этом случае тогда знаток Forth, PHP, Perl, Fortran, ABAP/4 да и вообще практически всех недекларативных языков (некоторые из этих языков я кстати учил, а не только разбираться приходилось). Давайте мне зарплату 10000 баксов как суперуниверсалу, жду вал предложений

Здравствуйте, elmal, Вы писали:

A>>Я не отношу себя к знатокам бейсика, никогда его не учил, но разбираться в коде приходилось. Каких-то особых сложностей не возникло.
E>А ты на нем что-нидь серьезное попиши — тогда и посмотрим, какой знаток. Уверяю, это будет сложнее, чем на С++ на порядок.

Не понял — бейсик сложнее С++ что ли? Если писать большой проект, то понятно, что тяжело в любом случае будет. Но если надо быстро написать небольшую программу, то С++ использовать будет сложно, т.к. надо много времени на обучение. Бейсик, C# для этой цели лучше подойдут.

landerhigh wrote:
> TL>Народ, вы в своих аргументах бредить начинаете — а я на ваш бред к
> словам цепляться К чему еще, кроме кода, вообще теоретически даже может
> работать completions?
> Вот вы и попались, господин хороший.
> Комментарии к коду, стало быть, совсем не пишем?
А что не так с комментариями? Если мне нужно написать комментарий на
метод — я ставлю /** и моя IDE сразу мне подставит темплейт для него, с
заполнеными именами параметров.

kaa.python wrote:
> C>Драйверы (и ядерный код вообще)
> если драйвер написан с умом, то всю логику из него можно покрыть
> тестами. взаимодействие с железом не уверен.
В драйверах очень сложно тестировать "крайние точки". Типа поведения
драйвера при hibernate. Или при резком выдергивании устройства из порта.

> C> сложный код взаимодействия разных систем
> с легкостью. главное правильно выбрать что будет тестироваться. я имею
> ввиду единицу, для которой будет писаться тест.
Ага, конечно. Особенно, если взаимодействие с другой системой
транзакционное и имеет достаточно сложную семантику.

> C> код для встроеных систем.
> тоже никаких проблем. логика с легкостью делается кросс-платформенной и
> тестируется на Win или Linux.
Ха. Ха. Ха.

Ты можешь мне показать, как я могу прикрутить систему датчиков движения,
требующий 30 GPIO входов к обычному PC с Windows? Да, мне бы еще
хотелось поддержку DMA. А, пока не забыл — для устройства нужны еще
очень точные realtime-прерывания, иначе там переполняется внутренний
буффер и теряются данные.

> C> Ну и банальный GUI.
> первый случай когда вы сказали по делу. но и тут, если ГУИ написан
> грамотно, то отдельно стоящую бизнес-логику протестировать можно.
Вот только "бизнес-логика" самого GUI никак не тестируется. Мы пробовали
несколько UI-тестеров (Marathon, GUI Dancer, SwingUnit) — они требуют
больше времени, чем экономят.

> C>Часто стоимость test harness будет превышать стоимость всего проекта в
> разы.
> часто стоимость проекта написанного по принципу "надо копать и как можно
> скорее" в разы превышает стоимость проектов в которых есть нормальное
> покрытие кода тестами.
Ага, и часто эти "проекты с нормальным покрытием" находятся в области
фантастики.

landerhigh wrote:
> C>Драйверы (и ядерный код вообще), сложный код взаимодействия разных
> систем, код для встроеных систем. Ну и банальный GUI.
> Довольно значимую часть драйвера можно покрыть юнит-тестами, кстати.
Обычно очень сложно. Часто нужно для этого делать эмуляцию устройств, а
это само по себе уже очень сложно.

> С гуем будут сложности, да. Но это лишь еще один довод в пользу
> разделения юзер интерфейса и логики.
Как ни разделяй — а интерфейс для сложных систем обычно все равно
остается сложным.

> C>Часто стоимость test harness будет превышать стоимость всего проекта в
> разы.
> , елси Вы не умеете их готовить.
Ну просветите меня, бедного...

> Правильный подход к юнит-тестированию понижает стоимость дальшейшей
> поддержки на порядки и даже сокращает время разработки.
Да-да-да. Это я все слышал. И даже иногда это работает — с
отдельными библиотеками, например.

landerhigh wrote:
> L>>Может, пора признаться себе, что Вы просто гуевый мышевозила?
> C>А может тебе стоит признать, что нифига ты не знаешь современные
> средства программирования?
> А что, для знания "современного программирования" необходимо уже
> пользоваться редактором, который кто-то считает современным?
Нет. Но причем здесь это? Мы же вроде занимаемся взаимными оскорблениями?

> C>Так чем Emacs отличается от продвинутого "Блокнота"? Они оба работают
> с текстом, разве что у Emacs'а больше средств работы с ним.
> Хотя бы тем, что блокнот — это такое наколенное поделие
И что? Чем принципиально отличается Emacs/vi и блокнот?

> C>VisualStudio+VAssist работают уже с *программой* — они понимают
> структуру кода. Это уже совершенно другой уровень.
> Ага. Только completions в комментариях не работают (подумайте дважды,
> перед тем, как спрашивать зачем это надо, ладно?)
В комментариях работает completion по словам. В _ХОРОШИХ_ IDE в
комментариях работает completion для кода. В ОЧЕНЬ ХОРОШИХ IDE в
комментариях и строковых литералах работает autocomplete даже для
injected languages.

> Да и при программировании шаблонов толку от них маловато.
Вполне нормально работает.

> WH>>>А то ты так ничего и не назвал. Все что назвал есть в студии.
> В том же vim completions работают всегда и везде.
Так как они тупы как пробка. Это просто доплнения по словам.

> L>>Приведенные выше шорткаты. Они есть, только использовать их банально
> неудобно.
> C>http://www.viemu.com/ — и наслаждайся своими шорткатами до посинения...
> Видел. Жалкая пародия.
Тебе нужны шорткаты из ViMа для вырезания 100 строк? Они там есть.

> L>>Пальцы это "дайте мне студию, и неважно что пишем под
> [unix|VxWorks|symbian...], бо без интеграции с отладчиком и жизнь не мила".
> C>Именно. Достает пользоваться уродскими инструментами.
> Мыши плакали, кололись, но продолжали жрать кактус?
Так а что делать? Нету нормального инструментария...

Здравствуйте, alzt, Вы писали:

A>Не понял — бейсик сложнее С++ что ли? Если писать большой проект, то понятно, что тяжело в любом случае будет. Но если надо быстро написать небольшую программу, то С++ использовать будет сложно, т.к. надо много времени на обучение. Бейсик, C# для этой цели лучше подойдут.
Виноват, вообще запостил зря. Я слово НЕ не заметил, подумал, что кто-то считает себя знатоком на основании того, что когда-то разбирался .
Естественно согласен. Но на бейсиках всяких писать я бы не сказал что проще, чем на С++. Вьезжаешь в язык быстрее — да, но из-за многих ограничений придется изголяться, вдобавок IDE оставляет желать лучшего. Ошибиться очень просто, и многие ошибки компилятор не заметит, проблемы будут только во время выполнения, и синтаксис ужасный, и обработка ошибок мягко говоря не очень. Вызывать какую-то API функцию с параметрами структура — танцы с бубном. Для простейших случаев все хорошо, как что посерьезнее надо — начинается большой геморой, ИМХО на плюсах их было бы меньше.
А VB.Net я вообще за бейсик уже не считаю, уже нормальный язык по возможностям.

Здравствуйте, elmal, Вы писали:

E> Но на бейсиках всяких писать я бы не сказал что проще, чем на С++. Вьезжаешь в язык быстрее — да, но из-за многих ограничений придется изголяться

Как обычно происходит увлечение программированием (может и ошибаюсь, исследований здесь не проводил) — человек захотел что-то такое сделать (программу написать, узнал, что технология xxx — это круто, услышал, что заработать много можно), после этого тратит некоторое время на обучение. При этом не все доводят своё желание до конца. Многие отказываются по разным причинам (скучно, нет времени или мозгов, передумал). Чем сложнее язык тем больше надо потратить времени и больше иметь мозгов. В итоге отсеиваются не сильно умные люди, кроме того, если человек потратил на изучение языка программирования много времени, то наверное он и программок обучающих написал больше, больше узнал вообще о программировании, организации ЭВМ.
Т.е. в итоге средний С++-программист в среднем более квалифицирован, чем программист бейсик. Но это не значит, что надо учить С++ в ущерб бейсику (с-шарпу, функциональным языкам). Если человек приложит достаточные усилия для своего профессионального роста, то он будет хорошим специалистом, даже. если знает только бейсик. Но многие программисты будут кривиться от этого опыта, т.к. часто наблюдали плохо подготовленных коллег, которые используют бейсик.
В общем как-то много получилось, надеюсь выразил свою мысль.
Первоначально мысль была "хорошее IDE мозгам не помеха".

E>синтаксис ужасный

Синтаксис бейсика не нравится очень многим, кто долго с С или С++ работал. Просто привычка.

The Lex пишет:
>
> L>Ради интереса, посмотрел бы, как это делает LaTeX и как выглядит
> результат его работы.
>
> Я смотрел — не ради интереса. А Вы смотрели как это делает Word?
А самим не надоели такие споры. Ворду вордово, теху техово.
А так споры напоминают, вы пробовали микроскопом гвозди забивать, а вы
пробовали в линзу бактерию увидеть.

Здравствуйте, alzt, Вы писали:

A>Как обычно происходит увлечение программированием (может и ошибаюсь, исследований здесь не проводил) — человек захотел что-то такое сделать (программу написать, узнал, что технология xxx — это круто, услышал, что заработать много можно), после этого тратит некоторое время на обучение. При этом не все доводят своё желание до конца. Многие отказываются по разным причинам (скучно, нет времени или мозгов, передумал). Чем сложнее язык тем больше надо потратить времени и больше иметь мозгов. В итоге отсеиваются не сильно умные люди, кроме того, если человек потратил на изучение языка программирования много времени, то наверное он и программок обучающих написал больше, больше узнал вообще о программировании, организации ЭВМ.
A>Т.е. в итоге средний С++-программист в среднем более квалифицирован, чем программист бейсик. Но это не значит, что надо учить С++ в ущерб бейсику (с-шарпу, функциональным языкам). Если человек приложит достаточные усилия для своего профессионального роста, то он будет хорошим специалистом, даже. если знает только бейсик. Но многие программисты будут кривиться от этого опыта, т.к. часто наблюдали плохо подготовленных коллег, которые используют бейсик.
A>В общем как-то много получилось, надеюсь выразил свою мысль.
A>Первоначально мысль была "хорошее IDE мозгам не помеха".

Есть такое хорошее понятие: overqualification — оной, уж простите, болезнью, страдают многие "истинные программисты". Лично я считаю профессионалом человека, реализующего решение задачи (с уточнениями и дополнениями). Не все решения — даже далеко не все — есть смысл решать на C++ и прочем ООП — для многих это действительно "колоть орехи микроскопом". За свою скромную карьеру я наблюдал подозрительно и даже неприятно большое количество действительно хорошо подготовленных коллег, прекрасно разбирающихся и в C++, и во всяких хитрых технологиях — которые, очевидно, очень тяготились своим знанием, поскольку очень часто (постоянно? всегда? ) предлагали решения многократно более сложные, чем достаточно было бы для реализации _поставленной_ задачи. При этом очень часто на вопрос "зачем делать именно так, а не 'деревянно', зато много проще — и быстрее?" — они ответить аргументированно не могли.

В этом есть особенность "менталитета настоящего программиста": он прилагает массу усилий чтобы "стать очень хорошим специалистом" — часто заменяя "профессиональным ростом" то, для чего он, собственно, нужен — для решения практических задач. Я так думаю.

E>>синтаксис ужасный

A>Синтаксис бейсика не нравится очень многим, кто долго с С или С++ работал. Просто привычка.

У LISP простой и я бы даже сказал гениальный синтаксис — много кому он действительно нравится?

Здравствуйте, Cyberax, Вы писали:

C>landerhigh wrote:
>> C>Драйверы (и ядерный код вообще), сложный код взаимодействия разных
>> систем, код для встроеных систем. Ну и банальный GUI.
>> Довольно значимую часть драйвера можно покрыть юнит-тестами, кстати.
C>Обычно очень сложно. Часто нужно для этого делать эмуляцию устройств, а
C>это само по себе уже очень сложно.
Это не "обычно" сложно. Это очень просто. Гораздо проще, чем ловить потом BSODы и заниматься отписками с производителями железа.
>> С гуем будут сложности, да. Но это лишь еще один довод в пользу
>> разделения юзер интерфейса и логики.
C>Как ни разделяй — а интерфейс для сложных систем обычно все равно
C>остается сложным.
Чем сложнее система, тем заметнее выгода от отделения бизнес-логики и интерфейса.
>> C>Часто стоимость test harness будет превышать стоимость всего проекта в
>> разы.
>> , елси Вы не умеете их готовить.
C>Ну просветите меня, бедного...
про TDD что-нибудь слышали?
Еще раз — когда тесты являются неотъемлимой частью разработки и не воспринимаются программистами как некая (еще одна) непонятная обязаловка, спущенная сверху по прихоти менеджера или заказчика, их использование оказывает неоценимую помощь. Правильный подход помогает писать более компактный и стабильный код, выявляя потенциальные проблемы еще до того, как этот код увидит кто-то другой.
>> Правильный подход к юнит-тестированию понижает стоимость дальшейшей
>> поддержки на порядки и даже сокращает время разработки.
C>Да-да-да. Это я все слышал. И даже иногда это работает — с
C>отдельными библиотеками, например.
Будете в Сиднее, покажу одну такую "библиотеку"... хотя к тому времени, уже и не одну.

Интересно отметить, что Ваше непонимание того, в чем реальная польза UT, растет в определенном смысле из "интергрированного отладчика". А что, действительно велик соблазн по-быстрому набросать код, расставить брякпоинты, пройтись по коду с парой входных значений и посмотреть, получили ли то, что хотели. Только вот Вы забываете, что компьютер — это такая машина для автоматизации рутины. Юнит-тесты помогают автоматизировать то, что Вы привыкли делать руками в "интегрированном отладчике", причем несмотря на необходимость писать дополнительный код теста, размер которого порой на порядок превышает тестируемый код, экономия времени и прочих ресурсов вроде нервов в итоге окзаывается колоссальной.

Здравствуйте, The Lex, Вы писали:

L>>Ради интереса, посмотрел бы, как это делает LaTeX и как выглядит результат его работы.

TL>Я смотрел — не ради интереса. А Вы смотрели как это делает Word?

Ректально он это делает.
Что интересно, результат выглядит соответствующе.

Здравствуйте, WolfHound, Вы писали:

L>>...для гуевых мышевозил
WH>Гм... когда же я последний раз ГУИ то рисовал... ах да когда присал кроссплатформенный (win/web/хз что...) ГУИ движеок... чисто для отладки...
L>>Ну нету в студии редактора нормального. Например, те же completions работают только для кода, и то не всегда.
WH>То что ты им не умеешь пользоваться мы уже выиснили.
Ну научи, дорогой, как включить автодополнение кода, работающее внутри блока комментария.

Здравствуйте, Cyberax, Вы писали:

>> Комментарии к коду, стало быть, совсем не пишем?
C>А что не так с комментариями? Если мне нужно написать комментарий на
C>метод — я ставлю /** и моя IDE сразу мне подставит темплейт для него, с
C>заполнеными именами параметров.
Doxygen теги типа \code.. \endcode
господину специалисту по IDE что-нибудь говорят?