|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : vitus@ice.ru 2:5020/400 26 Jun 2001 10:38:59
To : Ilya Anfimov
Subject : Re: Программить графику под линукс - как?
--------------------------------------------------------------------------------
Ilya Anfimov <ilan@adt.ru> wrote:
>> VW> А дебаггер суть средство исследования кода. При этом исследование
>> VW> своего собственного кода суть признак непрофессионализма.
>>
>>Значит я непрофессионал. Hе говоря уже о том, что в M$ и борланде тоже
>>сплошные ламеры, раз снабжают свои профессиональные приблуды такой
>>возможностью. Если в
IA>Ты знаешь, это мне напомнило одну вычитанную в газете историю:
IA>Парень (П) покупает газету Завтра (по долгу службы).
IA>Видит, что стоит продает ее нестарая и интелигентного вида Женщина (Ж).
IA>(П) И что же вы такие газеты продаете, ведь такие гадости пишут.
IA>(Ж) Вы же их покупаете. А я что -- я только деньги стою зарабатываю.
Вот-вот. В MS и Borland сидят трезвые люди - профессиональные
маркетологи, которые прекрасно знают что 95% их пользователей - ламеры.
Поэтому и продают софт, ориентированный на ламеров. В котором
профессионалу разобраться, конечно, можно (на то он и профессионал),
но блевать хочется. Как, например, меня доставало при программировании
на WordBasic, что ошибку на которую я специально ON ERROR GOTO написал,
он хочет обязательно предъявить в диалоговом окошке, и чтоб ему OK
нажали.
А сами - пользуются XP и прочими методами промышленного
программирования. Заметим, что Windows чуть ли не до версии 95
собиралась не MSVC, а Watcom-ом. Вот борландовцы, правда, всегда
компилили свои компиляторы ими же самими. Hо у них и компиляторы были
весьма и весьма. Я до сих пор catdoc под DOS собираю turbo C 2.01. Благо
его нынче даром раздают.
>>эхотаге нельзя нормально (читай удобно) отлаживать - так и скажи, я буду сразу
>>настраиваться на более другие способы написания приложения и забуду про gdb.
IA>Можно. Удобнее, чем под td. Просто не нужно. К gdb на самом деле
IA>привыкнешь быстро. Освоишь 5-7 команд (ну там next, step, dis-
IA>play, print, break) -- уже на уровень td вышел. Дальше понимаешь,
Хитрость в том, что в TD кроме этих 5-7 команд ничего нет. Там всего-то
три менюшки по пять пунктов. А в gdb есть еще пара десятков команд, да
и у этих по паре десятков параметров. Посему и возникает у чайника
фрустрация: ну нафига же я в клаву тыкаюсь. Ведь наверняка же можно
проще и быстрее. Лезет чайник в info gdb, выясняет, что да,
действительно можно. И так постепенно вырастает в самовара, а то и в
титана.
IA>что td в целом отдыхает даже если в принципе работает.Только это
IA>обычно не помогает. Или помогает, но очень медленно.
>>
>> VW> Вообще gdb, как и многие другие средства в Unix делает одну
>> VW> задачу - копаться в потрохах программы, и делает это хорошо.
>> VW> Общаться с юзером - не его задача, он и не пытается это делать - он
>> VW> принимает со stdin команды и выдает на stdout информацию.
>> VW> Для того чтобы с этим работать предназначены разнообразные фронтэнды
>> VW> типа ddd. (который, кстати умеет работать и с другими отладчиками.
>> VW> Ведь отлаживать можно не только бинарник на уровне команд
>> VW> ассемблера/C)
>>
>>Мне не нужно отлаживать бинарник в асмовских командах. Мне нужно нормально (по
Если у тебя программа на C/C++ и скомпилирована в бинарник, то ты
отлаживаешь именно бинарник. И именно на уровне команд (операторов)
языка C.
А я в ddd отлаживаю (когда отлаживаю) перловые скрипты. Hа уровне операторов
языка Perl.
К экспектовскому дебаггеру Tcl цеплять его не пробовал. Tcl я лучше
понимаю, а в перле мне периодически нужен дебаггер, чтобы понять почему
Larry Wall захотел чтобы данный оператор вел себя так как он себя ведет,
а не так как мне кажется правильным. (как правило я при этом убеждаюсь,
что поведение, заложенное Ларри, тоже весьма логично, просто я его
неправильно понял)
>>ходу дела, не отвлекаясь) отлаживать прогу в процессе разработки. Т.е. вместо
>>кучи DEBUG_PRINT'ов и совсем глупых ASSERT'ов разок пройтись дебагером.
А мне нужно разрабатывать код, который работает. Hе отвлекась на отладку.
IA>А куда же без ASSERT'ов? Без них совсем никак. Да и DEBUG_PRINT'ы
IA>обычно оказываются нагляднее, чем trace от gdb. А тем более
IA>текущий snapshot от td.
Особенно, если учесть что работает программа достаточно часто в такой
обстановке, которую воспроизвести под отладчиком крайне нетривиально -
под другим uid, в другом environment и так далее.
А ASSERT между прочим, не только средство отладки, но еще и средство
повышения удобочитаемости кода. Это декларация "Я уверен, что этого
не может быть, потому что не может быть никогда". Hа эту тему советую
почитать про контрактное программирование. В частности про язык
Eiffel (www.eiffel.org).
--
Victor Wagner vitus@ice.ru
Chief Technical Officer Office:7-(095)-748-53-88
Communiware.Net Home: 7-(095)-135-46-61
http://www.communiware.net http://www.ice.ru/~vitus
--- ifmail v.2.15dev5
* Origin: FT-center (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
