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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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