я уже не помню но когда то увлекался изобретательством и в 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-ечку.
natural born flamer
Re: закон эволюции систем и его применимость к индустрии ИТ
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 нет. Просто мы НИ ХРЕНА не понимаем в авиации, ибо я больше чем уверен, что с точеи зрения авиатора- именно в его области все неодназначно. Ну и далее везде
Re[2]: закон эволюции систем и его применимость к индустрии
_>Такую тему бесполезно обсуждать среди программистов. Они тебе скажут, что вообще все технические отрасли (напр. авиация ) все это прошли, а programming нет. Просто мы НИ ХРЕНА не понимаем в авиации, ибо я больше чем уверен, что с точеи зрения авиатора- именно в его области все неодназначно. Ну и далее везде
Да но разве объективно народ не более доволен авиацией чем софтом ?! Нету жалоб практически.
Вы слышали когда нибудь имя владельца боинга ? А имя владельца майкрософт у всех на слуху изза судебных процессов.
natural born flamer
Re[3]: закон эволюции систем и его применимость к индустрии
_>>Такую тему бесполезно обсуждать среди программистов. Они тебе скажут, что вообще все технические отрасли (напр. авиация ) все это прошли, а 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) Каковы алгоритмы решения программистских задач? (Речь идет об > алгоритмах творчества. Просьба не путать с численными алгоритмами, > которые достаточно хорошо изучены.
Многие пытались адаптировать ТРИЗ к программированию — получается плохо.
Слишком большая степень свободы. Скажем, в механических системах детали
обычно взаимодействуют с максимум десятком других деталей, и их
взаимодействия можно хорошо промоделировать.
> Это позволит нам, наконец, понять, /чему и как обучать > профессиональных программистов/. Сейчас с обучением просто беда, как у > нас, так и в остальном мире. Мы программируем методом проб и ошибок, > тупо перебирая все возможные варианты, пока не найдем подходящий. > Отсюда разброс производительности: правильный вариант может попасться > в начале или в конце перебора. Только с годами накапливается некий > интуитивный опыт: «куда надо ходить, а куда — нет». Задача – > ограничить пространство перебора. Во сколько раз ограничим, во столько > раз повысим эффективность производства ПО.
Так тут уже другая проблема — можно слишком ограничить пространство
решений.
Здравствуйте, Cyberax, Вы писали:
C>Многие пытались адаптировать ТРИЗ к программированию — получается плохо.
Согласен, адаптировать ТРИЗ, вряд ли, имеет смысл. Программные системы нечто совершенно новое, по сравнению с техническими системами, которые имеют тысячелетнюю историю. Законы развития программных систем, вероятно, другие. Поэтому стоит говорить не об адаптации ТРИЗ к программированию, а о применении методологического подхода, который использовался при ее построении, и о создании «Теории решения программистских задач».
C>Так тут уже другая проблема — можно слишком ограничить пространство C>решений.
А чем это плохо, если мы будем уверены, что в ограниченном пространстве находятся решения не хуже, чем вне него?
Да есть ваш ТРИЗ для программирования — десятки ТРИЗов есть.
ООП, АОП, паттерны, рефакторинг ну и т.д.
а воз где ?
по моему проблема в том что если программист пишет новую программу — нового в ней концептуально всегда больше чем в новой модели автомобиля.
и не потому, что она действительно такая новая, а просто потому что основные подходы в проектировании (те же паттерны) недостаточно широко применяются и изучаются. Почему ? Потому что они весьма абстрактно подаются. По моему в университетах после прохождения основ программирования и ОО надо сразу же начинать преподавать типовые примеры пронрамных проектов: модели сохранения данных и их применимость, построение документно ориентированных приложений, построение программ учёта, программ документооборота, серверов, тонких, толстых клиентов и т.д. Вы скажете что это слишком узко ! Но тем не менее именно так обучают инженеров на всех других специальностях. Эти преподанные схемы покроют 90% проблем при проектировании на самом деле. И преподавать их надо не "прочтите главу, пройдите тест" а реально — чтоб от зубов. В этом смысле Фаулер молодец бы был если бы его книжка не так ориентировалась на конкретный язык и технологии. Более того — несмотря на то что прошло 50 лет и исписаны талмуды — общей точки зрения на то какойдолжна была бы быть книжка фаулера нет !!! Опять же в одних случаях с теми то тулзами выгоднее так, в других — по другому. Как ? Выбор слишком широкий получается — акомбинация выриантов — вообще запредельной. И как с этим бороться ?
craft-brother пишет:
> C>Многие пытались адаптировать ТРИЗ к программированию — получается > плохо. > Согласен, /адаптировать/ ТРИЗ, вряд ли, имеет смысл. Программные > системы нечто совершенно новое, по сравнению с техническими системами, > которые имеют тысячелетнюю историю. Законы развития программных > систем, вероятно, другие. Поэтому стоит говорить не об адаптации ТРИЗ > к программированию, а о применении методологического подхода, который > использовался при ее построении, и о создании «Теории решения > /программистских/ задач».
Так нету единой теории, так как нет единой задачи программирования. А
частностей — куча. В ООП — смотри про паттерны, в процедурном
программировании — Кнут, в функциональщине тоже свои методы есть.
> C>Так тут уже другая проблема — можно слишком ограничить пространство > C>решений. > А чем это плохо, если мы будем уверены, что в ограниченном > пространстве находятся решения не хуже, чем вне него?
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>первый вариант — всегда практически. Отсюда и все наши беды.
Это не беда, это закон экономики: «спрос рождает предложение». А как управлять спросом это вопрос не сюда, а скорее в маркетинг.
«Пиплы хавают» (с) Б.Титомир
Здравствуйте, antidogm, Вы писали:
A>Авиаконструктор, строиттель
Не может??? То то я гляжу в новых квартирах отклонение реальной ситуации от плана бывает по несколько десятков см., а кривые стены уже никого не удивляют. А если бы в разработку единичной софтинки вкладывалось столько же денег, сколько в разработку самолета, софт бы вылизан до блеска.
CB>Это не беда, это закон экономики: «спрос рождает предложение». А как управлять спросом это вопрос не сюда, а скорее в маркетинг. CB>«Пиплы хавают» (с) Б.Титомир
Так мало того что хавают — таким софтом мы создаём кучу новых проблем и сами же их (за отдельные деньги ! решаем (тоже из рук вон плохо))
Т.е. потребитель сам виноват в плохом качестве продукции ?
A>Т.е. потребитель сам виноват в плохом качестве продукции ?
Думаю, что виноватых искать задача неблагодарная.
В данной ситуации потребителя разводят рекламой продюсеры поп-софта (на мой взгляд, аналогия с поп-культурой полная). А бизнес-потребитель пока не очень продвинутый: красивше творений Церителли (да еще за дешево и быстро!) ничего не видел. Вряд ли, на БЦВМ баллистических ракет купят что-нибудь от MS.Хотя, из суеверия стучу по дереву, не дай Бог.
Re[2]: К вопросу о построении «Теории решения программистски
Например, одним из свойств, но далеко не единственным, идеальной программы, может быть то, что требования к ней должны быть сформулированы на языке, для которого существует компилятор. Это не маниловщина. Сейчас активно «копают» в этом направлении, например, xUML. и не только.
А на Ваш взгляд, какие еще могут быть свойства у идеальной программной системы?
) говорим (см. сабж)? 
