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

E>Основная сложность в разработке ПО -- это получить работающий продукт. Вообще. Еще сложнее получить его вовремя и в рамках бюджета.

Ну это и ежу понятно. Но задачу надо все-таки деструктурировать.

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

То же самое можно про процессоры сказать. Хоть их быстродействие и повысилось на порядки, аналогичного прироста в скорости работы ПК не наблюдается, скорее даже наоборот. Даже на кассетном спектруме среда разработки грузилась быстрее, чем сейчас на моем компе

Кё>>Всё это и будет являться работой программиста — сделать требования чёткими. А не просчитывать заранее и не ставить эксперименты с силой импульсов, чтобы потом полученные числа подставить в алгоритм.

E>Так, имхо, именно этим программисты сейчас и занимаются.

Нет, они по большей части эти требования реализуют — пишут код.

E>А постановка экспериментов подстановка чисел в алгоритм -- это ты о чем?

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

Кё>>Плохо решается. Можно лучше.

E>Извини, но здесь мне хочется вспомнить: "Ба! Вы не любите кошек? Вы просто не умеете их готовить!" ((C) народный фольклер).
E>Конечно же все улучшается. Но гораздо медленнее, чем нам хотелось бы. И принципиальных прорывов здесь, имхо, не будет. Разве что заменят программирование чем-то другим.

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

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

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


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

Кё>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.

И кто мешает написать функцию:

ПоднятьРуку( Правую )

или вызвать метод:

Человек.Конечности.Рука.Поднять( ... )

Дело в том, что инструкции вида:

"направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц".

— всё равно придётся выполнять. Законы природы не обманешь. Если тебе нужно, что бы поднялась правая рука и на 15 градусов в бок — это всё равно придётся описывать или — расплатой будет то, что операции будут слабоуправляемы (если большинство параметров зашиты внутри).
Поскольку компьютер сам не в состоянии придумать, что нужно делать, то абсолютно всё равно в каком виде ему отдавать команды — в императивном ли, в декларативном ли — всё равно где то придётся их описывать. Кто, где и как за тебя опишет в любой программе — что конкретно должно означать "Поднять руку"?
Вот потому декларативное программирование — как и функциональное — хорошо работает, пока речь идёт о известных (т.е. реализованных в библиотеке) вещах — вроде сортировки или foreach. А как только начинается практическая работа — как то отдача чётких инструкций оборудованию — всякая красота или пропадает (у неумелого разработчика) — или определяется тем, какую архитектуру для описания своих задач придумает разработчик.

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


E>>Если же говорить серьезно, то, поскольку программирование для меня не только работа но и пагубное увлечение с неискореннимым креном в велосипедостроение, то мое желание формулируется очень просто: иметь возможность выпускать собственные велосипеды и чтобы эти велосипеды были востребованны. Даже если ради этого придется пахать, как папа Карло.

E>>Как говорил Линус Торвальдс: когда вопрос о выживании не стоит, то все делается just for fun.

Кё>А велосипеды у тебя никто не отнимет.

Не скажи. Ведь есть же где-то благословенные места, где программистам говорят -- мы должны что-то изобрести! Чтобы не как у других!
Но на эту тему я уже распостранялся: Re[4]: Джек Ривз. Как проектировать ПО?

Автор: eao197
Дата: 22.05.05

.

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

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

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

Так и будем бегать по замкнутому кругу

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


Кё>>>Всё это и будет являться работой программиста — сделать требования чёткими. А не просчитывать заранее и не ставить эксперименты с силой импульсов, чтобы потом полученные числа подставить в алгоритм.

E>>Так, имхо, именно этим программисты сейчас и занимаются.

Кё>Нет, они по большей части эти требования реализуют — пишут код.

Так ведь это и есть самое детальное изложение собственных (ну или чужих) идей.

E>>А постановка экспериментов подстановка чисел в алгоритм -- это ты о чем?

Кё>А том, что ты заранее не знаешь, сколько секунд и какой силы импульсы надо отправлять, и должен их сам просчитать и затем полученные числа использовать. Хотя компьютер это в состоянии сделать сам. Проблема лишь в том, как ему дать такое задание? Сейчас такое задание дается как последовательность команд императивного языка. Фактически, как калькулятор с отложенным вычислением. А можно по-другому.

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

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

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

Кё>А по поводу "принципиальных улучшений не будет" — президент IBM когда-то не верил, что компьютеры станут покупать, поищи в хуморе этот старый баян

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

Здравствуйте, Кодёнок,

Естественно. Компиляция программы — вот он самый настоящий аналог строительства дома. Это описано у классиков, но точно не помню где, кажется: Брукс "Мифический человекомесяц".

Кё>>А велосипеды у тебя никто не отнимет.

E>Не скажи. Ведь есть же где-то благословенные места, где программистам говорят -- мы должны что-то изобрести! Чтобы не как у других!
E>Но на эту тему я уже распостранялся: Re[4]: Джек Ривз. Как проектировать ПО?

Автор: eao197
Дата: 22.05.05

.

Ты вообще противоречишь сам себе. Если ты программируешь для удовольствия, то и делай у себя дома что захочешь, если хочешь как-то свою волю реализовывать, то создавай свою компанию. А наёмная работа по определению предполагает реализацию идей начальника, каков бы его уровень понимания не был. В чем твоя проблема-то? Не нравится, что индустрия разработки ПО работает не в твою пользу, даёт не те задания, которые тебе интересны?

Это проблема наемной работы в любой области, зачем новые идеи из-за этого останавливать-то?

Кё>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.

AF>И кто мешает написать функцию:
AF> ПоднятьРуку( Правую )
AF>или вызвать метод:
AF> Человек.Конечности.Рука.Поднять( ... )

Это у тебя получилось, потому что "поднять руку" по своей сути императивная инструкция, я слишком всё упростил.

"Через 10 секунд у робота правая рука должна быть поднята вертикально вверх" — вот так примерно выглядит декларативное описание. Сравни это с императивной реализацией:

робот.начать_поднимание_руки(правая, (тут полярные координаты нужного положения ) )
пока (прошедшее_время < 10 сек)
ничего не делать;
робот.получить_состояние_правой_руки
...тут генерировать исключение, если не успел...

Просто современные декларативные языки ещё на примитивном уровне. Я о более высоком

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

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


Кё>>>А велосипеды у тебя никто не отнимет.

E>>Не скажи. Ведь есть же где-то благословенные места, где программистам говорят -- мы должны что-то изобрести! Чтобы не как у других!
E>>Но на эту тему я уже распостранялся: Re[4]: Джек Ривз. Как проектировать ПО?

Автор: eao197
Дата: 22.05.05

.

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

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

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

А в научно-исследовательских центрах крупных корпораций по-твоему не наемные рабочие работают?
Или ты думаешь, что Грослинг Java придумывал дома для удовольствия?

Кё> В чем твоя проблема-то? Не нравится, что индустрия разработки ПО работает не в твою пользу, даёт не те задания, которые тебе интересны?

Индустрия вообще не дает знаний, имхо, она их потребляет.
Кроме того, публичный форум совсем не место для осуждения личных проблем.

Кё>Это проблема наемной работы в любой области, зачем новые идеи из-за этого останавливать-то?

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

ИМХО, в принципе неправильно проводить параллели между строительством (или чем-нибудь еще) и разработкой программ. Понятно, что многие процессы разработки ПО были заимстовваны из традиционных отраслей. Но это только усугубляет. Потому что существует принципиальная разница между software и hardware engeneering! (не буду перечислять, об этом столько раз уже писали классики.)
Пока эта разница не будет до конца осознана, успешная разработка средних и крупных проектов по-прежнему будет оставаться героическим делом!

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


Кё>>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.

Кё>"Через 10 секунд у робота правая рука должна быть поднята вертикально вверх" — вот так примерно выглядит декларативное описание. Сравни это с императивной реализацией:
Кё>

Кё>робот.начать_поднимание_руки(правая, (тут полярные координаты нужного положения ) )
Кё>пока (прошедшее_время < 10 сек)
Кё> ничего не делать;
Кё>робот.получить_состояние_правой_руки
Кё>...тут генерировать исключение, если не успел...

Кё>Просто современные декларативные языки ещё на примитивном уровне. Я о более высоком

Скорее это твоя попытка сделать неудачное решение императивным подходом. Что тебе мешало записать так:

робот.начать_понятие_руки( правая, координаты, ограничение_по_времени( 10мин ) )
/* никаких проверок не делаем, если в заданное время не уложились,
    то исключение будет сгенерированно автоматически */

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

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

Каких требований? В какой парадигме будут формулироваться требования? В объектной? В логической? В императивной? В ...?

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


Кё>>>Всё это и будет являться работой программиста — сделать требования чёткими. А не просчитывать заранее и не ставить эксперименты с силой импульсов, чтобы потом полученные числа подставить в алгоритм.
E>>Так, имхо, именно этим программисты сейчас и занимаются.
Кё>Нет, они по большей части эти требования реализуют — пишут код.

Процитирую перевод с Programmer's Stone:

Мы инженеры-программисты. Почему? Для чего служит программная инженерия? Что делают инженеры-программисты? Мы получаем самые курьезные ответы на этот вопрос. Один чудак сказал: "Они следуют процедурам Стандартов Программной Инженерии!" Другой добавил: "Они переформулируют (transliterate) требования!"

E>Для создания компании и обеспечения ее жизнеспособности нужны некоторые специфические качества.
E>Кроме того, есть и третий путь -- убедить руководство твоей компании вложится в твою идею. Google, имхо, такой подход практикует.

С третьим путём далеко не уедешь. Для компании всегда на первом месте будет прибыль, а зарплата и благополучие работников по минимуму, чтобы продолжали работать. Хочешь свободы — летай один закон жизни.

E>А в научно-исследовательских центрах крупных корпораций по-твоему не наемные рабочие работают?
E>Или ты думаешь, что Грослинг Java придумывал дома для удовольствия?

А я не говорил, что начальство принципиально не будет брать твои идеи. Но брать строго каждую и вообще работать ради твоего блага тоже не будет.

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

Кё>>Это проблема наемной работы в любой области, зачем новые идеи из-за этого останавливать-то?

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

Идея ничего никому доказать не может. Если ты сам её продвинешь, вложишь достаточное количество усилий и времени, этим ТЫ докажешь её право на жизнь. Сколько примеров, когда не лучшее живёт, а лучшее помирает, просто потому, что в нелучшее случайно вложили больше усилий. Проблем с наличием идей и их продвижением никогда не было, главная проблема в наличии людей, которые за это возьмутся. Все или ждут волшебника, который даст $10M и все условия для исследований, либо согласны только на обычную работу без гарантии результата. Ни то, ни другое не является приклекательным для инвестиций.

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


E>>Для создания компании и обеспечения ее жизнеспособности нужны некоторые специфические качества.
E>>Кроме того, есть и третий путь -- убедить руководство твоей компании вложится в твою идею. Google, имхо, такой подход практикует.

Кё>С третьим путём далеко не уедешь.

Мне кажется, что эта твоя фраза как раз противоречит твоему же примеру с IBM.

Кё>Собственно, сейчас, если ты хочешь повысить свою квалификацию, или попробовать применить Лисп в проекте, или попробовать редизайнить программу с применением какой-нибудь интересной методологии, тебя скорее попросят делать это не на работе и не с основной веткой Если это удастся, идею возьмут с охотой, и поощрить могут, но суть останется одна: исследованием, созданием нового, творчеством ты занимаешься сам, по своей инициативе.

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

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

Кё>Идея ничего никому доказать не может. Если ты сам её продвинешь, вложишь достаточное количество усилий и времени, этим ТЫ докажешь её право на жизнь.

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

Можно сказать и так: программисты переводят (транслируют) инженерные представления в код.

Кё>>Просто современные декларативные языки ещё на примитивном уровне. Я о более высоком

E>Скорее это твоя попытка сделать неудачное решение императивным подходом. Что тебе мешало записать так:
E>робот.начать_понятие_руки( правая, координаты, ограничение_по_времени( 10мин ) )
E>/* никаких проверок не делаем, если в заданное время не уложились,
E> то исключение будет сгенерированно автоматически */

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

начать_поднятие_руки
поднять_руку
начать_поднятие_рук
поднять_руки
начать_поднятие_ноги
поднять_ногу

и т.д. Это я для понятности говорю, на самом деле кода не должно быть.

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

Возвращаясь к первоначальной статье, можно так сказать: программа собирается прямо из UML-схем. Минуя стадию кодирования. Вряд ли UML способен настолько детализовано описать систему, но теоретически принцип именно такой.

E>Так ведь я же тебе и говорю: доказывай свою идею о том, что декларативный подход способен изменить подход к разработке.
Пока речь идет о фантазиях, о том, что "хорошо бы что бы". Если это фантазии, то давай к ним и относится как к фантазиям. Если же ты веришь в это, если у тебя есть идея -- озвучь ее, дай потрогать. Чтобы практикой скепсис развееть.

Это фантазии Сам я ещё только изучаю готовое, Лисп, Пролог... То, о чем я говорю — это перспектива, если бы её не было, то и декларативного программирования бы не существовало.

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

E>>Пока речь идет о фантазиях, о том, что "хорошо бы что бы". Если это фантазии, то давай к ним и относится как к фантазиям. Если же ты веришь в это, если у тебя есть идея -- озвучь ее, дай потрогать. Чтобы практикой скепсис развееть.

Кё>Это фантазии Сам я ещё только изучаю готовое, Лисп, Пролог... То, о чем я говорю — это перспектива, если бы её не было, то и декларативного программирования бы не существовало.

А, тогда понятно. Фантазии -- это и интересно, и полезно.
Только дальше я пас. Велосипедостроение от фантазирования отличается тем, что велосипед обязательно нужно заставить ездить. И это у меня, имхо, получается. Этим я и продолжу заниматься.

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


Кё>>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.

AF>>И кто мешает написать функцию:
AF>> ПоднятьРуку( Правую )
AF>>или вызвать метод:
AF>> Человек.Конечности.Рука.Поднять( ... )

Кё>Это у тебя получилось, потому что "поднять руку" по своей сути императивная инструкция, я слишком всё упростил.

Кё>"Через 10 секунд у робота правая рука должна быть поднята вертикально вверх" — вот так примерно выглядит декларативное описание. Сравни это с императивной реализацией:
Кё>

Кё>робот.начать_поднимание_руки(правая, (тут полярные координаты нужного положения ) )
Кё>пока (прошедшее_время < 10 сек)
Кё> ничего не делать;
Кё>робот.получить_состояние_правой_руки
Кё>...тут генерировать исключение, если не успел...

Это мы жулничаем — сравниваем вещи разного уровня. Ты бы ещё дезасемблировал программу. Адекватный императивный код выглядит так:

Ждать( 10 секунд )
Робот.правая_рука.поднять( вертикально_вверх )

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

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

И кто будет описывать реализацию того, как подаются команды сервомоторам робота? Пушкин?
Пусть за меня всё напишут, а я тогда очень просто смогу этим пользоваться
Если за меня напишут реализацию подачи всех необходимых команд сервомеханике, разработают логику управления, терминологию и т.п то мне без разницы как написать две строки — декларативно или императивно.

А в реальной жизни придётся реализовывать управляющие последовательности самому. Вот тут то всей красивой теории резко придёт конец.
Просто потому, что вместо упрошённого описания:

Через 10 секунд у робота правая рука должна быть поднята вертикально вверх

Придётся писать:
Через 10 секунд у робота правая рука должна быть поднята вертикально вверх. Поднятие руки нужно делать медленно (за 2 секунды), с плавным поворотом ладонью вперёд (скорость поворота 90 градусов за 2 секунды). Амплитуда случайных колебаний (используется иммитация естественного движения) должна находится в диапазоне от 3 до 5% от максимальной амплитуды движения для заданной степени свободы.....

А потом — всё это ещё и реализовывать! Вот где песня то будет!

О чём забывают фанаты декларативных языков — так это о том, что ДЯ появились одновременно с императивными. Но большого развития не получили. Интересно — почему это?