![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassЧтобы ИТ-индустрия окончательно встала раком, Гуглу сейчас нужно сделать ход конем - разработать ТРЕТИЙ вариант кроссплатформенного языка-платформы с собственной виртуальной машиной, JIT, итд, итп, в дополнение к жабе и дотнету. И сманить девелоперов на него какими-нибудь заманухами страшными.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-08-15 04:46 am (UTC)Но метапрограммирование позволяет сделать из него некое подобие функционального.
Функциональные языки плохо подходят для описания предметной области?
Мой пойнт в том, что математика лучше всего подходит для описания предметной области.
И конструктивная математика тоже очень подходит, например, достаточно мощная интуиционистская логика. А вот уж категории, так и совсем ;-)
Соответственно, языки, в которых можно описывать предметную область близко к математике, очень даже подходят, и моя практика это подтверждает. Правда, иногда думать много приходится, но это не лишние усилия, это окупается!
То же ОО описывается внутри этих языков, если это зачем-то бывает нужно. Даже на Haskell худо-бедно можно описать ОО, хотя и не всегда внешне похожее на то, что стараемся промоделировать.
no subject
Date: 2010-08-15 04:58 am (UTC)Лисп, скорее, императивный.
Но метапрограммирование позволяет сделать из него некое подобие функционального.
Ну для кого как для меня функциональный.
Мой пойнт в том, что математика лучше всего подходит для описания предметной области.
И конструктивная математика тоже очень подходит, например, достаточно мощная интуиционистская логика. А вот уж категории, так и совсем ;-)
В случае когда мы начинаем описывать предметную область математикой мы приходим к математическому аппарату, а это гарантировано порождает полное описание области, даже в тех аспектах которые системой никогда использоваться не будут. Это как следствие порождает громоздкую реализацию. Лучше всего предметную область описывать вербально с выделением сущностей и их взаимодействием. К примеру при помощи use-case диаграмм и представлениями пользователя.
Правда, иногда думать много приходится, но это не лишние усилия, это окупается!
Далеко не всегда. Часто бывает, а давайте сделаем систему! И пока математики формализуют предметную область, программисты уже напишут систему которая будет работать.
no subject
Date: 2010-08-15 05:03 am (UTC)no subject
Date: 2010-08-15 05:10 am (UTC)no subject
Date: 2010-08-15 05:43 am (UTC)Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
no subject
Date: 2010-08-15 05:48 am (UTC)Так как раз проблемы в проектировании системы обычно всплывают в мелочах и подсистемах. Т.е. если разбить на подсистемы и спроектировать наиболее неадекватные куски используя строго теоретические модели - мы уже спасемся от части маразма
Только это займет много времени и часто будет шибко громоздко. Матан оно конечно хорошо, но далеко не всегда.
Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
Конечно. Но приведение предметной области к такой типизации, при помощи логики займет меньше времени, чем приведение ее же но при помощи математики.
no subject
Date: 2010-08-15 05:51 am (UTC)no subject
Date: 2010-08-15 05:56 am (UTC)no subject
Date: 2010-08-15 06:34 am (UTC)Ах, вот оно в чём дело.
Подозревал, но не думал, что такое может быть.
Ну, теперь понятно. Дальше смысла объяснять нет.
(no subject)
From:no subject
Date: 2010-08-15 06:29 am (UTC)Можно даже сказать что-нибудь эдакое -
Из того, что человек что-то программирует, увы, очень часто следует, что это получается крайне криво. И хотя этого можно избежать, и у некоторых даже получается (!), но получается это очень редко и опыт никогда ну никак не удаётся перенять и поэтому, программирование всегда останется кривым, кривым, кривым...
В известном смысле, конструктивная математика, это то же самое, что и программирование. И на сегодняшний день это далеко не только теория, а очень даже практически развитая вещь.
То, что предметная область и требования существенно лучше ложатся не на функциональные языки, это ерунда. Ну, тут мне что-то сказать сложно, ведь может же получиться, что имеется в виду что-то очень новое и неочевидное, чего я не знаю.
Но если имеется в виду ОО, то это полная чушь, предположительно, вызванная двумя возможными причинами - некомпетентностью и/или желанием потроллить.
Без иронии - надеюсь, что я ошибаюсь.
Крайне редко при наличии достаточных описательных возможностей языка нужно ОО. Даже в OCaml, в котором, на мой взгляд, во многих местах система типов откровенно слабоватая, объекты на практике используются довольно редко, да и далеко "не по полной программе". И уж точно, в Haskell привнесение объектов (был такой O'Haskell) оказалось совершенно никому не нужным. А сейчас это сделать уж совсем запросто, если кому-то будет надо, только не нужно это никому.
> имеется моделирование математикой, которая
> хорошо может быть заменена выделением сущностей
> и описанием их взаимодействия.
Это всё равно, как увидеть хуёвый дизайн (пусть даже на любимом ОО-языке), сказать, что это никуда не годится, и переписать на ассемблере, "заменяя выделением сущностей и описанием их взаимодействия".
Математический дизайн тоже бывает плохой! Использование математики, к сожалению, не означает автоматической корректности и удобства работы. Разумеется, первым фактором, влияющим на некую "близость к серебрянной пуле", как и прежде, в первую очередь, остаётся квалификация человека.
Математика даёт возможность ограничить очень много, чего. И затем не допустить многих обшибок, например, по невнимательности или по незнанию (типаа давно писал код, забыл).
Теоретически, есть возможность избежать _всех_ ошибок, сделав полное совпадение с формально описанной спецификацией. Но реально, пока что, это делается довольно редко. Естественно, только потому, что это довольно трудоёмко, но и тут ситуация вполне конкретно переламывается, кстати.
Если найду, покажу измерения в человеко-часах, которые ушли на построение формально верифицированного компилятора C, проект называется Compcert.
Вкратце, даже полностью верифицированная хрень по человеко-часам не очень намного превышала просто хорошо написанный и хорошо оттестированный сишный компилятор. Но у них-то корректность _доказана_, а не протестирована!
no subject
Date: 2010-08-15 06:57 am (UTC)no subject
Date: 2010-08-15 07:01 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-08-15 07:03 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-08-15 04:52 pm (UTC)Нет.
Математика строится на сценариях использования, как и любое другое описание.
По крайней мере, так работают профессиональные математики.
no subject
Date: 2010-08-16 01:27 am (UTC)no subject
Date: 2010-08-16 08:36 am (UTC)"По сценариям выходит, что мы должны протянуть этот файл по всем состояниям. Как бы нам выразить это в нашем ЯП?"
Теперь подойдём с другой стороны.
Будьте добры, докажите, что в вашем подходе не используется математика и что вы не строите полную и непротиворечивую (с точностью до набора сценариев использования) модель предметной области. И чтобы там даже духу конструктивной математики не было.
no subject
Date: 2010-08-16 10:05 am (UTC)Будьте добры, докажите, что в вашем подходе не используется математика
У меня нет никаких математических выкладок по доказательству не противоречивости модели. Только логические выкладки и использование реляционной логики для отражения предметной области в СУБД и построение графов в случае необходимости.
и что вы не строите полную и непротиворечивую (с точностью до набора сценариев использования) модель предметной области.
Строю. Но я не использую при этом математических методов и терминов.
no subject
Date: 2010-08-16 07:25 pm (UTC)Главное, не называть белую обезьяну белой обезьяной. Тогда получится не думать о белой обезьяне.
Принятие математической основы программирования не изменит вашу программистскую жизнь сразу и радикально.
(no subject)
From:no subject
Date: 2010-08-15 06:32 am (UTC)no subject
Date: 2010-08-15 06:49 am (UTC)Для начала, если иметь в виду достаточно мощщную логику (ну там, агда-кок), то так же, как и в функциональщине, только можно накладывать гораздо больше ограничений ;-)
Те же хацкельные паттерны довольно-таки содержательны, только реализовать их надо бы более близко к математике.
Остальное, это онтология, которая тоже довольно неплохо описывается в достаточно мощной логике. Правда, тут очень не хватает автоматического доказательства. И оказывается, что даже какой-то "несчастный" пролог уже много, где рулит ;-)
В идеале, надо заниматься не только онтологией, но и гносеологией-эпистемологией.
no subject
Date: 2010-08-15 09:08 am (UTC)no subject
Date: 2010-08-15 10:37 am (UTC)То есть, при большом желании, конечно, можно выделить время.
Но ведь написать про это не очень просто, а я убеждён,
что мне ещё надо оочень многое читать, вот и стараюсь.
Тем более, что практика у меня ограничивается лишь немного большим,
чем моделирование разного "функционально-категорными" паттернами.
Хотя и это уже довольно сильно и может описать очень многое.
Скажу, что если один тут проект выйдет, то будет
куча статей (в основном, не от меня), в том числе,
и для экономистов, про онтологию экономики предприятия,
и обязательно, про моделирование этого дела категориями,
это уже буду писать я, скорее всего.
Через пару месяцев что-то смогу сказать конкретно.
С одной стороны, код и описание будут открытыми,
но меня попросили не афишировать ето дело до тех пор,
пока оно не станет "достаточно крутым".
Так что, показать смогу, но какбе, "по секрету".
no subject
Date: 2010-08-15 11:04 am (UTC)no subject
Date: 2010-08-15 12:39 pm (UTC)В этом случае получается, как бы, что ты сам формируешь лекцию, наиболее удобную для твоего понимания. И к объясняющему обращаешься, как к базе знаний. Гораздо проще извлечь из памяти что-то, чем думать над тем, как бы это уложить в какую-то целостную структуру типа статьи.
Отчасти, именно поэтому я и прошу всех спрашивать в category_theory, поскольку, ответить на конкретный вопрос гораздо проще для отвечающего, чем подготовить хорошее целостное объяснение.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-08-15 12:52 pm (UTC)Знал бы ты, какие там крутые экономисты!
С другой стороны, если они заинтересовались категориями, то уж точно крутые ;-)
Но имён называть не буду, до поры до времени.
И они заинтересовались категориями, как инструментом для манипулирования онтологиями.
Классно же? ;-)
Заодно, я более внимательно перечитал, что писал про онтологии Осман Бинеев, и это было любопытно.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From: