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

К>Это всё здорово, конечно, но есть другой вопрос — скорость программирования у тебя определяется скоростью набора на клавиатуре? ИМХО это далеко не так и гораздо больше времени уходит на обдумывание и проектирование.

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

Лично я не трачу какого-то невероятного времени на проектирование. Более того, я могу за два часа напроектировать столько сколько 10 кодеров не запрограммируют за две недели.

Лично у меня основное время уходит именно на эксперементы с кодом.

И вообще разказы о фундаментальном проектировании меня смешат. Проектирование конкретной реализации на 90% зависит от тех особенностей которые я узнаю по ходу дела. Просто невозможно заранее предусмотреть все проблемы. Так что в процессе кодирования приходится корректировать исходный план. Таким образом процесс проектирования у меня неотемлемо связан с процессом кодирования.

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

К>А тут могут быть полезны диаграмки классов и т.п. инструменты.

А диаграмы классов это тоже часть современной IDE. Правда полезны они скорее не для проектирования, а скорее для изучения (на высоком уровне) чужого кода.

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

Может не надо ссылаться на авторитетов говоривших каки-то слова в далеком прошом? Времена меняются. Меняется и производительность труда программиста. Да даже значимость строчки кода меняется. Сегодня на Немерле в одну строку зачастую умещается целая страница на С++. И пишу я их куда больше чем 20. Точнее может и 20, но за час, а не в день.

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

К>Да, дурацкие 20 строчек, но доля правды в них есть: ну не зависит производительность программиста от скорости набора. Так же как и у писателей, допустим.

Это чущь. Уверяю тебя как один из тех самых писателей. Скорость написания статей во многом зависит от того с какой скоростью ты долбишь на клавиатуре. Обдумать мысль можно в мгновение ока. А изложить ее — это время и не малое. И способность излогать мысли на машине со скоростью их обдумывания дорогого стоит. Многие писатели, в прошом, в следствии того, что не умеют быстро писать на машине писали от руки.

С программированием все сложнее. Тут уже скорость набора может быть скоменсирована RAD-остями IDE. Ведь все идетнтификаторы в глове не удержишь, а хорошая IDE легко помогает в этом.

К>Да, проверки синтаксиса и т.п. фенечки полезны, но они не играют решающую роль, имхо.

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

Лагерь защиты скриптов и командных строк и сам переодически вспоминает о разных Реплах. Но почему-то не воспринимает этот Репл как одну из возможных RAD-остей. А между тем это именно так. Просто хорошая IDE предоставляет много таких радостей, а не одну.

К>Интересно, что за области программинга, где главная задача для проргаммиста будет набить как больше кода?
К>Лично я таких не могу себе представить.

Это проблемы твоего воображения. А области любые. Просто напдо понимать, что ускоряется не только набивание кода. Ускоряется процесс разработки. Ты начинашь быстрее понимать чухой (или свой, но давно не читанный) код, быстрее находить нужны фрагменты, быстрее вносих изменения, быстрее проверяешь их влияние на приложение, быстрее отлаживаешь код и в итоге быстрее получаешь необходимый результат.

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

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

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

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

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

Фактически над проектом долгое время работали двое, а то и вообще один человек и не полный работчий день. Так что цифру 90 можно смело умножать на 4. Плюсь еще надо понимать, что код на Немерле зачастую в 2-4 раза компактнее аналогичного Шарповского. Вот и получается, что 20 строк в день это сильно заниженный результат. А точнее просто ахинея. Так просто нельзя считать.

VladD2 wrote:
> Точно так же если ты долго варился в культуре *н?ксов и знаешь как свои
> пять пальцев разные баши, ссаши, грепы и другую дребедень, то тебе
> возможно проще будет решить задачу ими.
>
> И спор это опять о предпочтениях. А ведь начинался он вполне
> конструктивно. Ведь если отбросить предпочтения то тяжело спорить, что
> использовать удобный язык, мощьную IDE с отладчиком и хорошим набором
> утилитарного библиотечного кода — это лучше чем долбить руками в консоли
> что-то параллельно читая маны и молиться, чтобы оно заработало так как надо.
Особенно очевидно это мне на задачах, для которых упомянутый язык плох,
так как вдаётся в детали. График можно быстро построить в maple, octave
или на J, но не пользоваться же для этого языком общего назначения.
Быстро провести подсчёт вхождений слова в файл удобно в vim или на
shell, но не пользоваться же для этого языком общего назначения — это
будет длиннее. Выборки из базы данных со сложными условиями пишутся на
разных диалектах SQL, не пишут же их на языках общего назначения...

VladD2 wrote:
> R>Понятие pipe, нормально загнанное в библиотеку, жизнеспособно на
> R>Nemerle. На свежем C#, возможно, жизнеспособно, но за это я не поручусь
> R>(не держу я mono). На предыдущей версии C# — судя по тому, как её
> R>упоминали — заведомо не живёт. Так что это всё же вопрос не только
> R>библиотек. Когда строк кода 1 раз по 1К — это неважно, когда 50 раз по
> R>20 — неприятно.
>
> Ничего не понял. Какша какая-то.
grep something file | sort -k 1n | uniq -c

Имеем 3 библиотечных функции. И удобный метод их скомбинировать. Который
не требует — для больших файлов — выделять память по размеру всего файла.

Как этот метод комбинации функций добавляется в С# из .NET 1.1?

> R>А тут так любят ссылаться на практику применения как на недостаток Lisp.
> R>За много лет никто так в библиотеку это до конца и не загнал, или о
> R>результате никто не слышал, в результате программы в десять строк на

> 1. Кто-то что-то загнал. Не надо обобщать.
Тогда вторая ветвь "или" — столь же краткого по записи результата почти
никто не увидел?

> 2. Возможно большинству людей это просто не нужно. Я вот лично очень
> редко вообще скрипты пишу. И когда пишу, то почему-то функциональность
> греп-а мне нужна не часто.
Но некоторым обработка текста нужна.

> 3. Возможно многие просто не знают о некоторых возможностях некоторых
> утилит и изобретают велосипеды на ровном месте.
И так много лет.. В таком случае надо продвигать хотя бы то, что есть —
чтобы люди не мучались.

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

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

E>Последние среды, которыми я пытался пользоваться более-менее серьезно, были VS 6.0 и CodeGuide 3.0 (или 4.0, не помню), в 2001-м году. Причем VS 6.0 меня настолько задолбал, что я сначала выключил в нем все подсказки, а затем и перестал пользоваться вообще.

Разве в VS 6.0 были подсказки?

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

E>* есть набор фундаментальных понятий, которые должны отложиться в подкорке (или речь вообще не должна идти о знании языка). Например, в C++ элементарно запоминается, что у большинства контейнеров есть push_back, а у ассоциативных -- insert.

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

Я действительно хочу понять. Народ здесь просто прикалывается, всё это от желания поспорить и отстоять своё, пусть даже плохонькое, но своё, мнение? В чём поинт?

E>Т.е. подсказки и autocomplete веши для многих, безусловно, полезные. Но их значимость и влияние на качество кода изрядно преувеличивается, имхо.

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

E>Более того, когда кто-то говорит о том, что подсказки оказывают серьезную помощь при программировании, то лично у меня это вызывает очень серьезные сомнения в качестве подобного кода (к сожалению, доводилось наблюдать подобные эффекты).

Ну что тут сказать? Пастернака не читал, но осуждаю.

Подсказки, как минимум не мешают. Очень помогают подсказки, когда надо разобрать с незнакомым или забытым кодом.

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

EC>Речь идёт о том, что быстрее — воспользоваться grep'ом или написать программу на C#.

Ну дык если такая фича нужна мне в моей программе, то конечно лучше наприсать код на C#, чем обучать пользувателю grep'у.

EC>А искать в файлах проекта конечно лучше средствами студии.

Ну вот и славненько.

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

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

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

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

Женя, при всём моём к тебе уважении я тебя и в правду скоро забаню за подобную хрень И не жалко же собственного времени?

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

У меня как-то был один проект, в котором общее количество строк при его сопровождении и добавлении новых фич неумолимо уменьшалось. Хобби у меня такое — переписывать откровенный бред, своего писать как можно меньше и отжимать из кода всё лишнее. По-твоему получается я писал по -20 строк в день?

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

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

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

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

Да, и ещё в качестве конкретного примера по конкретному подсчёту строк. Вчера я потратил около часа на то, чтобы найти в компиляторе багу, исправить её и проверить, что ничего не сломалось. В результате была изменено строчек кода — один, добавлено новых строчек кода — один, добавлено строчек с коментариями — три. Больше я вчера ничего серьёзного по проекту не делал. Надеюсь ты учтёшь это как-нибудь в своих расчётах.

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

IT>Разве в VS 6.0 были подсказки?

Если не ошибаюсь, то в ней даже комплита не было.

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

E>Нет, не ясно. Хотелось бы увидеть пример более сложных методов, на которые разработчик не смотрит до их использования.

О. Это легко можно увидить. Скачиваешь Рефлектор. Открываешь его. Раскрваешь первую же ветку и начинаешь ее изучать.

Если начнешь сечас, то чере месяц можно продолжить беседу.

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

Когда я начинал программировать на С я постоянно лазил в хелп. Помогало то, что уже QuickC 1.0 умел открывать контекстную помощь. Но производительность была не всокой, так как искать описание конкретных параметров и т.п. все равно было довольно медленно. С появлением зачатков комплита (сначала в Gupta SQLWindows, а затем в VB 4) стало намного проще. Ну, а когда появились продукты класса VS 2005 и IDEA, то жизнь просто таки преобразилась. Сейчас я с большой неохотой пишу и читаю код без поддержки IDE. В том же Немерле постоянно испытываю дискомфорт. И это не смотря на то, что язык дает фору не только С++ и Шарпу, но и всем Руби вместе взятым.

E>Речь не о зазубривании. Речь вот о чем:
E>* есть набор фундаментальных понятий, которые должны отложиться в подкорке (или речь вообще не должна идти о знании языка). Например, в C++ элементарно запоминается, что у большинства контейнеров есть push_back, а у ассоциативных -- insert. В Ruby, например, конкатенация строк и добавление элементов в конец массива выполняется через <<. Это такой базис, который позволяет писать основные действия не задумываясь;

С операторами соглашусь. А вот зачем мне запоминать списки методов и темболее их перегрузки (списки параметров), я вообразить не могу.

E>* есть набор более сложных вещей, с которыми приходится сталкиваться время от времени. Например, установление SSL соединения, выбор подходящего класса-Connector в ACE, выборка нужного сертификата в хранилище сертификатов и т.д. В этих случаях разработчику нужно погрузиться в предметную область, ознакомится с существующими API-вызовами (как правило, выбрать какую-то из альтернатив), определиться с последовательностью действий и порядком подготовки API вызовов (что бы нужные параметры формировались в нужных местах и в нужных форматах).

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

Что до последовательностей вызвовов, то в хороших библиотеках они и так должны быть очевидными. Правильно спроектированных библиотеках вообще тяжедо ошибиться с последовательностью. Скажем бред который был в CRT с функцями доступа к файлам вообще не возможен в том же Шарпе. Ведь если ты не открыл файл, то ты просто не получишь ссылу на объект его олицетвояющий.

Посему мне достаочно запомнить что для работы с файлами нужно написать "File." и я получу список доступных вариантов. Причем я даже не обязан помнить в каком он пространсве имен. Как только я напишу "File", если нужное пространство имен еще не открыто IDE выведет об этом придупреждение и нажатием Shift+F10 я могу автоматом открыть нужное простраство имен.

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

Пойми, что банально быстрее нажать "." чем лазить по документации.

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

Только тебе. Я вообще в документацию залезаю только с определенной целью. Описание методов мне доступно и так.

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

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

E>Т.е. подсказки и autocomplete веши для многих, безусловно, полезные.

Ну, уже сдвиг. И то хорошо.

E> Но их значимость и влияние на качество кода изрядно преувеличивается, имхо.

Не на качество кода, а на скорость получения этого самого качественного кода. А так же на скорость его изучения и на скорость его модификации.

E> Более того, когда кто-то говорит о том, что подсказки оказывают серьезную помощь при программировании, то лично у меня это вызывает очень серьезные сомнения в качестве подобного кода (к сожалению, доводилось наблюдать подобные эффекты).

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

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

E>Последние среды, которыми я пытался пользоваться более-менее серьезно, были VS 6.0 и CodeGuide 3.0 (или 4.0, не помню), в 2001-м году. Причем VS 6.0 меня настолько задолбал, что я сначала выключил в нем все подсказки, а затем и перестал пользоваться вообще. И CodeGuide в плане IDE был на порядок круче VS 6.0. А от CodeGuide отказался довольно быстро, когда увидел, что его подсказки мне мешают. С тех пор я несколько раз смотрел на IDEA, но не работал в ней, т.к. на Java не программировал с 2001-го.

В VC 6 комплит практически не работал. Да и до сих пор я не видил ни одной приличной реализации комплита для С++. Больно проблематичный язык. Ну, а о каких-то более сложных вещах и говорить не приходится. VC 6 — это очень убогая IDE. Так что считай что ты так и не видел современной IDE. IDEA последних версий действительно крута. Но ее недостаточно открыть. Ею надо пользоваться для реальной работы хотя бы пару месяцев. И при этом изучать и испльзовать ее возможности.

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

Опять таки. Если ты сталкиваешся с тривиальными задачами где есть небольшой набор типов с малым числом методов, то это еще ничего не значит. У других забот по более. Обойтись каким-то ограниченным поднабором нельзя. А забывать старые описания и заучивать новые (причем снова на время) постоянно невозможно.
И, главное, не нужно. Все и так есть. Причем имеет очень логичные и легко ищущиеся названия. Например, все для работы с директориями лежит в классе Directory и DirectoryInfo. А все утилитарные фукнции работы со строками доступны в классе string. Я вот не помню даже какие там методы. Но когда смотрю на их список, то вопросов у меня не возникает. А уж их параметры...

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

E>Как раз я никого не отговариваю от использования IDE. Это здесь в адрес тех, кто IDE не пользуется, слишком много критики высказывается.

Ага, ага. Только рассказывашь все как мало тлоку дают все эти диковенные фичи.

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

R>grep something file | sort -k 1n | uniq -c

R>Имеем 3 библиотечных функции. И удобный метод их скомбинировать. Который
R>не требует — для больших файлов — выделять память по размеру всего файла.

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

Функции могут возвращать итераторы. Так что проблем с объемом памяти не будет. И выглядить это будет примерно так:

grep.Something(file).Sort().Uniq()

R>Как этот метод комбинации функций добавляется в С# из .NET 1.1?

Так же как и 2.0. На входе и выходе энумераторы. Конечно с дженериками и итераторами было бы чуть удобнее, но не суть важно.

R>Тогда вторая ветвь "или" — столь же краткого по записи результата почти
R>никто не увидел?

Опять ничего не понял.

R>Но некоторым обработка текста нужна.

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

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

Проще создать управляемую библиотеки с возможностями грепа. Благо весь функционал уже есть.

R>С ними поставляются? В том же стандарте описаны — более тесная связь.

Нет. Это разговор со стенкой.

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

R>Особенно очевидно это мне на задачах, для которых упомянутый язык плох,
R>так как вдаётся в детали. График можно быстро построить в maple, octave
R>или на J, но не пользоваться же для этого языком общего назначения.

Смотря где данные берутся, как обрабатываются и какой сложнсоти нужен графиг. В простых случаях все что ты перечислил будет оврекилом, так как на Excel-е это будет куда проще. А в сложных как раз отлично подойдет язык общего назначения. Благо графики вручную рисовать не надо. Для этого есть компоненты.

R>Быстро провести подсчёт вхождений слова в файл удобно в vim или на
R>shell, но не пользоваться же для этого языком общего назначения — это
R>будет длиннее.

shell такими возможностями не обладает. А фукнцию по фигу где вызвать. Даже в shell менее удобно.

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

R> Выборки из базы данных со сложными условиями пишутся на
R>разных диалектах SQL, не пишут же их на языках общего назначения...

Понятно, что если есть мощьный ДСЛ, то применять универсальные языки глупо. Вот только shell не есть ДСЛ. Это как раз убогий универсальный язык. Причем очень убогий. И спасают его только библиотеки в виде утилит.

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

E>Дело вовсе не в этом.
E>Имхо, дело в том, что уже есть годами отработанные механизмы для решения этих задачек -- unix-овые утилиты.

Это ошибочный взгляд на проблему.

Утилиты — это аналоги библиотек. А языки там Баш и т.п. Вот вместо них применять полноценный язык вполне можно. А заполучить библиотеку с возможностями грепа вряд ли кто откажется.

E> Они адаптированны под такие цели не хуже (если не лучше), чем современные IDE

Это алогизм. Они вообще не могут сравниваться с IDE как не может сравниваться с IDE библиотека. С IDE надо сравнивать редактор в котором ты редактируешь шел-скрипты. А сами шел-скрипты с ЯП сравнивать. Вот тогда будет все логично.

E> для разработки "серьезных" программ. И просто глупо оказываться от использования отлаженных и проверенных инструментов в пользу написания еще одной программки для решения каждой задачки (даже если это не отнимает много времени).

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

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

TBG>>Только если молотком и отверткой пользоваться не умеете, то к станку с ЧПУ Вам явно еще рановато.
VD>А кто тебе сказал что не умеем? Не суди о других по себе.

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

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

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

Ну да. Принцип помнит, но немного подзабыл.. Если уже работал и работает, он даже сам не знает что подставлять надо — все само подставляется. Если чуток подзабыл, то ой.. Подсказки не подсказки, вот цитаты из разделы справки — это то, что я ценю в IDE (можно быстренько по диагонили пробежаться и вспомнить). Дополнения разные, ну разве что при хитром комплите по большим буквам тоже удобно. Ну еще универсальная Ctrl-1 в Eclipse.
Но если человек ни с технологией не работал, ни толком то не программил, то по "." начинает гадать и додумывать, что этот метод делает. Ну тоже хорошо, конечно, в определенных ситуациях..

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

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

Первым начали уводить разговор Вы. Это ответная реакция.
Теперь про мои высказывания. Не говорил, что запомнить можно много. Я также скажу, что то, что запомнено — забывается. И лишь говорил о том, что часто используется — запоминается само собой. Например, Вы часто ставите ".", а потом курсором выбираете метод? Или бывает, что Вы уже знаете какой метод Вам нужен и быстренько его набираете по заглавным буквам и давите Ctrl-Space?
Про что-то там глазами вообще не помню такого высказывания. Если не поленитесь, вставье мою цитату и я дам Вам развернутый ответ.
А про треп — это все от того, что много людей любят додумывать за остальных.

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

Люди вообще все разные. Только если человек освоил VIM и при этом начинает говорить, что IDE — не нужные после этого, равно так же как и человек, который осваивает новейший IDE и считает, что разные редакторы — удел убожеств, то все это — крайности. А крайности, как известно, имеют гораздо меньшую гибкость.

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

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

TBG>> Поскольку если человека пересадить на другую IDE, то все ее возможности нивелируются
VD>Ну, конечно! Замечательное обоснование убогости камменного века! Ведь каменный молоток можно всегда таскать с собой.

Телепатией Вы не обладаете, поэтому не стоит пытаться ее использовать. Фраза была сказана к тому, что IDE должна быть не столько качественной, сколько привычной для достижения максимальной производительности. Поскольку без предварительного обучения и Tips&Tricks любая IDE лишь станок с ЧПУ в руках обезьяны. Да к чему это я? А к тому, что совсем не обязательно на качественной IDE будет получена максимальная производительность в произвольном промежутке времени.

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

Вам меня не понять..

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

К сожалению, IDE еще не научилась писать программы за программиста. В этом случае ваша фраза была бы верна.

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

Редактор всегда обладает меньшими возможностями, чем IDE. На то IDE и есть I. Редакторы не все до этого уровня доводятся. Которые доводятся — необходимо совершать какие-то телодвижения. Но только не надо говорить, что редактор какой-либо IDE ну круче, чем редактор VIM, потому что находится унутрях любимой IDE.

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

VD>Так зачем ты влез в этот спор? Ты оказывается на стороне тех кто считает, что без современной IDE производительность труда программиста

Я был и буду на своей стороне. Решил принять участие в споре лишь затем, чтобы показать, что свет клином не сошелся на IDE. Есть еще и другие инструменты.

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

Я говорил. Действительно, с помощью IDE новички пишут код быстрее (и необдуманнее, кстати говоря). Никакая IDE не может стать частью мозга. Да и по наблюдениям некоторых зарубежных коллег, хорошая производительность программиста составляет 20-30 отлаженных строчек в день. Их особо не напрягаясь можно написать и без IDE. И профессионалы могут это сделать. Другое дело, что не хотят. Потому как чтение контесктной справки прятниее из IDE. Дебаг (это зло) тоже приятнее из IDE. Да и много вещей приятнее из IDE. Потому как для этого она и создавалась — для того, чтобы было приятно и удобно.

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

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

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

IT>Подсказки, как минимум не мешают. Очень помогают подсказки, когда надо разобрать с незнакомым или забытым кодом.

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