Pull to refresh

Comments 13

Интересно, как истории из прошлого.
Сами идеи и предложения — вполне себе стандартные.
Читаем начальные книги по НЛП и связку экономики и психологии по Каннеману.
Врубаемся в цикл Деминга и логико-структурный подход.
Потом изучаем методы системной инженерии и их применение к программированию.
Потом внимательно разбираемся в идеями и воплощением GERAM.
Все что описано в статье уже давно разобрано в этих методологиях (лет 20 назад точно).
Причем все отработано на практике, доведено до моделей и мета-кода.
Не только постановка задачи, но и множество вариантов решения во взаимодействии с реальным миром.
По сути, эти методологии дают интерфейс между детерминированными моделями и реальным не детерминированным миром.
Но в них затронута еще более интересная задача: какими методами работать непосредственно с не детерминированным миром, не всегда стоя детерминированные модели.
Спасибо за анализ. Да, это истории из прошлого. Это и заявлено. И в выводах я не претендовал на оригинальность. Иначе я бы послал статью в академический журнал. А Хабр для меня воспринимается как интеллектуальная завалинка, где каждый волен петь по своему, не ожидая упрека типа: «Ой Маруся, а ведь эту песню пела еще моя бабка!».
С НЛП и Демингом я немного знаком, а вот про GERAM я и не слышвл. Восхищен Вашей эрудицией. Нашел GERAM в Википедии и вижу, что это очень интересно. С удовольствием читаю. Так что ещё раз спасибо.
>> А может Idris…

На самом деле это просто хайп.

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

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

В общем — познакомиться с хайпом можно, просто что бы не было мучительно больно от осознания, что «все знают, а я всё ещё такой тупой!»

Очень верно. Но сам, увы, стал знакомиться с F# и Haskell. Все таки у меня физмат-образование, а я не знаком с языками с синтаксисом, близком к математическому. Познакомлюсь с "«изподвыподвертами». Термин мне понравился и заинтриговал.
Буду держать в голове Ваши советы. Спасибо.
Не совсем понял мысль. Или закралось противоречие. Есть возможность чуть шире развернуть? Ну или просто объяснить где я запутался. В разделе «язык программирования» Вы пишите, что
Есть коряво пишущие знатоки русского языка и есть не совсем грамотные хорошие писатели. Самое замечательное знание языка программирования не обеспечивает хорошего программирования.

И буквально чуть ниже…
И ещё, я не верю, что полуграмотный в родном языке, способен написать грамотный “роман” на языке программирования. Рассказик – может быть, роман – нет.
Да формально есть противоречие. В оправдание скажу вот что.

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

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

Я так понял. что "кто ясно мыслит, тот ясно излагает".

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

А вы про DDD слышали? Вот некоторые вещи хорошо ложатся, а некоторые прямо противоречат, как мне показалось.

Про DDD слышал и просмотрел книгу Эванса. В проекте Бизнес-аналитика я и старался построить модель предметной области, пользуясь ООП.
Вот некоторые вещи хорошо ложатся, а некоторые прямо противоречат, как мне показалось

А можно поподробнее?

Вот єта вот часть:


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

Основной принцип DDD — бизнес и разработка говорят на одном языке и его используют в коде. Если есть разделение разработчиков на проектировщиков и кодеров, то как минимум проектировщики говорят и используют в коде один язык с бизнесом, выдавая внутренние постановки для кодеров на понятном им языке, но именование программных сущностей (модулей, класссов, функий*/процедур, методов, таблиц в БД и т. п.) должно быть на одном языке с бизнесом. Только чисто технические штуки, детали имплементации, могут именоваться непонятным для бизнеса образом типа InMemoryCache или UserFactory

Несомненно. Информационная модель(БД) и объектная модель должны представлять модель предметной области и как можно более изоморфные ей. Поэтому имена объектов, методов, таблиц, отношений, событий должны браться из предметной области.
Тем самым проектировщик освобождался от детального знания предметной области, а мыслил уже в родных терминах.

Вот эта фраза меня смутила конкретно. Типа раз мыслит в родных терминах, а не в доменных, то в коде, базе и ит. п. домен разве сто случайно просочится

Sign up to leave a comment.

Articles