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

_>Hi All

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией

Да минусов дофига, и один из них — то, что ей, а вернее, С++, до сих пор пользуются. Честно скажу сразу — я не крутой спец, повидавший и написавший горы кода. Но, сдается мне (с), что в конце конце концов (и не так уж долго это будет продолжаться, несмотря на горы софта, написанные на С/С++) сойдет на нет С++ — ый энтузиазм, и .NET или что там после нее более высокоуровневое (хоть многие и хаят и воспринимают как смехотворную эту мысль на сегодняшний день, но вполне возможно, что через N лет будут составлять программы совсем не программисты, а обычный подкованный в типа-UMLноподобной среде менеджер или вроде того и поддержка всего этого будет уделом узкого круга спецов). ПО эволюционирует, микрокоды, asm, ЯВУ, развитый фреймворк, интересно услышать мнеия от ув. ALL, что дальше?

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

А>Да минусов дофига, и один из них — то, что ей, а вернее, С++, до сих пор пользуются. Честно скажу сразу — я не крутой спец, повидавший и написавший горы кода. Но, сдается мне (с), что в конце конце концов (и не так уж долго это будет продолжаться, несмотря на горы софта, написанные на С/С++) сойдет на нет С++ — ый энтузиазм, и .NET или что там после нее более высокоуровневое (хоть многие и хаят и воспринимают как смехотворную эту мысль на сегодняшний день, но вполне возможно, что через N лет будут составлять программы совсем не программисты, а обычный подкованный в типа-UMLноподобной среде менеджер или вроде того и поддержка всего этого будет уделом узкого круга спецов). ПО эволюционирует, микрокоды, asm, ЯВУ, развитый фреймворк, интересно услышать мнеия от ув. ALL, что дальше?

То, что дальше, выделено жирным:

Колыбель. Пеленки. Плач.
Слово. Шаг. Простуда. Врач.
Беготня. Игрушки. Брат .
Двор. Качели. Детский сад.
Школа. Двойка. Тройка. Пять.
Мяч. Подножка. Гипс. Кровать.
Драка. Кровь. Разбитый нос.
Двор. Друзья. Тусовка. Форс.
Институт. Весна. Кусты.
Лето. Сессия. Хвосты.
Пиво. Водка. Джин со льдом.
Кофе. Сессия. Диплом .
Романтизм. Любовь. Звезда.
Руки. Губы. Ночь без сна.
Свадьба. Теща. Тесть. Капкан.
Ссора. Клуб. Друзья. Стакан.
Дом. Работа.
Дом. Семья.
Солнце. Лето.
Снег. Зима.
Сын. Пеленки. Колыбель.
Стресс. Любовница. Постель.
Бизнес. Деньги. План. Аврал.
Телевизор. Сериал.
Дача. Вишни. Кабачки.
Седина. Мигрень. Очки.
Внук. Пеленки. Колыбель.
Стресс. Давление. Постель.
Сердце. Почки. Кости. Врач.
Речи. Гроб. Прощанье. Плач

((c) неизвестен)

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

А>Да минусов дофига, и один из них — то, что ей, а вернее, С++, до сих пор пользуются. Честно скажу сразу — я не крутой спец, повидавший и написавший горы кода. Но, сдается мне (с), что в конце конце концов (и не так уж долго это будет продолжаться, несмотря на горы софта, написанные на С/С++) сойдет на нет С++ — ый энтузиазм, и .NET или что там после нее более высокоуровневое (хоть многие и хаят и воспринимают как смехотворную эту мысль на сегодняшний день, но вполне возможно, что через N лет будут составлять программы совсем не программисты, а обычный подкованный в типа-UMLноподобной среде менеджер или вроде того и поддержка всего этого будет уделом узкого круга спецов). ПО эволюционирует, микрокоды, asm, ЯВУ, развитый фреймворк, интересно услышать мнеия от ув. ALL, что дальше?

Давайте опять воплотим в жизнь идею, что каждая домохозяйка может программировать,
как уже было в начале 90-х в Америке...

Аноним wrote:

> подкованный в типа-UMLноподобной среде менеджер или вроде того и
Как показала практика, программирование в GUI — только для типичных, массовых вещей, притом так, что один раз написал и
забыл, т.е. фактически не для профессиональных программистов.

Если и возродится это направление для профессионального программирования, то только на основе каких-то новых веяний
построения GUI-взаимодействия, а что это будет и будет ли вообще — гадать не имеет смысла. А пока — текстовые файлы.

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

E>То, что дальше, выделено жирным:

Гм.. Это какая-то модернизированная переделка. У классиков оно вот как:

Мама, каша, ложка, кошка, книжка, яркая обложка,
Буратино, Kарабас, ранец, школа, первый класс,
грязь в тетрадке, тройка, двойка, папа, крик, головомойка,
лето, труд, овин, солома, осень, сбор металлолома,
Пушкин, Дарвин, Кромвель, Ом, Робеспьер, Наполеон,
Менделеев, Герострат, бал прощальный, аттестат,
институт, экзамен, нервы, конкурс, лекции, курс первый,
тренировки, семинары, песни, танцы, тары-бары,
Прелесть! Нравится! Влечет... Сессия, весна, зачет,
стройотряд, жара, работа, культпоход, газета, фото,
общежитье, "пас" и "мизер", радиола, телевизор,
карандаш, рейсфедер, дом, пятый курс, проект, диплом,
отпуск, море, пароход, Крым, Ай-Петри, турпоход,
кульман, шеф, конец квартала, цех, участок, план по валу,
ЖСК, гараж, квартира, теща, сын, жена Эльвира,
детский сад, велосипед, карты, шахматы, сосед,
сердце, печень, лишний вес, внуки, пенсия собес,
юбилей, часы, награда, речи, памятник, ОГРАДА.

Впрочем, заканчивается так же, что неудивительно.

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

E>То, что дальше, выделено жирным:
E>

E>Колыбель. Пеленки. Плач.
E>Слово. Шаг. Простуда. Врач.
E>Беготня. Игрушки. Брат .
E>Двор. Качели. Детский сад.
E>Школа. Двойка. Тройка. Пять.
E>Мяч. Подножка. Гипс. Кровать.
E>Драка. Кровь. Разбитый нос.
E>Двор. Друзья. Тусовка. Форс.
E>Институт. Весна. Кусты.
E>Лето. Сессия. Хвосты.
E>Пиво. Водка. Джин со льдом.
E>Кофе. Сессия. Диплом .
E>Романтизм. Любовь. Звезда.
E>Руки. Губы. Ночь без сна.
E>Свадьба. Теща. Тесть. Капкан.
E>Ссора. Клуб. Друзья. Стакан.
E>Дом. Работа.
E>Дом. Семья.
E>Солнце. Лето.
E>Снег. Зима.
E>Сын. Пеленки. Колыбель.
E>Стресс. Любовница. Постель.
E>Бизнес. Деньги. План. Аврал.
E>Телевизор. Сериал.
E>Дача. Вишни. Кабачки.
E>Седина. Мигрень. Очки.
E>Внук. Пеленки. Колыбель.
E>Стресс. Давление. Постель.
E>Сердце. Почки. Кости. Врач.
E>Речи. Гроб. Прощанье. Плач

E>((c) неизвестен)

Однако как много я еще не попробовал. А ведь если здесь сидеть, то и не попробуешь.

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

E>>Колыбель. Пеленки. Плач.
E>>Слово. Шаг. Простуда. Врач.
E>>Беготня. Игрушки. Брат .
E>>Двор. Качели. Детский сад.
E>>Школа. Двойка. Тройка. Пять.
E>>Мяч. Подножка. Гипс. Кровать.
E>>Драка. Кровь. Разбитый нос.
E>>Двор. Друзья. Тусовка. Форс.
E>>Институт. Весна. Кусты.
E>>Лето. Сессия. Хвосты.
E>>Пиво. Водка. Джин со льдом.
E>>Кофе. Сессия. Диплом .
E>>Романтизм. Любовь. Звезда.
E>>Руки. Губы. Ночь без сна.
E>>Свадьба. Теща. Тесть. Капкан.
E>>Ссора. Клуб. Друзья. Стакан.
E>>Дом. Работа.
E>>Дом. Семья.
E>>Солнце. Лето.
E>>Снег. Зима.
E>>Сын. Пеленки. Колыбель.
E>>Стресс. Любовница. Постель.
E>>Бизнес. Деньги. План. Аврал.
E>>Телевизор. Сериал.
E>>Дача. Вишни. Кабачки.
E>>Седина. Мигрень. Очки.
E>>Внук. Пеленки. Колыбель.
E>>Стресс. Давление. Постель.
E>>Сердце. Почки. Кости. Врач.
E>>Речи. Гроб. Прощанье. Плач

VD>Однако как много я еще не попробовал.

На какой строчке застрял?

Здравствуйте, <Аноним>, Вы писали:
А>Да минусов дофига, и один из них — то, что ей, а вернее, С++, до сих пор пользуются. Честно скажу сразу — я не крутой спец, повидавший и написавший горы кода. Но, сдается мне (с), что в конце конце концов (и не так уж долго это будет продолжаться, несмотря на горы софта, написанные на С/С++) сойдет на нет С++ — ый энтузиазм, и .NET или что там после нее более высокоуровневое (хоть многие и хаят и воспринимают как смехотворную эту мысль на сегодняшний день, но вполне возможно, что через N лет будут составлять программы совсем не программисты, а обычный подкованный в типа-UMLноподобной среде менеджер или вроде того и поддержка всего этого будет уделом узкого круга спецов). ПО эволюционирует, микрокоды, asm, ЯВУ, развитый фреймворк, интересно услышать мнеия от ув. ALL, что дальше?

Ребята, ничего никуда не сойдет. Программирование — это не знание языков/технологий/библиотек. От этого, конечно, можно избавиться.
Нельзя избавиться (и еще очень долго будет нельзя) от умения формализовывать задачу.
Практика показывает, что среднестатистическая домохозяйка или менеджер не обладают достаточными навыками по формулировке своих требований в достаточно строгом для компьютера виде.
В некоторых узких задачах удается построить инструменты, которые позволяют обойтись без специальных знаний, хотя даже поиск в Гугле не всем дается одинаково легко.
В общем же случае проблема остается неразрешимой. Рисование прямоугольников ничуть не лучше написания операторов — это всего лишь еще один язык, который нужно изучать.

Sinclair wrote:

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

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

kan>Аноним wrote:

>> подкованный в типа-UMLноподобной среде менеджер или вроде того и
kan>Как показала практика, программирование в GUI — только для типичных, массовых вещей, притом так, что один раз написал и
kan>забыл, т.е. фактически не для профессиональных программистов.

kan>Если и возродится это направление для профессионального программирования, то только на основе каких-то новых веяний
kan>построения GUI-взаимодействия, а что это будет и будет ли вообще — гадать не имеет смысла. А пока — текстовые файлы.

Не согласная я Ну что за убожество эти текстовые файлы. Понятно что 40 лет назад, когда всё это начиналось, они были вполне приемлимы. Но нынешние-то вычислительные возможности позволяют представить программу куда как более эффективно. Ну вот вспомните когда вы последний раз читали с листа хоть сколько-либо большое в плане обьёма? Ведь компилятор разрывается каждый раз строя зависимости между этими несчастными файлами, компилируя кучу раз одно и то же и т.п. Да, я знаю что всё это обходится — precompiled headers, т.д. и т.п. — но согласитесь что это именно решение проблемы путём подставления подпорок.

Лично я думаю что программа должна быть представлена в виде набора файлов — но в каждом из них должен быть не только текст, но и уже откомпилированные куски, browse info, возможно — информация для Version Control System (поскольку ей самой очень тяжело разобраться в специфике вносимых изменений, а вот IDE могло бы ей и подсказать что к чему).
Ну и конечно же IDE должно предоставлять возможность просмотреть и отредактировать эту информацию самыми различными способами.

Вообщем, размечтался я

Left2 wrote:

>> > подкованный в типа-UMLноподобной среде менеджер или вроде того и
> kan>Как показала практика, программирование в GUI — только для типичных,
> массовых вещей, притом так, что один раз написал и
> kan>забыл, т.е. фактически не для профессиональных программистов.
>
> kan>Если и возродится это направление для профессионального
> программирования, то только на основе каких-то новых веяний
> kan>построения GUI-взаимодействия, а что это будет и будет ли вообще —
> гадать не имеет смысла. А пока — текстовые файлы.
>
> Не согласная я Ну что за убожество эти текстовые файлы. Понятно что 40
> лет назад, когда всё это начиналось, они были вполне приемлимы. Но
> нынешние-то вычислительные возможности позволяют представить программу
> куда как более эффективно. Ну вот вспомните когда вы последний раз
> читали с листа хоть сколько-либо большое в плане обьёма? Ведь компилятор
В смысле с листа? С бумажного имеешь в виду?

> разрывается каждый раз строя зависимости между этими несчастными
> файлами, компилируя кучу раз одно и то же и т.п. Да, я знаю что всё это
Это из-за нынешних вычислительных возможностей?

> обходится — precompiled headers, т.д. и т.п. — но согласитесь что это
> именно решение проблемы путём подставления подпорок.
Это на самом деле больше особенности конкретных языков, С/С++.

> Лично я думаю что программа должна быть представлена в виде набора
> файлов — но в каждом из них должен быть не только текст, но и уже
> откомпилированные куски, browse info, возможно — информация для Version
Ну как бы оно так и есть сейчас, просто это временные файлы, "невидимые" для программиста. А в систему контроля версий
это не имеет смысла пихать и уж тем более редактировать. Зачем хранить то, что можно сгенерить автоматически?

> Control System (поскольку ей самой очень тяжело разобраться в специфике
> вносимых изменений, а вот IDE могло бы ей и подсказать что к чему).
> Ну и конечно же IDE должно предоставлять возможность просмотреть и
> отредактировать эту информацию самыми различными способами.
Эм... Как сказать... Порой в процессе правки/отладки я так изменяю исходники, что IDE лучше забыть про этот ужас и
запустить банальный diff в конце, во время commit.
Тут достаточно делать diff по типу содержимомого файла, для C++ один алгоритм, для Java другой, для XML вообще совсем
всё по-другому. К тому же, svn это уже легко прикручивается без проблем, афаир. Так что тут не о чем мечтать, всё уже
работает.

> Вообщем, размечтался я
Вредно не мечтать.

Всё-таки, программирование — описание задачи на формальном языке, а значит ноги растут из математики. А в математике
тоже не особо принято графическое представление, оно лишь необходимо для объяснения материала, сделать наглядным. Но в
большинстве случаев при доказательстве чего-то нового — голые формулы.

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

L>Да, я знаю что всё это обходится — precompiled headers, т.д. и т.п. — но согласитесь что это именно решение проблемы путём подставления подпорок.
Это решается нормальными языками. Не нужно все по С++ мерять.

L>Лично я думаю что программа должна быть представлена в виде набора файлов —
L>но в каждом из них должен быть не только текст,
Зачем? Что это нам дает кроме гемороя в случае сбоев?
L>но и уже откомпилированные куски,
Нафиг не упало. Пусть они лежат гдето в локальном кеше. Ибо нефиг хранить то что и так можно сгенерировать.
А если еще вспомнить о ключах компиляции
L>browse info,
В локальный кешь ибо на раз пересчитывается.
L>возможно — информация для Version Control System (поскольку ей самой очень тяжело разобраться в специфике вносимых изменений, а вот IDE могло бы ей и подсказать что к чему).
Вот уж чего не нужно версионнику так это разбиратся в специфики изменений. Задача версионника хранить версии, а не разбираться в специфики каких то левых бинарников.
ИМХО идеальный версионник это SVN. Ничего лишнего только и умеет что хранить блобы но делает это хорошо.
А сливать изменения в случаи конфликтов могут скольугодно навороченные инструменты. От версионника требуется только представить 3 версии файла до изменений, после изменений и версию из репозитория.
L>Ну и конечно же IDE должно предоставлять возможность просмотреть и отредактировать эту информацию самыми различными способами.
Переходи на нормальные языки. Например для C# и Java доступны замечательные IDE типа VS + ReSharper и IDEA. Когда используешь такие инструменты текстовые файлы кажутся уже не такими уж и текстовыми.

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

WH>Вот уж чего не нужно версионнику так это разбиратся в специфики изменений. Задача версионника хранить версии, а не разбираться в специфики каких то левых бинарников.
WH>ИМХО идеальный версионник это SVN. Ничего лишнего только и умеет что хранить блобы но делает это хорошо.
WH>А сливать изменения в случаи конфликтов могут скольугодно навороченные инструменты. От версионника требуется только представить 3 версии файла до изменений, после изменений и версию из репозитория.

Это слишком простая модель, не работающая в случае повторных слияний (при такой модели изменения каждый раз придется сливать заново). В более сложную модель (Perforce, BitKeeper) как раз включается информация об истории предыдущих слияний и правок.

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

А>(хоть многие и хаят и воспринимают как смехотворную эту мысль на сегодняшний день, но вполне возможно, что через N лет будут составлять программы совсем не программисты, а обычный подкованный в типа-UMLноподобной среде менеджер или вроде того и поддержка всего этого будет уделом узкого круга спецов). ПО эволюционирует, микрокоды, asm, ЯВУ, развитый фреймворк, интересно услышать мнеия от ув. ALL, что дальше?

По-моему, я один раз здесь уже это писал, но скажу еще раз.

В середине 80-х я читал книжку, название уже не помню, подзаголовок был "...или Программирование без программистов". Это был перевод книги, изданной на западе в конце 70-х. Основная идея, думаю, понятна и без пересказа: чем более высокого уровня средства программирования используются, тем легче с ними работать и тем меньшая подготовка нужна для делания одних и тех же вещей, что в пределе позволяет обойтись вообще без программистов. В качестве основной иллюстрации там использовалась только что появившаяся система Query by Example — очень мощное средство, позволявшее найти, например, всех сотрудников мужского пола с зарплатой выше 2к и стажем меньше 3 лет, просто заполнив пару колонок таблицы, без необходимости (как это было до того) составить техзадание на написание модуля поиска таких сотрудников, согласовать это задание, ждать, пока у отдела программирования дойдут до него руки и т.д.

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

Почему Вы думаете, что нынешний этап чем-то отличается от предыдущих?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это слишком простая модель, не работающая в случае повторных слияний (при такой модели изменения каждый раз придется сливать заново). В более сложную модель (Perforce, BitKeeper) как раз включается информация об истории предыдущих слияний и правок.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это слишком простая модель, не работающая в случае повторных слияний (при такой модели изменения каждый раз придется сливать заново). В более сложную модель (Perforce, BitKeeper) как раз включается информация об истории предыдущих слияний и правок.

Откровенно говоря по жизни VSN-а за глаза хватает. Ну, да и Perforce тоже с текстом работает. Так что по сути Вольфхаунд прав. Бинарные данные сюда прелетать не стоит.

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

ПК>> В более сложную модель (Perforce, BitKeeper) как раз включается информация об истории предыдущих слияний и правок.

ГВ>Ты имеешь ввиду, что каждая последующая версия автоматом заново мержится? Просто интересно, как это выглядит.

Для простоты возьмем Мишину

Автор: mbergal
Дата: 24.08.06

картинку, и обратим внимание на следующие действия: отпочковывание Feature A и Feature B, заливка Feature A -> HEAD, merge HEAD -> Feature B, обратный merge Feature B -> HEAD.

Допустим, во время merge HEAD -> Feature B было разрешено много конфликтов, вызванных параллельными изменениями в Feature A и Feature B.

Теперь, после стабилизации Feature B, её нужно обратно заливать в HEAD.

Если изменения, пришедшие из Feature B рассматривать как полностью новые, то всё разрешение конфликтов придется делать заново.

Если хотя бы была сохранена история того, для каких версий конфликты уже были разрешены, и "в какую сторону", то при заливке Feature B -> HEAD нужно будет разрешать только новые конфликты, а файлы, которые в HEAD после merge HEAD -> Feature B не менялись, заново разрешать будет не нужно.

На кусочки HEAD -> Feature C -> C-merge и периодическую заливку Patches for release AB -> HEAD без сохранения истории слияний смотреть просто страшно.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Для простоты возьмем Мишину

Автор: mbergal
Дата: 24.08.06

картинку, и обратим внимание на следующие действия: отпочковывание Feature A и Feature B, заливка Feature A -> HEAD, merge HEAD -> Feature B, обратный merge Feature B -> HEAD.
ПК>

Допустим, во время merge HEAD -> Feature B было разрешено много конфликтов, вызванных параллельными изменениями в Feature A и Feature B.
ПК>

Теперь, после стабилизации Feature B, её нужно обратно заливать в HEAD.
ПК>

Если изменения, пришедшие из Feature B рассматривать как полностью новые, то всё разрешение конфликтов придется делать заново.
ПК>

Если хотя бы была сохранена история того, для каких версий конфликты уже были разрешены, и "в какую сторону", то при заливке Feature B -> HEAD нужно будет разрешать только новые конфликты, а файлы, которые в HEAD после merge HEAD -> Feature B не менялись, заново разрешать будет не нужно.

Или я чего-то не понимаю, или же у SVN с таким сценарием проблем не видно.
В SVN подобная штука делается таким образом:

начальная ревизия N;

отпочковывается ветка branches/A, отпочковывается ветка branches/B.

на ревизии (N+A) изменения из branches/A нужно поместить в trunk, выполняется команда:

cd ~/prj/trunk
svn merge -r N:N+A svn://repo/branches/A .

если теперь на (N+A+1) нужно взять эти же изменения из trunk в branches/B, то просто делаем:

cd ~/prj/branches/B
svn merge -r N:N+A+1 svn://repo/trunk .

дальше фигачатся изменения в branches/B.

на ревизии (N+B) (которая после N+A+1) нужно вернуть изменения из branches/B в trunk:

cd ~/prj/trunk
svn merge -r N+A+1:N+B svn://repo/branches/B .

если на момент времени (N+A2) (который после N+B) нужно в trunk залить изменения из branches/A, которые были сделаны после (N+A), то:

cd ~/prj/trunk
svn merge -r N+A:N+A2 svn://repo/branches/A .

таким образом получаем в trunk изменения из branches/B после N и изменения из branches/A.

если нужно взять изменения из trunk в branches/B, то делаем:

cd ~/prj/branches/B
svn merge -r N+A+1:HEAD svn://repo/trunk .

т.е. забираем из trunk все изменения, после того, как мы заливали в trunk из B в последний раз (в том числе и изменения из branches/A между ревизиями (N+A) и (N+A2)).

если нужно из branches/B опять залить в trunk (т.е. наступил момент N+B2), то:

cd ~/prj/trunk
svn merge -r N+B:HEAD svn://repo/branches/B

Естественно, здесь подразумевалось, что после каждого merge будет исправление конфликтов и последующий checkin.

Павел Кузнецов wrote:
> Это слишком простая модель, не работающая в случае повторных слияний
> (при такой модели изменения каждый раз придется сливать заново). В более
> сложную модель (Perforce, BitKeeper) как раз включается информация об
> истории предыдущих слияний и правок.
Для SVN есть SVK и svnmerge

kan>В смысле с листа? С бумажного имеешь в виду?

Ага, именно. Впрочем, можно ещё больше обобщить — имеется в виду чтение исходников не из "родной" IDE.

>> разрывается каждый раз строя зависимости между этими несчастными
>> файлами, компилируя кучу раз одно и то же и т.п. Да, я знаю что всё это
kan>Это из-за нынешних вычислительных возможностей?

А нафига по 100 раз делать одно и то же? Вычислительные возможности никогда лишними не бывают.

>> обходится — precompiled headers, т.д. и т.п. — но согласитесь что это
>> именно решение проблемы путём подставления подпорок.
kan>Это на самом деле больше особенности конкретных языков, С/С++.

Ну, в чём-то согласен, да.

>> Лично я думаю что программа должна быть представлена в виде набора
>> файлов — но в каждом из них должен быть не только текст, но и уже
>> откомпилированные куски, browse info, возможно — информация для Version
kan>Ну как бы оно так и есть сейчас, просто это временные файлы, "невидимые" для программиста. А в систему контроля версий
kan>это не имеет смысла пихать и уж тем более редактировать.
kan>Зачем хранить то, что можно сгенерить автоматически?
Затем чтобы не генерировать это по нескольку раз Хотя грань тут тонкая что стоит хранить и что не стоит.


kan>Эм... Как сказать... Порой в процессе правки/отладки я так изменяю исходники, что IDE лучше забыть про этот ужас и
kan>запустить банальный diff в конце, во время commit.
kan>Тут достаточно делать diff по типу содержимомого файла, для C++ один алгоритм, для Java другой, для XML вообще совсем
kan>всё по-другому. К тому же, svn это уже легко прикручивается без проблем, афаир. Так что тут не о чем мечтать, всё уже
kan>работает.

Э, нет — позвольте не согласиться. Неужто одного меня не устраивают текущие возможности даже того же SVN? Неужто только у меня возникает желание по конкретному куску кода (заметьте — не файлу, а именно куску кода, причём это может быть функция, класс или просто кусок кода внутри той же функции) — посмотреть откуда у него "растут ноги" — кто его написал, кто и как его менял, какие рефакторинги к нему применялись, как он переползал из файла в файл и т.п.? Очень сомневаюсь что такое можно вшить на уровне SVN. ИМХО, тут без поддержки IDE (с его "пониманием" языка) никак не справиться.

>> Вообщем, размечтался я
kan>Вредно не мечтать.


kan>Всё-таки, программирование — описание задачи на формальном языке, а значит ноги растут из математики. А в математике
kan>тоже не особо принято графическое представление, оно лишь необходимо для объяснения материала, сделать наглядным. Но в
kan>большинстве случаев при доказательстве чего-то нового — голые формулы.

Тоже согласен не в полной мере. Во-1 — программирование не чистая математика. Зачастую (я бы даже сказал — в большинстве случаев) оно ближе к инженерному делу, а уж там рисунки — в полный рост. Ну и во-2 — раньше просто не было возможности сделать удобно и красиво, те же CAD-системы радикально повысили производительность инженерного труда.