Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
1) Надеюсь, исчезнут файлы с кодом программ,
программа будет храниться в таблицах Sql сервера раздробленная, по крайней мере, до уровня функций.
Различные вьюхи в IDE, при необходимости, восстановят с любой детализацией лубой фрагмент(class, namespace, method).
Файлы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
2) Автоматеческое профилирование.
Данные профайлера после запуска программы автоматически попадают в специальные поля, связанные с методами программы, так что мы всегда, глядя на код метода в IDE, примерно знаем — как часто он вызывается, сколько времени выполняется, процент покрытия кода тестами и тд — без всяких внешних тулзов.
3) Документация — часть программы.
Спецификации модулей должны храниться в той же базе и быть напрямую связаны с участками кода, которые имплементируют эту спецификацию. Должен быть реализован переход в один клик от кода к спецификации и обратно.
4) Багтрекинг — часть программы.
Изменения в коде должны быть ассоциированы с причинами, породившими эти изменения.
автоматическое вычисление производительности труда программиста напрямую интегрированное с его счетом в банке
написал функцию, исправил баг — счет пополнился...
это добавит азарт к работе
написание программы превратится в увлекательную игру
C>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
существенное требуемое изменение:
один и тот же код IDE может представить в разных представлениях,
IDE обеспечивает удобное редактирование кода прямо в виде используемого представления (без необходимости переходить в каноническое представление).
зы
по терминам:
C# (до синтаксического сахара, после развертывания сахара), IL, маш. код, дерево классов, трасса(лог) выполнения, результаты профилировки и т.д. — это все разные представления одной и той же программы.
каноническое представление — это представление из которого строятся все остальные
Здравствуйте, 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>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
На входе: программист с системой для чтения мыслей
На выходе: бэкенд в виде набора взаимосвязанных базовых блоков, с торчащим наружу API для подключения к любым совместимым фронтендам.
Дальше эту бизнес логику можно загрузить в любую оболочку (телефон, телевизор, холодильник).
Уровень программиста будет зависеть от того насколько он четко формирует ментальные образы и контролирует мыслительный процесс.
Если руки золотые, не важно из какого места они растут.
Здравствуйте, Achilles, Вы писали:
A>автоматическое вычисление производительности труда программиста напрямую интегрированное с его счетом в банке A>написал функцию, исправил баг — счет пополнился... A>это добавит азарт к работе A>написание программы превратится в увлекательную игру
Отличная идея) Еще надо бы наоборот сделать, породил баг — снимается штраф со счета, породил страшный неуловимый баг — срок с конфискацией))
Здравствуйте, 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. Контракты и отлов большей части потенциальных ошибок на этапе компиляции. С оочень отдалённой перспективой полноценной верификации кода.
Здравствуйте, servancho, Вы писали:
S>Здравствуйте, Chrome, Вы писали:
C>>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
S>На входе: программист с системой для чтения мыслей S>На выходе: бэкенд в виде набора взаимосвязанных базовых блоков, с торчащим наружу API для подключения к любым совместимым фронтендам.
S>Дальше эту бизнес логику можно загрузить в любую оболочку (телефон, телевизор, холодильник).
S>Уровень программиста будет зависеть от того насколько он четко формирует ментальные образы и контролирует мыслительный процесс.
параллельно встроенный порнофильтр генерирует халявный контент для 100-200 порносайтов
ну чтобы отфильтрованное добро не пропадало...
Здравствуйте, Achilles, Вы писали:
A>автоматическое вычисление производительности труда программиста напрямую интегрированное с его счетом в банке A>написал функцию, исправил баг — счет пополнился... A>это добавит азарт к работе A>написание программы превратится в увлекательную игру
Причем в командную игру по парному программированию: один вносит баги, второй их правит, деньги делят пополам
Здравствуйте, Chrome, Вы писали:
C>1) Надеюсь, исчезнут файлы с кодом программ,
Ага. То есть автоматическая генерация файлов идёт лесом, поиск и замена по всем файлам также идут лесом, возможность быстро запаковать-распаковать, выложить на ftp, сделать или изменить свою иерархию исходников — тоже... Замечательно.
Насколько я помню, было такое. Очень неудобно, потому и отказались.
C>2) Автоматеческое профилирование.
Бессмысленно без (автоматической) генерации профиля нагрузки. Одноразовый прогон все равно нефига не показывает.
Впрочем, интеграция профайлеров с IDE и сейчас такое позволяет делать, в том же Eclipse.
C>3) Документация — часть программы. C>Спецификации модулей должны храниться в той же базе и быть напрямую связаны с участками кода, которые имплементируют эту спецификацию. Должен быть реализован переход в один клик от кода к спецификации и обратно.
Ну, можно и сейчас сделать, тот же JavaDoc + расширения Eclipse легко тебе это обеспечат.
C>4) Багтрекинг — часть программы. C>Изменения в коде должны быть ассоциированы с причинами, породившими эти изменения.
Уже сейчас это есть. Популярный трекер + Eclipse + Mylyn — это и делает.
В общем, на эклипсе это все и сейчас можно собрать из плагинов. Даже времени уйдет недолго.
Собственно, многие и пользуются.
Здравствуйте, Chrome, Вы писали:
C>1) Надеюсь, исчезнут файлы с кодом программ, C>программа будет храниться в таблицах Sql сервера раздробленная, по крайней мере, до уровня функций.
OMFG!
Сразу нафиг такое, и как можно дальше.
C>Различные вьюхи в IDE, при необходимости, восстановят с любой детализацией лубой фрагмент(class, namespace, method).
Эта... От DB зависимости таблеток курс пропить не помешает.
C>Файлы уже давно кажутся мне устаревшей фичей, которую незачем брать в будущее.
C>2) Автоматеческое профилирование. C>Данные профайлера после запуска программы автоматически попадают в специальные поля, связанные с методами программы, так что мы всегда, глядя на код метода в IDE, примерно знаем — как часто он вызывается, сколько времени выполняется, процент покрытия кода тестами и тд — без всяких внешних тулзов.
Т.е. надо это или нет — программа всегда выполняет туеву хучу лишней работы?
Тоже в топку!
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Предлагаю обсудть, какие изменения нужны в среде для разработки программ.
PD>Что бы мы ни хотели видеть, все равно через 10 лет окажется, что увидим мы совсем не то.
Здравствуйте, Lloyd, Вы писали:
L>А что, VS 2010 так уж сильно отличается от 6-ки?
Если бы в 1998 году мне сказали, что вместо легкой и изящной среды VS6 мы получим монстр VS2010 практически без каких-то существенных новых возможностей в плане работы с С++ (о языке не говорю)...
Если бы в 1998 году мне сказали, что неизвестно куда исчезнет профайлер на 8 лет, а вернувшись, превратится в чудовище, генерирующее огромные логи...
Если бы в 1998 году мне сказали, что через 10 лет этой IDE нужно будет несколько сот Мб для работы...
Если бы в 1998 году мне сказали, что будет реализована целенаправленная программа по ухудшению MSDN и она завершится полным успехом к 2010 году...
то я бы тогда в 1998 году впал бы в глубокий транс и не вышел бы из него до сих пор
Здравствуйте, 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) ничего не найдено. Тьфу!
