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

A>Вы слышали когда нибудь имя владельца боинга ?

Не поверишь, но его основатель Вильям Боинг

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

1) в принципе возможно (ура — мы взлетели !)
2) обнаружение основных концептуальных противоречий (допустим вместительность и обтекаемость)
3) нахождение (вычисление) базовых оптимальных конструктивных решений (би/три/моноплан ? тянущий/толкающий винт ? материал ? как крылья и хвост расположить ?) (таких наборов решений может быть несколько для разных областей применения)
4) выведение теории на основе экспериментальных данных (появление аэродинамики, профессиональных школ пилотирования и т.д.)
5) рост в сторону различных экстремумов ("мрия" и боинг 747 <-> авиамодели) с одной стороны и увеличение комфортности использования (электроника, автопилоты и вообще беспилотные системы) с другой

так вот аналогичные цепочки можно выстроить для чего угодно — от политики и до микробиологии
(причём в политике мы видимо только только учимся понимать чем та или иная модель хороша — т.е. где то на втором этапе
я пытаюсь выстроить такую цепь для компьютеров:
1) первый компьютер — середина 40х!
2) размер/энергопотребление/цена <-> скорость вычислений и объём памяти
3) 1-* процессорный сервер с кучей памяти и устройств хранения, 1 процессорный комп с простым винтом, кластер из таких компов — наверно 3 самые устоявшиеся модели, и они ещё доолго продержатся
4) рабочих теорий оптимального способа создания и построения вычислительных машин и сетей тоже куча, вам спроектируют и создадут от суперкомпьютера и до грида с 1000 машинами (не говоря уже о простой домашней писишке с закрытыми глазами и притом заранее будет известно всё: от цены до размеров
5) известия о создании мега мощных или микро маленьких компов и их комплектующих мы получаем раз в месяц, комфортность их конфигурирования и использования выросла в десятки раз (поставил и забыл в идеале — часто так оно и есть теперь)

а вот теперь попытайтесь кто нить для программирования построить такую цепочку:
как ни верти — а по моему мы где то на 2 этапе застряли

1) да — программировать возможно и вполне успешно ! конечно не АИ но итак куча полезного налицо

2) дешевизна и скорость написания в вечном конфликте с качеством и скоростью исполнения в рантайме

3) какой язык С# C++ Ada Oberon Smalltalk Java VB Object Pascal ? как хранить ХМЛ/ДБ/ООДБ ? какая ОС ? Опен сорс ? командная строка или ГУИ ? вопросов куча на самом деле.

4) Фаулер ? ООП ? АОП ? это притом что все имеющиеся популярные ОС и ДБ написаны на ассемблере С и оч. плохом С++ ? Фаулер занимался вроде бы простейшей рутинной задачей — автоматизацией бизнес процессов, споров про и контра по его книге куча. Рефакторинг ? Выгоднее переписать заново/лучше вообще не трогать. О кодестайлах и нэйминге тома написаны, равно как и о правильном ОО. Оное же — Гради Бутч и все остальные — эти люди 10 лет назад говорили и верили в одно, сейчас в другое, завтра все на АОП перейдут ради повышения продаж книгопродукции и сопутствующих тулзов вроде Рэйшенал Роуз.

5) Комфортность растёт при этом конечно (но и тут нет согласия — кому то ДОС или Юникс больше нравятся, а кто то считает что Мак ОС красивше нет). Есть реальный успех в популяризации софта среди юзерства но и тот сомнителен — юзер все проги кроме игрушек чаще всего ненавидит. С комфортностью растёт и количество багов. Интернет комфортности ещё добавил но и баги сделал уже критически опасными изза вирусов. Экстремумы — в сторону повышения аппаратных запросов только рост замечен однозначный.

хотя некоторые утверждают что софт девелопмент очень быстро растущая индустрия мы растём медленнее авиации по моему — за первые 50 лет авиаконструкторы прошли все этапы. мы уверенно только 2, остальные на слаааабую 3-ечку.

мы пишем такую систему сейчас — область — составление тестов для аппаратуры в виде блок схем — насколько я знаю — попыток создания таких систем было много (и у нас и за рубежом — и применительно к бизнес процессам)- насколько понимаю проблемы следующие:

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

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

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

_>>Такую тему бесполезно обсуждать среди программистов. Они тебе скажут, что вообще все технические отрасли (напр. авиация ) все это прошли, а programming нет. Просто мы НИ ХРЕНА не понимаем в авиации, ибо я больше чем уверен, что с точеи зрения авиатора- именно в его области все неодназначно. Ну и далее везде

A>Да но разве объективно народ не более доволен авиацией чем софтом ?! Нету жалоб практически.
A>Вы слышали когда нибудь имя владельца боинга ?

— Ты кем работешь?
— Укладчиком парашютов.
— И как?
— Да пока никто не жаловался!
Анекдот

CB>Не могу с Вами не согласиться. Сейчас мы используем универсальные языки, на которых пишем программы и для склада, и для расчета траекторий космических аппаратов. Универсальные языки гибки – могут все. Но писать на них программы не эффективно (почему? – сейчас не об этом). Будущие языки программирования мне представляются как языки описания задач (понимай требований к системе) в конкретной прикладной области. на этих языках должны писать специалисты конкретной прикладной области. Возвращаясь к своему примеру, вектора и матрицы – это элементы языка математиков, а цена, товар, склад, продажа – это элементы языка торговли. Если мы этот язык формализуем, то искомые программы будут иметь минимально возможный объем.

Любые языки будут требовать детальности и структурированности в формировании требований — этого среднестатистический (и дажее более чем средний) спец предметной области не потянет. А если и потянет то на остальное у него времени не останется. Они даже на человеческом языке свои требования более менее детально не могут написать. А уж на формализованном языке писать тем более не потянут — иначе вся проблема была бы в создании библиотеки для VB или С# и пишите код типа:

Customers.Add(new Customer("petia", 1980, Gender.Male));

ну чем не предметная область ?
что кроме правильных имён и готовых свойств дадут новые языки ?

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

A>Авиаконструктор, строиттель

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

CB>На счет «маразма» — это Вы преувеличиваете. Например, вспоминается случай, когда мы реализовали на С++ библиотеку матричной алгебры с перегрузкой операций для ее объектов, то программирования метода Кутта-Мерсона для решения задачи Коши свелось к копированию векторных формул метода из справочника. Эти формулы (несколько строк), как раз и были требованиями к программе решения задачи Коши. Имеющийся аналог – процедура на Фортране содержала раз в 10 больше строк.

это и есть редчайшее меньшинство случаев — когда результат надо вычислять много а проверить легко — любое решение уравнений например — или взлом шифра подпадают под такое дело. но такого кода пишут считанные строчки от всего объёма обычно — математические методы программировать без багов легко — прекрасно всё формализуется и проверяется. вы вот попробуйте бизнес приложения так описать. а этого кода 99% во всём мире. Ведь бизнес приложения как раз реализовывать не трудно — трудно определиться с тем ЧТО КОНКРЕТНО НАДО реализовывать. и если кто то дал описание бизнес приложения на каком либо формальном языке — наверняка можно будет и написать компилятор с этого языка дающий готовое приложение )

A>я уже не помню но когда то увлекался изобретательством и в 80-х вычитал (к сожалению книжки уже нет — цитирую своими словами), что любая отрасль, допустим авиация, развиваясь проходит следующие этапы:

Самопальство какое-то, но это не важно в данной ситуации

A>1) в принципе возможно (ура — мы взлетели !)
A>2) обнаружение основных концептуальных противоречий (допустим вместительность и обтекаемость)
A>3) нахождение (вычисление) базовых оптимальных конструктивных решений (би/три/моноплан ? тянущий/толкающий винт ? материал ? как крылья и хвост расположить ?) (таких наборов решений может быть несколько для разных областей применения)
A>4) выведение теории на основе экспериментальных данных (появление аэродинамики, профессиональных школ пилотирования и т.д.)
A>5) рост в сторону различных экстремумов ("мрия" и боинг 747 <-> авиамодели) с одной стороны и увеличение комфортности использования (электроника, автопилоты и вообще беспилотные системы) с другой

[....]

A>а вот теперь попытайтесь кто нить для программирования построить такую цепочку:
A>как ни верти — а по моему мы где то на 2 этапе застряли

A>1) да — программировать возможно и вполне успешно ! конечно не АИ но итак куча полезного налицо

A>2) дешевизна и скорость написания в вечном конфликте с качеством и скоростью исполнения в рантайме

A>3) какой язык С# C++ Ada Oberon Smalltalk Java VB Object Pascal ? как хранить ХМЛ/ДБ/ООДБ ? какая ОС ? Опен сорс ? командная строка или ГУИ ? вопросов куча на самом деле.

A>4) Фаулер ? ООП ? АОП ? это притом что все имеющиеся популярные ОС и ДБ написаны на ассемблере С и оч. плохом С++ ? Фаулер занимался вроде бы простейшей рутинной задачей — автоматизацией бизнес процессов, споров про и контра по его книге куча. Рефакторинг ? Выгоднее переписать заново/лучше вообще не трогать. О кодестайлах и нэйминге тома написаны, равно как и о правильном ОО. Оное же — Гради Бутч и все остальные — эти люди 10 лет назад говорили и верили в одно, сейчас в другое, завтра все на АОП перейдут ради повышения продаж книгопродукции и сопутствующих тулзов вроде Рэйшенал Роуз.

A>5) Комфортность растёт при этом конечно (но и тут нет согласия — кому то ДОС или Юникс больше нравятся, а кто то считает что Мак ОС красивше нет). Есть реальный успех в популяризации софта среди юзерства но и тот сомнителен — юзер все проги кроме игрушек чаще всего ненавидит. С комфортностью растёт и количество багов. Интернет комфортности ещё добавил но и баги сделал уже критически опасными изза вирусов. Экстремумы — в сторону повышения аппаратных запросов только рост замечен однозначный.

A>хотя некоторые утверждают что софт девелопмент очень быстро растущая индустрия мы растём медленнее авиации по моему — за первые 50 лет авиаконструкторы прошли все этапы. мы уверенно только 2, остальные на слаааабую 3-ечку.

Такую тему бесполезно обсуждать среди программистов. Они тебе скажут, что вообще все технические отрасли (напр. авиация ) все это прошли, а programming нет. Просто мы НИ ХРЕНА не понимаем в авиации, ибо я больше чем уверен, что с точеи зрения авиатора- именно в его области все неодназначно. Ну и далее везде

_>Такую тему бесполезно обсуждать среди программистов. Они тебе скажут, что вообще все технические отрасли (напр. авиация ) все это прошли, а programming нет. Просто мы НИ ХРЕНА не понимаем в авиации, ибо я больше чем уверен, что с точеи зрения авиатора- именно в его области все неодназначно. Ну и далее везде

Да но разве объективно народ не более доволен авиацией чем софтом ?! Нету жалоб практически.
Вы слышали когда нибудь имя владельца боинга ? А имя владельца майкрософт у всех на слуху изза судебных процессов.

_>>Такую тему бесполезно обсуждать среди программистов. Они тебе скажут, что вообще все технические отрасли (напр. авиация ) все это прошли, а programming нет. Просто мы НИ ХРЕНА не понимаем в авиации, ибо я больше чем уверен, что с точеи зрения авиатора- именно в его области все неодназначно. Ну и далее везде

A>Да но разве объективно народ не более доволен авиацией чем софтом ?! Нету жалоб практически.
A>Вы слышали когда нибудь имя владельца боинга ? А имя владельца майкрософт у всех на слуху изза судебных процессов.

Ммм. А причем тут народ, если мы о ТЕОРИИ (бред кстати всё это ) говорим (см. сабж)?
К тому же ты (ничего, если я на ты) сравни сколько людей пользуется авиацией, а сколько компами.
Приходится констатировать, что PC попали в руки, не побоюсь этого слова, ИДИОТАМ, которых обратно в школу надо отправлять. Они и жалуются. Почему это все думают, что ядерный синтез это сложно, а PC- так, как два байта (они кстати не знаю что это такое ) переслать...

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

A>хотя некоторые утверждают что софт девелопмент очень быстро растущая индустрия мы растём медленнее авиации по моему — за первые 50 лет авиаконструкторы прошли все этапы. мы уверенно только 2, остальные на слаааабую 3-ечку.

Мне кажется, что автор с верной стороны посмотрел на проблемы Software Engineering.

Есть такая технология ТРИЗ — теория решения изобретательских задач (http://www.altshuller.ru/), которая применяется для технических систем. Нетривиальная программистская задача очень похожа на изобретательскую, поэтому, на мой взгляд, должен быть справедлив аналогичный подход к решению программистских задач.

Нам надо ответить на следующие вопросы:
1) Каковы законы развития программных систем?
2) Что такое идеальная программная система?
3) Что такое программистская задача?
4) Каковы алгоритмы решения программистских задач? (Речь идет об алгоритмах творчества. Просьба не путать с численными алгоритмами, которые достаточно хорошо изучены.)

Это позволит нам, наконец, понять, чему и как обучать профессиональных программистов. Сейчас с обучением просто беда, как у нас, так и в остальном мире. Мы программируем методом проб и ошибок, тупо перебирая все возможные варианты, пока не найдем подходящий. Отсюда разброс производительности: правильный вариант может попасться в начале или в конце перебора. Только с годами накапливается некий интуитивный опыт: «куда надо ходить, а куда — нет». Задача – ограничить пространство перебора. Во сколько раз ограничим, во столько раз повысим эффективность производства ПО.

craft-brother пишет:

> Нам надо ответить на следующие вопросы:
> 1) Каковы законы развития программных систем?
> 2) Что такое идеальная программная система?
> 3) Что такое программистская задача?
> 4) Каковы алгоритмы решения программистских задач? (Речь идет об
> алгоритмах творчества. Просьба не путать с численными алгоритмами,
> которые достаточно хорошо изучены.

Многие пытались адаптировать ТРИЗ к программированию — получается плохо.
Слишком большая степень свободы. Скажем, в механических системах детали
обычно взаимодействуют с максимум десятком других деталей, и их
взаимодействия можно хорошо промоделировать.

> Это позволит нам, наконец, понять, /чему и как обучать
> профессиональных программистов/. Сейчас с обучением просто беда, как у
> нас, так и в остальном мире. Мы программируем методом проб и ошибок,
> тупо перебирая все возможные варианты, пока не найдем подходящий.
> Отсюда разброс производительности: правильный вариант может попасться
> в начале или в конце перебора. Только с годами накапливается некий
> интуитивный опыт: «куда надо ходить, а куда — нет». Задача –
> ограничить пространство перебора. Во сколько раз ограничим, во столько
> раз повысим эффективность производства ПО.

Так тут уже другая проблема — можно слишком ограничить пространство
решений.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Многие пытались адаптировать ТРИЗ к программированию — получается плохо.

Согласен, адаптировать ТРИЗ, вряд ли, имеет смысл. Программные системы нечто совершенно новое, по сравнению с техническими системами, которые имеют тысячелетнюю историю. Законы развития программных систем, вероятно, другие. Поэтому стоит говорить не об адаптации ТРИЗ к программированию, а о применении методологического подхода, который использовался при ее построении, и о создании «Теории решения программистских задач».

C>Так тут уже другая проблема — можно слишком ограничить пространство
C>решений.

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

Да есть ваш ТРИЗ для программирования — десятки ТРИЗов есть.
ООП, АОП, паттерны, рефакторинг ну и т.д.
а воз где ?
по моему проблема в том что если программист пишет новую программу — нового в ней концептуально всегда больше чем в новой модели автомобиля.
и не потому, что она действительно такая новая, а просто потому что основные подходы в проектировании (те же паттерны) недостаточно широко применяются и изучаются. Почему ? Потому что они весьма абстрактно подаются. По моему в университетах после прохождения основ программирования и ОО надо сразу же начинать преподавать типовые примеры пронрамных проектов: модели сохранения данных и их применимость, построение документно ориентированных приложений, построение программ учёта, программ документооборота, серверов, тонких, толстых клиентов и т.д. Вы скажете что это слишком узко ! Но тем не менее именно так обучают инженеров на всех других специальностях. Эти преподанные схемы покроют 90% проблем при проектировании на самом деле. И преподавать их надо не "прочтите главу, пройдите тест" а реально — чтоб от зубов. В этом смысле Фаулер молодец бы был если бы его книжка не так ориентировалась на конкретный язык и технологии. Более того — несмотря на то что прошло 50 лет и исписаны талмуды — общей точки зрения на то какойдолжна была бы быть книжка фаулера нет !!! Опять же в одних случаях с теми то тулзами выгоднее так, в других — по другому. Как ? Выбор слишком широкий получается — акомбинация выриантов — вообще запредельной. И как с этим бороться ?

craft-brother пишет:

> C>Многие пытались адаптировать ТРИЗ к программированию — получается
> плохо.
> Согласен, /адаптировать/ ТРИЗ, вряд ли, имеет смысл. Программные
> системы нечто совершенно новое, по сравнению с техническими системами,
> которые имеют тысячелетнюю историю. Законы развития программных
> систем, вероятно, другие. Поэтому стоит говорить не об адаптации ТРИЗ
> к программированию, а о применении методологического подхода, который
> использовался при ее построении, и о создании «Теории решения
> /программистских/ задач».

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

> C>Так тут уже другая проблема — можно слишком ограничить пространство
> C>решений.
> А чем это плохо, если мы будем уверены, что в ограниченном
> пространстве находятся решения не хуже, чем вне него?

Слишком негибко или громоздко может получиться.

--
С уважением,
Alex Besogonov (alexy@izh.com)

C>Так нету единой теории, так как нет единой задачи программирования.

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

а) модули с наименьшим зацеплением
б) процедуры помельче и повложенней (т.е. сведение на нет избыточности кода)

И всё бы ОК, но он хромал для больших программ ибо зацепление на деле нужно было куда большее и
не было пути его контролировать.
Потом ввели ОО с разными средствами позволяющими при повышенной связности как то ограничивать
потенциальные опасноти из неё вытекающие. Ввиду своей многогранности ОО породило кучу
противоречивых подходов к проектированию. Сегодня в моде один, завтра другой. Через пять лет и
сегодняшние труды предадут анафеме.

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

A>Вот на это я и жалуюсь — нету.
A>Проектировщику жилого дома просто — есть у него единая теория, есть учебник, ГОСТ,
A>ещё масса чего — всё согласовано более менее — а мне сложно — у меня нету

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

А теперь посмотрите на проблему с ещё одной стороны — у вас есть возможность использовать софт с багами
сегодня и дёшево или качественный завтра и дорого. Что вы выберете ? По законам рынка — клиенты выбирают
первый вариант — всегда практически. Отсюда и все наши беды.

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

A>Да есть ваш ТРИЗ для программирования — десятки ТРИЗов есть.
A>ООП, АОП, паттерны, рефакторинг ну и т.д.
A>а воз где ?

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

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

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

A>>Вот на это я и жалуюсь — нету.
A>>Проектировщику жилого дома просто — есть у него единая теория, есть учебник, ГОСТ,
A>>ещё масса чего — всё согласовано более менее — а мне сложно — у меня нету

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

не могу не согласиться — и по этому поводу мой пост от "14.01.05 16:32" — клиенты хотят быстро и
просто — и получают — быстро и просто — и с глюком. Только мы к этому относимся с предубеждением — это мол плохо — с другой стороны это именно отличительная и привлекательная особенность нашей индустрии — мы можем быстренько тяп ляп налабать и это даже в принципе будет работать ! — Авиаконструктор, строиттель — не может — а мы можем ! И клиентам это видимо очень нравится. Иначе спрос на супербыстрый софт с глюками не объяснишь.

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

A>А теперь посмотрите на проблему с ещё одной стороны — у вас есть возможность использовать софт с багами
A>сегодня и дёшево или качественный завтра и дорого. Что вы выберете ? По законам рынка — клиенты выбирают
A>первый вариант — всегда практически. Отсюда и все наши беды.

Это не беда, это закон экономики: «спрос рождает предложение». А как управлять спросом это вопрос не сюда, а скорее в маркетинг.
«Пиплы хавают» (с) Б.Титомир

CB>Это не беда, это закон экономики: «спрос рождает предложение». А как управлять спросом это вопрос не сюда, а скорее в маркетинг.
CB>«Пиплы хавают» (с) Б.Титомир

Так мало того что хавают — таким софтом мы создаём кучу новых проблем и сами же их (за отдельные деньги ! решаем (тоже из рук вон плохо))
Т.е. потребитель сам виноват в плохом качестве продукции ?

A>Т.е. потребитель сам виноват в плохом качестве продукции ?

Думаю, что виноватых искать задача неблагодарная.
В данной ситуации потребителя разводят рекламой продюсеры поп-софта (на мой взгляд, аналогия с поп-культурой полная). А бизнес-потребитель пока не очень продвинутый: красивше творений Церителли (да еще за дешево и быстро!) ничего не видел. Вряд ли, на БЦВМ баллистических ракет купят что-нибудь от MS.Хотя, из суеверия стучу по дереву, не дай Бог.

Например, одним из свойств, но далеко не единственным, идеальной программы, может быть то, что требования к ней должны быть сформулированы на языке, для которого существует компилятор. Это не маниловщина. Сейчас активно «копают» в этом направлении, например, xUML. и не только.
А на Ваш взгляд, какие еще могут быть свойства у идеальной программной системы?

то даже не маниловщина — это маразм ! — трудоёмкость написания спецификаций (и безошибочных — иначе грош им цена !) на таком языке будет не ниже чем трудоёмкость написания программы в большинстве случаев

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

A>то даже не маниловщина — это маразм ! — трудоёмкость написания спецификаций (и безошибочных — иначе грош им цена !) на таком языке будет не ниже чем трудоёмкость написания программы в большинстве случаев :))

На счет «маразма» — это Вы преувеличиваете. Например, вспоминается случай, когда мы реализовали на С++ библиотеку матричной алгебры с перегрузкой операций для ее объектов, то программирования метода Кутта-Мерсона для решения задачи Коши свелось к копированию векторных формул метода из справочника. Эти формулы (несколько строк), как раз и были требованиями к программе решения задачи Коши. Имеющийся аналог – процедура на Фортране содержала раз в 10 больше строк.

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

A>Ведь бизнес приложения как раз реализовывать не трудно — трудно определиться с тем ЧТО КОНКРЕТНО НАДО реализовывать. и если кто то дал описание бизнес приложения на каком либо формальном языке — наверняка можно будет и написать компилятор с этого языка дающий готовое приложение :))))

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

A>что кроме правильных имён и готовых свойств дадут новые языки ?

Мне представляется, что в будущем среды программирования будут в основном визуальными, что-то похожее на CAD системы или на среды создания GUI. Прикладные программные системы будут создаваться подобно современным имитационным моделям, в которых я могу собрать, например, электронную схему из готовой элементной базы: моделей транзисторов, переключателей, соединителей и проч. При этом пользователь ничего не программирует, а таскает мышкой объекты и настраивает их свойства. Аналогично, я хотел бы собирать и корпоративные информационные системы.
А что нам может помешать двигаться в этомнаправлении? ИМХО это лишь дело времени.

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

A>я уже не помню но когда то увлекался изобретательством и в 80-х вычитал (к сожалению книжки уже нет — цитирую своими словами), что любая отрасль, допустим авиация, развиваясь проходит следующие этапы:

A>1) в принципе возможно (ура — мы взлетели !)
A>2) обнаружение основных концептуальных противоречий (допустим вместительность и обтекаемость)
A>3) нахождение (вычисление) базовых оптимальных конструктивных решений (би/три/моноплан ? тянущий/толкающий винт ? материал ? как крылья и хвост расположить ?) (таких наборов решений может быть несколько для разных областей применения)
A>4) выведение теории на основе экспериментальных данных (появление аэродинамики, профессиональных школ пилотирования и т.д.)
A>5) рост в сторону различных экстремумов ("мрия" и боинг 747 <-> авиамодели) с одной стороны и увеличение комфортности использования (электроника, автопилоты и вообще беспилотные системы) с другой

A>так вот аналогичные цепочки можно выстроить для чего угодно — от политики и до микробиологии

Логично. Не указан только последний этап, имеющий два варианта:
6 a) стагнация — выход на "полочку" логистической кривой (никаких существенных достижений в "мэйнстриме")
6 b) увядание (медленная смерть отрасли и переход в разряд "экзотики для фанатов" вследствие появления конкурентов)

Авиация, естественно, пошла по пути (a). С 60-х — 70-х годов там не было никаких прорывов. А увядания не происходит вследствие отсутствия альтернатив в плане быстрого перемещения на дальние расстояния. Если придумают какую-нибудь нуль-транспортировку, тогда она и погибнет, а пока спокойно сидит на своей "полочке" логистической кривой.

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

В программировании всё сложнее и запутаннее, так как это на самом деле не отрасль, а целый клубок отраслей. И каждый со своей логистической кривой. Например:

• В области СУБД — стойкая стагнация.
  
• Графические редакторы — полная стагнация.
  
• В области ОСостроения — период господства динозавров.
  
• Утилитописание — на подъёме, хотя славные времена, когда каждый новый текстовый редактор был прорывом — в прошлом. Развитие в основном за счёт горизонтальной экспансии на носимые прибамбасы.
  
• ERP и прочие слова из трёх букв — на этапе 4.
  
• Нейрокомпутеры — умерли, так толком и не родившись.
  
• Средства разработки — стадия 5.

Продолжать можно долго. К томуже, возможно, в этом своём списке я раз семь и ошибся

V>

В области СУБД — стойкая стагнация.
V>

Графические редакторы — полная стагнация.
V>

В области ОСостроения — период господства динозавров.
V>

Утилитописание — на подъёме, хотя славные времена, когда каждый новый текстовый редактор был прорывом — в прошлом. Развитие в основном за счёт горизонтальной экспансии на носимые прибамбасы.
V>

ERP и прочие слова из трёх букв — на этапе 4.
V>

Нейрокомпутеры — умерли, так толком и не родившись.
V>

Средства разработки — стадия 5.
V>[/list]
V>Продолжать можно долго. К томуже, возможно, в этом своём списке я раз семь и ошибся

я вообще то как раз потому и говорил о целом программировании что интересна ситуация в целом. если снизойти до деталей — всё зашибись. есть людт готорые используют сиквел, хп, дот.нет и счастливы, есть те кто юникс джаву оракл и счастливы и т.д. но это совсем не ситуация в программирования в общем. нет единного понятия о том КАК писать программы. КАКИМ должно быть средство разработки. Что такое хорошая ОС. Что такое хорошая ДБ. У всех свои мнения на этот счёт. И изза этого индустрия растаскивается. Хотя казалось бы программирование настолько легко позволяет реализовывать идеи что оно очень быстро должно было до идеала докатиться. Не могу я VS.NET или Борландовские билдеры считать средством разработки стадии пять — для меня это скорее боинг с начинкой от бомбардировщика 2 мировой и салоном с неудобными креслами в стиле людовика 15. Но что самое страшное пилоты в них сидят чаще всего либо только только освоившие учебные самолётики, либо опытные истребители но никак не пилотёры боингов
В авиации такое звучало бы страшно — а у нас всё ок ! Так и живём.

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

A>я вообще то как раз потому и говорил о целом программировании что интересна ситуация в целом. если снизойти до деталей — всё зашибись
"Программирование" — слишком широкое понятие. Есть кодирование, есть алгоритмизация, есть дизайн пользовательских интерфейсов, есть проектирование распределённых систем, есть обработка сигналов. В какой-то степени программированием можно даже назвать реинжиниринг бизнес-процессов.

Это как автомобильное дело. И автомеханик, и дизайнер салонов, и гонщик, и директор гаражного хозяйства могут сказать, что они "занимаются автомобилями".

A>Нет единного понятия о том КАК писать программы. КАКИМ должно быть средство разработки. Что такое хорошая ОС. Что такое хорошая ДБ. У всех свои мнения на этот счёт. И изза этого индустрия растаскивается.
Как, впрочем, нет единого понятия о том, ИЗ ЧЕГО надо строить дома. То, что подходит для небоскрёба, не подходит для охотничьего домика. И наоборот.

A>Хотя казалось бы программирование настолько легко позволяет реализовывать идеи что оно очень быстро должно было до идеала докатиться.
Мелкие идеи — да. Но концептуальные — иногда сложно до невероятия.

A>Не могу я VS.NET или Борландовские билдеры считать средством разработки стадии пять — для меня это скорее боинг с начинкой от бомбардировщика 2 мировой и салоном с неудобными креслами в стиле людовика 15. Но что самое страшное пилоты в них сидят чаще всего либо только только освоившие учебные самолётики, либо опытные истребители но никак не пилотёры боингов
Можно поспорить, но лень...

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

V>"Программирование" — слишком широкое понятие. Есть кодирование, есть алгоритмизация, есть дизайн пользовательских интерфейсов, есть проектирование распределённых систем, есть обработка сигналов. В какой-то степени программированием можно даже назвать реинжиниринг бизнес-процессов.
V>Это как автомобильное дело. И автомеханик, и дизайнер салонов, и гонщик, и директор гаражного хозяйства могут сказать, что они "занимаются автомобилями".

Но авиация не менее широкая область ! Есть истребители, есть бомбардировщики, есть лайнеры, есть гидропланы и т.д.

A>>Нет единного понятия о том КАК писать программы. КАКИМ должно быть средство разработки. Что такое хорошая ОС. Что такое хорошая ДБ. У всех свои мнения на этот счёт. И изза этого индустрия растаскивается.

V>Как, впрочем, нет единого понятия о том, ИЗ ЧЕГО надо строить дома. То, что подходит для небоскрёба, не подходит для охотничьего домика. И наоборот.

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

A>>Хотя казалось бы программирование настолько легко позволяет реализовывать идеи что оно очень быстро должно было до идеала докатиться.
V>Мелкие идеи — да. Но концептуальные — иногда сложно до невероятия.

Воооооооооот, на эти то сложные и жалуюсь! По моему они сложны так именно по глупости отцов основателей и интересов монстров индустрии.

A>>Не могу я VS.NET или Борландовские билдеры считать средством разработки стадии пять — для меня это скорее боинг с начинкой от бомбардировщика 2 мировой и салоном с неудобными креслами в стиле людовика 15. Но что самое страшное пилоты в них сидят чаще всего либо только только освоившие учебные самолётики, либо опытные истребители но никак не пилотёры боингов
V>Можно поспорить, но лень...

А вы скажите что из этого списка вам незнакомо если вы работаете на одном из лучших продуктов данной категории VS.NET:
1) а меня достало что слишком большой проект после отладки всё вокруг лочит
2) что билд его идёт 1-2 минуты на сверхскоростной машине
3) что нет edit and continue
4) что для удобства работы надо 1-2 третьесторонние утилиты приладить вроде Resharper (которые тормозят немножко — ибо "неродные")
5) что такая примитивная вещь как дизайнер форм так глючит
6) что визуальных компонентов родных нормальных нет
7) что VSS тормозит так страшно, при открытии проекта
8) что до сих пор (через 25 лет после изобретения смолтолка и через 40 лет после изобретения БД!) мы храним сорсы в текстовых файлах и имеем компилятор с коммандной строки работающий со всеми сопутствующими этому проблемами, тормозами и т.д.
9) что при взятии новой версии проекта иногда студию приходится перезапускать — иначе хрен скомпилит правильные исходники.
10) что нет интегрированных средств прожект менеджмента и багтрекинга родных (их вообще нет нормальных !)
11) что 99% программистов не имеют специального образования (примат или схемотехник — это согласитесь не специальное, а приблудное скорее), что все они новые технологии изучают по книжкам часто таких же как они сами за неделю а потом опыт набирают на реальных проектах !!!(вы представьте такую лётную школу !!!)

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

да и такое редко — но получается качество работы такое низкое изза низкой ответственности ?
т.е. спроси с нас строже мы и писать будем супер ОО от зубов ?

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

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

A>Рецепт для разных задач разный. Но когда он для одной задачи разный — это кошмар.
Свобода выбора пока есть. Это точно. И мне, кстати, это нравится.

A>>>Хотя казалось бы программирование настолько легко позволяет реализовывать идеи что оно очень быстро должно было до идеала докатиться.
V>>Мелкие идеи — да. Но концептуальные — иногда сложно до невероятия.

A>Воооооооооот, на эти то сложные и жалуюсь! По моему они сложны так именно по глупости отцов основателей и интересов монстров индустрии.
Отцы-основатели решали свои частные задачи. И успешно их решили, за что и считаются отцами-основателями.
Что до монстров индустрии, то им, по большому счёту, на реализацию наших концептуальных идей наплевать. У них другие есть радости жизни.

A>А вы скажите что из этого списка вам незнакомо если вы работаете на одном из лучших продуктов данной категории VS.NET:
A>1) .. 11)
К сожалению (или к счастью?), я имею дело с VS.NET весьма эпизодически. Чаще юзаю VC6. В нём (как бы это сформулировать?) чистоты больше.

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

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

_>>Такую тему бесполезно обсуждать среди программистов. Они тебе скажут, что вообще все технические отрасли (напр. авиация ) все это прошли, а programming нет. Просто мы НИ ХРЕНА не понимаем в авиации, ибо я больше чем уверен, что с точеи зрения авиатора- именно в его области все неодназначно. Ну и далее везде

A>Да но разве объективно народ не более доволен авиацией чем софтом ?! Нету жалоб практически.
ЭЭЭ... просто те, кто имеет жалобы к авиацие, пожаловаться уже не могут...

A>>Рецепт для разных задач разный. Но когда он для одной задачи разный — это кошмар.
V>Свобода выбора пока есть. Это точно. И мне, кстати, это нравится.

свобода выбора — когда вы один выбираете — это супер — а когда все выбирают разное — а вам потом с этим жить — это другое

A>>Воооооооооот, на эти то сложные и жалуюсь! По моему они сложны так именно по глупости отцов основателей и интересов монстров индустрии.
V>Отцы-основатели решали свои частные задачи. И успешно их решили, за что и считаются отцами-основателями.
V>Что до монстров индустрии, то им, по большому счёту, на реализацию наших концептуальных идей наплевать. У них другие есть радости жизни.

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

A>>А вы скажите что из этого списка вам незнакомо если вы работаете на одном из лучших продуктов данной категории VS.NET:
A>>1) .. 11)
V>К сожалению (или к счастью?), я имею дело с VS.NET весьма эпизодически. Чаще юзаю VC6. В нём (как бы это сформулировать?) чистоты больше.

ой — а то VC6 компилит быстрее (я на это дело угробил 3 года жизни) ? пцш файлы не монстр рождённый сном разума ? или соурс сэйф в нём быстрее пашет ? или МФЦ ВТЛ СТЛ и прочие — нормальные библиотеки ?

A>>качество работы такое низкое изза низкой ответственности ?
A>>т.е. спроси с нас строже мы и писать будем супер ОО от зубов ?
V>Не только. Как показывает наша российская реальность последнего времени, чрезмерным закручиванием гаек можно добиться прямо противоположного результата.

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