![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Ход раком
Чтобы ИТ-индустрия окончательно встала раком, Гуглу сейчас нужно сделать ход конем - разработать ТРЕТИЙ вариант кроссплатформенного языка-платформы с собственной виртуальной машиной, JIT, итд, итп, в дополнение к жабе и дотнету. И сманить девелоперов на него какими-нибудь заманухами страшными.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
no subject
Я бы поостерёгся называть лисп функциональным.
А какой он? Вот тот что я изучал состоял из списков и функций. Как-то остального там не наблюдалось.
Называть питон "мультипарадигменным" и говорить, что он может выступать в качестве функционального, я бы тоже поостерёгся.
Он не является мультипарадигменным. Ну да есть там некоторые фишки функционального языка, но от этого функциональным он не становится.
Предлагаю показать, в чём недостаток Agda2/Coq в описании предметной области.
Или хотяябы Haskell (у него-то такие недостатки есть, но аргументировать будет сложно).
В случае лиспа могу сказать, что как минимум, он не хуже, чем любой динамический язык, на выбор.
Спасибо конечно но не хочу. В том числе не хочу использовать Haskell в продакшене. По той самой причине, что его знают и под него пишет мало людей.
no subject
Но метапрограммирование позволяет сделать из него некое подобие функционального.
Функциональные языки плохо подходят для описания предметной области?
Мой пойнт в том, что математика лучше всего подходит для описания предметной области.
И конструктивная математика тоже очень подходит, например, достаточно мощная интуиционистская логика. А вот уж категории, так и совсем ;-)
Соответственно, языки, в которых можно описывать предметную область близко к математике, очень даже подходят, и моя практика это подтверждает. Правда, иногда думать много приходится, но это не лишние усилия, это окупается!
То же ОО описывается внутри этих языков, если это зачем-то бывает нужно. Даже на Haskell худо-бедно можно описать ОО, хотя и не всегда внешне похожее на то, что стараемся промоделировать.
no subject
Лисп, скорее, императивный.
Но метапрограммирование позволяет сделать из него некое подобие функционального.
Ну для кого как для меня функциональный.
Мой пойнт в том, что математика лучше всего подходит для описания предметной области.
И конструктивная математика тоже очень подходит, например, достаточно мощная интуиционистская логика. А вот уж категории, так и совсем ;-)
В случае когда мы начинаем описывать предметную область математикой мы приходим к математическому аппарату, а это гарантировано порождает полное описание области, даже в тех аспектах которые системой никогда использоваться не будут. Это как следствие порождает громоздкую реализацию. Лучше всего предметную область описывать вербально с выделением сущностей и их взаимодействием. К примеру при помощи use-case диаграмм и представлениями пользователя.
Правда, иногда думать много приходится, но это не лишние усилия, это окупается!
Далеко не всегда. Часто бывает, а давайте сделаем систему! И пока математики формализуют предметную область, программисты уже напишут систему которая будет работать.
no subject
no subject
no subject
Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
no subject
Так как раз проблемы в проектировании системы обычно всплывают в мелочах и подсистемах. Т.е. если разбить на подсистемы и спроектировать наиболее неадекватные куски используя строго теоретические модели - мы уже спасемся от части маразма
Только это займет много времени и часто будет шибко громоздко. Матан оно конечно хорошо, но далеко не всегда.
Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
Конечно. Но приведение предметной области к такой типизации, при помощи логики займет меньше времени, чем приведение ее же но при помощи математики.
no subject
no subject
(no subject)
(no subject)
no subject
Можно даже сказать что-нибудь эдакое -
Из того, что человек что-то программирует, увы, очень часто следует, что это получается крайне криво. И хотя этого можно избежать, и у некоторых даже получается (!), но получается это очень редко и опыт никогда ну никак не удаётся перенять и поэтому, программирование всегда останется кривым, кривым, кривым...
В известном смысле, конструктивная математика, это то же самое, что и программирование. И на сегодняшний день это далеко не только теория, а очень даже практически развитая вещь.
То, что предметная область и требования существенно лучше ложатся не на функциональные языки, это ерунда. Ну, тут мне что-то сказать сложно, ведь может же получиться, что имеется в виду что-то очень новое и неочевидное, чего я не знаю.
Но если имеется в виду ОО, то это полная чушь, предположительно, вызванная двумя возможными причинами - некомпетентностью и/или желанием потроллить.
Без иронии - надеюсь, что я ошибаюсь.
Крайне редко при наличии достаточных описательных возможностей языка нужно ОО. Даже в OCaml, в котором, на мой взгляд, во многих местах система типов откровенно слабоватая, объекты на практике используются довольно редко, да и далеко "не по полной программе". И уж точно, в Haskell привнесение объектов (был такой O'Haskell) оказалось совершенно никому не нужным. А сейчас это сделать уж совсем запросто, если кому-то будет надо, только не нужно это никому.
> имеется моделирование математикой, которая
> хорошо может быть заменена выделением сущностей
> и описанием их взаимодействия.
Это всё равно, как увидеть хуёвый дизайн (пусть даже на любимом ОО-языке), сказать, что это никуда не годится, и переписать на ассемблере, "заменяя выделением сущностей и описанием их взаимодействия".
Математический дизайн тоже бывает плохой! Использование математики, к сожалению, не означает автоматической корректности и удобства работы. Разумеется, первым фактором, влияющим на некую "близость к серебрянной пуле", как и прежде, в первую очередь, остаётся квалификация человека.
Математика даёт возможность ограничить очень много, чего. И затем не допустить многих обшибок, например, по невнимательности или по незнанию (типаа давно писал код, забыл).
Теоретически, есть возможность избежать _всех_ ошибок, сделав полное совпадение с формально описанной спецификацией. Но реально, пока что, это делается довольно редко. Естественно, только потому, что это довольно трудоёмко, но и тут ситуация вполне конкретно переламывается, кстати.
Если найду, покажу измерения в человеко-часах, которые ушли на построение формально верифицированного компилятора C, проект называется Compcert.
Вкратце, даже полностью верифицированная хрень по человеко-часам не очень намного превышала просто хорошо написанный и хорошо оттестированный сишный компилятор. Но у них-то корректность _доказана_, а не протестирована!
no subject
no subject
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
no subject
Нет.
Математика строится на сценариях использования, как и любое другое описание.
По крайней мере, так работают профессиональные математики.
no subject
no subject
"По сценариям выходит, что мы должны протянуть этот файл по всем состояниям. Как бы нам выразить это в нашем ЯП?"
Теперь подойдём с другой стороны.
Будьте добры, докажите, что в вашем подходе не используется математика и что вы не строите полную и непротиворечивую (с точностью до набора сценариев использования) модель предметной области. И чтобы там даже духу конструктивной математики не было.
no subject
Будьте добры, докажите, что в вашем подходе не используется математика
У меня нет никаких математических выкладок по доказательству не противоречивости модели. Только логические выкладки и использование реляционной логики для отражения предметной области в СУБД и построение графов в случае необходимости.
и что вы не строите полную и непротиворечивую (с точностью до набора сценариев использования) модель предметной области.
Строю. Но я не использую при этом математических методов и терминов.
no subject
Главное, не называть белую обезьяну белой обезьяной. Тогда получится не думать о белой обезьяне.
Принятие математической основы программирования не изменит вашу программистскую жизнь сразу и радикально.
(no subject)
no subject
no subject
Для начала, если иметь в виду достаточно мощщную логику (ну там, агда-кок), то так же, как и в функциональщине, только можно накладывать гораздо больше ограничений ;-)
Те же хацкельные паттерны довольно-таки содержательны, только реализовать их надо бы более близко к математике.
Остальное, это онтология, которая тоже довольно неплохо описывается в достаточно мощной логике. Правда, тут очень не хватает автоматического доказательства. И оказывается, что даже какой-то "несчастный" пролог уже много, где рулит ;-)
В идеале, надо заниматься не только онтологией, но и гносеологией-эпистемологией.
no subject
no subject
То есть, при большом желании, конечно, можно выделить время.
Но ведь написать про это не очень просто, а я убеждён,
что мне ещё надо оочень многое читать, вот и стараюсь.
Тем более, что практика у меня ограничивается лишь немного большим,
чем моделирование разного "функционально-категорными" паттернами.
Хотя и это уже довольно сильно и может описать очень многое.
Скажу, что если один тут проект выйдет, то будет
куча статей (в основном, не от меня), в том числе,
и для экономистов, про онтологию экономики предприятия,
и обязательно, про моделирование этого дела категориями,
это уже буду писать я, скорее всего.
Через пару месяцев что-то смогу сказать конкретно.
С одной стороны, код и описание будут открытыми,
но меня попросили не афишировать ето дело до тех пор,
пока оно не станет "достаточно крутым".
Так что, показать смогу, но какбе, "по секрету".
no subject
no subject
В этом случае получается, как бы, что ты сам формируешь лекцию, наиболее удобную для твоего понимания. И к объясняющему обращаешься, как к базе знаний. Гораздо проще извлечь из памяти что-то, чем думать над тем, как бы это уложить в какую-то целостную структуру типа статьи.
Отчасти, именно поэтому я и прошу всех спрашивать в category_theory, поскольку, ответить на конкретный вопрос гораздо проще для отвечающего, чем подготовить хорошее целостное объяснение.
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Знал бы ты, какие там крутые экономисты!
С другой стороны, если они заинтересовались категориями, то уж точно крутые ;-)
Но имён называть не буду, до поры до времени.
И они заинтересовались категориями, как инструментом для манипулирования онтологиями.
Классно же? ;-)
Заодно, я более внимательно перечитал, что писал про онтологии Осман Бинеев, и это было любопытно.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)