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

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

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

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

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

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

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

Некорректное сравнение у инженеров чертежи всегда были важны, часто даже важнее расчетов.

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

ZC>То получаеться что потребность в программистах(хороших, а не тех которые выучили 1-2 языка и думают что они уже могут все) действительно будет расти.
Еслиб хотябы один... А то многие и одного не знают, а думают что могут все...

Left2 wrote:

> kan>В смысле с листа? С бумажного имеешь в виду?
> Ага, именно. Впрочем, можно ещё больше обобщить — имеется в виду чтение
> исходников не из "родной" IDE.
Ну... Исходники mozilla... gds + far

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

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

> kan>Эм... Как сказать... Порой в процессе правки/отладки я так изменяю
> исходники, что IDE лучше забыть про этот ужас и
> kan>запустить банальный diff в конце, во время commit.
> kan>Тут достаточно делать diff по типу содержимомого файла, для C++ один
> алгоритм, для Java другой, для XML вообще совсем
> kan>всё по-другому. К тому же, svn это уже легко прикручивается без
> проблем, афаир. Так что тут не о чем мечтать, всё уже
> kan>работает.
> Э, нет — позвольте не согласиться. Неужто одного меня не устраивают
> текущие возможности даже того же SVN? Неужто только у меня возникает
> желание по конкретному куску кода (заметьте — не файлу, а именно куску
> кода, причём это может быть функция, класс или просто кусок кода внутри
> той же функции) — посмотреть откуда у него "растут ноги" — кто его
> написал, кто и как его менял, какие рефакторинги к нему применялись, как
> он переползал из файла в файл и т.п.? Очень сомневаюсь что такое можно
> вшить на уровне SVN. ИМХО, тут без поддержки IDE (с его "пониманием"
> языка) никак не справиться.
Ну, вообще говоря, атомарные коммиты позволяют отслеживать "переползания" между файлами. А svn blame отследить всё это
дело построчно. Однако, это относится к куску файла, как кучке строк, а не, скажем, к методу класса. В общем, только эта
проблема.

> kan>Всё-таки, программирование — описание задачи на формальном языке, а
> значит ноги растут из математики. А в математике
> kan>тоже не особо принято графическое представление, оно лишь необходимо
> для объяснения материала, сделать наглядным. Но в
> kan>большинстве случаев при доказательстве чего-то нового — голые формулы.
> Тоже согласен не в полной мере. Во-1 — программирование не чистая
> математика. Зачастую (я бы даже сказал — в большинстве случаев) оно
> ближе к инженерному делу, а уж там рисунки — в полный рост. Ну и во-2 —
> раньше просто не было возможности сделать удобно и красиво, те же
> CAD-системы радикально повысили производительность инженерного труда.
Э... Осознаёшь разницу между туннелем под Ла-Маншем и туннелем под SSH?

VladD2 wrote:

> Откровенно говоря по жизни VSN-а за глаза хватает. Ну, да и Perforce
После того, как мне VSN уничтожил файл (просто от того, что на диске с репозиторием место закончилось и он на месте
файла создал файл нулевой длины при простом коммите), я понял, что никогда им пользоваться по доброй воле не буду.

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

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

kan>Э... Осознаёшь разницу между туннелем под Ла-Маншем и туннелем под SSH?

Ну зачем же так грубо понимать аналогию-то...

Left2 wrote:
> Вот-вот, проблема — и ИМХО чем решать её на уровне SVN, проще дать
> возможность IDE "подсказывать", дабы SVN мог представлять себе историю
> изменений не на уровне файлов, а на уровне сущностей языка(языков)
> программирования.
IDEA умеет так делать — можно для выделенного участка посмотреть историю.

Я давно написал себе скрипт на Питоне (50 строчек), который делает то же
самое для SVN. Все достаточно просто — делаем blame (aka annotate),
находим нужные строки, смотрим версию когда они поменялись, делаем blame
от этой версии и т.д.

> kan>Э... Осознаёшь разницу между туннелем под Ла-Маншем и туннелем под SSH?
> Ну зачем же так грубо понимать аналогию-то...
Ну тем не менее. CADы в программировании совсем не прижились. Кто здесь
для программирования пользуется Together'ом, в котором можно рисовать
мышкой почти всю программу?

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

C>IDEA умеет так делать — можно для выделенного участка посмотреть историю.

C>Я давно написал себе скрипт на Питоне (50 строчек), который делает то же
C>самое для SVN. Все достаточно просто — делаем blame (aka annotate),
C>находим нужные строки, смотрим версию когда они поменялись, делаем blame
C>от этой версии и т.д.

это работает, если если к нему применяли переформатирование?
А если его перенесли из файла в файл? Может быть, не один раз?
Или всё вместе?

C>Ну тем не менее. CADы в программировании совсем не прижились. Кто здесь
C>для программирования пользуется Together'ом, в котором можно рисовать
C>мышкой почти всю программу?

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

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

kan>Тут достаточно делать diff по типу содержимомого файла, для C++ один алгоритм, для Java другой, для XML вообще совсем
kan>всё по-другому.

А какие тулзы умеют это делать?

Здравствуйте, yoriсk.kiev.ua, Вы писали:

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

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

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

А не подскажете имечко классика?

Дарней wrote:

> kan>Тут достаточно делать diff по типу содержимомого файла, для C++ один
> алгоритм, для Java другой, для XML вообще совсем
> kan>всё по-другому.
> А какие тулзы умеют это делать?
Я не разбирался подробно, но если поставить tortoisesvn там есть папочка Diff-Scripts, которая содержит скрипты для
MSWord вот такие:

    word = WScript.CreateObject("Word.Application");
// Open the new document
destination = word.Documents.Open(sNewDoc);

// Compare to the base document
destination.Compare(sBaseDoc);

Как я понял, можно прикручивть к любому mime-type соответствующий diff/merge-script.
Однако, проблема, как я понимаю, одна — наличие вменяемых C++/Java/XML/и т.д. утилит для сравнения и слияния...
текстовые файлы всё равно получаются лучше, видимо KISS таки работает.

Дарней wrote:
> C>Я давно написал себе скрипт на Питоне (50 строчек), который делает то же
> C>самое для SVN. Все достаточно просто — делаем blame (aka annotate),
> C>находим нужные строки, смотрим версию когда они поменялись, делаем blame
> C>от этой версии и т.д.
> это работает, если если к нему применяли переформатирование?
> А если его перенесли из файла в файл? Может быть, не один раз?
> Или всё вместе?
У меня просто отслеживается блок строк. Миграцию между файлами он
поймет, если это были операции с самим файлом (переименование и т.п.).
Как-то больше ничего особого и не нужно.

> C>Ну тем не менее. CADы в программировании совсем не прижились. Кто здесь
> C>для программирования пользуется Together'ом, в котором можно рисовать
> C>мышкой почти всю программу?
> нельзя там "программу нарисовать", можно только набросать черновик.
Можно. Рисуется диаграмма классов, диаграммы состояний и в комментарии к
ним добавляется код.

> А как средство исследования чужого кода он очень удобен, поскольку
> позволяет быстро получить приблизительную картину всей проги в целом
Тоже фигово. Только красивые прямоугольнички рисуют.

Дарней wrote:
> kan>Тут достаточно делать diff по типу содержимомого файла, для C++ один
> алгоритм, для Java другой, для XML вообще совсем
> kan>всё по-другому.
> А какие тулзы умеют это делать?
IDEA для Java, например. Она позволяет смотреть историю для определенных
элементов, при этом она понимает семантику исходного кода.

Для XML тоже что-то видел (ну еще бы, задача-то простая).

Для С++ вряд ли что-нибудь будет

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

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

LVV>А не подскажете имечко классика?

Кстати, поиск по Internet-у показал, что это два независимых произведения. Процитированное мной называется "Жизнь в 100 словах", а процитированное yoriсk.kiev.ua -- "Жизнь". И временами они соседствуют, как, например, здесь.

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

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

C>Для SVN есть SVK и svnmerge

Которые, очевидно, уже не вписываются в описанную ранее Wolfhound'ом модель.

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

C>У меня просто отслеживается блок строк. Миграцию между файлами он
C>поймет, если это были операции с самим файлом (переименование и т.п.).

то есть когда во время рефакторинга метод перемещается из класса в класс, то "след будет потерян"

C>Можно. Рисуется диаграмма классов, диаграммы состояний и в комментарии к
C>ним добавляется код.

теоретически — да, на практике это неудобно

C>Тоже фигово. Только красивые прямоугольнички рисуют.

это уж кому как. открыв книгу одни видят только "красивые буквы и картинки", другие — мысли за ними

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

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

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

Если я правильно понял происходящее, то здесь предполагается, что разработчик хранит информацию о том, когда, куда и что было залито. Вот это и есть огромная проблема. Особенно, когда появляется необходимость заливать отдельные файлы (hotfixes) а не все целиком, и когда ветки окончательно "встречаются" только спустя какое-то время, после того, как изменения проводились из одной в другую много раз опосредованно.

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

ПК>Если я правильно понял происходящее, то здесь предполагается, что разработчик хранит информацию о том, когда, куда и что было залито. Вот это и есть огромная проблема. Особенно, когда появляется необходимость заливать отдельные файлы (hotfixes) а не все целиком, и когда ветки окончательно "встречаются" только спустя какое-то время, после того, как изменения проводились из одной в другую много раз опосредованно.

Эта информация находится в истории репозитория.

Дарней wrote:
> C>У меня просто отслеживается блок строк. Миграцию между файлами он
> C>поймет, если это были операции с самим файлом (переименование и т.п.).
> то есть когда во время рефакторинга метод перемещается из класса в
> класс, то "след будет потерян"
Почему же, находим ревизию в которой потерялся след и смотрим какие еще
файлы поменялись. Автоматизировать сложно, но руками делается элементарно.

> C>Можно. Рисуется диаграмма классов, диаграммы состояний и в комментарии к
> C>ним добавляется код.
> теоретически — да, на практике это неудобно
Ну вот я об этом и говорю.

> C>Тоже фигово. Только красивые прямоугольнички рисуют.
> это уж кому как. открыв книгу одни видят только "красивые буквы и
> картинки", другие — мысли за ними
Я пробовал использовать Розу для анализа приложения в 30Мб кода на Java.
Получается фигово — диаграмму классов читать ничуть не проще, чем
смотреть код с нормальным навигатором по нему. Общую структуру в
мегадиаграмме не видно, а частные структуры проще смотреть в коде.

Естественно, я не говорю про случаи когда UML делается людьми, с
комментариями для целей изучения проекта.

Павел Кузнецов wrote:
> Особенно, когда появляется
> необходимость заливать отдельные файлы (hotfixes) а не все целиком, и
> когда ветки окончательно "встречаются" только спустя какое-то время,
> после того, как изменения проводились из одной в другую много раз
> опосредованно.
Тогда SVK Оно это умеет делать, для каждого merge'а создается GUID,
по которому осуществляется трэкинг. При этом не допускается повторное
наложение одних и тех же патчей.

Я у себя ее использую для оффлайновой работы дома. Зеркалю себе на ноут
нужную ветку и коммичу из дома в оффлайновую ветку. Когда прихожу на
работу — объединяю оффлайновую ветку с основной. Можно такой же механизм
и для обычной работы использовать.