Здравствуйте, konsoletyper, Вы писали:
K>А вот я не понимаю людей, которые в наше время маниакально следуют традиции 70-х всё и вся писать в vi+bash. У нас нынче уже следующий век! Ортодоксам я могу показать путь к IDE.
А вот я совсем не понимаю людей, которые для того, чтобы посмотреть список файлов в каталоге (на удаленном сервере без ГИП), открывают на локальной машине IDE (VS, Eclipse, KDevelop, AnyOtherDevelop и т.д.) и начинают писать команду dir или ls.
K>1. На самом деле, языки, используемые в bash и в cmd — языки-уродцы с кривым синтаксисом. А вот то же самое можно описать на C# (или, кому как нравится, на Python), благо, чтобы открыть/удалить/создать файл, запустить процесс и т.д. в библиотеках современных языков есть неплохая поддержка.
Уродец или не уродец — это, собственно, лишь дело привычки. А вот то же самое описывать на C# (или, кому как нравится, на N programming language, или вкратце, eNlang) — моветон. Я понимаю, что на скриптовых языках bash и cmd трудно опиывать сложную бизнес-логику (да ладно, будем честны друг с другом — логику вообще), но они для этого и не предназначены. У этих языков своя вполне определенная ниша и они в ней прочно держатся. Потому что зачем использовать что-то сложнее, если не видно разницы? По поводу библиотек современных языков могу сказать, что с помощью WinAPI по виндами все функции по открытию/удалению/созданию файла, запуска процесса и т.д. доступны в ассемблере. Только вот давно ли вы это практиковали?
K>2. Чем вручную проверять все даты модификации, уместно задать декларативное описание и по нему вызывать нужные функции. Т.к. функции часто
[немного поскипано] K> всякими autoconf+automake. И это всё при том, что такие вещи, как MSBuild и Ant гораздо мощнее и красивее.
Всякие там autoconf и automake возникли вовсе не из-за кривости синтаксиса bash (а вы m4 то видели, который тоже можно встретить часто), а из-за зоопарка всяких unix-систем.
Про MSBuild не читал (но и не осуждаю), а вот про Ant скажу. Вот где корявый синтаксис, то это у него. Компенсируется он лишь тем, что благодаря ему можно создать визуальные средства редактирования ant-файлов, что, собственно, и делается. Да и появился ant для того, чтобы обеспечить функциональность make, но с максимальной независимостью от платформы.
K>3. Работать удобнее в GUI (можно даже пофлеймить об этом отдельно, не в этой ветке), причём тут нет никаких ограничений, т.к. я не
Это вы рабочему на стройке скажите, что удобнее работать в ГИП, или с помощью удобного интерфейса командной строки. Пофлеймить не получится. Аналогия, конечно, кривовата, но я думаю, вы поняли, что я хотел сказать.
K>рассматриваю Unix-сервер как подходящее рабочее место для программиста. Так что ортодокс в начале работы откроет cmd/Konsole/xterm и при каждлой перекомпиляции будет писать make/msbuild (или нажисать стрелку вверх и жать Enter). Но, во-первых, всегда удобнее нажать F5, во-вторых, мы просто экономим время, когда не ищем строку №XXX, а просто щёлкаем мышкой по ошибке и IDE сам показывает нам это место.
Спасибо за вводную. Аж чуть не прослезился.. Но вот что Вам скажу, мне удобнее ничего не нажимать. У меня в IDE autobuild настроен. Знаете ли, экономлю таким образом время на нажатие F5. И мышкой щелать не надо, все проблемные места сразу же подчеркиваются. Может, Вам тоже так попробовать? А то народ в заблуждение вводите.
K>Кроме этих пунктов хочу отметить, что у редакторов VS и Eclipse всё-таки больше полезных фич, чем в vi (про фичи сомнительной полезности я
Редакторы VS и Eclipse фич не имеют совсем. Зато у них IDE хорошие. Собственно, это обстоятельство и делает удобным работу в них. Но если бы в этих IDE был только редактор, то зачем вообще нужны такие IDE? Про MonoDevelop и KDevelop не читал (но опять же, не осуждаю). Да, и, сравнивать VS (Eclipse, IDEA, NetBeans, BlueJ, MonoDevelop, KDevelop и т.д.) с vi (даже не с vim) — это все равно, что сравнивать теплое с мягким, то есть лучше не надо — это несравнимые вещи.
K>умолчу). По крайней мере, это верно для C# и для Java, насчёт других языков я могу заблуждаться. Опять же, связка vi+bash+make позволяет в некотором приближении делать всё то, что я перечислил в трёх пунктах, их можно настроить для такой же удобной компиляции, как F5 в VS, но тогда уместнее говорить о среде vi+bash+make+собственный_набор_скриптов, т.е проблемы с перекомпиляцией отпадают автоматически. И всё-таки,
F5 — я Вам уже подсказал, что есть и лучшие пути. Поковыряйтесь в своей IDE, не будтье ортодоксом 90-х.
K>я считаю, что можно банально поставить GUI и юзать себе на здоровье Eclipse, SharpDevelop, MonoDevelop, KDevelop или даже VS, если деньги найдутся, либо VS EE. И не надо при этом извращаться; если нашлись люди, которые автоматизировали процесс, а следовательно сделали его более быстрым и удобным, то надо обрадоваться и заюзать, а не впадать в приступы острой ортодоксии.
Да, советую вам так и поступить. Почитайте что-нибудь вроде Tips&Tricks для Вашей IDE.
Здравствуйте, konsoletyper, Вы писали:
K>Вот как раз синтаксис одинаково кривой, что у bash, что у cmd. У C# синтаксис гораздо симпатичнее. А вот семантика и правда у cmd убогая.
О синтаксисе можно спорить вечно.. Хорошо, хоть Lisp не вспомнили..
K>Вот у меня лежит дистрибутив Fedora Core 3 вместе с исходниками (ну да, не самый новый ). Исходники по большей части (приятное
Вы бы еще BlackCat 6 назвали бы. Или RedHat 5.
K>Generate method stub в VS?
Батюшки, это фича редактора?
K>А вот есть пара фич, удобных объективно. Например, подсветка имён типов. Или хинты при наведении мышки. Советую заюзать — это не кому-то удобнее, это, если преодолеть брезгливость, повысит производительность любого. Где такие фичи в vim?
Про производительность это Вы загнули. По моим наблюдениям, IDE повышают производительность обучения и написания кода у новичков. Старички хинты предсказать могут, все типы подсвеченные быстро глазами пробегут. Что очень удобно — это шаблоны всякие, который сам на себя уже понаписал, но тут тоже заметьте аналогию. Что еще удобно — это реверс исходников. В vim я не совсем профи, не знаю как сделать там это удобно. Если бы знал — им бы и пользовался..
Здравствуйте, Turtle.BAZON.Group, Вы писали:
K>>Вот как раз синтаксис одинаково кривой, что у bash, что у cmd. У C# синтаксис гораздо симпатичнее. А вот семантика и правда у cmd убогая.
TBG>О синтаксисе можно спорить вечно.. Хорошо, хоть Lisp не вспомнили..
У Лиспа красивый синтаксис, хотя и весьма необычный. А вот у таких языков, как shell, perl и PHP синтаксис уродский.
K>>Вот у меня лежит дистрибутив Fedora Core 3 вместе с исходниками (ну да, не самый новый ). Исходники по большей части (приятное
TBG>Вы бы еще BlackCat 6 назвали бы. Или RedHat 5.
Ну, не такой он уж и старый.
K>>Generate method stub в VS?
TBG>Батюшки, это фича редактора?
Вот я про то, что редактор вроде vim такого не сделает, для этого нужна IDE.
K>>А вот есть пара фич, удобных объективно. Например, подсветка имён типов. Или хинты при наведении мышки. Советую заюзать — это не кому-то удобнее, это, если преодолеть брезгливость, повысит производительность любого. Где такие фичи в vim?
TBG>Про производительность это Вы загнули. По моим наблюдениям, IDE повышают производительность обучения и написания кода у новичков. Старички хинты предсказать могут, все типы подсвеченные быстро глазами пробегут. Что очень удобно — это шаблоны всякие, который сам на себя уже понаписал, но тут тоже заметьте аналогию. Что еще удобно — это реверс исходников. В vim я не совсем профи, не знаю как сделать там это удобно. Если бы знал — им бы и пользовался..
Да, да, Влад и IT — новички, они из-за своей неопытности решили для Nemerle сделать хинты. Вот вчера попробовал писать на Немерле в SciTE (за неимением чего-либо другого), так оказалось, что это раз в 10 медленнее, чем на C# в VS.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
K>>1. На самом деле, языки, используемые в bash и в cmd — языки-уродцы с кривым синтаксисом. А вот то же самое можно описать на C# (или, кому как нравится, на Python), благо, чтобы открыть/удалить/создать файл, запустить процесс и т.д. в библиотеках современных языков есть неплохая поддержка.
TBG>Уродец или не уродец — это, собственно, лишь дело привычки. А вот то же самое описывать на C# (или, кому как нравится, на N programming language, или вкратце, eNlang) — моветон. Я понимаю, что на скриптовых языках bash и cmd трудно опиывать сложную бизнес-логику (да ладно, будем честны друг с другом — логику вообще), но они для этого и не предназначены. У этих языков своя вполне определенная ниша и они в ней прочно держатся. Потому что зачем использовать что-то сложнее, если не видно разницы?
А вот как раз описывается эта сложная "бизнес-логика", именно, как Вы правильно заметили ниже, потому что понаплодили зоопарк слабосовместимых Unix-ов.
TBG>По поводу библиотек современных языков могу сказать, что с помощью WinAPI по виндами все функции по открытию/удалению/созданию файла, запуска процесса и т.д. доступны в ассемблере. Только вот давно ли вы это практиковали?
Ну, ассемблер — штука для таких вещей неудобная, а вот task-и MSBuild-а писать на С# — одно удовольствие.
K>>3. Работать удобнее в GUI (можно даже пофлеймить об этом отдельно, не в этой ветке), причём тут нет никаких ограничений, т.к. я не
TBG>Это вы рабочему на стройке скажите, что удобнее работать в ГИП, или с помощью удобного интерфейса командной строки. Пофлеймить не получится. Аналогия, конечно, кривовата, но я думаю, вы поняли, что я хотел сказать.
Нет, аналогию не понял, требую объяснить. Я, конечно, не буду требовать от админа Unix-сервера требовать, чтобы он работал в GUI. А вот программиста в этом ничего не ограничивает.
K>>рассматриваю Unix-сервер как подходящее рабочее место для программиста. Так что ортодокс в начале работы откроет cmd/Konsole/xterm и при каждлой перекомпиляции будет писать make/msbuild (или нажисать стрелку вверх и жать Enter). Но, во-первых, всегда удобнее нажать F5, во-вторых, мы просто экономим время, когда не ищем строку №XXX, а просто щёлкаем мышкой по ошибке и IDE сам показывает нам это место.
TBG>Спасибо за вводную. Аж чуть не прослезился.. Но вот что Вам скажу, мне удобнее ничего не нажимать. У меня в IDE autobuild настроен. Знаете ли, экономлю таким образом время на нажатие F5. И мышкой щелать не надо, все проблемные места сразу же подчеркиваются. Может, Вам тоже так попробовать? А то народ в заблуждение вводите.
Это где такая красота? В Smalltalk? Ну тогда о чём спорим? А вот, между прочим, с C++ такого сделать нельзя в принципе. Это при том, что последние версии Eclipse-а такое во многих случаях умеют. Да и VS, надеюсь только пока такого не умеет (хотя простейшие синтаксические ошибки подчёркивает).
K>>Кроме этих пунктов хочу отметить, что у редакторов VS и Eclipse всё-таки больше полезных фич, чем в vi (про фичи сомнительной полезности я
TBG>Редакторы VS и Eclipse фич не имеют совсем. Зато у них IDE хорошие. Собственно, это обстоятельство и делает удобным работу в них. Но если бы в этих IDE был только редактор, то зачем вообще нужны такие IDE? Про MonoDevelop и KDevelop не читал (но опять же, не осуждаю). Да, и, сравнивать VS (Eclipse, IDEA, NetBeans, BlueJ, MonoDevelop, KDevelop и т.д.) с vi (даже не с vim) — это все равно, что сравнивать теплое с мягким, то есть лучше не надо — это несравнимые вещи.
VS и Eclipse тем и лучше, что они IDE. И у них, соответственно, все полезные фичи сосредоточены в IDE-шной части. А вот в vim куча фич сомнительной полезности. Например, зачем мне двумя касаниями переводить курсор на 3 слова вправо. А вот элементарно переключаться между окнами — нажимать сочетание клавиш через всю клавиатуру.
K>>я считаю, что можно банально поставить GUI и юзать себе на здоровье Eclipse, SharpDevelop, MonoDevelop, KDevelop или даже VS, если деньги найдутся, либо VS EE. И не надо при этом извращаться; если нашлись люди, которые автоматизировали процесс, а следовательно сделали его более быстрым и удобным, то надо обрадоваться и заюзать, а не впадать в приступы острой ортодоксии.
TBG>Да, советую вам так и поступить. Почитайте что-нибудь вроде Tips&Tricks для Вашей IDE.
konsoletyper wrote:
> TBG>Спасибо за вводную. Аж чуть не прослезился.. Но вот что Вам скажу, > мне удобнее ничего не нажимать. У меня в IDE autobuild настроен. Знаете > ли, экономлю таким образом время на нажатие F5. И мышкой щелать не надо, > все проблемные места сразу же подчеркиваются. Может, Вам тоже так > попробовать? А то народ в заблуждение вводите. > > Это где такая красота? В Smalltalk? Ну тогда о чём спорим? А вот, между > прочим, с C++ такого сделать нельзя в принципе. Это при том, что
А почему — в принципе? При каждом сохранении и просто по задержкам в
печати... Можно при сходящихся скобках вырезать функцию под курсором и
компилировать без сборки, и отдельно пытаться скомпилировать её.
> последние версии Eclipse-а такое во многих случаях умеют. Да и VS, > надеюсь только *пока* такого не умеет (хотя простейшие синтаксические > ошибки подчёркивает).
> VS и Eclipse тем и лучше, что они IDE. И у них, соответственно, все > полезные фичи сосредоточены в IDE-шной части. А вот в vim куча фич > сомнительной полезности. Например, зачем мне двумя касаниями переводить > курсор на 3 слова вправо. А вот элементарно переключаться между окнами — > нажимать сочетание клавиш через всю клавиатуру.
Если у Вас вся клавиатура — это от ctrl до w, то без :map здесь не
обойтись. Но ctrl-tab ближе не так намного. Многие редакторные — вроде
бы — фичи позволяют делать mappings легко и кратко. Но нечитаемо.
Впрочем, не запрещая вариант пользоваться только функциями и писать
читаемые макросы.
Здравствуйте, konsoletyper, Вы писали:
K>Кроме этих пунктов хочу отметить, что у редакторов VS и Eclipse всё-таки больше полезных фич, чем в vi (про фичи сомнительной полезности я умолчу). По крайней мере, это верно для C# и для Java, насчёт других языков я могу заблуждаться. Опять же, связка vi+bash+make позволяет в некотором приближении делать всё то, что я перечислил в трёх пунктах, их можно настроить для такой же удобной компиляции, как F5 в VS, но тогда уместнее говорить о среде vi+bash+make+собственный_набор_скриптов, т.е проблемы с перекомпиляцией отпадают автоматически. И всё-таки, я считаю, что можно банально поставить GUI и юзать себе на здоровье Eclipse, SharpDevelop, MonoDevelop, KDevelop или даже VS, если деньги найдутся, либо VS EE. И не надо при этом извращаться; если нашлись люди, которые автоматизировали процесс, а следовательно сделали его более быстрым и удобным, то надо обрадоваться и заюзать, а не впадать в приступы острой ортодоксии.
Интересно, а где вы таких застрявших в 70-х годах ортодоксов увидели?
К тому же, мне кажется, вы слабо себе представляете, на что способен VIM (именно ViM, а не vi) в умелых руках.
Вот, например:
Здравствуйте, konsoletyper, Вы писали:
K>У Лиспа красивый синтаксис, хотя и весьма необычный. А вот у таких языков, как shell, perl и PHP синтаксис уродский.
Но он является предметом жарких споров.
TBG>>Вы бы еще BlackCat 6 назвали бы. Или RedHat 5. K>Ну, не такой он уж и старый.
Учитывая, что текущий релиз 6, а у федоры они выходят не так уж часто.
TBG>>Батюшки, это фича редактора? K>Вот я про то, что редактор вроде vim такого не сделает, для этого нужна IDE.
А я про то, что редактор у IDE похуже, но не в этом их ценность.
K>Да, да, Влад и IT — новички, они из-за своей неопытности решили для Nemerle сделать хинты. Вот вчера попробовал писать на Немерле в SciTE (за неимением чего-либо другого), так оказалось, что это раз в 10 медленнее, чем на C# в VS.
Здравствуйте, konsoletyper, Вы писали:
K>Нет, аналогию не понял, требую объяснить. Я, конечно, не буду требовать от админа Unix-сервера требовать, чтобы он работал в GUI. А вот программиста в этом ничего не ограничивает.
Ну требуйте себе на здоровье!
K>Это где такая красота? В Smalltalk? Ну тогда о чём спорим? А вот, между прочим, с C++ такого сделать нельзя в принципе. Это при том, что
В Eclipse, уважаемый. О котором вы говорили, кстати.
K>VS и Eclipse тем и лучше, что они IDE. И у них, соответственно, все полезные фичи сосредоточены в IDE-шной части. А вот в vim куча фич
И использовать их как IDE и надо. А не как интерактивную консоль.
K>сомнительной полезности. Например, зачем мне двумя касаниями переводить курсор на 3 слова вправо. А вот элементарно переключаться между окнами — нажимать сочетание клавиш через всю клавиатуру.
Это ваше ИМХО. Опять же, понятия удобности сложно оценить.
TBG>>Да, советую вам так и поступить. Почитайте что-нибудь вроде Tips&Tricks для Вашей IDE. K>Свою IDE я и так использую по полной программе.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Про производительность это Вы загнули. По моим наблюдениям, IDE повышают производительность обучения и написания кода у новичков. Старички хинты предсказать могут, все типы подсвеченные быстро глазами пробегут.
А переход к определению метода старички тоже предсказать могут? А воспроизвести в памяти список из 20-ти перегруженных методов со всеми их параметрами? А быстренько перебрать в памяти сотню методов одного из нескольких тысяч классов фреймворка?
TBG>Что очень удобно — это шаблоны всякие, который сам на себя уже понаписал, но тут тоже заметьте аналогию.
Это что-то типа сниппетов? А я вот этим как-то не пользуюсь совсем Проще ручками. Хотя нет. Иногда использую два: ctor и prop.
В общем, дело не в старичках. Дело в предпочтениях, а обобщать свои предпочтения на такую большую категорию как старички не стоит даже самым законеченным старпёрам.
TBG> Что еще удобно — это реверс исходников.
А это каким боком к IDE?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
K>>Generate method stub в VS?
TBG>Батюшки, это фича редактора?
Это фича IDE.
K>>А вот есть пара фич, удобных объективно. Например, подсветка имён типов. Или хинты при наведении мышки. Советую заюзать — это не кому-то удобнее, это, если преодолеть брезгливость, повысит производительность любого. Где такие фичи в vim?
TBG>Старички хинты предсказать могут
Неужто весь MSDN (или manы там) наизусть выучили? Ну-ка по памяти все классы из System.CodeDom (и с параметрами конструкторов, конечно).
Здравствуйте, IT, Вы писали:
IT>А переход к определению метода старички тоже предсказать могут? А воспроизвести в памяти список из 20-ти перегруженных методов со всеми их параметрами? А быстренько перебрать в памяти сотню методов одного из нескольких тысяч классов фреймворка?
Да, конечно. Или знают, где это можно быстро посмотреть. А также усомниться в этом фреймворке. Поскольку дело уже иначе пахнет.
IT>Это что-то типа сниппетов? А я вот этим как-то не пользуюсь совсем Проще ручками. Хотя нет. Иногда использую два: ctor и prop.
Нет, это типа коде теплейтов.
IT>В общем, дело не в старичках. Дело в предпочтениях, а обобщать свои предпочтения на такую большую категорию как старички не стоит даже самым законеченным старпёрам.
Если Вы могли замтетить, я как раз ничего не обобщал. Я занял позицию сепаратизма инструментов.
TBG>> Что еще удобно — это реверс исходников. IT>А это каким боком к IDE?
А таким, что при переброске людей с проекта на проект приходится постигать оный не только по проектной документации. Вот тут и поможет реверс в виде просмотра конструкторов, перегруженных методов. Построить иерархию вызовов, иерархию типов. Вот тут Eclipse или IDEA (в среде Java) однозначно рулят. Кстати, кто подскажет как в vim такое сделать (конкретнее, что почитать из большого обилия) — буду благодарен.
Здравствуйте, Андрей Хропов, Вы писали:
TBG>>Батюшки, это фича редактора? АХ>Это фича IDE.
О чем, собственно говоря, и речь.
TBG>>Старички хинты предсказать могут АХ>Неужто весь MSDN (или manы там) наизусть выучили? Ну-ка по памяти все классы из System.CodeDom (и с параметрами конструкторов, конечно).
Ну из java.lang пожалуйста. И еще из нескольких пакетов. С чем работают — могут по памяти сказать. С чем не работают — зачем надо это знать?
IT wrote: > А переход к определению метода старички тоже предсказать могут? А > воспроизвести в памяти список из 20-ти перегруженных методов со всеми их > параметрами? А быстренько перебрать в памяти сотню методов одного из > нескольких тысяч классов фреймворка?
XRef это все умеет для С++.
Здравствуйте, Cyberax, Вы писали:
C>IT wrote: >> А переход к определению метода старички тоже предсказать могут? А >> воспроизвести в памяти список из 20-ти перегруженных методов со всеми их >> параметрами? А быстренько перебрать в памяти сотню методов одного из >> нескольких тысяч классов фреймворка? C>XRef это все умеет для С++.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
АХ>>Неужто весь MSDN (или manы там) наизусть выучили? Ну-ка по памяти все классы из System.CodeDom (и с параметрами конструкторов, конечно).
TBG>Ну из java.lang пожалуйста. Все методы и типы параметров для них? Не верю (с)
Ну даже если и так, то таких уникумов не много. Да и не стоит тратить время на заучивание всего этого.
TBG> И еще из нескольких пакетов. С чем работают — могут по памяти сказать. С чем не работают — зачем надо это знать?
Дело в том "с чем работают" понятие растяжимое. Есть методы которые 100 раз на дню используются (ToString какой-нибудь). Понятно, что большинство их помнит.
А есть которые используются пореже, которые уже не запоминаются. Да и вообще hintы надежнее. Память и подвести может (3 с 4 параметры нечасто используемого метода случайно перепутать запросто).
Здравствуйте, Андрей Хропов, Вы писали:
TBG>>Ну из java.lang пожалуйста. АХ>Все методы и типы параметров для них? Не верю (с)
А там немного. Это я специально такой пакет выбрал..
АХ>Ну даже если и так, то таких уникумов не много. Да и не стоит тратить время на заучивание всего этого.
Правильно, надо запоминать то, что используется.
АХ>Дело в том "с чем работают" понятие растяжимое. Есть методы которые 100 раз на дню используются (ToString какой-нибудь). Понятно, что большинство их помнит.
Так и должно быть. 80% функциональности реализуется 20% используемых методов.
АХ>А есть которые используются пореже, которые уже не запоминаются. Да и вообще hintы надежнее. Память и подвести может (3 с 4 параметры нечасто используемого метода случайно перепутать запросто).
Здравствуйте, Turtle.BAZON.Group, Вы писали:
IT>>А переход к определению метода старички тоже предсказать могут? А воспроизвести в памяти список из 20-ти перегруженных методов со всеми их параметрами? А быстренько перебрать в памяти сотню методов одного из нескольких тысяч классов фреймворка?
TBG>Да, конечно.
Конечно, нет. Нет более бессмысленного занятия, чем забивать себе голову названиями и параметрами тысяч методов.
TBG>Или знают, где это можно быстро посмотреть.
Быстрее всего посмотреть прямо в IDE. Нажал кнопку и вот тебе список возможных вармантов, да ещё и контекстный список.
TBG>А также усомниться в этом фреймворке. Поскольку дело уже иначе пахнет.
Усомниться прежде всего предётся в .NET & Java frameworks. А это уже иначе выглядит.
IT>>Это что-то типа сниппетов? А я вот этим как-то не пользуюсь совсем Проще ручками. Хотя нет. Иногда использую два: ctor и prop.
TBG>Нет, это типа коде теплейтов.
А что это типа такое?
IT>>В общем, дело не в старичках. Дело в предпочтениях, а обобщать свои предпочтения на такую большую категорию как старички не стоит даже самым законеченным старпёрам.
TBG>Если Вы могли замтетить, я как раз ничего не обобщал. Я занял позицию сепаратизма инструментов.
Этого я не смог заметить. Обобщение про старичков заметил. Так вот на это я в свою очередь могу заметить, что не все "старички" считают предсказание хинтов вообще разумным времяпрепровождением. Если эту тупую работу быстрее и точнее может сделать компьютер (конкретно IDE), то вот пусть он её и делает.
TBG>>> Что еще удобно — это реверс исходников. IT>>А это каким боком к IDE?
TBG>А таким, что при переброске людей с проекта на проект приходится постигать оный не только по проектной документации. Вот тут и поможет реверс в виде просмотра конструкторов, перегруженных методов. Построить иерархию вызовов, иерархию типов. Вот тут Eclipse или IDEA (в среде Java) однозначно рулят.
Опять не пойму. Речь о навигации по коду или о просмотре структуры кода?
TBG>Кстати, кто подскажет как в vim такое сделать (конкретнее, что почитать из большого обилия) — буду благодарен.
Для этого IDE как минимум должно поддерживать интеграцию с конкретным языком программирования.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Андрей Хропов, Вы писали:
TBG>> И еще из нескольких пакетов. С чем работают — могут по памяти сказать. С чем не работают — зачем надо это знать? АХ>Дело в том "с чем работают" понятие растяжимое. Есть методы которые 100 раз на дню используются (ToString какой-нибудь). Понятно, что большинство их помнит. АХ>А есть которые используются пореже, которые уже не запоминаются. Да и вообще hintы надежнее. Память и подвести может (3 с 4 параметры нечасто используемого метода случайно перепутать запросто).
А можно мне вот такую загадку объяснить: вот пишете вы вызов метода и hint вам подсказывает, что в метод требуется передать пять параметров. Откуда вы их возьмете, если вызов метода уже начали писать, но про параметры этого метода не знали (т.е. не представляли ни их количества, ни назначения, ни формата, ни допустимых даипазонов)?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А можно мне вот такую загадку объяснить: вот пишете вы вызов метода и hint вам подсказывает, что в метод требуется передать пять параметров. Откуда вы их возьмете, если вызов метода уже начали писать, но про параметры этого метода не знали (т.е. не представляли ни их количества, ни назначения, ни формата, ни допустимых даипазонов)?
Настоятельно рекомендую выключить демагогию. Я обещал банить за это и скоро начну это делать.
Если нам не помогут, то мы тоже никого не пощадим.
). Исходники по большей части (приятное 
Что еще удобно — это реверс исходников. В vim я не совсем профи, не знаю как сделать там это удобно. Если бы знал — им бы и пользовался..
Проще ручками. Хотя нет. Иногда использую два: ctor и prop.
Если нам не помогут, то мы тоже никого не пощадим.
