Здравствуйте, 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-системы радикально повысили производительность инженерного труда.

Здравствуйте, 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,
по которому осуществляется трэкинг. При этом не допускается повторное
наложение одних и тех же патчей.

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

Cyberax wrote:

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

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

C>IDEA для Java, например. Она позволяет смотреть историю для определенных
C>элементов, при этом она понимает семантику исходного кода.

то есть можно например посмотреть историю некоторого класса, метода и так далее? интересно, какая там минимальная гранулярность?

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

kan>Я не разбирался подробно, но если поставить tortoisesvn там есть папочка Diff-Scripts, которая содержит скрипты для
kan>MSWord вот такие:
kan>

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

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

никогда не видел, чтобы эта фича работала в деле

Дарней wrote:
> C>IDEA для Java, например. Она позволяет смотреть историю для определенных
> C>элементов, при этом она понимает семантику исходного кода.
> то есть можно например посмотреть историю некоторого класса, метода и
> так далее? интересно, какая там минимальная гранулярность?
Да, берешь выделяешь метод и жмешь "View history".

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

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

Твои проблемы. Думаю, что если ошибка и была, то ее уже давно устранили.

ЗЫ

Надеюсь, что ты при этом не VSS-ом пользуешся. Так как он портит репозиторий при банальных проблемах в сети.

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

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

офтоп:
А ты сейчас в Москве обиташь?

VladD2 wrote:

> kan>После того, как мне VSN уничтожил файл (просто от того, что на диске
> с репозиторием место закончилось и он на месте файла создал файл нулевой
> длины при простом коммите), я понял, что никогда им пользоваться по
> доброй воле не буду.
> Твои проблемы. Думаю, что если ошибка и была, то ее уже давно устранили.
Ой, я имел в виду VSS от MS.

> ЗЫ
> Надеюсь, что ты при этом не VSS-ом пользуешся. Так как он портит
> репозиторий при банальных проблемах в сети.
SVN я использую. А кто такой VSN?

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

VD>офтоп:
VD>А ты сейчас в Москве обиташь?
Да. Но сейчас сильно занят. Как разберусь с делами заскочу в гости.

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

WH>Да. Но сейчас сильно занят. Как разберусь с делами заскочу в гости.

ОК. Ждем.

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

kan>Ой, я имел в виду VSS от MS.

Ясно.

kan>SVN я использую. А кто такой VSN?

Он и есть. Просто очепятка.

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

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

Вопрос в том, какой процент людей сможет понять этот новый, графический, язык. Люди не умеют формализовать проблему текстом.
Но кто сказал, что такой же процент будет и для графического способо формализации задачи ?

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

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

PE>Вопрос в том, какой процент людей сможет понять этот новый, графический, язык. Люди не умеют формализовать проблему текстом.
PE>Но кто сказал, что такой же процент будет и для графического способо формализации задачи ?

Неа, Люди не умеют формализовать задачу. Точка.

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

PE>>Вопрос в том, какой процент людей сможет понять этот новый, графический, язык. Люди не умеют формализовать проблему текстом.
PE>>Но кто сказал, что такой же процент будет и для графического способо формализации задачи ?

F>Неа, Люди не умеют формализовать задачу. Точка.

Программисты значит не люди ?

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

PE>>Вопрос в том, какой процент людей сможет понять этот новый, графический, язык. Люди не умеют формализовать проблему текстом.
PE>>Но кто сказал, что такой же процент будет и для графического способо формализации задачи ?

F>Неа, Люди не умеют формализовать задачу. Точка.

В своей области специалисты уже сейчас могут формализовать задачу при наличии нужных средств.
Собственно возможность генерации кода программы и выполнение этого же когда есть шаг к этой возможности.
Естественно что необходимость в обычных программистах никак не отпадет. Просто программисты будут заниматься другими делами.

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

PE>>>Вопрос в том, какой процент людей сможет понять этот новый, графический, язык. Люди не умеют формализовать проблему текстом.
PE>>>Но кто сказал, что такой же процент будет и для графического способо формализации задачи ?

F>>Неа, Люди не умеют формализовать задачу. Точка.

PE>Программисты значит не люди ?

Вот только не надо к словам придираться — я тоже могу сказать, что ты утверждаешь, будто программисты не умеют писать текстовые программы. Смотри выделенное.
Уточняем — "большинство людей" не могут четко абстрагироваться от своих проблем и формально выделить проблемную задачу и способы ее решения. Потому и остается программирование — делом программистов, а не домохозяек или секретарш. И это нормально. Кесарю — кесарево. У всех свои задачи.

А текст писать или кружочки в прямоуольниках рисовать — это уже вторично.

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

PE>Программисты значит не люди ?

А то?

Ты их видел? Ужас!

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

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

В результате возник SQL Помню, что давно читал в книгах (и не одной), что одним из преимуществ SQL является близость к английскому языку, и каждый бухгалтер теперь сможет не прибегая к помощи программиста набрать SQL запрос и получить то, что ему надо

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

F>Вот только не надо к словам придираться — я тоже могу сказать, что ты утверждаешь, будто программисты не умеют писать текстовые программы. Смотри выделенное.
F>Уточняем — "большинство людей" не могут четко абстрагироваться от своих проблем и формально выделить проблемную задачу и способы ее решения. Потому и остается программирование — делом программистов, а не домохозяек или секретарш. И это нормально. Кесарю — кесарево. У всех свои задачи.

Большинству вообще ничего не надо, к чему ты про домохозяек вспомнил ? Речь идет о специалистах-профессионалах, у которых основное занятие отличное от программирования.

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

Специалисты (а не домохозяйки) в своей области они разбираются на отлично. На данный момент вынуждены использовать всякие VB Script, Java script и тд. Но люди не хотят учить полноценный язык, поэтому я, например, получаю деньги за то, что пишу для них всякие готовые решения. Знали бы люди C# тот же, я бы работал в другом месте Однако чудес не бывает — знали бы они C#, значит не знали бы чтото другое.

Все потому, что мышление этих специалистов отличное от мышления программситов. И текстовые языки им не подходят.

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

Еще раз повторяю — программисты как класс не выродятся ни в коем случае. Но и пользователи продвинутся в программинг куда глубже чем сейчас.

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

PE>Еще раз повторяю — программисты как класс не выродятся ни в коем случае. Но и пользователи продвинутся в программинг куда глубже чем сейчас.

Но многим из тех, кто сейчас считает себя "программистами", придется поискать себе более подходящее занятие. Текущая нехватка программистов вызывается исключительно недостаточным развитием средств программирования, из-за чего "метод монгольских орд" применяется слишком часто.

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

Д>Но многим из тех, кто сейчас считает себя "программистами", придется поискать себе более подходящее занятие. Текущая нехватка программистов вызывается исключительно недостаточным развитием средств программирования, из-за чего "метод монгольских орд" применяется слишком часто.

Конечно. Человек, который считает себя программистом и который программисты — две большие разницы. Правда на данный момент эта граница пока еще размыта.

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

Д>Но многим из тех, кто сейчас считает себя "программистами", придется поискать себе более подходящее занятие. Текущая нехватка программистов вызывается исключительно недостаточным развитием средств программирования, из-за чего "метод монгольских орд" применяется слишком часто.

Мне кажется, что миф о том, что программисты всегда имеют недостаточной мощьности средства программирования, уже настолько стар, что не заслуживает доверия.

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

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

M>В результате возник SQL
Нашол чему радоватся. Совершенно уродский язык. Еслиб не пытались сделать для доможозяек то можно былобы сделать намного лучше.
M>Помню, что давно читал в книгах (и не одной), что одним из преимуществ SQL является близость к английскому языку, и каждый бухгалтер теперь сможет не прибегая к помощи программиста набрать SQL запрос и получить то, что ему надо
Практика показывает что ничерта они не могут. Всеравно программист нужен.
А чтобы хорошо работало нужен хороший программист.

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

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

и 1с у нас...

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

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

Ты наверно удивишься — любимый тобой миф о том, что "никакого технического прогресса нет", куда старше. Полагаю, его можно считать ровесником первых инструментов, которые изобрел человек. Как только один человек придумал копье, тут же нашелся другой, который сказал, что от этой штуки один вред и он лично кулаком может куда лучше. А те, кто пользуются копьями, просто лентяи и вообще не заслуживают высокого звания Первобытного Охотника.

E>Вот, например, ты в курсе, что найти хорошую строительную бригаду для выполнения ремонта в квартире -- это целая проблема, такая же, как найти хорошего программиста. И ладно если просто на деньги разведут, но сделают качественно. Более вероятно, что останешься и без денег, и без ремонта. И ведь нельзя сказать, что строительные инструменты находятся на недостаточной степени развития.

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

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

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

Д>Ты наверно удивишься — любимый тобой миф о том, что "никакого технического прогресса нет", куда старше.

Что-то я не помню, чтобы я подобные вещи утверждал. Не приписывай мне чужих фантазий.

Я всего лишь хочу сказать, что инструменты постоянно развиваются и становятся мощнее и мощнее, но разговоры об их недостаточной мощности никогда не останавливались. Так что дело не в инструментах, а в людях. Если человека не научить достигать цели с имеющимися средствами, то он никогда ее не будет достигать -- только будет постоянно требовать более совершенных инструментов. И оправдывать свои провалы их отсутствием.

Так что, речь лучше вести не о том, что "нет технического прогресса", а о том, что "я не могу использовать то, чем владею". Именно "я не могу", а не "инструмент недостаточной мощный".

E>>Вот, например, ты в курсе, что найти хорошую строительную бригаду для выполнения ремонта в квартире -- это целая проблема, такая же, как найти хорошего программиста. И ладно если просто на деньги разведут, но сделают качественно. Более вероятно, что останешься и без денег, и без ремонта. И ведь нельзя сказать, что строительные инструменты находятся на недостаточной степени развития.

Д>похоже, у тебя сегодня "день некорректных сравнений"
Д>здесь ты опять забыл об очень существенной разнице — у строителей нет (пока) инструментов, которые могут выполнять работу автоматически, без присмотра человека.

А у программистов есть?
Мне почему-то кажется, что когда make автоматически разруливает зависимости и управляет компиляцией, то это такая же малая автоматизация, как распиливание труб отопления болгаркой или поднятие грузов с помощью лебедки -- без человека ни то, ни другое невозможно. Make не сможет вместо меня придумать makefile.

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

Кстати о прорабах. Именно они и доказывают, "что рыба гниет с головы". Если тебе попадается бригада с мухлевщиком-прорабом, то уже не важно, какая квалификация и отношение к работе у остальных работников. Ты все равно останешься с носом. Зато у нормального прораба разгильдяев в бригаде нет, а те, кто есть, знают, что такое относиться к работе спустя рукава.

Ситуация в точности как в командах разработчиков. Люди важнее инструментов.

E>Я всего лишь хочу сказать, что инструменты постоянно развиваются и становятся мощнее и мощнее, но разговоры об их недостаточной мощности никогда не останавливались. Так что дело не в инструментах, а в людях. Если человека не научить достигать цели с имеющимися средствами, то он никогда ее не будет достигать -- только будет постоянно требовать более совершенных инструментов. И оправдывать свои провалы их отсутствием.

И, вообще говоря, как только мы создаем для себя инструменты, с помощью которых легко решаются текущие задачи, так сразу нужно приступать к решению более сложных. И наш новый инструмент оказывается морально устаревшим. Это процесс без остановки, который подталкивает сам себя (мощный инструмент открывает путь к решению более сложных задач, более сложные задачи делают существующие инструменты непригодными, появляются более мощные и т.д.). Поэтому наивно ожидать, что когда-нибудь появится "достаточно" мощный инструмент.

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

Имхо немаловажная, но не всем очевидная причина — слишком маленький размер существующих экранов. Для представления мало-мальски нетривиальной идеи в графическом виде, не повредит хотя бы двухметровое полотно И непременно с дигитайзером!

Есть такой графический язык, как LabVIEW. Идея — колоссальная, реализация, извиняюсь, шлак. Программа рисуется в виде схемы, узлы которой представляют из себя произвольные исполняющие сущности (подпрограммы, математические операции, интерфейсы к устройствам, и т.д.), а потоки данных между узлами представлены в виде проводов. Каждый исполняющий узел, в свою очередь, также является схемой (терминальные узлы — это, естественно, не что иное как вызовы функций dll, либо интринсики). Хочешь передать в подпрограмму структуру данных — свяжи провода в кабель, чтобы не загромождать схему. Язык создан, судя по всему, для электронщиков. Теоретически, на этом самом LabView можно напрограммировать всё что угодно, и под любую платформу (с соответствующим кодогенератором). На деле, даже при разрешении 1600x1200 на экране не хватает места. Естественно, скроллинг и большая глубина вложенности узлов, мягко говоря, не благоприятствуют восприятию "кода" человеком.

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

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

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

_>и 1с у нас...

Ага... есть такая тема.

Здравствуйте, Plutonia Experiment, Вы писали:
PE>В своей области специалисты уже сейчас могут формализовать задачу при наличии нужных средств.
Не встречал. Кроме ОЧЕНЬ редких исключений.

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

PE>Вопрос в том, какой процент людей сможет понять этот новый, графический, язык. Люди не умеют формализовать проблему текстом.
PE>Но кто сказал, что такой же процент будет и для графического способо формализации задачи ?
Люди в среднем очень плохо формализуют задачу в голове. Я же сказал — сам по себе язык почти ничего не стоит. Независимо от того, текстовый он, графический, или музыкальный. Люди предпочитают мыслить очень расплывчатыми категориями. Очень редкий специалист сразу точно скажет, чем отличается Клиент от Контрагента и что у них общего. После того, как он это для себя понял, нарисовать два прямоугольника или написать двадцать строк кода проблемы не представляет. Увы, как правило для этого и нужен программист — человек, способный выделить существенное и отбросить несушественное из этого пыльного чулана знаний специалиста.

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

Д> Текущая нехватка программистов вызывается исключительно недостаточным развитием средств программирования, из-за чего "метод монгольских орд" применяется слишком часто.

Уверяю тебя, программистов, умеющих работать по методу "маленьких, но очень эффективных команд морпехов", действительно, не хватает. И средства в этом деле играют, в лучшем случае, второстепенную роль.

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

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

B>Имхо немаловажная, но не всем очевидная причина — слишком маленький размер существующих экранов. Для представления мало-мальски нетривиальной идеи в графическом виде, не повредит хотя бы двухметровое полотно И непременно с дигитайзером!

Инженеры создают огромные комплекты сложных чертежей в Автокаде и вполне довольны.

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

B>Есть такой графический язык, как LabVIEW. Идея — колоссальная, реализация, извиняюсь, шлак. Программа рисуется в виде схемы, узлы которой представляют из себя произвольные исполняющие сущности (подпрограммы, математические операции, интерфейсы к устройствам, и т.д.), а потоки данных между узлами представлены в виде проводов. Каждый исполняющий узел, в свою очередь, также является схемой (терминальные узлы — это, естественно, не что иное как вызовы функций dll, либо интринсики). Хочешь передать в подпрограмму структуру данных — свяжи провода в кабель, чтобы не загромождать схему. Язык создан, судя по всему, для электронщиков. Теоретически, на этом самом LabView можно напрограммировать всё что угодно, и под любую платформу (с соответствующим кодогенератором). На деле, даже при разрешении 1600x1200 на экране не хватает места. Естественно, скроллинг и большая глубина вложенности узлов, мягко говоря, не благоприятствуют восприятию "кода" человеком.

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

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

PE>>В своей области специалисты уже сейчас могут формализовать задачу при наличии нужных средств.
S>Не встречал. Кроме ОЧЕНЬ редких исключений.

Я говорю про специалистов, которые инженеры а не лишь бы кто. Инженер — это предполагает что человек будет решать конкретную проблему, и перед эти ему надо формализовать задачу.

Раз у тебя есть исключения, то приведи пример и тех и других. Надо полагать у тебя есть минимум по одному примеру кто может формализовать, а кто не может.

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



B>Есть такой графический язык, как LabVIEW. Идея — колоссальная, реализация, извиняюсь, шлак. Программа рисуется в виде схемы, узлы которой представляют из себя произвольные исполняющие сущности (подпрограммы, математические операции, интерфейсы к устройствам, и т.д.), а потоки данных между узлами представлены в виде проводов. Каждый исполняющий узел, в свою очередь, также является схемой (терминальные узлы — это, естественно, не что иное как вызовы функций dll, либо интринсики). Хочешь передать в подпрограмму структуру данных — свяжи провода в кабель, чтобы не загромождать схему. Язык создан, судя по всему, для электронщиков...


Ага, видел этот LabVIEW, такая шняга. Теже электронщики предпочитают C/C++.

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

E>Что-то я не помню, чтобы я подобные вещи утверждал. Не приписывай мне чужих фантазий.

Если изобретают новые, более мощные средства — значит, мощности старых недостаточно. Потому что если всех устраивают существующие инструменты, то никто и не подумает создавать новые.
Так что одно из двух. Или недостаточность мощности инструментов — это не миф, или никакого технического прогресса в этой области нет. Определяйся уж, что ты хотел сказать.

E>Я всего лишь хочу сказать, что инструменты постоянно развиваются и становятся мощнее и мощнее, но разговоры об их недостаточной мощности никогда не останавливались. Так что дело не в инструментах, а в людях. Если человека не научить достигать цели с имеющимися средствами, то он никогда ее не будет достигать -- только будет постоянно требовать более совершенных инструментов. И оправдывать свои провалы их отсутствием.
E>Так что, речь лучше вести не о том, что "нет технического прогресса", а о том, что "я не могу использовать то, чем владею". Именно "я не могу", а не "инструмент недостаточной мощный".

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

E>А у программистов есть?
E>Мне почему-то кажется, что когда make автоматически разруливает зависимости и управляет компиляцией, то это такая же малая автоматизация, как распиливание труб отопления болгаркой или поднятие грузов с помощью лебедки -- без человека ни то, ни другое невозможно. Make не сможет вместо меня придумать makefile.

И снова — неверная аналогия. Написание мэйкфайла — это не распиливание труб, не поднятие грузов и не укладывание кирпича. Это — составление спецификации, где надо пилить трубы, куда поднимать грузы и как укладывать кирпич.

E>Ситуация в точности как в командах разработчиков. Люди важнее инструментов.

Не надо подменять утверждение "инструменты не важны" на "люди важнее инструментов".

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

PE>Я говорю про специалистов, которые инженеры а не лишь бы кто. Инженер — это предполагает что человек будет решать конкретную проблему, и перед эти ему надо формализовать задачу.

Большинство задач в области программирования — "грязные", т.е. такие, которые для формализации задачи требуют полного или частичного ее решения.

Здравствуйте, 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) неизвестен)

Уж не хочешь ли ты сказать, что текущий этап — "Сердце. Почки. Кости. Врач."?

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

E>>Что-то я не помню, чтобы я подобные вещи утверждал. Не приписывай мне чужих фантазий.

Д>Если изобретают новые, более мощные средства — значит, мощности старых недостаточно. Потому что если всех устраивают существующие инструменты, то никто и не подумает создавать новые.
Д>Так что одно из двух. Или недостаточность мощности инструментов — это не миф, или никакого технического прогресса в этой области нет. Определяйся уж, что ты хотел сказать.

Во-первых, это твои логические умозаключения, что либо одно, либо другое. Я ничего подобного не говорил.
Во-вторых, ты сказал

Автор: Дарней
Дата: 22.09.06

, что:

Текущая нехватка программистов вызывается исключительно недостаточным развитием средств программирования, из-за чего "метод монгольских орд" применяется слишком часто.

Так вот миф в том, что программистов не хватает из-за "исключетельно недостаточного развития" средств программирования. Я уже говорил, что инструменты всегда будут недостаточно мощными и наивно ожидать, что когда-нибудь они вообще таковыми станут. И программистов не хвает вовсе не из-за уровня развития инструментов, а по другим причинам.

E>>Так что, речь лучше вести не о том, что "нет технического прогресса", а о том, что "я не могу использовать то, чем владею". Именно "я не могу", а не "инструмент недостаточной мощный".

Д>Как ловко. Ты хотел сказать, что те, кто говорят о недостаточной мощности инструментов — это просто неудачники, которые не могут использовать существующие?

Ты пытаешься передергивать мои слова. Но что я хотел сказать, то и сказал. Действительно, те, кто постоянно жалуется на недостаточную мощность инструментов, вряд ли успешно решают свои текущие задачи. А уж удачники они или неудачники -- это уж они пускай сами решают. В конце-концов, посредственный программист, первый кандидат на вылет в случае сокращения штатов, может быть очень счастливым по жизни человеком, с хорошей семьей, с интересными увлечениями, с массой хороших друзей. И гораздо более удачливым по жизни, чем супер-пупер программист-трудоголик с аутично-шизоидным типом психики.

E>>Ситуация в точности как в командах разработчиков. Люди важнее инструментов.

Д>Не надо подменять утверждение "инструменты не важны" на "люди важнее инструментов".

А где я подменил?

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

RA>Уж не хочешь ли ты сказать, что текущий этап — "Сердце. Почки. Кости. Врач."?

Это уж у кого как. К тому же это является частью "врачебной тайны"

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

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

Ну наверное, с менеджером я погорячился. Назовем его аналитиком. Ну и UML зря упомянул, зачем срузу вцепляться именно в рисование прямоугольников. Сам не могу представить, какой в будущем может быть инструментарий создания ПО... Может, будет стандартизован интерфейс приложений и др., хотя на сегодняшний день это нереально. Наверное, нужно немного смягчить: программист будущего (ну по крайней мере прораммист бизнес-приложений) будет совсем не похож на сегодняшнего программиста: алгоритмическая подготовка, знание архитектуры, API платформы, исползование императивных/функциональных языков будут не актульны.
Пост, конечно, носил провокационный характер . Я понимаю, делать прогнозы в сфере IT даже на несколько лет вперед — дело неблагодарное, за примерами далеко ходить не надо: типа скепсиса IBM в отношении ПК и заявлений одного очень известного человека , что 640 КВ достаточно для любого приложения, AI (даже его подобие) так и не создан, несмотря на первоначальный оптимизм, что-то не так уж сильно японцы продвинулись в этом нправлении. Все-таки, кроме критики, мнений о том, "что дальше?" я вэтой ветке так и не услышал.

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

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

Может быть, все же увеличение потребности в программистах на протяжении 30 лет объясняется проникновением за это время информационных технологий во все большее число сфер человеческой деятельности, стремлением все большего числа компаний автоматизировать бизнес-процессы, документооборот и т.п.? И сколько бы потребовалось их (программистов) на сегодоняшний день при уровне технологий 30-летней давности?

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

P.S. Так какими же ты все-таки видишь в перспективе программирование и программистов?

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

E>Во-первых, это твои логические умозаключения, что либо одно, либо другое. Я ничего подобного не говорил.

Да, не говорил. Да, логические. Я просто стараюсь быть логичным, вот и всё
Просто причитать "ой, как всё вокруг плохо" — это совершенно неконструктивно.

E>И программистов не хвает вовсе не из-за уровня развития инструментов, а по другим причинам.

а по каким же?

E>Ты пытаешься передергивать мои слова.

В чём заключалось "передергивание"?

E>Но что я хотел сказать, то и сказал. Действительно, те, кто постоянно жалуется на недостаточную мощность инструментов, вряд ли успешно решают свои текущие задачи.

Среди них действительно есть такие, но далеко не 100%. Твое стремление свалить всех несогласных с тобой в одну кучу выглядит, мягко говоря, некорректным.
Твердо можно сказать только одно — среди тех, кто доволен существующими инструментами, никогда не будет ни одного действительно выдающегося разработчика.

Д>>Не надо подменять утверждение "инструменты не важны" на "люди важнее инструментов".
E>А где я подменил?

То есть ты согласен с тем, что развитие инструментов очень важно для уменьшения количества неквалифицированного труда?

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


RA>Ну наверное, с менеджером я погорячился. Назовем его аналитиком. Ну и UML зря упомянул, зачем срузу вцепляться именно в рисование прямоугольников. Сам не могу представить, какой в будущем может быть инструментарий создания ПО... Может, будет стандартизован интерфейс приложений и др., хотя на сегодняшний день это нереально. Наверное, нужно немного смягчить: программист будущего (ну по крайней мере прораммист бизнес-приложений) будет совсем не похож на сегодняшнего программиста: алгоритмическая подготовка, знание архитектуры, API платформы, исползование императивных/функциональных языков будут не актульны.

А что тогда будет актуально?
Может интуитивное понимание уравнения Шредингера? И умение конструировать не в жесткой а в вероятностной логике?

Хотя если спустится на землю, то просто по самой природе современное программирование проще и понятнее представляется именно в текстовом виде.

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


FR>А что тогда будет актуально?
FR>Может интуитивное понимание уравнения Шредингера? И умение конструировать не в жесткой а в вероятностной логике?

А я вообще ваше мнение хотел услышать

FR>Хотя если спустится на землю, то просто по самой природе современное программирование проще и понятнее представляется именно в текстовом виде.

Без пены, честно, я не программист-недоучка, который спит и видит, чтобы похоронили ненавистный C++ и иже с ним и можно было без проблем и геморроя лабать схемки и рисовать прямоугольники. Я говорил вообще-то не про современное.

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

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


FR>>А что тогда будет актуально?
FR>>Может интуитивное понимание уравнения Шредингера? И умение конструировать не в жесткой а в вероятностной логике?

RA> А я вообще ваше мнение хотел услышать

Мое мнение такое что будущее сейчас неопределенно и практически непредсказуемо
Например уже есть первые потуги создать квантовые вычислители, если это получится нас ждет коренной перелом, но может и не получится или получится лет через 50.

FR>>Хотя если спустится на землю, то просто по самой природе современное программирование проще и понятнее представляется именно в текстовом виде.

RA>Без пены, честно, я не программист-недоучка, который спит и видит, чтобы похоронили ненавистный C++ и иже с ним и можно было без проблем и геморроя лабать схемки и рисовать прямоугольники. Я говорил вообще-то не про современное.

А что граф. схемы, что C++, что наскель они в общем-то равномощны, вот те возможные будущие языки основанные на квантовом исчислении, уже птицы совсем другой породы. И что из этого может выйти предсказать так же легко, как после того, как появилась абстрактная машина тьюринга сразу же предсказать, что через 60 лет будут популярны C++, java и шарп

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

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

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

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

Дело в том, что одно из них — песня Гладкова на слова поэта — сейчас не вспомню какого... И это официально написано на сидюке с песней... Песня прекрасная — слышал несколько раз, но не могу ее найти чего-то в инете...

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

E>>Во-первых, это твои логические умозаключения, что либо одно, либо другое. Я ничего подобного не говорил.

Д>Да, не говорил. Да, логические. Я просто стараюсь быть логичным, вот и всё
Д>Просто причитать "ой, как всё вокруг плохо" — это совершенно неконструктивно.

У каждого своя логика. А когда ты пишешь "любимый тобой миф", то подразумевается уже не логика, а наличие фактов.
И я так же не говорил, что вокруг все плохо. Ты опять мне пытаешь приписать либо чужие слова, либо результаты каких-то своих логических построений.

E>>И программистов не хвает вовсе не из-за уровня развития инструментов, а по другим причинам.

Д>а по каким же?

Их много. Но сейчас я не готов озвучивать хотя бы часть из них. Слишком сложная тема.

E>>Ты пытаешься передергивать мои слова.

Д>В чём заключалось "передергивание"?

В том, что ты придал моим словам вот такой смысл:

Ты хотел сказать, что те, кто говорят о недостаточной мощности инструментов — это просто неудачники, которые не могут использовать существующие?

Я их неудачниками не обзывал.

Д>Твердо можно сказать только одно — среди тех, кто доволен существующими инструментами, никогда не будет ни одного действительно выдающегося разработчика.

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

Д>>>Не надо подменять утверждение "инструменты не важны" на "люди важнее инструментов".
E>>А где я подменил?

Д>То есть ты согласен с тем, что развитие инструментов очень важно для уменьшения количества неквалифицированного труда?

А этот тезис откуда возник?
Кроме того, даже если принять его на веру, он вовсе не обещает, что количество программистов сможет уменьшиться. Скорее, наоборот, возникнет столько новых задач, что на их решение потребуется еще большее количество квалифицированных программистов.

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

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

Я, кажется, упоминал в посте про поддержку. Многих ли ты видел в глаза разработчиков широко распространенных компиляторов?

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

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

И сколько, по твоему мнеию, нужно знать языков, чтобы быть хорошим программистом? (вопрос тоже философский)

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

FR>Мое мнение такое что будущее сейчас неопределенно и практически непредсказуемо
Пожалуй, я соглашусь с тобой

FR>А что граф. схемы, что C++, что наскель они в общем-то равномощны, вот те возможные будущие языки основанные на квантовом исчислении, уже птицы совсем другой породы. И что из этого может выйти предсказать так же легко, как после того, как появилась абстрактная машина тьюринга сразу же предсказать, что через 60 лет будут популярны C++, java и шарп
Ну речь идет все-таки о более высокоурвневых средствах, типа исползования подмножества естественного языка...

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


FR>>А что граф. схемы, что C++, что наскель они в общем-то равномощны, вот те возможные будущие языки основанные на квантовом исчислении, уже птицы совсем другой породы. И что из этого может выйти предсказать так же легко, как после того, как появилась абстрактная машина тьюринга сразу же предсказать, что через 60 лет будут популярны C++, java и шарп
RA>Ну речь идет все-таки о более высокоурвневых средствах, типа исползования подмножества естественного языка...

Здесь все еще более туманно
Речь о таких средствах уже идет как минимум 40 лет, а сдвигов никаких.

Да если даже такое и появится вполне может оказатся что существующие сейчас компьютерные языки гораздо более эффективный инструмент программирования чем подмножества естественного языка.

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

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

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

RA>И сколько, по твоему мнеию, нужно знать языков, чтобы быть хорошим программистом? (вопрос тоже философский)

Это зависит от того что понимать под словом "знать"

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

E>И я так же не говорил, что вокруг все плохо. Ты опять мне пытаешь приписать либо чужие слова, либо результаты каких-то своих логических построений.

А с чего ты взял, что это про тебя?

E>Их много. Но сейчас я не готов озвучивать хотя бы часть из них. Слишком сложная тема.

Ясно. А я думал, у тебя есть какие-то мысли, если ты с такой уверенностью об этом говоришь.

E>Я их неудачниками не обзывал.

Если говоришь "А", то надо говорить и "Б". Говорить "ничего такого я не имел в виду" — это просто лукавство.

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

цитирую:

Действительно, те, кто постоянно жалуется на недостаточную мощность инструментов, вряд ли успешно решают свои текущие задачи.

Как иначе это следует понимать?

E>А этот тезис откуда возник?

я с самого начала про это говорил.

E>Кроме того, даже если принять его на веру, он вовсе не обещает, что количество программистов сможет уменьшиться. Скорее, наоборот, возникнет столько новых задач, что на их решение потребуется еще большее количество квалифицированных программистов.

Квалифицированных — да. Но сейчас процент таковых от общего числа "программистов" очень невелик.

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

E>>И я так же не говорил, что вокруг все плохо. Ты опять мне пытаешь приписать либо чужие слова, либо результаты каких-то своих логических построений.

Д>А с чего ты взял, что это про тебя?

Из контекста, мы же выясняли, кто и что сказал.

E>>Их много. Но сейчас я не готов озвучивать хотя бы часть из них. Слишком сложная тема.

Д>Ясно. А я думал, у тебя есть какие-то мысли, если ты с такой уверенностью об этом говоришь.

Мысли есть, только оформлять их в письменном виде я не готов.

E>>Я их неудачниками не обзывал.

Д>Если говоришь "А", то надо говорить и "Б". Говорить "ничего такого я не имел в виду" — это просто лукавство.

Ты опять мне пытаешься приписать какие-то свои измышления. Ты воспринял мои слова таким образом -- это твои проблемы.

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

Д>цитирую:
Д>

Д>Действительно, те, кто постоянно жалуется на недостаточную мощность инструментов, вряд ли успешно решают свои текущие задачи.

Д>Как иначе это следует понимать?

Буквально. И обрати внимание, про степень довольства уровнем развития инструментов у тех, кто свои задачи успешно решает, не сказано ни слова.

Д>Квалифицированных — да. Но сейчас процент таковых от общего числа "программистов" очень невелик.

У меня на этот счет другое мнение, и оно сильно отличается от твоего.

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

E>Из контекста, мы же выясняли, кто и что сказал.

ход логических построений неясен

E>Мысли есть, только оформлять их в письменном виде я не готов.

иными словами, их просто нет

E>Ты опять мне пытаешься приписать какие-то свои измышления. Ты воспринял мои слова таким образом -- это твои проблемы.

Если ты пытаешься донести свою мысль до окружающих и они тебя не понимают, то проблемы таки у тебя.

Д>>Квалифицированных — да. Но сейчас процент таковых от общего числа "программистов" очень невелик.

E>У меня на этот счет другое мнение, и оно сильно отличается от твоего.

значит, у нас очень разная планка для понятия "квалифицированный"

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

E>>Мысли есть, только оформлять их в письменном виде я не готов.

Д>иными словами, их просто нет

Ой, урыл-таки. Боюсь, боюсь. Не бей меня, о мен, целый год посещающий "качалку"!

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

Но если ты уж такой Фома Неверующий, или же пытаешься поймать меня на "слабо", то можешь сам, например, подумать о таком законе рынка, как "Спрос рождает предложение". Сегодня спрос на программистов намного превышает предложение, но так было (имхо, и будет) не всегда. Например, когда я закончил универ в 95-м, у нас в городе найти нормальную работу программиста было не просто. Во многих местах требовался опыт работы не менее двух лет, поэтому часть выпускников вообще не имела шансов в эти места попасть. До этого, в 90-м году, наше КБ системного программирования (одно из крупнейших в Союзе) насчитывало 1200 только программистов. А с 92-го начался кризис отрасли и к 97-98-му годам в КБ осталось всего 250 человек, включая обслуживающий персонал. Спроса на программистов не было, поскольку из-за экономической ситуации в стране мало кто мог позволить себе заказывать ПО. А разные бухгалтерии, кадры и склады клепали и внедряли небольшие конторки, в которых работало два-три толковых программиста и пристроится к ним было не так просто. Можно еще вспомнить крах дот-комов 2001-го года. Когда оффшорные шараги, только-только поднявшие у нас голову, были вынуждены прекратить прием новых сотрудников, органичить заработные платы и даже пойти на увольнение части сотрудников. Это примеры падения спроса.

Сейчас ситуация, когда благодоря процветанию оффшора спрос на программистов стабильно превышает предложение. Наша система образования не может поймать конъюктуру рынка и перестроится на подготовку большого числа программистов. Поэтому даже мало чего умеющие выпускники ВУЗ-ов без проблем получают работу, даже если лучше было бы части из них вообще программированием не заниматься. А дефицит программистов столь актуален.

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

Вот такая, вот, например, мысль есть по этому поводу. Есть и другие.

E>>Ты опять мне пытаешься приписать какие-то свои измышления. Ты воспринял мои слова таким образом -- это твои проблемы.

Д>Если ты пытаешься донести свою мысль до окружающих и они тебя не понимают, то проблемы таки у тебя.

Во-первых, мне фиолетово.
Во-вторых, оценки, которые ставят моим сообщениям в данном разговоре, говорят, что проблем-таки нет.

Д>>>Квалифицированных — да. Но сейчас процент таковых от общего числа "программистов" очень невелик.

E>>У меня на этот счет другое мнение, и оно сильно отличается от твоего.

Д>значит, у нас очень разная планка для понятия "квалифицированный"

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

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

Для начала, не переходи на личности. Попытка дискредитировать оппонента — это, скорее всего, признак того что тебе больше нечего сказать. К тому же это просто запрещено правилами форума, насколько я помню.
Во вторых, ты смотришь на проблему с точки зрения рынка труда в одной отдельной стране, емкость внутреннего рынка в которой крайне мала, а ее роль на офшорном рынке — очень низка. Именно поэтому у нас так сильно скачет спрос. Но в других странах он намного стабильнее и совсем не торопится снижаться, если не считать лопнувшего мыльного пузыря доткомов.
Попробуй поставить вопрос по другому — а почему программистов так сильно не хватает в США, к примеру? Настолько, что они импортируют программистов из других стран? В условиях, когда платить иммигрантам намного меньше местных жителей не позволяет визовая политика, а сам процесс получения визы неимоверно сложен?

E>Во-вторых, оценки, которые ставят моим сообщениям в данном разговоре, говорят, что проблем-таки нет.

Они говорят только о том, что на форуме есть много людей, которые думают так же как ты. "Power of Marginal", не забыл?

E>Скорее это означает, что я вижу причины этой ситуации с дефицитом программистов совсем не в области "квалификации" программистов.

Ага. А в чем конкретно, ты конечно не скажешь, потому что на это есть сто десять причин, и так далее. Это я уже слышал.

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

E>Но все это благодоря тому, что в развитых западных странах есть подходящие экономические условия, которые позволяют рынку ПО развиваться. А уровень расходов на тамошних программистов настолько высок, что оффшор плотно обосновался в странах треьего мира, с гораздо более дешовой рабочей силой (к коим, к сожалению, относится Россия (за исключением, разве что, Москвы и Питера), Белоруссия, Украина и другие бывшие Совецкие республики).

Интересно, что порой самым существенным является, пожалуй, не уровень расходов, а просто элементарное отсутствие квалифицированных кадров. А расходы еще большой вопрос, как выше: издержки на удаленную/распределенную работу + снижение эффективности запросто могут перекрывать разницу в зарплатах, скажем, между Айовой и Питерром.

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

E>Но все это благодоря тому, что в развитых западных странах есть подходящие экономические условия, которые позволяют рынку ПО развиваться. А уровень расходов на тамошних программистов настолько высок, что оффшор плотно обосновался в странах треьего мира.

Это не так. Дело не в дешевизне. Дело в банальной нехватке специалистов. С момента кризиса произошло несколько событий, результом которых и является сегодняшнее положение вещей:

— Начиная с 2001 года в коледжы США на компьютерные специальности поступило в 5-10 раз меньше студентов, чем в предыдущие года. Как раз с прошлого года промышленность стала получать в разы меньше молодых специалистов.
— Квота на иностранных специалистов сократилась до своей предбумовой величины и её увеличение осложняется, как мне кажется, в том числе и по причинам, связанным с 11 сентября.
— Было заморожено большинство новых проектов. Так долго продолжаться не могло и год-полтора назад их начали активно размораживать.
— За пять с лишним лет программное обеспечение устарело, появились новые технологии и сегодня многие конторы занимаются обновлением своих систем (сегодня полно предложений для дотнетчиков с опытом MFC).
— Необходимость в инженерах-программистах растёт просто из-за банального развития прогресса.

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

ПК>Интересно, что порой самым существенным является, пожалуй, не уровень расходов, а просто элементарное отсутствие квалифицированных кадров.

Точно? А вы попробуйте предложить $150k-$200k/y, может квалифицированные кадры сразу найдутся?

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

ПК>> Интересно, что порой самым существенным является, пожалуй, не уровень расходов, а просто элементарное отсутствие квалифицированных кадров.

IT> Точно? А вы попробуйте предложить $150k-$200k/y, может квалифицированные кадры сразу найдутся?

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

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

[skip]

А в Россию не тянет?

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

IT>- Начиная с 2001 года в коледжы США на компьютерные специальности поступило в 5-10 раз меньше студентов, чем в предыдущие года. Как раз с прошлого года промышленность стала получать в разы меньше молодых специалистов.
IT>- Квота на иностранных специалистов сократилась до своей предбумовой величины и её увеличение осложняется, как мне кажется, в том числе и по причинам, связанным с 11 сентября.
IT>- Было заморожено большинство новых проектов. Так долго продолжаться не могло и год-полтора назад их начали активно размораживать.
IT>- За пять с лишним лет программное обеспечение устарело, появились новые технологии и сегодня многие конторы занимаются обновлением своих систем (сегодня полно предложений для дотнетчиков с опытом MFC).
IT>- Необходимость в инженерах-программистах растёт просто из-за банального развития прогресса.

Игорь, я не в курсе состояния рынка программистов в США, поэтому приму твои слова на веру.
Однако, имхо, они относятся ко второй части моего высказывания, про процветание офшоров. Для меня же более важно, что текущее экономическое состояние США и стран Западной Европы таково, что их предприятия в состоянии оплачивать производство ПО (любого типа, начиная от документооборота, заканчивая встраиваемыми системами). В отличии от того, что было, например, в годы распада Союза. Да и сейчас экономическое состояние России или Белоруссии не способствует массовому производству ПО для внутреннего рынка.

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

E>>Но все это благодоря тому, что в развитых западных странах есть подходящие экономические условия, которые позволяют рынку ПО развиваться. А уровень расходов на тамошних программистов настолько высок, что оффшор плотно обосновался в странах треьего мира, с гораздо более дешовой рабочей силой (к коим, к сожалению, относится Россия (за исключением, разве что, Москвы и Питера), Белоруссия, Украина и другие бывшие Совецкие республики).

ПК>Интересно, что порой самым существенным является, пожалуй, не уровень расходов, а просто элементарное отсутствие квалифицированных кадров. А расходы еще большой вопрос, как выше: издержки на удаленную/распределенную работу + снижение эффективности запросто могут перекрывать разницу в зарплатах, скажем, между Айовой и Питерром.

Зато перемещение разработки из Москвы в Белоруссию реально снижает расходы на производство ПО

Дополнение: без связи с карьерой, работой. Просто по-человечески. Наверное, хорошо там, где нас нет Не был там, интересно послушать...

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

RA>А в Россию не тянет?

Сложный вопрос. Тянуть может и тянет, но вряд ли вытянет

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

IT>Здравствуйте, registered anonymous, Вы писали:

RA>>А в Россию не тянет?

IT>Сложный вопрос. Тянуть может и тянет, но вряд ли вытянет

мда... грусновато как-то...

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

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

IT>>Здравствуйте, registered anonymous, Вы писали:

RA>>>А в Россию не тянет?

IT>>Сложный вопрос. Тянуть может и тянет, но вряд ли вытянет

RA>мда... грустновато как-то...

опечатался, честно

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

ПК>Интересно, что порой самым существенным является, пожалуй, не уровень расходов, а просто элементарное отсутствие квалифицированных кадров. А расходы еще большой вопрос, как выше: издержки на удаленную/распределенную работу + снижение эффективности запросто могут перекрывать разницу в зарплатах, скажем, между Айовой и Питерром.

Паша, а о команде какого размера идет речь в твоем случае?

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

RA>Дополнение: без связи с карьерой, работой. Просто по-человечески.

Без связи как раз вряд ли получится.

RA>Наверное, хорошо там, где нас нет Не был там, интересно послушать...

Тут дело такое. Америка очень разная и в зависимости от того что ты хочешь услышать можно рассказать совершенно разные вещи, от щенячего восторга до гневного разоблачения

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

IT>Здравствуйте, registered anonymous, Вы писали:

RA>>Дополнение: без связи с карьерой, работой. Просто по-человечески.

IT>Без связи как раз вряд ли получится.

RA>>Наверное, хорошо там, где нас нет Не был там, интересно послушать...

IT>Тут дело такое. Америка очень разная и в зависимости от того что ты хочешь услышать можно рассказать совершенно разные вещи, от щенячего восторга до гневного разоблачения

Ну по большому счету? Хотя величина счета тоже, наверное, разная для каждого...

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

IT>>Тут дело такое. Америка очень разная и в зависимости от того что ты хочешь услышать можно рассказать совершенно разные вещи, от щенячего восторга до гневного разоблачения

RA>Ну по большому счету? Хотя величина счета тоже, наверное, разная для каждого...

По большому счёту здесь мой дом. Я тут живу и работаю, дети учатся, жена получает свой MBA, у меня куча друзей и куча мелких проблем. Всё как обычно

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

IT>Здравствуйте, registered anonymous, Вы писали:

IT>>>Тут дело такое. Америка очень разная и в зависимости от того что ты хочешь услышать можно рассказать совершенно разные вещи, от щенячего восторга до гневного разоблачения

RA>>Ну по большому счету? Хотя величина счета тоже, наверное, разная для каждого...

IT>По большому счёту здесь мой дом. Я тут живу и работаю, дети учатся, жена получает свой MBA, у меня куча друзей и куча мелких проблем. Всё как обычно

Ок, без всякой иронии и подвоха, рад за тебя

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

FR>Например уже есть первые потуги создать квантовые вычислители, если это получится нас ждет коренной перелом, но может и не получится или получится лет через 50.

Люди до сих пор параллельное вычисление не смогли толком использовать, а ты говоришь — квантовые вычислители. Когда (если) они появятся, то будут долго занимать очень узкую нишу специализированных число-дробителей. На рынок массового ПО это не повлияет никак.

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

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

FR>>Например уже есть первые потуги создать квантовые вычислители, если это получится нас ждет коренной перелом, но может и не получится или получится лет через 50.

Д>Люди до сих пор параллельное вычисление не смогли толком использовать, а ты говоришь — квантовые вычислители. Когда (если) они появятся, то будут долго занимать очень узкую нишу специализированных число-дробителей. На рынок массового ПО это не повлияет никак.

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

Здравствуйте, Plutonia Experiment, Вы писали:
PE>Я говорю про специалистов, которые инженеры а не лишь бы кто. Инженер — это предполагает что человек будет решать конкретную проблему, и перед эти ему надо формализовать задачу.
Инженер — птица очень редкая. Их единицы. Подавляющее большинство людей не имеют нормальной инженерной подготовки. Поэтому они нанимают инженеров. В том числе и software engineer.
PE>Раз у тебя есть исключения, то приведи пример и тех и других. Надо полагать у тебя есть минимум по одному примеру кто может формализовать, а кто не может.
У меня есть около, наверное, двухсот примеров людей, которые не могли мало-мальски формально оговорить задачу. Мне, если честно, лень перечислять конкретные проблемы в постановке.

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

PE>>Я говорю про специалистов, которые инженеры а не лишь бы кто. Инженер — это предполагает что человек будет решать конкретную проблему, и перед эти ему надо формализовать задачу.
S>Инженер — птица очень редкая. Их единицы. Подавляющее большинство людей не имеют нормальной инженерной подготовки. Поэтому они нанимают инженеров. В том числе и software engineer.

Инженер не такая и редкая птица. Кроме них есть люди, занимающиесся научной деятельностью (естественно связаная с техникой).
Про гуманитариев речь не идет.

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

PE>Инженер не такая и редкая птица. Кроме них есть люди, занимающиесся научной деятельностью (естественно связаная с техникой).
Гы-гы. Этих людей — доли процента. Напомню, что речь идет об общем снижении потребности в программистах. Обосновывать его тем, что 0.05% людей имеют нужную математическую подготовку, чтобы самостоятельно выполнить формализацию задачи, мягко говоря несерьезно.
PE>Про гуманитариев речь не идет.
Боюсь тебя разочаровать, но подавляющее большинство людей — именно гуманитарии. По складу мышления, естественно, а не по диплому.

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

S>Гы-гы. Этих людей — доли процента. Напомню, что речь идет об общем снижении потребности в программистах. Обосновывать его тем, что 0.05% людей имеют нужную математическую подготовку, чтобы самостоятельно выполнить формализацию задачи, мягко говоря несерьезно.

В Минске 1700000 жителей, из них взрослых, трудоспособного возраста примерно 1000000. По твоей оценке выходит программистов! только 500 человек. Маловато, несколько, тебе не кажется ?

Если суммировать все самые известные EPAM, IBA, SamSolutions уже получается примерно в два-три раза больеш твоей оценки Кроме этого есть еще программисты во множесте небольших фирм коих не счесть, во всех институтах, почти во всех государственнх предприятиях.
Кроме них есть люди занимающиеся научной деятельностью в различнх направлениях — физика, микроэлектроника, математика, электроника, схемотехника, микропроцесоры, микроконтроллеры, сопромат и тд и тд и тд. А есть еще и множество инженеров в этих же областях. А есть еще Академия Наук — там только в институтах физики, математики людей болье чем ты привел.

Суммарно, из того что я перечислил, по минску моя оценка около 10% от трудоспособного населения. Будь добр, опровергни аргуменатами, а не цифрами взятыми с потолка.


S>Боюсь тебя разочаровать, но подавляющее большинство людей — именно гуманитарии. По складу мышления, естественно, а не по диплому.

Забудь про образование. Я говорю про работу на должности инженера. Это немного разное.

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


PE>Суммарно, из того что я перечислил, по минску моя оценка около 10% от трудоспособного населения. Будь добр, опровергни аргуменатами, а не цифрами взятыми с потолка.

Минск как столица притягивает кучу специалистов из провинций, так что как минимум надо брать хотя бы треть или даже половину населения Белоруссии и считать от этого

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

PE>>Суммарно, из того что я перечислил, по минску моя оценка около 10% от трудоспособного населения. Будь добр, опровергни аргуменатами, а не цифрами взятыми с потолка.

FR>Минск как столица притягивает кучу специалистов из провинций, так что как минимум надо брать хотя бы треть или даже половину населения Белоруссии и считать от этого

Будь по твоему. Половина населения — 5 000 000. Пять миллионов. Оценка Синклера — 0.05%. Итого, выходит число 2500.
Чудеса, одних программистов только в Минске больше. Есть еще такие города как Гродно, Гомель, Брест, Могилев, Витебск.
Там наверное ни программистов, ни инженеров ? А уж научной деятельностью вообще никто не занимается

Очевидно, что в крупные города (а не в столицу как ты утверждаешь) едут люди. Но это всякие профессии, а не только технари.

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

S>Практика показывает, что среднестатистическая домохозяйка или менеджер не обладают достаточными навыками по формулировке своих требований в

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

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

E>Да и сейчас экономическое состояние России или Белоруссии не способствует массовому производству ПО для внутреннего рынка.

Большая часть моих знакомых программистов работает на внутренний рынок. Субъективно конечно, но официальных оценок соотношения внутреннего и внешнего рынка я не видел. Замечу лишь, что кризис доткомов на IT в России практически не отразился, дефолт 98 года был неизмеримо больнее.

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

AVK>Большая часть моих знакомых программистов работает на внутренний рынок. Субъективно конечно, но официальных оценок соотношения внутреннего и внешнего рынка я не видел. Замечу лишь, что кризис доткомов на IT в России практически не отразился, дефолт 98 года был неизмеримо больнее.

>Замечу лишь, что кризис доткомов на IT в России практически не отразился
да практически не на чем было отражаться (имхо), по крайней мере в связи с доткомами...

>дефолт 98 года был неизмеримо больнее.
еще и как больнее, и IT в этой связи — мизер