Мнение: объектно-ориентированное программирование — катастрофа на триллион долла - Философия программирования

Здравствуйте, Sinclair, Вы писали:

I>>Вот что бы был девелопер со слабой квалификацией и херачил на ФП — за двадцать лет такого ни разу не видел.
S>Вот что странно: значительная доля данных в мире ворочается через SQL. В том числе и девелоперами со слабой квалификацией. Безо всякой, надо сказать, императивщины. Это, конечно, не настоящее ФП, но тем не менее.

Пример с SQL хороший. Цитирую по памяти твои же слова: "Большинство программистов его не знают. Большая часть оставшихся думают, что знают."

S>Значительная доля расчётов в мире делается в Excel. В основном — тётеньками, которые алгоритм Евклида даже под страхом смерти не смогут заучить и пересказать. Это, конечно, тоже не настоящее ФП, но тем не менее.

Обычно так — ктото накидал шаблон, который эти тётеньки используют. Если надо самостоятельно покрыть все кейсы нового законодательства — заказывают новый шаблон.

S>То есть я так думаю, что проблема не в непостижимости самого ФП, как такового, а в неготовности реальных ФП-языков к целевой аудитории.

Несоответствии требованиям раныка.

S>Ну, то есть у нас же и в ИП всё не сразу зажглось — начиналось то всё вовсе не с шарпов и джавы, и даже не с С++, а со всяких там Кобола, Ады и Фортрана.
S>Это сейчас мы имеем этот офигенный ландшафт с понятными и удобными языками. А вы попробуйте написать современный сервер приложений на фортране-77, где даже поддержка строк сделана через ж. На её фоне даже сишный char* выглядит белым и пушистым.

Сейчас в разработчики повсеместно идут люди, которые с трудом пишут фильтр, а группировка считается невозможным скилом. Через лет 10 таких будует большинство. Потому рулить будет снова не ФП, а тупой примитивный язык который легко генерировать и на котором сносно можно будет чинить многочисленные мелкие баги. И у таких "чинильщиков" ЗП снова будет выше чем у инженеров.

Здравствуйте, varenikAA, Вы писали:

AA>>>и нарушаешь инкапсляцию?

I>>Инкапсуляция решает вполне конкретные задачи. Нет таких задач — не надо за неё и держаться. Самое главное в ООП это структуризация решения сложной задачи, и, как следствие, организация взаимодействия.

AA>А как же передача сообщения для вызова реакции на объекте? Прямой доступ к данным объекта есть прямое нарущение принципов ООП.

ООП это одновременно и те вещи, что с инкапсуляцией, и те вещи, что без неё. "три кита ООП" это давно уже устаревшее трактование.

Здравствуйте, Poopy Joe, Вы писали:

PJ>Питон сливает хаскелю, а то и f#, примерно всегда, тем не менее это мало кого останавливает от его использования.

А уже XML то и вовсе в минусах, сравнивая с Хаскелем!!!!1111расрасодиндватри
Ниша Питона — склейка числодробилок. Здесь Хаскелем даже не пахнет, более того — питон сдул вообще всех, кто стоял как рядом, так и поотдаль.

Здравствуйте, Ikemefula, Вы писали:
I>Думать человек может по всякому, но мир вокруг него изменяемый. И в первую очередь речь отражает именно это.
I>А вот уже позже, не раньше 16ти лет, у человека появляется полноценное абстрактное мышление. У большинства оно внятно и не проявится, кстати говоря.
I>Я про это и пишу — ФЯ не приживаются, а приживаются отдельные вещи. Фактически, императивное дополняет функциональное и наоборот. Аналогично с ФП и ООП.

S>>Совсем отказаться от императивщины не получится никак — из-за той же аппаратуры, которая не сводится к идее "абстрактного вычислителя без побочных эффектов". С другой стороны, сидеть в голой императивщине — очень невыгодно.

I>В твоей картине отсутствует тот, кто пишет код. А вот тенденция такая, что все больше и больше людей идет в разработчики. Фактически, появляются каменщики, бетонщики, арматурщики, маляры, штукатуры и тд — люди, которые выполняют ровно одну задачу.
I>И что характерно, у них уже нет ни то классного инженерного образования или, ни, тем более, прикладной или теоретической математики. А чем же они могут пользоваться, если абстрактное мышление у них слабовато ?
Вот это — большой вопрос. Грубо говоря, в екселе вся "программа" на виду. Если криворукий финансист будет допиливать решение на своём листе, то он запорет только своё решение.
Императив требует понимания не только "статической" картинки, но и динамики — как состояние изменяется со временем.
Большинство ошибок в императиве именно оттуда — у человека есть какая-то картинка, типа "заказ создают, потом аттачат платёж, потом проводят платёж, потом отгружают, потом закрывают".
И он пишет код для каждого этапа в святой уверенности, что он представляет себе состояние заказа в момент начала своей программы.
А потом оказывается, что совсем другой человек дописал ещё кусочек, и теперь у нас действие "отгрузка" происходит до действия "оплата", и всё взрывается из-за деления на букву О.
Причём оба человека свои кусочки по отдельности протестировали, и сходу ткнуть в ошибку ни в одном из них нельзя.

И это мы всё ещё про однопоточное императивное программирование, как в алгоритме Евклида — где у нас состояния r и q меняет только наша программа.
А если мы добавим в нашу систему обработки заказов возможность с другого терминала запустить действие "оплата" после начала, но до окончания действия "отгрузка", то у непривычных людей начинает взрываться мозг.
Лично я очень-очень хорошо помню свои впечатления при переходе к конкурентным изменениям общих данных — попервости реально голова кружилась.
Потом стало полегче, но до сих пор я удивляюсь некоторым коллегам на этом форуме, которые могут сходу ткнуть в race condition прямо в С++ коде!
А ведь я себя шибко тупым не считаю. Тем не менее, мои способности в уме построить модель вычислений, и сопоставить потоки исполнения в разных сочетаниях уступают таким пацанам в разы.

Что мы будем делать с малярами и каменщиками? Чисто-линейных приложений типа "калькулятор" становится всё меньше. Мы всё больше пилим data-intensive applications с массовыми совместными изменениями разделяемых данных; кто будет отлаживать всю вот эту лапшу, которую наши флюсоподобные специалисты напишут на императивном языке?

Выход один — вообще не давать этим людям шанса работать с состоянием. Только декларативное ФП.

Здравствуйте, Poopy Joe, Вы писали:

PJ>Это верно почти всегда, за исключением числодробительных алгоритмов, которые ни от чего больше не зависят. Ты неверно понимаешь IO. Это не только запись и чтение с диска, это вообще любое взаимодействие с внешним миров. Таймер это IO, любое прерывание от устройства это IO, итд. И их скорость не идет ни в какое сравнение со скоростью CPU.

Это всё здорово, но вы так и не продемонстрировали io-bound приложение на функциональных языках.

S>>Вот, например тесты производительности. В них функциональщина сливает по производительности практически всегда. Из особо показательных тестов: C# vs F# — функциональный вариант уступает императивному, исполняющемуся в той же среде (net core).

PJ>Сравнение f# и c# неверно в принципе, потому что f# ограничен возможностями oo clr. По сути это c# код с дополнительными конструкциями. Разумеется он будет медленнее.

Нет. И C# и F# транслируются в CIL, и далее исполняются идентично. То есть F# — это именно F#, а не C# с функциональщиной.
Поэтому этот тест показывает именно падение производительности при использовании функционального подхода.

PJ>В остальном это не сравнение приложений, а сравнение алгоритмов, (неизвестно насколько оптимально реализованных), которые, возможно, вносят нулевую разницу в общую скорость. Разумеется есть места где надо максимальную производительность любой ценой, но обычно такое место очень ограничено и нет никаких проблем использовать там любой язык.

Можете посмотреть другие тесты — функицональные языки в них совсем не блещут.

PJ>Питон сливает хаскелю, а то и f#, примерно всегда, тем не менее это мало кого останавливает от его использования.

Ну да — потому что у питона есть преимущества, которые нивелируют тормознутость. А вот тот же Хаскель как-то не светится в массовых проектах — видимо с преимуществами не особо.

Здравствуйте, alex_public, Вы писали:

I>>>Мы можем моделировать разные вещи при помощи Integer. При этом тип будет HouseNumber, Identifier, Key, Index и тд. Соответсвенно типы разные, а какая унутре неонка — дело десятое.
ltc>>А какие ныне существуют языки, которые позволяют легко подобное делать?

_>Можно даже пойти дальше, например ввести зависимости между типами. Более того, это всё можно увидеть в готовой библиотечке (https://www.boost.org/doc/libs/1_71_0/doc/html/boost_units.html) привносящей ровно 0 накладных расходов.

Посмотрел по диагонали, не понял где там зависимости между типами, можешь пальцем ткнуть?

Библиотечка интересная, но все-таки это частный случай для СИ, а хотелось бы что-то более общее и поддержку на уровне языка.
Чтобы ad hoc порождать новые типы из имеющихся:
type diceNumber : int[min=1, max=6]
type hexString : string[acceptedSymmbols="1..9,A..F", caseInsensitive]
type myIdentifier : hexString[maxLegth=16]

Здравствуйте, varenikAA, Вы писали:

AA>>>идут по пути все большего ограничения возможностей (из книги "Чистая архитектура" Р.М.):
AA>>>1. Структурное программирование накладывает ограничение на прямую передачу управления.
AA>>>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

AA>Как-то так. Нет?

Как-то сложно сформулировано.

AA>1. оператор goto — усложняет понимание логики.

Усложняет понимание и накладывает ограничение ни одно и тоже. А вызво ф-ии по адресу (делегат) разве запрещен? Тоже ведь косвенная передача управления.

AA>2. запрет на прямой изменение памяти — путем перемещения стека функции в кучу, т.е. создание объекта, который через вызовы функций по указателю(методы объекта) изменяет значения переменных связанных с этим объектом(его поля).

Я бы не назвал косвенную передачу управления нарушением инкапсуляции. Опять же какие-то путанные определения. Не косвенная передача управления, а неявное изменение состояния, наверное, так?

Здравствуйте, Sinclair, Вы писали:

I>>В твоей картине отсутствует тот, кто пишет код. А вот тенденция такая, что все больше и больше людей идет в разработчики. Фактически, появляются каменщики, бетонщики, арматурщики, маляры, штукатуры и тд — люди, которые выполняют ровно одну задачу.
I>>И что характерно, у них уже нет ни то классного инженерного образования или, ни, тем более, прикладной или теоретической математики. А чем же они могут пользоваться, если абстрактное мышление у них слабовато ?
S>Вот это — большой вопрос. Грубо говоря, в екселе вся "программа" на виду. Если криворукий финансист будет допиливать решение на своём листе, то он запорет только своё решение.

Финансист запорет всю контору своим файликом. Я сколько ни видел таких файликов, они приходят в readonly, что бы абы кто не редактировал. То есть, слишком рисковано доверять одному специалисту в другой области.

S>Императив требует понимания не только "статической" картинки, но и динамики — как состояние изменяется со временем.
S>Большинство ошибок в императиве именно оттуда — у человека есть какая-то картинка, типа "заказ создают, потом аттачат платёж, потом проводят платёж, потом отгружают, потом закрывают".
S>И он пишет код для каждого этапа в святой уверенности, что он представляет себе состояние заказа в момент начала своей программы.
S>А потом оказывается, что совсем другой человек дописал ещё кусочек, и теперь у нас действие "отгрузка" происходит до действия "оплата", и всё взрывается из-за деления на букву О.
S>Причём оба человека свои кусочки по отдельности протестировали, и сходу ткнуть в ошибку ни в одном из них нельзя.

Аналогично и в функциональном, если другой человек дописал еще какой то кусочек. Все ровно то же — нужно понимание динамики.

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

А что, в функциональном не надо думать про это ? Можно подумать все запросы к базе сами выстроятся в нужном порядке.

S>Что мы будем делать с малярами и каменщиками? Чисто-линейных приложений типа "калькулятор" становится всё меньше.

Этих приложений становится всё больше. Когда будет пройдет пик — хрен его знает.

>Мы всё больше пилим data-intensive applications с массовыми совместными изменениями разделяемых данных; кто будет отлаживать всю вот эту лапшу, которую наши флюсоподобные специалисты напишут на императивном языке?

Не сильно знаю, чего именно вы пилите, но везде спрос на фронтов у которых основной скилл это CSS+JS и минимальные навыки кодинга и базовые алгоритмы на уровне "простой фильтр по массиву".

S>Выход один — вообще не давать этим людям шанса работать с состоянием. Только декларативное ФП.

Теоретически, к этому идет, даже на фронте распространяется redux. Одна проблема — такие вещи для многих почему то слишком сложны

Здравствуйте, Ikemefula, Вы писали:

I>Финансист запорет всю контору своим файликом. Я сколько ни видел таких файликов, они приходят в readonly, что бы абы кто не редактировал. То есть, слишком рисковано доверять одному специалисту в другой области.
В теории — да, а на практике почти все компании строят бюджетные процессы именно в экселе. Все эти дорогущие SAP, Oracle Hyperion и прочее используются только в конце, когда сливают подготовленные данные.
Относительно сообразительная девочка в финотделе разрабатывает шаблон "служебной записки". В него забиваются данные региональными офисами, где вообще народ дальше от программирования, чем декабристы от народа.
Да, иногда эти служебки приходится причёсывать, иногда приходится орать на людей по телефону, но постепенно все осваивают вот этот "DSL" с кодами расходов в колонке B и кодами подразделений в колонке D.
И всё это прекрасно работает без вмешательства каких-либо бизнес-аналитиков или программистов; и финотдел наруливает ежегодно новые проверки и правила — по типу "расходы на капремонт в этом году не могут быть больше расходов на капремонт в прошлом году" или "расходы на ФОТ не могут быть больше 8% от запланированной маржи".

I>Аналогично и в функциональном, если другой человек дописал еще какой то кусочек. Все ровно то же — нужно понимание динамики.
Да вроде нет. Нет никакой особенной динамики; есть работа с состояниями.

I>А что, в функциональном не надо думать про это ? Можно подумать все запросы к базе сами выстроятся в нужном порядке.
Ну, я пока не видел учётных систем, построенных на ФП. Но, по идее, в отличие от императивы, мы можем формально проверить, что все пререквизиты есть — и действие "отгрузка" просто не выполнится, пока нет оплаты, даже если программист это руками не проверил.

I>Не сильно знаю, чего именно вы пилите, но везде спрос на фронтов у которых основной скилл это CSS+JS и минимальные навыки кодинга и базовые алгоритмы на уровне "простой фильтр по массиву".

может и правда, фронтов больше чем бэков. А может это просто непонимание такое — я когда в заказной разработке работал, постоянно сталкивался с тем, что ТЗ на публичную морду написано в мельчайших деталях, а когда задаешь вопросы по бэк-офису, у всех прямо ступор. Типа "ну вот разместил человек заявку; кто будет её выполнять?", а в ответ такое: "выполнять?.... БЛЯ!".
Потому что набегавшие пацаны делали анализ на основе того, что они видят у других. То есть приходит такой чувак, и говорит: "сколько стоит сделать веб-сайт из двух страниц: на одной — поле ввода и кнопка; на другой — список с постраничной навигацией". Ну, ему говорят, типа "24 часа по $15 в час, плюс 16 часов на тестирование, если вам надо QA". Он говорит: "ок, я согласен, давайте подробный план".
Его спрашивают: "а что должна делать кнопка?" Он отвечает: "Ну, как гугл. Находить все документы в китайском интернете, в которых содержатся слова, которые можно построить из введённых пользователем иероглифов".

I>Теоретически, к этому идет, даже на фронте распространяется redux. Одна проблема — такие вещи для многих почему то слишком сложны

Здравствуйте, Poopy Joe, Вы писали:

_>>Как раз определяется в очень большой степени. Потому что оперативная память — это жуткий тормоз по сравнению с процессором (хуже неё только IO). В какой-то степени эти тормоза компенсирует кэш процессора, но только в том случае, если им правильно пользоваться. Так вот, ФП как раз приводит к максимально не правильному использованию кэша...
PJ>Общая скорость определяется самым медленным элементом. Иногда это память, иногда процессор, но в 99% это IO. Именно оно и определяет в большей степени.

Ага, ага. ))) И именно поэтому современные серверы представляют из себя сотни ядер процессора и сотни гигабайт оперативки, имея при этом точной такой же IO (грубо говоря гигабитную сетевую карту), как и дохлый ноут.

PJ>Штука в том, что места где узкое место это числодробилка, они сами по себе небольшие, в сравнении с остальной частью, и часто имеют альтернативные решения в виде GPU или FPGA.

Во-первых в память упираются чаще как раз не числодробилки, а более классическое ПО. А во-вторых даже если говорить о подобных вычислениях на GPU или FPGA, то опять же там совершенно не наблюдается чистого ФП.

_>>О, забавно. Ты тут умудрился в одном предложение и высказать абсолютно верное утверждение и наврать на 100%. В реальности практически любой канонический ФП код серьёзно ускорится при его умелом переписывание на императивном подмножестве C/C++.
PJ>Смелое и бездоказательное утверждение. Я точно так же могу возразить, что в реальность практически любой кода останется примерно таким же. Какой-то, да, станет быстрее, какой-то сделать быстрее написать будет намного сложнее. И чем сложнее код, тем эта вероятность выше.

Это утверждение вполне обосновано множествами тестов, которые многократно обсуждались на этом форуме (лень повторяться). Более того, в случае использования ФП не в языке типа C++/D (это тоже там без проблем реализуется), а в каком-нибудь из канонических ФП языков (типа Хаскеля) со сборщиком мусора, у нас будет наблюдаться тормоза второго порядка. Т.е. если взять языки типа Java/C#, то они являются существенными тормозами относительно C++ в основном из-за использованной модели памяти (которая приносить лишний уровень косвенности, убивающей многие оптимизации процессора). А языки типа Хаскеля используют близкую к Java/C# модель памяти и поверх её тормозов накладывают ещё один уровень вытекающий из обязательной иммутабельности данных (увеличение расхода памяти и копирований, уменьшение локальности).

_>> Однако в 90% случае это просто не нужно, как раз потому, что этот код не является бутылочным горлышком (это не означает что он такой же быстрый, как на C/C++, а означает что его быстродействия хватает для выполнения бизнес-задач — быстрее просто не нужно).
PJ>Я ровно это и сказал. Хоть на ассемблере перепиши, если приложение ждет сетевой пакет, или просто реагирует на таймер, его общая скорость никак не изменится от переписывания. Где я тут чего наврал?

Наврал ты в том, что сказал "код никак не ускорится от переписывания на C/C++". По факту он ускорится и существенно. Просто это ускорение может быть не нужно для тех задач, которые решает данное ПО. Более того, в большинстве случаев это так и есть. К примеру сайты пишут на C++ только компании типа Гугла, Яндекса, Фейсбука (ну и ещё Шеридан, но это отдельный вопрос

), потому что для них выгода от увеличения быстродействия имеет смысл. А скажем мои сайты написаны на Питоне (хотя C++ я знаю на порядки лучше того же Шеридана), т.к. железо спокойно справляется с нагрузкой и важнее удобство и скорость написания. И у большей части сайтов в интернете аналогичная ситуация — их всех можно существенно ускорить, только никому это не нужно (какая разница будет CPU сервера занято на 10% или на 2%).

Вот, очень правильная мысль. Питон применяют тогда, когда удобство важнее быстродействия (хотя не всё так просто — в некоторых областях Питон делает всех за счёт использования специальных C библиотек, но это отдельная тема).

В случае ФП ситуация похожая, но несколько сложнее, потому как это парадигма, а не какой-то один язык. И соответственно ФП можно использовать в очень разных языках и ситуациях. Лично я бы выделил для обсуждения два стереотипных случая:

1. Использование ФП в любом языке программирования (большинство мейнстрим языков сейчас поддерживают эту парадигму) только в том случае, если она хорошо ложится на конкретный алгоритм (весьма актуально например для различных трансформаций, особенно конвейерных). Обычно это не приводит к замедлению или неудобству, а только повышает гарантии корректности кода. Процент подобного кода в приложение существенно зависит от предметной области, но в любом случае меньше 100%.

2. Попытка использования ФП для всего приложения (и как квинтэссенция такого подхода — чистые функциональные языки типа Хаскеля, навязывающие данную парадигму для всего приложения без вариантов), наплевав на то, что для многих типов задач (включая такие распространённые, как GUI) это не только не эффективно, но и банально неудобно. На мой взгляд таким могут заниматься только конченные фанатики, для которых "принципы" важнее удобства и эффективности.

P.S. Сам я с большим удовольствием пользуюсь ФП, но естественно только по первому сценарию.

Здравствуйте, Sinclair, Вы писали:

_>>Как раз определяется в очень большой степени. Потому что оперативная память — это жуткий тормоз по сравнению с процессором (хуже неё только IO). В какой-то степени эти тормоза компенсирует кэш процессора, но только в том случае, если им правильно пользоваться. Так вот, ФП как раз приводит к максимально не правильному использованию кэша...
S>За всё ФП не скажу, но декларативщина никак не противоречит "правильному использованию кэша" — например потому, что позволяет выполнять семантические оптимизации.
S>Грубо говоря, императивщина может быстро отсортировать массив, благодаря умелому использованию inplace операций и cache-friendly порядку обращений к массиву.
S>А декларативщина может определить, что только что отсортированный массив не нуждается в повторной сортировке, и выкинуть весь вызов сортировки целиком.

Ну так при таком взгляде данные подходы не конкурируют между собой, а дополняют друг друга. Что мне кажется очень правильным. Главное не пытаться решать обе задачи одним подходом...

Здравствуйте, Somescout, Вы писали:

PJ>>Это верно почти всегда, за исключением числодробительных алгоритмов, которые ни от чего больше не зависят. Ты неверно понимаешь IO. Это не только запись и чтение с диска, это вообще любое взаимодействие с внешним миров. Таймер это IO, любое прерывание от устройства это IO, итд. И их скорость не идет ни в какое сравнение со скоростью CPU.

S>Это всё здорово, но вы так и не продемонстрировали io-bound приложение на функциональных языках.

Продемонстрировали http://rsdn.org/forum/philosophy/7541051.1 Хаскель обогнал не кого нибудь, а Питон и Жээс! Это тебе не хухры мухры, завоевание мира Хаскелем можно считать открытым.

Здравствуйте, Sinclair, Вы писали:

S>Ну, то есть у нас же и в ИП всё не сразу зажглось — начиналось то всё вовсе не с шарпов и джавы, и даже не с С++, а со всяких там Кобола, Ады и Фортрана.

Я бы заменил в списке язык Ада на PL/1. Во-первых, PL/1 — любимый язык автора темы, а его до сих пор никто не вспомнил. А во-вторых Ада — это 1979 год, уже немножко другой уровень. В нем, ЕМНИП, даже объекты есть. Фортран и Кобол в 1979 году уже пытались отменить, но безуспешно. До сих пор работают.

S>Это сейчас мы имеем этот офигенный ландшафт с понятными и удобными языками. А вы попробуйте написать современный сервер приложений на фортране-77, где даже поддержка строк сделана через ж. На её фоне даже сишный char* выглядит белым и пушистым.

Здесь бы я тоже предложил написать сервер на PL/1. В конце концов Фортран был и остается переводчиком формул. А PL/1 делали универсальным.
Поддержка строк в Ф77 — хорошо, что ее туда вообще ввели. В Ф4 строковых переменных не было, зато строковых констант, ЕМНИП, было аж 3 вида.

Вообще говоря, на Фортране 77 написать сервер не так чтобы совсем невозможно. Но это будет дорого. Скажется отсутствие многопоточности, автоматических переменных. Придется зпускать несколько экземпляров программы под управлением диспетчера, написать который — тоже не самая тривиальная задача.

Вот матан я бы взялся на нем делать.

Здравствуйте, ltc, Вы писали:

_>>Можно даже пойти дальше, например ввести зависимости между типами. Более того, это всё можно увидеть в готовой библиотечке (https://www.boost.org/doc/libs/1_71_0/doc/html/boost_units.html) привносящей ровно 0 накладных расходов.
ltc>Посмотрел по диагонали, не понял где там зависимости между типами, можешь пальцем ткнуть?

Нуу смотри, если ты напишешь в своём коде F=m*a (где, F имеет тип quantity<force>, m — quantity<mass>, a — quantity<acceleration>), то всё отлично скомпилируется. А если ты напишешь F=m*v (где v имеет тип quantity<velocity>), то получишь ошибку компиляции. Но при этом код F=m*v/t отлично скомпилируется...

ltc>Библиотечка интересная, но все-таки это частный случай для СИ, а хотелось бы что-то более общее и поддержку на уровне языка.

Эм, ты вообще то спрашивал "А какие ныне существуют языки, которые позволяют легко подобное делать?". Вот я тебе показал пример языка, который позволяет это легко делать. И да, это C++, а не C. Язык C подобное не позволяет.

ltc>Чтобы ad hoc порождать новые типы из имеющихся:
ltc>type diceNumber : int[min=1, max=6]
ltc>type hexString : string[acceptedSymmbols="1..9,A..F", caseInsensitive]
ltc>type myIdentifier : hexString[maxLegth=16]

Не вижу никаких проблем сделать подобное на шаблонах C++. Синтаксис будет вида:

using diceNumber=min_max<int, 1, 6>;
using hexString=filtered<string, [{1,9},{A,F}], caseInsensitive>;
using myIdentifier=limited<hexString, 16>;

Да и большинство динамических языков тоже по идее должно справляться, правда там это всё будет медленно и без проверок на этапе компиляции.

Здравствуйте, alex_public, Вы писали:

ltc>>Библиотечка интересная, но все-таки это частный случай для СИ, а хотелось бы что-то более общее и поддержку на уровне языка.

_>Эм, ты вообще то спрашивал "А какие ныне существуют языки, которые позволяют легко подобное делать?". Вот я тебе показал пример языка, который позволяет это легко делать. И да, это C++, а не C. Язык C подобное не позволяет.

Я имел в виду, конечно, международную систему единиц (Complete SI and CGS unit systems are provided), а не язык.

В остальном — спасибо.

Здравствуйте, varenikAA, Вы писали:

AA>

~~Половина~~ две трети статьи — вода.

> Когда вы знаете 95% Lisp, вы знаете 90% Clojure. Этот простой скобочный синтаксис и есть вся фишка синтаксиса в данных языках. Они абсурдно просты.

Мне нравится как слово "примитивный" пытаются подменить "простым".

Здравствуйте, ltc, Вы писали:

ltc>Здравствуйте, alex_public, Вы писали:

I>>>>Мы можем моделировать разные вещи при помощи Integer. При этом тип будет HouseNumber, Identifier, Key, Index и тд. Соответсвенно типы разные, а какая унутре неонка — дело десятое.
ltc>>>А какие ныне существуют языки, которые позволяют легко подобное делать?

_>>Можно даже пойти дальше, например ввести зависимости между типами. Более того, это всё можно увидеть в готовой библиотечке (https://www.boost.org/doc/libs/1_71_0/doc/html/boost_units.html) привносящей ровно 0 накладных расходов.

ltc>Посмотрел по диагонали, не понял где там зависимости между типами, можешь пальцем ткнуть?

ltc>Библиотечка интересная, но все-таки это частный случай для СИ, а хотелось бы что-то более общее и поддержку на уровне языка.
ltc>Чтобы ad hoc порождать новые типы из имеющихся:
ltc>type diceNumber : int[min=1, max=6]
ltc>type hexString : string[acceptedSymmbols="1..9,A..F", caseInsensitive]
ltc>type myIdentifier : hexString[maxLegth=16]
Лично мне кажется, что основной затык тут будет в lifted operations.
То есть вот объявили мы такой подтип. А дальше? Откуда возьмутся операторы типа operator++(dicenumber dice), или operator+(hexString, string)? Хотя бы их сигнатуры?
В прямолинейном подходе у нас hexString ковариантен с обычным string; тогда hexString+string => string. Ну ок, совпадает с интуитивно ожидаемым, "вася"+hexString("BADFOOD") не является hexString.
Но уже тип результата hexString("BAD")+hexString("FOOD") вызывает сомнения: если мы пользуемся неявной приводимостью к string, а своих операторов у hexString нету, то конкатенация получает string, который к hexString нужно приводить руками

.
Если же мы попробуем схитрить, и слифтить операторы из типа-родителя, типа для всех операторов (string, string)->string мы порождаем такие жа операторы с сигнатурами (hexString, hexString)->hexString, то тогда мы напоремся на неожиданности с первым и третьим примерами: myIdentifier + myIdentifier нифига не даст myIdentifier, как и diceNumber(4)+diceNumber(4) не даст в итоге diceNumber.
Вообще, взаимоотношения подтипов, ограниченных предикатами, являются крайне нетривиальной темой.
Я не вижу сходу способа сделать эту поддержку достаточно общим способом. Независимо от языка.

Здравствуйте, Sinclair, Вы писали:

ltc>>Чтобы ad hoc порождать новые типы из имеющихся:
ltc>>type diceNumber : int[min=1, max=6]
ltc>>type hexString : string[acceptedSymmbols="1..9,A..F", caseInsensitive]
ltc>>type myIdentifier : hexString[maxLegth=16]
S>Лично мне кажется, что основной затык тут будет в lifted operations.
S>То есть вот объявили мы такой подтип. А дальше? Откуда возьмутся операторы типа operator++(dicenumber dice), или operator+(hexString, string)? Хотя бы их сигнатуры?
S>В прямолинейном подходе у нас hexString ковариантен с обычным string; тогда hexString+string => string. Ну ок, совпадает с интуитивно ожидаемым, "вася"+hexString("BADFOOD") не является hexString.
S>Но уже тип результата hexString("BAD")+hexString("FOOD") вызывает сомнения: если мы пользуемся неявной приводимостью к string, а своих операторов у hexString нету, то конкатенация получает string, который к hexString нужно приводить руками

.
S>Если же мы попробуем схитрить, и слифтить операторы из типа-родителя, типа для всех операторов (string, string)->string мы порождаем такие жа операторы с сигнатурами (hexString, hexString)->hexString, то тогда мы напоремся на неожиданности с первым и третьим примерами: myIdentifier + myIdentifier нифига не даст myIdentifier, как и diceNumber(4)+diceNumber(4) не даст в итоге diceNumber.
S>Вообще, взаимоотношения подтипов, ограниченных предикатами, являются крайне нетривиальной темой.
S>Я не вижу сходу способа сделать эту поддержку достаточно общим способом. Независимо от языка.

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

	От:	varenikAA
	Дата:	19.09.19 08:46
	Оценка:	-1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	19.09.19 08:56
Оценка:	+1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	19.09.19 09:05
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	19.09.19 09:29
Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	19.09.19 09:36
Оценка:	1 (1)