автоматическое вычисление производительности труда программиста напрямую интегрированное с его счетом в банке
написал функцию, исправил баг — счет пополнился...
это добавит азарт к работе
написание программы превратится в увлекательную игру
Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
1) Надеюсь, исчезнут файлы с кодом программ,
программа будет храниться в таблицах Sql сервера раздробленная, по крайней мере, до уровня функций.
Различные вьюхи в IDE, при необходимости, восстановят с любой детализацией лубой фрагмент(class, namespace, method).
Файлы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
2) Автоматеческое профилирование.
Данные профайлера после запуска программы автоматически попадают в специальные поля, связанные с методами программы, так что мы всегда, глядя на код метода в IDE, примерно знаем — как часто он вызывается, сколько времени выполняется, процент покрытия кода тестами и тд — без всяких внешних тулзов.
3) Документация — часть программы.
Спецификации модулей должны храниться в той же базе и быть напрямую связаны с участками кода, которые имплементируют эту спецификацию. Должен быть реализован переход в один клик от кода к спецификации и обратно.
4) Багтрекинг — часть программы.
Изменения в коде должны быть ассоциированы с причинами, породившими эти изменения.
Здравствуйте, Chrome, Вы писали:
C>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
C>1) Надеюсь, исчезнут файлы с кодом программ, C>программа будет храниться в таблицах Sql сервера раздробленная, по крайней мере, до уровня функций. C>Различные вьюхи в IDE, при необходимости, восстановят с любой детализацией лубой фрагмент(class, namespace, method). C>Файлы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
Это все было и не раз (в Visual FoxPro например). Я пробовал — текстовые файлы рулят со страшной силой.
C>2) Автоматеческое профилирование. C>Данные профайлера после запуска программы автоматически попадают в специальные поля, связанные с методами программы, так что мы всегда, глядя на код метода в IDE, примерно знаем — как часто он вызывается, сколько времени выполняется, процент покрытия кода тестами и тд — без всяких внешних тулзов.
Чисто при помощи магии? Профилирование оно далеко не бесплатное.
C>3) Документация — часть программы. C>Спецификации модулей должны храниться в той же базе и быть напрямую связаны с участками кода, которые имплементируют эту спецификацию. Должен быть реализован переход в один клик от кода к спецификации и обратно.
А ниче, что люди, которые спеки пишут пользуются другими тулзами? Как им всем в твою БД лазить.
Да и вообще идея утопична несколько.
C>4) Багтрекинг — часть программы. C>Изменения в коде должны быть ассоциированы с причинами, породившими эти изменения.
Мне казалось, что это уже сто лет как есть (Source Code->VCS->Bug Tracker).
C>Что еще?
У меня лично есть список мелких хотелок к моей IDE. ХЗ что бы такое глобально можно было улучшить.
Здравствуйте, Chrome, Вы писали:
C>1) Надеюсь, исчезнут файлы с кодом программ,
Нафиг-нафиг. Всё равно придётся переизобретать разбиение кода на части и утрамбовывание этих частей в иерархию. Кроме того, вы тут же отсекаете тонну софта разнообразной степени полезности, не предлагая ничего взамен.
C>Файлы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
Буквы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
C>2) Автоматеческое профилирование.
Да есть оно давно, только толку в тяжёлых случаях никакого, а в лёгких — хватает пары-тройки прогонов. Нафига его держать постоянно?
C>Мы всегда, глядя на код метода в IDE, примерно знаем — как часто он вызывается, сколько времени выполняется, процент покрытия кода тестами и тд — без всяких внешних тулзов.
Есть в студии. Код превращается в разноцветное пятно, что только мешает. Summary-табличка с быстрым переходом к проблемным участкам на порядок удобнее.
C>3) Документация — часть программы.
Для managed-языков — сам формат комментариев давно есть. Сделать красявый UI — тоже не проблема, вроде бы на первых презенташках VS 2010 что-то такое мелькало. Не даст это практически ничего — проще привести API к интуитивно понятному виду, чем сопровождать документацию вместе с кодом.
C>4) Багтрекинг — часть программы. C>Изменения в коде должны быть ассоциированы с причинами, породившими эти изменения.
Не программы, а VCS. Там всего-то надо — автопривязку коммита к текущему тикету + умный blame.
C>Что еще?
5. "Умный" анализ кода. Наше всё как минимум для 3х задач:
1. Нормальные diff-ы. На существующие поделки (за редким исключением) без слёз смотреть нельзя.
2. Облегчение кодинга — автоформатирование, проверки на следование best practices, нахождения багов в многопоточном коде и генерирования юнит-тестов.
3. Контракты и отлов большей части потенциальных ошибок на этапе компиляции. С оочень отдалённой перспективой полноценной верификации кода.
Здравствуйте, Achilles, Вы писали:
A>автоматическое вычисление производительности труда программиста напрямую интегрированное с его счетом в банке A>написал функцию, исправил баг — счет пополнился... A>это добавит азарт к работе A>написание программы превратится в увлекательную игру
Отличная идея) Еще надо бы наоборот сделать, породил баг — снимается штраф со счета, породил страшный неуловимый баг — срок с конфискацией))
Здравствуйте, Plague, Вы писали:
F>>Самое вкусное тут — предположение, что IDE сможет автоматически определять страшные неуловимые баги и причину их породившую. P>Т.е. садишься за комп, а тебя IDE не пускает? =)))
Это была бы вообще прекрасная система! "Invalid user found! Replace and press F1 to continue." (c)
Здравствуйте, Chrome, Вы писали:
C>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
На входе: программист с системой для чтения мыслей
На выходе: бэкенд в виде набора взаимосвязанных базовых блоков, с торчащим наружу API для подключения к любым совместимым фронтендам.
Дальше эту бизнес логику можно загрузить в любую оболочку (телефон, телевизор, холодильник).
Уровень программиста будет зависеть от того насколько он четко формирует ментальные образы и контролирует мыслительный процесс.
Если руки золотые, не важно из какого места они растут.
Здравствуйте, Achilles, Вы писали:
A>автоматическое вычисление производительности труда программиста напрямую интегрированное с его счетом в банке A>написал функцию, исправил баг — счет пополнился... A>это добавит азарт к работе A>написание программы превратится в увлекательную игру
Причем в командную игру по парному программированию: один вносит баги, второй их правит, деньги делят пополам
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
G>>6) Было ли в MSDN хотя бы десятая часть статей он нынешнего количества?
K>MSDN 2010 — это катастрофически неудобное и кривое угребище. При чем здесь объем статей?
Не вижу существенных изменений в MSDN . За исключением дизайна.
Здравствуйте, Chrome, Вы писали:
C>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
C>1) Надеюсь, исчезнут файлы с кодом программ, C>программа будет храниться в таблицах Sql сервера раздробленная, по крайней мере, до уровня функций. C>Различные вьюхи в IDE, при необходимости, восстановят с любой детализацией лубой фрагмент(class, namespace, method). C>Файлы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
Все, кто хотят исчезновения файлов с кодом, на самом деле со временем понимают, что хотят другого — доступа к коду как к AST. Т.е. любой файл на некотором языке — это аналог XML, есть некая либа, с помощью которой можно получить иерархию, и есть удобный и продуманный пользовательский интерфейс, с помощью которого можно к файлам обращаться.
Ну и еще — более продвинутый редактор кода, позволяющий отображать не весь код, а только то что нужно программисту в данный момент (например, скрывать те же документирующие теги, различные профилирующие теги, теги багтрекинга и т.д... да, все ваши пункты 2,3,4 — на самом деле специальные теги, возможно даже НЕ комментарии, а именно теги, встроенные в язык и проверяемые компилятором на корректность и грамотно обрабатываемые IDE).
Здравствуйте, Chrome, Вы писали:
C>1) Надеюсь, исчезнут файлы с кодом программ,
Ага. То есть автоматическая генерация файлов идёт лесом, поиск и замена по всем файлам также идут лесом, возможность быстро запаковать-распаковать, выложить на ftp, сделать или изменить свою иерархию исходников — тоже... Замечательно.
Здравствуйте, Lloyd, Вы писали:
L>А что, VS 2010 так уж сильно отличается от 6-ки?
Если бы в 1998 году мне сказали, что вместо легкой и изящной среды VS6 мы получим монстр VS2010 практически без каких-то существенных новых возможностей в плане работы с С++ (о языке не говорю)...
Если бы в 1998 году мне сказали, что неизвестно куда исчезнет профайлер на 8 лет, а вернувшись, превратится в чудовище, генерирующее огромные логи...
Если бы в 1998 году мне сказали, что через 10 лет этой IDE нужно будет несколько сот Мб для работы...
Если бы в 1998 году мне сказали, что будет реализована целенаправленная программа по ухудшению MSDN и она завершится полным успехом к 2010 году...
то я бы тогда в 1998 году впал бы в глубокий транс и не вышел бы из него до сих пор
Здравствуйте, winston, Вы писали:
W>Отличная идея) Еще надо бы наоборот сделать, породил баг — снимается штраф со счета, породил страшный неуловимый баг — срок с конфискацией))
Самое вкусное тут — предположение, что IDE сможет автоматически определять страшные неуловимые баги и причину их породившую.
Здравствуйте, GarryIV, Вы писали:
GIV>Все упирается в инстументы. Часто удобно какой-нибудь grep натравить на исходники. Ну не хочется грузить IDE или в ней вовсе нет этой фичи. VCS: В случае БД весионирование придется как то в нее саму зашивать, а ведь проекты бывают разнородные. И у разных проектов, разные требования к VCS.
А самое веселое — в VCS приходится не только исходники хранить. Придется что то там докручивать в хранилище, и в итоге один фик к абстракции типа файла придем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1490 on Windows 7 6.1.7600.0>>
Здравствуйте, Klatu, Вы писали:
GIV>>Это все было и не раз (в Visual FoxPro например). Я пробовал — текстовые файлы рулят со страшной силой.
K>почему?
Все упирается в инстументы. Часто удобно какой-нибудь grep натравить на исходники. Ну не хочется грузить IDE или в ней вовсе нет этой фичи. VCS: В случае БД весионирование придется как то в нее саму зашивать, а ведь проекты бывают разнородные. И у разных проектов, разные требования к VCS.
Здравствуйте, servancho, Вы писали:
S>Здравствуйте, Chrome, Вы писали:
C>>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
S>На входе: программист с системой для чтения мыслей S>На выходе: бэкенд в виде набора взаимосвязанных базовых блоков, с торчащим наружу API для подключения к любым совместимым фронтендам.
S>Дальше эту бизнес логику можно загрузить в любую оболочку (телефон, телевизор, холодильник).
S>Уровень программиста будет зависеть от того насколько он четко формирует ментальные образы и контролирует мыслительный процесс.
параллельно встроенный порнофильтр генерирует халявный контент для 100-200 порносайтов
ну чтобы отфильтрованное добро не пропадало...
Здравствуйте, Chrome, Вы писали:
C>1) Надеюсь, исчезнут файлы с кодом программ, C>программа будет храниться в таблицах Sql сервера раздробленная, по крайней мере, до уровня функций.
OMFG!
Сразу нафиг такое, и как можно дальше.
C>Различные вьюхи в IDE, при необходимости, восстановят с любой детализацией лубой фрагмент(class, namespace, method).
Эта... От DB зависимости таблеток курс пропить не помешает.
C>Файлы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
C>2) Автоматеческое профилирование. C>Данные профайлера после запуска программы автоматически попадают в специальные поля, связанные с методами программы, так что мы всегда, глядя на код метода в IDE, примерно знаем — как часто он вызывается, сколько времени выполняется, процент покрытия кода тестами и тд — без всяких внешних тулзов.
Т.е. надо это или нет — программа всегда выполняет туеву хучу лишней работы?
Тоже в топку!
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
PD>Что бы мы ни хотели видеть, все равно через 10 лет окажется, что увидим мы совсем не то.
Здравствуйте, winston, Вы писали:
A>>автоматическое вычисление производительности труда программиста напрямую интегрированное с его счетом в банке A>>написал функцию, исправил баг — счет пополнился... A>>это добавит азарт к работе A>>написание программы превратится в увлекательную игру W>Отличная идея) Еще надо бы наоборот сделать, породил баг — снимается штраф со счета, породил страшный неуловимый баг — срок с конфискацией))
Ну тогда бы все были ни с чем и сидели бы давно ужо
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Sinix, Вы писали:
S>AST очень неудобно проверять на определённый паттерн (например, является свойство простой обёрткой над полем, или содержит в себе какую-то дополнительную логику).
Вообще-то это реализуется тривиально с использованием сопоставления с образцом, у меня на этом подходе (запрос к AST) утиллита тестирования парсера C# построена.
C>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
существенное требуемое изменение:
один и тот же код IDE может представить в разных представлениях,
IDE обеспечивает удобное редактирование кода прямо в виде используемого представления (без необходимости переходить в каноническое представление).
зы
по терминам:
C# (до синтаксического сахара, после развертывания сахара), IL, маш. код, дерево классов, трасса(лог) выполнения, результаты профилировки и т.д. — это все разные представления одной и той же программы.
каноническое представление — это представление из которого строятся все остальные
Насколько я помню, было такое. Очень неудобно, потому и отказались.
C>2) Автоматеческое профилирование.
Бессмысленно без (автоматической) генерации профиля нагрузки. Одноразовый прогон все равно нефига не показывает.
Впрочем, интеграция профайлеров с IDE и сейчас такое позволяет делать, в том же Eclipse.
C>3) Документация — часть программы. C>Спецификации модулей должны храниться в той же базе и быть напрямую связаны с участками кода, которые имплементируют эту спецификацию. Должен быть реализован переход в один клик от кода к спецификации и обратно.
Ну, можно и сейчас сделать, тот же JavaDoc + расширения Eclipse легко тебе это обеспечат.
C>4) Багтрекинг — часть программы. C>Изменения в коде должны быть ассоциированы с причинами, породившими эти изменения.
Уже сейчас это есть. Популярный трекер + Eclipse + Mylyn — это и делает.
В общем, на эклипсе это все и сейчас можно собрать из плагинов. Даже времени уйдет недолго.
Собственно, многие и пользуются.
Здравствуйте, Pavel Dvorkin, Вы писали:
L>>А что, VS 2010 так уж сильно отличается от 6-ки?
PD>Если бы в 1998 году мне сказали, что вместо легкой и изящной среды VS6 мы получим монстр VS2010 практически без каких-то существенных новых возможностей в плане работы с С++ (о языке не говорю)... PD>Если бы в 1998 году мне сказали, что неизвестно куда исчезнет профайлер на 8 лет, а вернувшись, превратится в чудовище, генерирующее огромные логи... PD>Если бы в 1998 году мне сказали, что через 10 лет этой IDE нужно будет несколько сот Мб для работы... PD>Если бы в 1998 году мне сказали, что будет реализована целенаправленная программа по ухудшению MSDN и она завершится полным успехом к 2010 году...
PD>то я бы тогда в 1998 году впал бы в глубокий транс и не вышел бы из него до сих пор
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Lloyd, Вы писали:
L>>А что, VS 2010 так уж сильно отличается от 6-ки?
PD>Если бы в 1998 году мне сказали, что вместо легкой и изящной среды VS6 мы получим монстр VS2010 практически без каких-то существенных новых возможностей в плане работы с С++ (о языке не говорю)... PD>Если бы в 1998 году мне сказали, что неизвестно куда исчезнет профайлер на 8 лет, а вернувшись, превратится в чудовище, генерирующее огромные логи... PD>Если бы в 1998 году мне сказали, что через 10 лет этой IDE нужно будет несколько сот Мб для работы... PD>Если бы в 1998 году мне сказали, что будет реализована целенаправленная программа по ухудшению MSDN и она завершится полным успехом к 2010 году...
PD>то я бы тогда в 1998 году впал бы в глубокий транс и не вышел бы из него до сих пор
Интересно:
1) В 1998 году был intellisence? (читай парсинг на лету)
2) Была ли инкрементальная компиляция для C++
3) Была ли опция whole program optimization? Инлайнящая кросс-модульные вызовы.
4) Была ли отладка с поддержкой потоков?
5) Стоил ли гиг памяти как день работы программиста?
6) Было ли в MSDN хотя бы десятая часть статей он нынешнего количества?
Здравствуйте, gandjustas, Вы писали:
PD>>то я бы тогда в 1998 году впал бы в глубокий транс и не вышел бы из него до сих пор
G>Интересно: G>1) В 1998 году был intellisence? (читай парсинг на лету)
Да.
G>2) Была ли инкрементальная компиляция для C++
Да.
G>3) Была ли опция whole program optimization? Инлайнящая кросс-модульные вызовы.
Что такое "модуль" в применении к C++?
G>4) Была ли отладка с поддержкой потоков?
Не знаю, вроде нет.
G>5) Стоил ли гиг памяти как день работы программиста?
О таком никто даже не мечтал. Но и жрала студия существенно меньше.
G>6) Было ли в MSDN хотя бы десятая часть статей он нынешнего количества?
Сейчас объем MSDN-а не столь важен, а в то время инета считай что и не было.
Здравствуйте, gandjustas, Вы писали:
G>1) В 1998 году был intellisence? (читай парсинг на лету)
Надо заметить он в вижуалке для С++ до сих пор отстойный.
VAX наше всё.
Whole Tomato Software, Inc. was founded in 1997
Трудно уже сказать когда вышла самая первая версия, которая еще не Х была.
G>2) Была ли инкрементальная компиляция для C++
Это разве IDE? Это фичи компилятора.
G>3) Была ли опция whole program optimization? Инлайнящая кросс-модульные вызовы.
Опять таки к IDE никакого отношения.
Впрочем она и на данный момент не особо то и нужна.
Ну а тестовый проект (regression test) либы на 47KLoc WPO у меня героически мучало полтора часа (!), по ходу жизни отожрало под 2 гига памяти, в итоге уменьшило EXE на ~10 килобайт и никак не отразилось на скорости выполнения теста: был "дребезг" в пределах погрешности (тест как на корректность так и на производительность алгоритмов либы). В результате не пользуюсь.
G>4) Была ли отладка с поддержкой потоков?
Ну, многопоточку я в 99м или 2000м как то отлаживал. Давно было, деталей не помню уже.
G>5) Стоил ли гиг памяти как день работы программиста?
Опять вопрос: какое отношение это имеет к IDE?
В то время гиг памяти на рабочем компе было скорее мифом.
G>6) Было ли в MSDN хотя бы десятая часть статей он нынешнего количества?
Вообще то на данный момент Offline MSDN от 2003й студии куда удобнее чем онлайн MSDN, который по F1 на WinAPI функции которой лет 10 минимум показывает или вообще не то, или грит что для вашего языка (English) ничего не найдено. Тьфу!
Здравствуйте, Klatu, Вы писали:
GIV>>Это все было и не раз (в Visual FoxPro например). Я пробовал — текстовые файлы рулят со страшной силой.
K>почему?
Мне приходилось разбираться с проектами, в которых логика была зашита внутри форм или отчетов (FoxPro, VB6). Больше не хочется. Особенно если эту логику нужно было использовать где-то в другой части проекта. В двух словах — неподдерживаемая каша.
Здравствуйте, Privalov, Вы писали:
P>Мне приходилось разбираться с проектами, в которых логика была зашита внутри форм или отчетов (FoxPro, VB6). Больше не хочется. Особенно если эту логику нужно было использовать где-то в другой части проекта. В двух словах — неподдерживаемая каша.
Была, возможно не в полной мере. Вторая фаза компиляции, вызываемая из линкера (c2.dll), была.
G>4) Была ли отладка с поддержкой потоков?
Не уверен. Что именно ?
G>5) Стоил ли гиг памяти как день работы программиста?
Это не свойство VS
G>6) Было ли в MSDN хотя бы десятая часть статей он нынешнего количества?
Было столько же, и даже больше. MSDN Library выпускался на 3 CD, его аккуратно изменяли каждые 3 месяца, убирая устаревшие статьи и добавляя новые. Суммарный объем, таким образом, составлял 1.8 GB. MSDN 9.0 от VS2008 (в VS2010 вместо MSDN черт знает что) имеет объем в 2 GB. При этом надо иметь в виду, что тогдашний MSDN ни слова не содержал о .NET.
Здравствуйте, x-code, Вы писали:
XC>Все, кто хотят исчезновения файлов с кодом, на самом деле со временем понимают, что хотят другого — доступа к коду как к AST.
Тут есть интересная проблема: в разных случаях требуются разные модели.
AST очень неудобно проверять на определённый паттерн (например, является свойство простой обёрткой над полем, или содержит в себе какую-то дополнительную логику). И, наоборот, data flow очень неудобно отслеживать, оперируя только потоком il-инструкций.
Cамих юз-кейзов — дофига и больше:
— проверка форматирования и автоформатирование;
— рефакторинг и метапрограммирование;
— статический анализ кода;
— кодогенерация и emit;
— текстовые шаблоны (T4);
— всякие трансляторы DSL (linq).
и часть из них должна работать с невалидным AST — например, та же подсветка ошибок в реалтайме.
Это только то, что сразу пришло в голову.
Как всем угодить — я даже приблизительно не представляю.
C>1) Надеюсь, исчезнут файлы с кодом программ, C>2) Автоматеческое профилирование. C>3) Документация — часть программы. C>4) Багтрекинг — часть программы. C>Что еще?
Все вышенаписанное — отчасти фигня отчасти баян
А я хочу искуственный интеллект с распознаванием речи. Так чтобы я промычал в микрофон — "нублиаа.. как же мне ошибку юзеру показать" и оно мне услужлибо выдавало декларацию FriendlyErrorMessage из какого-нибудь трехэтажного .h-ника..
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>А я хочу искуственный интеллект с распознаванием речи. Так чтобы я промычал в микрофон — "нублиаа.. как же мне ошибку юзеру показать" и оно мне услужлибо выдавало декларацию FriendlyErrorMessage из какого-нибудь трехэтажного .h-ника..
В свете тенденций — закажет "Error Messages for Dummies" на амазоне со всеми возможными дополнительными покупками, покажет кучу рекламы, отправит жалобу тимлиду и выставит счёт за пользование сервисом
Здравствуйте, Chrome, Вы писали:
C>1) Надеюсь, исчезнут файлы с кодом программ,
Надеюсь, что нет.
C>программа будет храниться в таблицах Sql сервера раздробленная, по крайней мере, до уровня функций. C>Различные вьюхи в IDE, при необходимости, восстановят с любой детализацией лубой фрагмент(class, namespace, method).
Зачем?
C>2) Автоматеческое профилирование. C>Данные профайлера после запуска программы автоматически попадают в специальные поля, связанные с методами программы, так что мы всегда, глядя на код метода в IDE, примерно знаем — как часто он вызывается, сколько времени выполняется, процент покрытия кода тестами и тд — без всяких внешних тулзов.
Внешняя тулза удобнее.
C>3) Документация — часть программы. C>Спецификации модулей должны храниться в той же базе и быть напрямую связаны с участками кода, которые имплементируют эту спецификацию. Должен быть реализован переход в один клик от кода к спецификации и обратно.
Это сравнительно несложно реализовать.
C>4) Багтрекинг — часть программы. C>Изменения в коде должны быть ассоциированы с причинами, породившими эти изменения.
Это вроде бы и так уже есть, но не всегда нужно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1490 on Windows 7 6.1.7600.0>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Lloyd, Вы писали:
L>>А что, VS 2010 так уж сильно отличается от 6-ки?
PD>Если бы в 1998 году мне сказали, что вместо легкой и изящной среды VS6 мы получим монстр VS2010 практически без каких-то существенных новых возможностей в плане работы с С++ (о языке не говорю)...
Хм, попахивает холиваром, но: как-то я не ощущал экстаза ни от 4-ки, ни от 6-ки. И 2k-линейка Студии для меня куда более удобна и дружественна. Возможно, я с самой юности был безнадежно испорчен Borland Pascal и Turbo Debugger, а "шестерку" так и не научился готовить? И теперь просто пожинаю плоды от перехода Хейлсберга со товарищи из Borland в Microsoft?
Здравствуйте, Zdreni, Вы писали:
Z>Ага. То есть автоматическая генерация файлов идёт лесом, поиск и замена по всем файлам также идут лесом, возможность быстро запаковать-распаковать, выложить на ftp, сделать или изменить свою иерархию исходников — тоже... Замечательно.
согласен. отсутствие этих действий это просто замечательно.
