Разработчики Linux перейдут на Eclipse.

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

То есть пол-дня работешь, а потом пол-дня допускаешь ошибки, которые исправляешь уже следующие пол-дня? Оригинально.

Для решения это проблемы существует вовсе не отладчик, а обеденный перерыв, в течении часа следует полностью сосредоточится на еде (это обязательно) и титькак сидящей напротив коллеги (если она есть).

> С неясной головой даже симпатично выглядящий отладчик и модные подсказки не помогут.

Когда прогоняешь отладчиком и наглядно видишь что оно в таком-то месте делает ВООБЩЕ не то что задумано, то это помогает.

>а код такого качества, что по нему непонятно, что эта хрень делает

я не могу проверить код половины проекта. представь такой код:

calculate()
{
  f1();
  f2();
  f3();
  ...
  fN();
}

и в каждой из f() есть ещё куча кода и условий. как тут без дебагера?

> я не могу проверить код половины проекта.

Почему? Зачем тогда вообще дёргаться, если работать не охота?

> То есть пол-дня работешь, а потом пол-дня допускаешь ошибки, которые исправляешь уже следующие пол-дня? Оригинально.

Нет. Полдня в смысле светового. ;) Начинаешь "плыть", делаешь тупые ошибки, а они в программу уже пошли, откатываться на никто в своём уме не будет, т.к. что-то в этом состоянии всё же сделано правильно...

>Те что писать умеют - наверняка и на дельфи начнут не раскидывания кнопок на морде, как мне кажется.

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

Попробуйте создать штук 20 диалоговых окон с разными кнопками, вкладками, списками, ... обеими способами. А если их гораздо больше?

+1.

Куда уходим? plan9? У меня мышка плохая ;)

> Попробуйте создать штук 20 диалоговых окон с разными кнопками, вкладками, списками, ... обеими способами. А если их гораздо больше?

Зуб даю, сейчас тебе напишут про создание 1000 одинаковых кнопок копи-пастом описания одной из них. ;)

> и в каждой из f() есть ещё куча кода и условий. как тут без дебагера?

Скажи, ты веришь, что дебаггер сделает этот код надежнее, как постулировал товарищ, или все-таки только поможет найти некоторое количество ошибок - при этом оставив неизвестно сколько ошибок ненайденными.

Кстати, для поиска ошибок программу еще надо тестировать, а вот после их нахождения уже не столь и важно чем искали ошибку - принтами или отладчиком, поскольку все равно стало только на ОДНУ ошибку меньше ;)

>Почему?

мб потому что на это уйдёт куча времени? а мне надо только осправить одну ошибку, которая _совсем_ неизвестно где, может вообще в БД.

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

Это где я это говорил? :-/

> Попробуйте создать штук 20 диалоговых окон с разными кнопками, вкладками, списками, ... обеими способами. А если их гораздо больше?

Я вообще-то имею опыт, в частности и Tkinter, и Delphi. Tkinter по скорости, пожалуй, выиграет.

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

я про то что принтами это нереально сделать. это такая ошибра что ты даже не знаешь в какой из f() и в каком месте она появляется. просто calculate() выдаёт неверный результат - всё. принтом такую ошибку можно неделю ловить.

>Узконаправленные! Золотые слова! Любой хирург предпочтёт узконаправленный ланцет (или что там под задачу) вместо швейцарского ножа.

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

А ланцетом, в данном случае, будут как раз не eclipse, netbeans и т.д., а все те же (как вариант) ecb + ... и ctags + ... с соответствующим выбором редактора, т.е. emacs'a или vim'а.

Грубо говоря, проявление того самого unix-way.

З.Ы. Про плагины для того же eclipse просьба не упоминать - до дополнений к все тому же emacs'у им еще ооочень далеко

tags? или M-x на базе semantic?

Первое удобно для быстрой навигации, втрое тормозит на большой массе кода.

@sv75: > Хорошенькое поведение для модератора, нечего сказать, да?

ткнул... согласен :(

> И геттеров с сетерами в разных ипостасях и языках (C++\Delphi\C#) написал/нагенерировал изрядно.

раз пишешь что они нужны только чтоб их генерить - значит не просек их фишку.

@catap:

>сер, откройте для себя emacs :)

открыл... и закрыл в ужасе! не, я честно пытался его юзать несколько недель. настраивал, изучал. но в итоге забил.

@mv: > Тот, кому самоорганизации хватает для написания программ, сложнее hello world'ов, отладчиком уже не пользуется. Незачем.

Валялся пацтулом! Дальнейший спро с Вами считаю совершенно бесмысленным.

> я про то что принтами это нереально сделать. это такая ошибра что ты даже не знаешь в какой из f() и в каком месте она появляется. просто calculate() выдаёт неверный результат - всё. принтом такую ошибку можно неделю ловить.

Да, боюсь не о чем нам тут разговоривать. :(

Кстати, напомню всем любителям VS, что .NET Framework содержит специальную систему отладочной печати (на новом уровне реализации) и разных там asserts.

Виктор, вот именно.

И это грустно.

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

Когда код становится нечитабельным, проще его переписать, чем ковыряться с дебаггером.

>> И геттеров с сетерами в разных ипостасях и языках (C++\Delphi\C#) написал/нагенерировал изрядно.

> раз пишешь что они нужны только чтоб их генерить - значит не просек их фишку.

Раньше, когда я был глупее и не читал ЛОР, я твердо знал, что без них не жить. Однако по мере знакомства с языками отличными от перечисленных (ruby/python) и методиками тестирования ПО у меня появились подозрения, что все сложнее. (На всякий случай - на перле я давно писал, но урывками и не думая, так что это не помогло моему развитию).

возможно, но не всегда есть такая возможность. если вам не нравится код фс ядра, вы же не будите переписывать его весь?

> Если сразу толкать неумех за IDE, то это приведет к трагедии.

s/трагедии/увеличению предложения на рынке быдлокодеров/

у вас богатый жизненный опыт

> возможно, но не всегда есть такая возможность. если вам не нравится код фс ядра, вы же не будите переписывать его весь?

Ну и как успехи с отладкой ошибок в фс ядра, скажем типа того предновогоднего случая с ext3? Сильно Линусу помогли отладчики?

Блин, я тут ужинать собирался... В начале таких сообщений надо писать:

Disturning content, read on your own risk.

На самом деле умом это понять. И это даже логично. Но дети эту логику не поймут.

Японцев вон, вообще весь язык заставляют зазубривать, и ничего, живы ;)

>Ну и как успехи с отладкой ошибок в фс ядра, скажем типа того предновогоднего случая с ext3? Сильно Линусу помогли отладчики?

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

> наверняка он пользовался ими или трейсом.

Ты видимо, не читал про тот случай. Ошибка возникала *редко*. Не исключаю, что там наиболее эффективный способ заключался в чтении исходников, лежа на диване.

> другое дело когда нужно пропатчить что-то незнакомое,

Еще раз отправляю к сиходну письму. "помогает в создании надежного кода", а не "позволяет по быстрому пропатчить результаты чужой жизнедеятельности."

> машина intel core duo 3.4 ghz, 2gb ram.

> Сколько сколько "ghz"-цов?

коредуб с хорошим кулером прекрасно гонится

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

Просто я видел и тех, кто начинал с ДОСа и командной строки, и тех, кто начинал с дельфей. Первые редко используют дельфи, однако используют его действительно лишь для того, чтобы нарисовать "морду", остальной же код пишут нормально. Последние же останавливаются на отрисовке формы и дальше либо идут в интернет за компонентом, либо впадают в депрессию и зовут на помощь первых.

Я не против IDE как таковых! Я против тех, кто считает, что хорошая IDE сделает за программиста _всю_ работу, кроме перемещения мыши. Как правило, этим страдают те, кто _начинает_ программировать с IDE, а не со встроенного редактора FARа.

> А те недоумки что вы описали - они любым способом будут фигню гнать, хоть в делфи, хоть на ассемблере.

Согласен, но чтобы гнать фигню на ассемблере - уже нужен некоторый интеллект, так что дальше дельфей они не продвинутся. А те, кто продвинется, уже вырастут интеллектуально.

> я про то что принтами это нереально сделать.

log4(your langugage) ?

спасибо, я не знал что CFD существует в opensource мире!

> Валялся пацтулом! Дальнейший спро с Вами считаю совершенно бесмысленным.

Да я и не особо рвался с кем-то спорить :)

> Когда код становится нечитабельным, проще его переписать, чем ковыряться с дебаггером.

По-моему, эти товарищи просто будут искать более красивый дебаггер.

!!!Disturning content, read on your own risk.!!!

Ну извините. Правда я думал, что закалённых в ЛОРовских баталия джедаев уже ничем не смутить. Я ведь не описывал сам процесс вскрытия, как глаз лопнул и обрызгал преподшу, как она потом матюгалась и т.п., как долго не могли определить пол усопшего животного, т.к. старшекурсники несколько увлеклись процессом потрошения и не сортировали органы и кидали их в одну кучу и т.п., или как мы ставили опыты на лягушках . . .

И почему я потом пошёл учится на инженера.

всё верно. CDT в кой-то веки начала работать и ей очень нужны леминги для тестирования и правки, а то десяток кодеров уже не справляется.

Да, конечно же Приятного аппетита.

Ок, попытаюсь объяснить еще раз. Даже если ты разбираешь свой СОБСТВЕННЫЙ код далеко не всегда понятно в каком именно месте может возникнуть ошибка. Во-первых вызовы могут быть довольно запутаны и нетривиальны, во-вторых ты вызваешь функии разных либ, вывод которых может оказаться совсем не тем что ты ожидал.

Иногда искать ошибку тупой растановкой принтов просто долго. Учитывая цикл - поставить принты, скомпилить, запустить, повторить ситуацию при которой просиходит ошибка. Иногда это просто нереально! Если тебе нужно видеть call stack, значение 3-4 разных переменных.

Возвращясь к тезису о надежности. Чем быстрее ты находишь ошибки - тем больше ты их исправишь и надежнее получившийся код. И, главное, когда ты прошелся по всему проблемному месту увидев наглядно где и почему произошла ошибка - больше шансов что сделаешь нормальный фикс (надешь первоисточник проблемы?) чем просто локальный фикс.

Похоже ярые любители рисователей GUI не писали программ с использованием Tk, я им сочувствую.

Такой гибкости в возможностях расположения компонентов и скорости написания GUI не дает ни одна библиотека и/или ide

К сожалению вид у него архаичный.

Вишь ты.. ну, посмотрим, что получится.. Оно и сейчас уже довольно громоздкое..

> Даже если ты разбираешь свой СОБСТВЕННЫЙ код далеко не всегда понятно в каком именно месте может возникнуть ошибка.

Является ли такой код, в котром без отладчика ничего не найти - надежным?

> Иногда искать ошибку тупой растановкой принтов просто долго.

debug/trace/assert/etc следует использовать при написании кода, понимаешь?

> Чем быстрее ты находишь ошибки - тем больше ты их исправишь и надежнее получившийся код.

1. Ошибки находят при тестировании. В отладчике находят их причины. Число *найденных* ошибок зависит опять же от методики тестирования, а не от скорости использования отладчика.

2. Для более быстрого поиска ошибок есть методы встроенные, к примеру, в .NET Framework Library. Которые ведут лог, показывают стек и все проочее.

> К сожалению вид у него архаичный.

Вид у него полное г-но, к сожалению. :( Но PyGTK/Qt скажем никто не отменял.

>>Вид у него полное г-но, к сожалению.

не согласен. мне в общем нравится как выглядит софт на tk

Он разве интегрируется с темой KDE/Gnome?

> Возвращясь к тезису о надежности. Чем быстрее ты находишь ошибки - тем больше ты их исправишь и надежнее получившийся код.

Бред сивой кобылы. Тезис надёжности должен звучать так: чем меньше делаешь ошибок, тем надёжнее код. А по-вашему, код тем надёжней, чем быстрее и больше косяков находится.

@mv:

понимаешь ли... не делать косяков конечно хорошо. но это больше относиться к этапу дизайна софта. кроме того никакой IDE тут тебе не поможет. но будет реалисатми. ты все равно накосячишь. а вот тут от инструментов будет зависеть найдешь ты косяки или нет.

я насмотрелся на код написаный вот такими адептами "без дебагового программинга" и их идиотские косяки, которые они от релиза к релизу не чинили ибо походу им было влом искать. хотя если пошевелить мозгами и пройтись ПО ШАГАМ все лечилось примитивно просто.

> $ cat /proc/cpuinfo | grep -i mhz
> cpu MHz : 3400.203
> cpu MHz : 3400.203

Не верю... Это ____core duo____ ?

> model name : Intel(R) Pentium(R) D CPU 3.40GHz

Вот и не надо ля-ля, корку-дуо на таких частотах ни в жизнь не найти ;)

>спасибо, я не знал что CFD существует в opensource мире!

Довольно давно кстати. Я еще года 4 назад познакомился с человеком который работал с его разработчиками в одной конторе (до того как). Он собственно мне дал наводку на этот код но в то время к идее относился с сильной долей скепсиса.

Кроме того есть поделки попроще типа OpenFlower, FEniCS, MOUSE и тому подобных ... см. http://cfd-online.com/Links/soft.html#cfd

>Кстати, ты в его потрохах случайно не разбираешься? Там в принципе невозможно было вынести частично логику во что-нибудь не требующее гига исходников на C++? (Я сам посмотрю на это чудо когда будет время, но сейачс его нет)

Что и куда ты вынести захотел ? ;)

Это фремворк для постоения _задачи_ а не какая то одна программа.