LINUX.ORG.RU

[вброс]Почему объектно-ориентированное программирование провалилось?

 


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Ответ на: комментарий от tailgunner

А если не удобно запихивать сущность в один класс? Если сущность «размазана» по многим классам? С этого и начали ведь. Что тип ООП поддерживает структуру (если сделано разбиение согласно сущностям) и не поддерживает эффективно алгритм. Отношение (relation) - это тип? Преобразование (которое описано в виде алгоритма, каких-нибудь сдвигов, модуло и итераций)?

Если мы начнём не с объекта а с функции (оператора), процесса, и будем делать то - что нам велят правила согласно аттрибутам - может оказаться, что мы неправильно выбрали базис (объектное разбиение) и методы классов будут дёргаться неэффективно много раз. Т.е. для эффективности - появится тьма флагов, чтобы не проходить какое-нибудь большое дерево много раз или не парсить одно и тоже много раз. т.е. неправильное разбиение «аукнется» кучей внутренних артефактов/состояний/переменных. Что потенциально создаст баги.

А почему бы сразу не думать в терминах функции-оператора? А там (для минимализации сложности) - и объекты совсем другими будут. Может эффективно не адрес, а именно строки держать. Или 2 списка: валидные и невалидные индексы. Или вообще столбцы и их отношения across the files (локальная реляционка). Ведь это определяется алгоритмом - что надо сделать.

anonymous
()
Ответ на: комментарий от anonymous

т.е. я стараюсь мыслить в терминах процесса и динамики, что моя Тюринг-машина делает с окружением и как его меняет. Я не думаю в терминах объектов, и это мне помогает. Хотя бы тогда, когда поручают ответственный проект и мне и кому-то ещё, чтобы не завалить. И пару раз получалось, что чек делает через объекты, а потом оказывается, что на большой дате процесс идёт 2 дня. У меня отрабатывает за час. У него ещё и багов полно и он закопался. Хотя объекты какбы. А я знаю, что ничего лишнего я не нагродил, а добавлял объекты (и даже структуры, массивы) только по необходимости, и сильно быстрее это работать не может.

anonymous
()
Ответ на: комментарий от anonymous

> А если не удобно запихивать сущность в один класс? Если сущность «размазана» по многим классам?

Ты же сам сказал «сущность» - значит, на каком-то уровне она едина. Что, конечно, не мешает ей быть набором связанных объектов.

Отношение (relation) - это тип?

Да, конечно.

А почему бы сразу не думать в терминах функции-оператора?

Вполне можно.

А там (для минимализации сложности) - и объекты совсем другими будут.

Но они же будут.

Ведь это определяется алгоритмом - что надо сделать.

Можно c тем же успехом считать, что это определяется спецификацией выходных данных.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> А почему бы сразу не думать в терминах функции-оператора?

Вполне можно.

ну вот я и предлагаю

Ты же сам сказал «сущность» - значит, на каком-то уровне она едина. Что, конечно, не мешает ей быть набором связанных объектов.

таких сущностей сколько угодно, и множества - пересекающиеся. Какой базис выбрать? И надо ли выбирать вообще? Об этом топик. Я не против аттрибутов, а против ранней группировки их по классам! Аттрибуты и объекты - полезны только для выяснения требований. Это всего-лишь язык. Любое же раннее разбиение будет плохим (неэффективным) до полного выяснения всех деталей (что практически невозможно, ведь и спецификации меняются, понимание приходит постепенно, технологии тестируются, а нагрузка меняется). Хотя бы потому что у каждого набора параметров, размеров вводов итд - будет свой минимум (и сложности кода и скорости исполнения).

Это можно проиллюстрировать аналогией с базами данных, где Data Model - это аналог спецификации, общий язык домейна, абстрактные сущности, а вот физическая схема - может быть совсем иная. Уровень нормализации, выбор схемы (т.е. объектов) - диктуется нагрузкой и приоритетом чтения над записью, индексами, количеством/глубиной выполняемых джойнов итд. Т.е. в каком-нибудь OLTP - одни объекты/таблицы (разбиение), а в случае OLAP при тех-же данных - уже совсем другие, в сильно денормализованном виде, и представлены в виде фактов, а не тех старых привычных объектов что были вначале. Таким образом реальная имплементация - будет совсем не та какой казалась, глядя на исходные сущности и мысля о сущностях как таблицах. А может быть база вообще должна быть не реляционная, а иерархическая, или сетевая, или распределённая или поделённая на регионы. И в одном регионе будет одна схема, а в другом - другая. Итд. Т.е. привязка к объектам слишком рано - архивредно. Концепции (problem domain) не должны иметь связи с физической реализацией.

А некоторые ЮМЛьные тулы, курсы и ООП веяния - напрямую пропагандируют преобразовывать объекты домейна - в классы. Или тот же ОРМ. Вот и имеем тормоза или копирование гигабайтных данных через сеть туда-обратно для наполнения данных, в то время как надо вытащить всего лишь одно поле на несколько байт одним джойном в оптимизированной для этого базе данных.

Т.о. я не против объектов, а против раннего завязывания на конкретный базис объектов.

anonymous
()
Ответ на: комментарий от anonymous

под конец девелопмента - пусть будут объекты (так же как после стабилизации DB схемы). Можно даже всё сделать private под конец, чтобы никто не сувался. Но если сунутся - там и более других методов напортачить достаточно.

Я всегда (ещё с 98 года) использовал ЮМЛ (когда требовали) для одной цели: генерации финальной картинки, после окончания девелопмента. Только для показа основных классов, взаимодействий, модулей другим девелперам пост-фактум, после девелопмента - её ценность. Т.е. для документации и для будущих поколений. Но не для дизайна! (да и в первом многие предпочитают всё же дебаггер и сорс).

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Я всегда (ещё с 98 года) использовал ЮМЛ (когда требовали) для одной цели:

генерации финальной картинки, после окончания девелопмента. Но не для дизайна!

Уж сколько раз твердили миру... (с) Иван Крылов

Дизайн сложных проектов:
«снизу-вверх» - для 1 «гения»,
«сверху-вниз» - для многих «человеков».

P.S. anonymous, можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»? :)

quickquest ★★★★★
()
Ответ на: комментарий от quickquest

> P.S. anonymous, можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»? :)

Как подсказывает здравый смысл, начинать проект, типа полёт «Бурана», разумно будет с датчиков и их обвязки, а не с концепции большой кнопки - «Сделай мне заи*ись!».

anonymous
()
Ответ на: комментарий от anonymous

>Как подсказывает здравый смысл, начинать проект, типа полёт «Бурана», разумно будет с датчиков и их обвязки

Заблуждение. Любой большой проект начинают с абстрактного «чёрного_ящика», постепенно уточняя его свойства и функции. Технические требования на датчики (масса, габариты, обвязка, ...) тебе выдали бы только после завершения эскизного проекта всего «Бурана».

При методе «сверху-вниз» конечная цель оказывает постоянное воздействие на разрабатываемые средства достижения этой цели.

При методе «снизу-вверх» мы имеем «разброд и шатание», характерное для «гнутого софта».

quickquest ★★★★★
()
Ответ на: комментарий от quickquest

> Заблуждение.

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

Любой большой проект начинают с абстрактного «чёрного_ящика», постепенно уточняя его свойства и функции.

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

Технические требования на датчики (масса, габариты, обвязка, ...) тебе выдали бы только после завершения эскизного проекта всего «Бурана».

Кто выдал бы? Тебе? Зачем тебе? Чисто поэкспериментировать: сколько ошибок ты допустишь при быдлокодинге? Чушь какая-то.

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

Технические требования на датчики

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

При методе «сверху-вниз» конечная цель оказывает постоянное воздействие на разрабатываемые средства достижения этой цели.

Блин, где ж вас таких дрессируют то, а?

При методе «снизу-вверх» мы имеем «разброд и шатание», характерное для «гнутого софта».

«разброд и шатания» - у тебя в голове. При методе «снизу-вверх» мы имеем, к примеру, драйвера, а не пишем их каждый раз, когда абстракция добирается до уровня физической реализации.

anonymous
()
Ответ на: комментарий от anonymous

> Ты реально полагаешь, что эскизный проект «Бурана» рисовал сначала художник, а уже потом отдал посчитать всякую мелочевку инженерам?

А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

P.S. А ты там можешь полагать, что тебе угодно.

anonymous
()
Ответ на: комментарий от anonymous

>> А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

Да ради ТНБ. Только вот сначала его просчитывают весь, а потом просчитывают узлы.

P.S. А ты там можешь полагать, что тебе угодно.

А ты можешь настаивать на том, на чем тебе угодно.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Да ради ТНБ. Только вот сначала его просчитывают весь, а потом просчитывают узлы.

Прально! Т.к. у «Буранов» модель ЖЦ какбэ каскадная. И функциональные требования определяются с самого начала, и не меняются. Никто посредине проекта не станет превращать «Буран» в гусеничный глубоководный танк.

А софтом ситуация кардинально другая: тебования к нему... Да что там требования! Сама предметная область постоянно меняется. А значит подходы к проектированию нужны другие.

Macil ★★★★★
()
Ответ на: комментарий от Macil

> А софтом ситуация кардинально другая

Не кардинально. На самом деле, для больших систем она даже не сильно отличается.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>На самом деле, для больших систем она даже не сильно отличается.

Не согласен. Например, для экономических ИС требования постоянно уточняются и пересматриваются.


Для потребительского коммерческого софта ситуация похожа: он постоянно должен следовать «модным трендам».

Macil ★★★★★
()
Ответ на: комментарий от Macil

>> На самом деле, для больших систем она даже не сильно отличается.

Не согласен. Например, для экономических ИС

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

tailgunner ★★★★★
()
Ответ на: комментарий от quickquest

> можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»?

не вижу тз.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от tailgunner

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

тут ты еще хотел, _видимо_, что-то сказать про время жизни проекта, не?

жизнь такова, что «требования» меняются +/- 6-7 раз в год.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Rastafarra

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

тут ты еще хотел, _видимо_, что-то сказать про время жизни проекта, не?

Ну я сказал про «большие системы» - их время жизни велико по определению. И изменение архитектуры стоит от «дорого» до «неприемлимо дорого».

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>архитектура определяется раз и навсегда

Архитектура — в какой-то степени да. Но меняется законодательство, иногда достаточно серьезно. Иногда государство аццки отжыгает.

Меняются бизнес-процессы. Иногда настолько кардинально, что все ранее сделанное приходится пересматривать.

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

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

Macil ★★★★★
()
Ответ на: комментарий от anonymous

>А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

Дык, эскизный проект - это и есть предварительний расчёт базовых характеристик изделия,
а не картинка художника.
Действует триада: НИР - ОКР - Рабочее проектирование.
НИР: «чёрный ящик» -> эскизный проект
ОКР: эскизный проект -> рабочий проект
Рабочее проектирование: рабочий проект -> готовое изделие.

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


Удивить не сможешь, ибо самых важных наук нет!

Подождите пока материаловеды обеспечат материалы с нужными нам свойствами и мы сразу же сделаем вам датчики, удовлетворяющие вашим требованиям!


Именно так! В ВПК, где я участвовал в некоторых достаточно больших разработках, типовая система: «генерал» -> представитель_заказчика(ПЗ) -> начальник -> разработчик -> материаловед.
«Генерал» формулирует требования к «чёрному ящику», ничего не зная о возможностях материаловеда.

При методе «снизу-вверх» мы имеем, к примеру, драйвера,


Драйвер, в отличие от больших проектов, может быть написан 1 человеком «снизу-вверх», а мы обсуждаем коллективное творчество, где метод «сверху-вниз» незаменим.

quickquest ★★★★★
()
Ответ на: комментарий от Macil

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

И это известно уже лет 30-40. Давно признано, что разработка итеративна, но крупная разработка начинается именно сверху вниз.

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

Ха-ха. Более чем возможно, инфа 100%

tailgunner ★★★★★
()
Ответ на: комментарий от quickquest

опять всё смешали в кучу. Хотя нет, объектники (жаба программисты) не только почти отобрали работу у проф. дизайнеров сайтов (в начале 2000х), начав страницы лабать на JSP/JSTL/JSF, забрав и традиционные формы и css (благо ситуация с аяксом поменялась), но и желают отнять работу у бизнес-аналитиков (экспертов домена). Не слишком ли много самоуверенности?

Объясняю: определение требований пишется экспертами в виде спецификации, на языке близком к человеческому, возможно с кусками превдокода. И те знатоки домена, процессов, бизнеса - единственный кто понимает всё до мелочей. Только они могут описать что им нужно, кто-же ещё? Вот они и делают «сверху-вниз». Потом (в идеале) перед программистами кладут мануал (спек) с диаграммами, требованиями, описаниями, скетчами возможных экранов. Где программисту остаётся выбрать технологии и транслировать человеческий язык в язык машины. А программисту - гораздо проще «снизу-вверх», с этого момента.

можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»? :)

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

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

Т.е. когда я говорю о «снизю-вверх» - я говорю исключительно о девелоперах (о чём топик), а не о планировании, разработке требований, написании мануалов функциональной спецификации, технической спецификации. Последние - не для жаба-программистов, а для экспертов домена!

anonymous
()
Ответ на: комментарий от tailgunner

>>> А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

Только вот сначала его просчитывают весь, а потом просчитывают узлы.

Весь? Правда?

Расскажи, как? Как его просчитывают весь сразу? Или рассказывай, что ты понимаешь под словом «весь»?

anonymous
()
Ответ на: комментарий от anonymous

>определение требований пишется экспертами в виде спецификации, на языке близком к человеческому

СЖИГАТЬ! Током низкого напряжения!

домена


Предметной области, камрад.

перед программистами кладут


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

Запомни простую истину. Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов», потому что программисту хошь-нехошь, а формализовывать задачу придется. А «эксперты» зачастую умеют только болтать, да качественно иметь мозг и втирать очки начальству.

Macil ★★★★★
()
Ответ на: комментарий от quickquest

> Любой большой проект начинают с абстрактного «чёрного_ящика», постепенно уточняя его свойства и функции. Технические требования на датчики (масса, габариты, обвязка, ...) тебе выдали бы только после завершения эскизного проекта всего «Бурана».

Ещё раз: вы не разделяете работу бизнес-аналитиков (домейн-экспертов) и программистов - в больших проектах. Программер придёт в конце, после завершения спецификаций (в идеале) и всё напишет на удобном ему языке, используя технологии, которые впишутся в требования. И сделает он это «снизу-вверх», если нормальный программист. Либо архитект напишет работающую «козу», поймёт где какие модули, даст модули писать рядовым программистам и те свои куски тоже напишут «снизу-вверх», постоянно контролируя ситуацию в своём модуле, имея на каждом этапе работающую программу с юнит тестами.

В реале же (когда не устаканены детали) и короткие сроки (что в общем-то бардак) - бизнес и программисты работают одновременно: первые рефайнят спецификацию, заполняя белые пятна спецификации, программисты пишут по устаканеному спеку. И вот здесь искусство программиста - угадать возможные изменения, создать гибкие структуры. Но и здесь завязываться на сотни объектов - себе на голову.

Чем больше классов - тем больше рефакторинга. Классов должно быть как можно меньше. О чём я и говорил изначально. Я начинаю с минимума, вообще с процесса и обстрактной обработки (ингода сам не знаю чего), абстрактного парсинга, процессинга, репортинга итд, практически лепя темплейты. Мне и классы не нужны: это последовательность функций. По мере понимания объёма задачи, отпочковываем процедуры, которые могут быть переданы другим программистам. Но в виде последовательного, линейного пайплайма процессинга заметьте, а не сотен классов и разных методов и объяснения другим - что каждый класс делает. А именно второму учит как некое откровение ООП, разве не так?

anonymous
()
Ответ на: комментарий от anonymous

>И уверен - что если бы были SDLC в то время и авто-генерация объектов из ЮМЛей - Буран бы не полетел, потому что суперсложную систему так бы и не релизнули из-за багов и невозможность их починить из-за сложности.

Для «Бурана» был сделан советский аналог UML - «ДРАКОН».
Почитай историю создания софта для этого проекта и попробуй найти там разработку «снизу-вверх».

quickquest ★★★★★
()
Ответ на: комментарий от Macil

> Запомни простую истину. Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов», потому что программисту хошь-нехошь, а формализовывать задачу придется.

Блин! Это должны были быть мои слова! Понятие формализация задачи было ключевым.

А «эксперты» зачастую умеют только болтать, да качественно иметь мозг и втирать очки начальству.

«Эксперты» необходимы. Как правило, у них есть теоретические обоснования и наработки по технологической базе.

anonymous
()
Ответ на: комментарий от Macil

> СЖИГАТЬ! Током низкого напряжения!

не всё так однозначно. Во-первых, часто бывает старая документация. Которая устаканена годами. И для новой имплементации (например, переделка из проприетарных давно ушедших технологий) - нужно всего-то добавить новые требования к первоначальным спекам. Во-вторых, в больших конторах очень много бизнес-аналитиков экспертов предмета, которые поддерживают бизнес (они не программисты!). А программистов не напасёшься. Например, сегодня веб, а со вчера из программеров только кобольщики остались. Таки надо нанимать веб-программистов, своих-то нет. Кто знает процесс? А бухи, а профессиональные математики-статистики, которые программируют на каком-нибудь SAS и всё. И научить их нормально программировать - либо займёт 20 лет, либо скорее - бесконечность.

anonymous
()
Ответ на: комментарий от Macil

> Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов»

А еще он не существует, настоящий.

tailgunner ★★★★★
()
Ответ на: комментарий от quickquest

уверен: это был бизнес-язык, максимум псевдо-код (по ссылкам не ходил, сорри) и он не генерил классы. Иначе бы не полетело и уж точно бы не прилетело. Ещё раз: я же не против DSL, а только за. Я - против генерации кода. Против прямого маппинга объектов предметной области на объекты языка (мой пример с DB схемой: я же не против схемы! Но любой дб спец скажет что логическая шема и физическая - это 2 разные вещи. А адепты ООП ЮМЛ кодогенерации не понимают).

anonymous
()
Ответ на: комментарий от Macil

> Запомни простую истину. Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов», потому что программисту хошь-нехошь, а формализовывать задачу придется. А «эксперты» зачастую умеют только болтать, да качественно иметь мозг и втирать очки начальству.

тебе не повезло с экспертами. Есть спецы, кроме SAS или экселевских макросов ни на чём не программирующих, но они - эксперты и знают область. Надо долго поработать - чтобы так знать.

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

anonymous
()
Ответ на: комментарий от quickquest

> В 1983 году разработчики космического корабля Буран обратились в Институт [прикладной математики] с просьбой помочь в разработке бортового программного обеспечения и программного обеспечения наземных испытаний корабля. По их оценкам для этой работы требовалось несколько тысяч программистов.

Как полагаешь, это подход «сверху-вниз» или «снизу-вверх»?

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

Создание DSL - означает решение задачи «снизу-вверх».

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

Прослойка обеспечила проблемно-ориентированный интерфейс к оборудованию.

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

Они сделали инструмент (a`la driver), своеобразное приспособление для решения поставленной задачи.

anonymous
()
Ответ на: комментарий от anonymous

>Как правило, у них есть теоретические обоснования и наработки по технологической базе.

А вот это уже зависит. От многих факторов.

Понятие формализация задачи было ключевым.


Кстати, UML как раз для этого придумали. Уж лучше такой формализм, чем никакого. Опять же. Буч — хреновый пиарщик, его вообще к написанию книг по UML нельзя было допускать. И установка «мы говорим UML, подразумеваем RUP» совсем не способствует.

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

Macil ★★★★★
()
Ответ на: комментарий от tailgunner

>А еще он не существует, настоящий.

Я как-то раз видел. ;)

Macil ★★★★★
()
Ответ на: комментарий от anonymous

или прикинь - диагнозы всех болезней. Я что - медицинский должен был ещё заканчивать? Да и после него буду сырым новичком, так как надо ещё в госпиталях десятилетия отпахать. А задача, например - сделать регрессионный анализ и предиктить что-то. Или статистику посчитать. Я даже не знаю что от чего зависит, т.е. не могу даже ламерские решения принять: могу ли использовать линейную регрессию итд. Это всё спецы должны делать, а не я кодер. А я отвечаю за технологии и чтобы работало не 2 дня, а 2 часа.

anonymous
()
Ответ на: комментарий от anonymous

> Как полагаешь, это подход «сверху-вниз» или «снизу-вверх»?

сверху-вниз конечно же. Опять двадцать пять. Я не против планирования. Планирование всего-лишь не должно включать планирование классов!

anonymous
()
Ответ на: комментарий от Macil

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

Ильич тоже наверное хотел как лучше.

А вот последние 10 лет я воюю исключительно с пионерами, поднимающими Буча на щит и генерящих классы, требовавших от меня поработать в дизайнере (тот который архитект) - чтобы волшебным образом нагенерит всяких классов. А там мол и быдлокодеры методы заполнят и всё. Это ли не идеализм и отсутствие практики? Несколько раз разгребал проекты где всё упёрлось в сложность именно из-за генерации. Или где объектов с начальных фаз девелопмента - туча. А обойтись можно одной функцией и парой тысяч строк кода в ней (о кей, о кей, я разбиваю на классы под конец - чтобы умещалось на экран ;)

anonymous
()
Ответ на: комментарий от anonymous

>бывает старая документация

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

Возвращаясь в онтопик, скажу что система типов ЯП в какой-то мере пытается это сделать. Изоморфизм Карри-Ховарда еще никто не отменял.

Macil ★★★★★
()
Ответ на: комментарий от Macil

> Кстати, UML как раз для этого придумали.

Я знаю UML и даже всеми (7ю?) диаграммами пользуюсь, рисуя на доске для важности, когда надо. Я зол на то, как его используют и для чего. И кто.

Помянем IDL, корбу (тоже поработал когда-то). Теперь ждём когда наконец загнутся ejb, jms, xml и далее бесконечный список который пишут сегодня в резюме.

anonymous
()
Ответ на: комментарий от anonymous

>> Как полагаешь, это подход «сверху-вниз» или «снизу-вверх»?

сверху-вниз конечно же.

Ещё раз: с точки зрения разработки автоматизированной системы управления, разработка DSL обеспечивает подход «сверху-вниз». Тут и спорить бессмысленно. :) Но, с точки зрения разработки проекта «Буран», разработка DSL для системы управления представляет собой низкоуровневую работу с оборудованием, т.е. подход «снизу-вверх», несмотря на тот факт, что DSL должен учитывать высокоуровневую модель постановки задачи.

DSL - это драйвер, промежуточный слой спроектированный снизу, от оборудования к задаче, в масштабах всего проекта «Буран».

Опять двадцать пять. Я не против планирования. Планирование всего-лишь не должно включать планирование классов!

Ну, планирование, по определению, как процесс, подразумевает подход «сверху-вниз». :)

anonymous
()
Ответ на: комментарий от anonymous

>я воюю исключительно с пионерами

У пионерии есть одно замечательное свойство: проходит со временем. Все мы ломаем массу дров. Я вот до сих пор ломаю, пытась по-пионерски закидать шапками сложную проблему, не видя полной несостоятельности своих действий ;)

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

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

Macil ★★★★★
()
Ответ на: комментарий от anonymous

> Кстати, UML как раз для этого придумали.

забыл сказать главное- из-за чего затевал предыдущий пост. бизнес-людей (экстремальный случай - бухгалтеры) - колбасит от UML, это не для них. И никакой формализм не покатит. Они гумманитарии. (тогда зачем полдороги - сразу уж их посадить за нормальный язык и ничего самому делать не надо было). Или САСники, которые уже пишут в макросах. Что бы сразу на си или жабе не писать?

Я вот долго воевал с регулярными выражениями. Написал упрощенный вариант им, и транслирую в регэкспы. Но даже тот упрощенный вариант - замучиваются править: одни ошибки, одни ошибки, хотя 2 сосны всего. А вот дело своё знают.

anonymous
()
Ответ на: комментарий от anonymous

>Теперь ждём когда наконец загнутся ejb, jms, xml и далее бесконечный список который пишут сегодня в резюме.

Лично я жду, когда загнется SQL и будет использоваться Datalog ;))

Macil ★★★★★
()
Ответ на: комментарий от Macil

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

я проработал все 2000е на контрактах (кроме последних 3х лет). Много где был, включая в штатах. По моему опыту - таких было подавляющее большинство. Серьёзные люди только островками.

что творится сейчас - даже боюсь себе представить

anonymous
()
Ответ на: комментарий от Macil

Лично я жду, когда загнется SQL и будет использоваться Datalog ;))

не дождётесь (C) :) (легаси же, да и реляционная алгебра как она есть с точности до переименования операторов)

anonymous
()
Ответ на: комментарий от Macil

> У пионерии есть одно замечательное свойство: проходит со временем.

Есть остаточный эффект. Вдруг говорят: «да, плохо. Но стандард же уже!» А ты: «как? когда? когда успели?» И надо разгребать...

Вон жена тоже разгребала только что: несколько десятков строк, специальный фреймвок для открытия файлов, и все фреймвоки в мире от спринга до ejb. У них svn то нормально не работает, ошибки одни, ничего не собирается, никто в сложности не разбирается. А всё туда же - все фреймвоки впихнуть, клептомания какая-то. А большая компания, миллиионы юзеров.

anonymous
()
Ответ на: комментарий от anonymous

Короче, подытоживая, скажу, что то что сложилось с фреймвоками, EJB (кешить объекты! да ещё и на отдельных серверах!) - всё это вина ООП. Неправильного упора на него, вместо того чтобы учить алгоритмам и программированию. А не ознакомлением с объектами в процессе обучения - как всего-лишь частном случае структур. И никаких кодогенераций.

anonymous
()
Ответ на: комментарий от Macil

забыл послать коммент на это

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

да, это сейчас модно. Моделировать и смотреть на графический буфер - что там получится. Вон и Вольфрам экспериментирует. Тут кажется обсуждалось. Я тоже было предложил непрерывность по Коши проверять, увеличивая резолюцию буфера и смотря на пиксеми (а чё - всё строго согласно определению :)

думаю, у этого направления большое будущее.

anonymous
()
Ответ на: комментарий от Macil

> Лично я жду, когда загнется SQL и будет использоваться Datalog ;))

Может надо ждать более активно?

А то я у тебя спрашивал хорошую книжку по даталогу, желательно в эл. виде, а ты (вроде) и не ответил ;-)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Ага, щас только галоши надену...

А то я у тебя спрашивал хорошую книжку по даталогу


У меня? Я что-то запамятовал. Хорошей книжки по даталогу я не знаю. Скажем так, нечто описано в Д. Ульман, Д. Уидом «Основы реляционных баз данных» aka First Course in Database Systems. Но достаточно походя. Зато есть ссылки на другие труды.

Есть различные исследовательские проекты. Язык OverLog, даталог-подобный язык для описания оверлейных (P2P) сетей. Что-то вроде есть в Racket (PLT Scheme). Есть библиотечка на Clojure.

Macil ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.