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

K>Слушайте, товарищ! Хватит зниматься демагогией! То Вы доказывали Владу, что писать интерпретируемые скрипты удобнее, чем компилируемый код на C#/Java, и что юзаете gcc из командной строки, то Вы восхваляете Eclipse. Давайте точно определим предмет спора. Обозначьте свою генеральную линию. Я вот обозначил, что проще написать простенький код в IDE, где куча подсказочек, возможность отладки и т.д. но при этом мы ничего не теряем. Таким образом, я заключаю, что удобнее для поиска по регэкспу удобнее в VS(Eclipse), чем в bash+grep.

Глобально удобнее?
А ты не думаешь, что всё зависит от конкретной задачи?
Допустим мне нужно найти опр. строку в логе на серваке под солярисом, куда есть только ssh? Причём задача "разовая", т.е. критерии для поиска, файл и т.п. — вещь ситуативная и "сделал/выбросил".
Как ты будешь решать такую задачу?

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

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

K>>>О, это действительно круто. Однако, он всё равно производит впечатление чего-то устаревшего. Вот неужели такие же фичи нельзя оформить под более дружественной оболочкой (чтобы хотя бы GUI симпатичный был)?

EC>>А смысл тратить кучу усилий, на то, что не повысит продуктивность? Я перестал обращать внимание на новый вид студии при переходе с 2003 на 2005 через 2 дня использования. Выпуклость тулбара мою продуктивность не повышает.

K>Зато в 2003 не было подсветки типов. И autocompletion там был без приоритетов по частоте использования. Да и сами autocompletion в 2005 студии сами собой выпадают, что позволяет сэкономить время на нажатие Control+Space (а это сочетание отвлекает при десятипальцевом наборе), и тем самым набирать довольно-таки длинные имена в 3-4 касания. А это сильно повышает продуктивность кодинга. Сколько я не заставлял когда-то себя привыкнуть к vim, у меня так производительно никогда не получалось.

Это всё здорово, конечно, но есть другой вопрос — скорость программирования у тебя определяется скоростью набора на клавиатуре? ИМХО это далеко не так и гораздо больше времени уходит на обдумывание и проектирование.
А тут могут быть полезны диаграмки классов и т.п. инструменты.
Не зря кто-то из довольно известных людей (Брукс?) говорил, что средняя норма — 20 чтоли строчек отлаженного кода в день для программиста.

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

E>>А можно мне вот такую загадку объяснить: вот пишете вы вызов метода и hint вам подсказывает, что в метод требуется передать пять параметров. Откуда вы их возьмете, если вызов метода уже начали писать, но про параметры этого метода не знали (т.е. не представляли ни их количества, ни назначения, ни формата, ни допустимых даипазонов)?

VD>Интересно. Ты просто так неудачно дурака включил или действительно настлько некомпетентен в данном вопросе, что даже представить не можешь то о чем говришь?

Т.е. кроме наезда на личность сказать нечего?

Я веду к тому, что документацию по тем классам/методам, которые собираешься использовать, нужно смотреть до их использования. А для этого вовсе не нужно, чтобы документация отображалась в том же редакторе, рядом с исходным кодом. Достаточно иметь соседнее приложение (MSDN, CHM viewer, PDF viewer, консольный man, консольный info или обычный Web-браузер).

Здравствуйте, Андрей Хропов, Вы писали:

E>>IDE -- это не обязательно то, что продается с надписью IDE на упаковке. IDE можно и своими руками собрать и под себя настроить

АХ>IDE — это Integrated Development Environment (Интегрированная Среда Разработки). Не больше, не меньше.

Только в слово "Integrated" каждый вкладывает собственную степень "интеграции". По мне, так Unix вместе с X-Windows это уже очень даже Integrated Development Enviroment, поскольку между нужными мне инструментами я легко переключаюсь по Alt+Tab. И даже без X-ов Unix очень даже удобный development environment, насколько, что я без Cygwin уже под Windows не могу работать.

АХ>Люблю знаешь ли ClearType и 16,7 млн цветов . И гибкое изменение размеров окон (а не только по знакоместам). Да и tooltips. Да и много чего еще.

Дык я тоже. И, если условия позволяют (а так и есть в большинстве случаев) использую gVim -- тут и ClearType, и миллионы цветов, и размер окна меняется, и тулбар с менюшками (который только для красоты и весит, поскольку все равно все команды в command-mode вводятся).
Зато, если нужно отказаться от графики, то это вообще не заметно -- привычная среда для работы сохраняется.

E>>Тем более, что у vim и emacs есть одно очень важное качество -- привычная среда разработки сохраняется не взирая на текущую платформу.
АХ>Ну а Eclipse/MonoDevelop чем хуже?

А разве они умеют в текстовом режиме через ssh работать?
И там есть такая штука, как mode line:

% vim:tw=78:ts=2:sts=2:sw=2:expandtab:ft=tex.latex:fenc=cp1251

E>> А если работать в консольных версиях, то не важно даже, работаешь ли ты на своей машине или через ssh/telnet на удаленной.
АХ>Ну меня и GUIшным remote desktopом не удивишь. Сам так работал.

А нет на серьезных Unix-овых серверах x-server-а.

E>>Для этого другие инструменты есть. QtDesigner, например, совершенно спокойно можно использовать и вне VIM.
АХ>Но тогда теряется буква I — интегрированность. Боюсь по нажатию на кнопке на форме в исходном коде в vim сразу event handler не сгенерируется. Или я не прав (QtDesigner не использовал)?

Там вообще другой принцип работы. QDesigner генерирует базовый класс с необходимыми методами и привязками. Затем нужно от него отнаследоваться и перекрыть нужные сигналы/слоты. Поэтому QDesigner при модификации формы изменяет базовый класса, а изменение производного (производных классов, коих может быть несколько) -- дело программиста.
<offtopic>
В Qt вообще удобный подход к размещению контролов и организации UI (различные layout-ы и spacer-ы) и в Qt я часто делал сложные GUI вообще без дизайнера -- так было гораздо проще.
</offtopic>

VladD2 wrote:
> IT>>А переход к определению метода старички тоже предсказать могут? А
> воспроизвести в памяти список из 20-ти перегруженных методов со всеми их
> параметрами? А быстренько перебрать в памяти сотню методов одного из
> нескольких тысяч классов фреймворка?
>
> TBG>Да, конечно. Или знают, где это можно быстро посмотреть. А также
> усомниться в этом фреймворке. Поскольку дело уже иначе пахнет.
>
> Все с тобой ясно. Человек который называет процесс ручного поиска типа в
> большом проекте и просмотра его исходников быстрым является трепачем
> никогда не видившим того что такое действительно быстро, да и никогда не
> видившего большие проекты.
Если речь про ViM или Emacs — то ctags уже явно прикручен, поэтому время
равно времени нажатия Ctrl-] плюс времени на просмотр редактором
сортированного списка на предмет наличия этого слова (типа или названия
метода) плюс время на загрузку файла (буде он ещё не в памяти).

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>Прогрммист — существо разумное, произошедшее от человека разумного. Поэтому он будет выбирать молоток для гвоздей, а отвертку для шурупов. Это я описал себя. А Вы разве не такой же программист?

Нет, я не такой же. Молоток и отвёртка — это инструменты кустарей. Я же предпочитаю использовать в своей работе современный станок с ЧПУ, которым в нашем деле является IDE.

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

К>Не зря кто-то из довольно известных людей (Брукс?) говорил, что средняя норма — 20 чтоли строчек отлаженного кода в день для программиста.

Забавно, вот здесь

Автор: Курилка
Дата: 21.12.06

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

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

IT>Здравствуйте, Курилка, Вы писали:

К>>Не зря кто-то из довольно известных людей (Брукс?) говорил, что средняя норма — 20 чтоли строчек отлаженного кода в день для программиста.

IT>Забавно, вот здесь

Автор: Курилка
Дата: 21.12.06

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


Да, дурацкие 20 строчек, но доля правды в них есть: ну не зависит производительность программиста от скорости набора. Так же как и у писателей, допустим.
Да, проверки синтаксиса и т.п. фенечки полезны, но они не играют решающую роль, имхо.
Интересно, что за области программинга, где главная задача для проргаммиста будет набить как больше кода?
Лично я таких не могу себе представить.

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

IT>Кстати, студия ищет гораздо быстрее и точнее, чем, например, стандартный поиск в винде.

Хм, видимо разработчиков поиска в Windows плохо кормят (вон и WinFS не доделали). Или взаимодействие у них там не налажено .

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

IT>Нет, я не такой же. Молоток и отвёртка — это инструменты кустарей. Я же предпочитаю использовать в своей работе современный станок с ЧПУ, которым в нашем деле является IDE.

Только если молотком и отверткой пользоваться не умеете, то к станку с ЧПУ Вам явно еще рановато. А уж если вы будете использовать станок с ЧПУ для того, чтобы забить гвоздь или закрутить шуруп — удачи, удачи..

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

EC>>И перекомпиливать проект после изменения регекса? Или передавать его как аргумент (тогда чем это лучше grep'а)?

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

Речь идёт о том, что быстрее — воспользоваться grep'ом или написать программу на C#.
А искать в файлах проекта конечно лучше средствами студии.

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

EC>>Под поиском по регекспу понимается поиск строк в файле? Если да, то убеди меня, что IDE удобнее командной строки.

VD>Намного. Потому как ты можешь бежать по найденым фрагментам по F8 и сразу править текст. Да и задать регексп в диалоге куда проще чем вспоминать команды грепа.

Здесь малость коряво вопрос сформулирован: имелось в виду что быстрее — воспользоваться grep'ом или написать программу на C#.
Это понятно, если прочитать сообщения чуть выше по треду.

VD>И на что уходит время? На нажатие Ctrl+Shift+F и переключение одной галочки? У меня на это уходит два нажатия на клваиатуру. А сколько нужно потратить только на переключение в консоль? А как потом результаты поиска исползовать?

Это всё известно и успешно используется, но речь о другом.

Кстати: твоё молчание в ответ на моё сообщение

Автор: EvilChild
Дата: 06.12.06

можно рассматривать как согласие с тем, что мой вариант оптимальние написания программы на C#?

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

К>Глобально удобнее?
К>А ты не думаешь, что всё зависит от конкретной задачи?
К>Допустим мне нужно найти опр. строку в логе на серваке под солярисом, куда есть только ssh? Причём задача "разовая", т.е. критерии для поиска, файл и т.п. — вещь ситуативная и "сделал/выбросил".
К>Как ты будешь решать такую задачу?

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

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>Скажем так. Я использую из компиляторов gcc из командной строки (иногда), и ncc из командной строки (иногда) и sbcl тоже из командной строки (бывает), да javac тоже из командной строки (бывает), и еще csc из командной строки (ну один раз..). Из сборщиков make, ant, mvn из командной строки (иногда, очень иногда, поскольку они там сами билдятся, без моего ведома). Также использую редакторы vim (очень часто), emacs (иногда) и блокнот (почти никогда). Из сред Eclipse (очень часто), SharpDevelop (иногда), Code::Blocks (иногда), MinGWDeveloperStudio (очень иногда), VS (почти совсем никогда), MonoDevlop (один раз пока). И вот в командной строке программки ls, find, grep, awk, wget (ну просто очень часто).

!!! Вот мне, сирому и убогому кодеру что-либо, кроме VS2005, и открывать-то старшно. Воистину, респект!

TBG>>>И использовать их как IDE и надо. А не как интерактивную консоль.
K>>Это почему? Если IDE помогает в отладке (чего не позволяет консоль), так зачем использовать консоль?

TBG>Отладка может несколькими путями делаться. В том числе и интерактивно, где нужен отладчик. Удобно, если встроенный. Но это не единственный путь.

Какие же ещё есть пути?

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>>>Или знают, где это можно быстро посмотреть.
IT>>Быстрее всего посмотреть прямо в IDE. Нажал кнопку и вот тебе список возможных вармантов, да ещё и контекстный список.

TBG>Ага. А еще и контекстная справка. Но это для отдельных методов. Чтобы понять, как все это в сумме работает придется таки вылезать за пределы IDE.

Это чтобы узнать что-то в корне новое. Если программист уже работал с технологией, принцип помнит, но вот порядок параметров при вызове методов забыл, то Control+Space (а в VS2005 — просто набор символа ".") даёт оперативную удобную подсказку.

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>Только если молотком и отверткой пользоваться не умеете, то к станку с ЧПУ Вам явно еще рановато.

А кто тебе сказал что не умеем? Не суди о других по себе.

Здравствуйте, Turtle.BAZON.Group, Вы писали:

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

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

TBG>С вами тоже ясно. Человек, который называет процесс восприятия человека по некоторым обрывкам фраз — телепатией, является в лучшем случае не понимающим людей. В худшем — навязывающим свое мнение. Перечитайте еще раз мои посты и мое отношение к IDE и проектам.

Не уводи тему разговора. Ты высказался о том что можно что-то там быстро глазами... или запомнить много?
Высказвался. Ну, вот тебе и ответили, что это треп. Физически нельзя запомнить тысячи описаний или быстро просмотрить их в исходниках. Даже обращение к документации процесс очень не быстрый.

И IT прав. Старички есть разыне. Они радуются от того, что освоили VIM, а другие спокойно осваивают новещий IDE и считают это само собой разумеющимся.

TBG>Может, подчеркнем слово качественной? А также соты доли (с учетом движения мышки и нажатия на клавиатуру — минимум десятые)?

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

TBG> А еще "качественной" замените на "привычной".

И к чему эти слова?

TBG> Поскольку если человека пересадить на другую IDE, то все ее возможности нивелируются

Ну, конечно! Замечательное обоснование убогости камменного века! Ведь каменный молоток можно всегда таскать с собой.

Так вот. Плохие привычки нужно и можно менять. А вот IDE стоит менять только от большой необходимости или если появлилась более мошьная IDE.

TBG> (на себе испытал, а вы много IDE сменили в своей жизни?).

Использовал много. Сменил... это более сложный вопрос. Скорее перестал использовать Гуптовую и Борлондовские среды так как МС-ная стала лучше их.

TBG> IDE в общем случае это хороший (иногда отличный) помощник. Но никак не правая или левая рука программиста.

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

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

Редактор — составная часть IDE. Он не может быть не нужен. Но если сравнить редактор и полнофункциональную IDE, то они могут иметь только зависимость редактор <= IDE.

TBG>Жду от Вас замеров, как вы справляетесь за сотые доли секунд. Хочу спросить про Вашу первую фразу. Где это я так был невыспавшийся, что назвал "процесс ручного поиска типа в большом проекте и просмотра его исходников быстрым"?

Так зачем ты влез в этот спор? Ты оказывается на стороне тех кто считает, что без современной IDE производительность труда программиста занчительно ниже. И фразу "Про производительность это Вы загнули. По моим наблюдениям, IDE повышают производительность обучения и написания кода у новичков." это не ты говорил?

VD>>От того потом и появляются вопросы вроде "а может IDE загрузиться за 10 секунд?". Да она за 2 грузится. В худшем случае. И грузить ее не надо, так как это IDE и в ней открыты все нужные файлы.

TBG>Да хоть 2 минуты пусть грузится. В масштабе работы это песчинка.

Ты встал на сторону тех, то высказывал фразу аналогичную процетированной. Может ты просто не ту сторону выбрал?

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

R>Если речь про ViM или Emacs — то ctags уже явно прикручен, поэтому время
R>равно времени нажатия Ctrl-] плюс времени на просмотр редактором
R>сортированного списка на предмет наличия этого слова (типа или названия
R>метода) плюс время на загрузку файла (буде он ещё не в памяти).

И что это чудо умеет без ошибочно распознать любой исходник на С++ (включая шаблоны и маросы) и верно перейти к нужному месту?

Ой не верю я вообще в корректный парсинг С++-исходников. Но если это так, то это уже и есть свойства IDE. Это уже не просто редактор. А хинты с описанием типов это чудо показвать умеет? Ну, наводишь мышку на произвольный идентификатор в фале, а тебе хинт вылазит с полным описанием того что этот идентификатор представляет (ну, или хотя бы отдельное окошко).

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

E>>>А можно мне вот такую загадку объяснить: вот пишете вы вызов метода и hint вам подсказывает, что в метод требуется передать пять параметров. Откуда вы их возьмете, если вызов метода уже начали писать, но про параметры этого метода не знали (т.е. не представляли ни их количества, ни назначения, ни формата, ни допустимых даипазонов)?

VD>>Интересно. Ты просто так неудачно дурака включил или действительно настлько некомпетентен в данном вопросе, что даже представить не можешь то о чем говришь?

E>Т.е. кроме наезда на личность сказать нечего?

Какие наезды? Ты на вопрос то ответь. Ведь то что ты наговорил можно навзать или демагогией или полнешим и форменным бредом. Я вот только классифицировать без уточнения не могу.

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

Ясно. То есть ты действительно никогда не пользовался нормальной IDE.
Ну, вот ответь мне на вопрос. Зачем мне читать документацию на скажем метод Add в классе Dictionary<T>? Я и так прекрасно понимаю, что он делает. Но чтобы не лезть в документацию я и не узнавать, что он называется Add, а не скажем AppendNewElem я пишу "x." и жму Ctrl+Space. В результате выпадает список из которого я выбираю нужный метод. Далее я вбиваю "(" и появляется описание параметров. Из него я вижу, что первый параметр это ключ, а второй — это ассоциируемое с ним значение. Причем тут же, сразу за описанием метода и параметров, я вижу краткую справку по этому методу. И мне вообще не надо лезть в справку.

Понятно?

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

E> А для этого вовсе не нужно, чтобы документация отображалась в том же редакторе, рядом с исходным кодом. Достаточно иметь соседнее приложение (MSDN, CHM viewer, PDF viewer, консольный man, консольный info или обычный Web-браузер).

Пойми. Ты настолько отстал от жизни, что твои слова воспринимаются как демагогия вполне вменяемыми людьми. Вот Грэхм говорил о Блаб-программистах имея в виду непонимания кем-то более мощьного языка в следствии оценкии его с позиций менее мощьного. Так вот у тебя та же проблема но не в области языков, а в области современных средств разработки. Ты все оцениваешь с точки зрения ограниченных средств. Ты попросту не видишь того как люди используют более мощьные и что они от этого получают. Как следствие ты считашь это балавством и непонятными сложностями. Меж тем это не так. Просто попробуй поработать по другому определенное время. Мы даже готовые тебе помочь советами. Уверяю тебя твое мнение координально изменится.

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

IT>Забавно, вот здесь

Автор: Курилка
Дата: 21.12.06

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

Древнее, говоришь.
Вот я сделал только что svn export http://nemerle.org/svn/vs-plugin/trunk
Затем подсчитал количество непустых строк во всех *.cs/*.n файлах (чуть больше 20K) и разделил на количество дней, прошедших с 2005-05-07 (это дата сообщения: Содержимое SVN://RSDN/Nemerle

Автор: V.Petrovski
Дата: 07.05.06

). Получилось, что за один день писалось всего 90 строк:

bash-3.1$ /usr/bin/find . -name '*' | grep -E '\.(cs|n)$' | xargs cat | grep -v -E '^[[:space:]]*$' | wc -l | \
ruby -e'lines = gets.to_i;puts lines/((Time.now - Time.parse("2006-05-07"))/86400)'
90.4658565961219

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

Вот здесь МакКоннел приводит данные за 1997 год, по которым выходит, что в проктах свыше 10K строк на одного разработчика приходится всего от 1.7 до 2.6 функциональных пункта в месяц. Так что старичок Брукс не так уж и далек от истинны -- если, конечно, вести речь об отлаженных, а не о просто написанных строках.