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

_>Утомил меня этот наш бестолковый спор о терминах.

Спор начали вы, видимо обидевшись за C++ на слово "нетипизированный".

_>Вы пытаетесь цепляться за придуманные вами же определения и не обращаете внимания на смысл вообще.

Определение выдумал не я, на смысл внимание обращаю. Это вы выдумываете какие-то странные подвиды "используемого кода".

_>Предлагаю простейшее разрешение вопроса. Раз вы считаете, что шаблоны C++ нетипизированные, то тогда просто приведите ровно один любой пример, в котором из-за этой нетипизированности будет создаваться некорректно работающее ПО.

Ну опять двадцать пять. Работающее (запускающееся) ПО будет типизировано до того, как запустится. Мы говорим про обобщенный код, который никогда не запускается. В плюсах он и не типизируется. Не потому, что это не нужно, или наоборот для чего-то нужно, чтоб типизации не было. Это просто не сделано при разработке шаблонов.

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

I>Открой для себя семантику программирования, это дисциплина которая занимается построением и изучением математических моделей для всех языковых конструкций. На каком именно базисе будет построено ООП, не в курсе

См. мой ответ Синклеру (ниже).

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

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

Нет, речь не про такие инструменты. А например про UML и ещё множество других из этой же области.

I>В общем случае если мы сделаем АПИ для этого фремворка в разных языках, внезапно, будет разница в том, что как эффективно использовать и где за каким деталями придется следить.
I>Вот в С++ ты точно не сможешь избавиться от указателей, инстанцирований, деклараций шаблонов, указания типов и тд и тд и тд
I>А в Хаскеле — запросто.

Ну вот простой пример. Надо нам написать Блокнот, скажем под виндой (типа дефолтного).

Попробуем в начале без всяких мощных фреймворков. Естественно при этом будет гора кода с функциями, классами (хотя не обязательно) и т.п.

На чистом C++ будет естественно жуть, т.к. WinAPI.
На чистом Python'е будет дважды жуть. Т.к. и WinAPI и ещё надо до него добраться (внешний вызов).
На чистом Haskell'e будет трижды жуть. Т.к. и WinAPI и внешние вызовы и всё это будет внутри монадного кода.

Теперь возьмём какую-нибудь мощную библиотечку. Например wxWidgets или Qt (к ним есть биндинги отовсюду).

На C++ весь код превратился в одну страницу, причём там код простейший, представляющий собой исключительно вызовы функций библиотечки.
На Python'e будет буквально такой же код, как и на C++. Т.е. с точностью до замены скобочек на отступы.
На Haskell'е ситуация будет чуть хуже за счёт монадного мусора, но если приравнять его к своеобразному аналогу скобочек, то снова получится буквально такой же код.

I>DSL как правило это небольшая, очень узкая область математики

Тогда 1С придумывал математик под кайфом. )))

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

S>Всё совершенно наоборот. Нет никаких "не вписывающихся в концепцию" нюансов; ФП с самого начала эквивалентно МТ (см. Тезис Чёрча).
S>ФП честно объясняет: у вас нет никакого "глобального вычислителя", который неявно передаётся от команды к команде.

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

S>Если вам нужно состояние — то вы описываете его явно.

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

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

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

S>Ваши рассуждения про резервацию должны бы быть применимы к любой другой монаде — например, к монаде List, или Optional. Но почему-то вам кажется, что IO/ST — это какая-то отдельная резервация, а Optional — это нормальный ФП код.

1. Optional и List не связаны с нарушением чистоты.
2. Optional и List имеют личный функциональный смысл. Поэтому их подобия встречаются во многих языках. В то время как IO и ST не имеют подобного смысла и являются всего лишь порождением сомнительного дизайна языка.

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

Дело не в том откуда её вызывают, а в том что мы вызываем в ней. Там будут системные вызовы, т.е. снова сплошная монада IO.

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

S>См. https://www.google.ru/search?q=theory+of+classification+site:jot.fm Чистая математика, вся концепция ООП в виде формул.

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

Т.е. если там в качестве абстракции используются понятия класс, объект, функция и т.п., то я говорил об абстракциях типа ООП, SOLID и т.п. Т.е. вообще на другом уровне.

Но всё равно спасибо за ссылку. Довольно любопытно, полистаю в свободное время)

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

K>Нет, не реализуются. Без метапрограммирования никаких шаблонов проектирования в коде нет — только результат их применения в голове программиста. Поэтому к уровню кода они никакого значения не имеют.

Т.е. например в C# или Java шаблонов проектирования не существует? )))

K>Из функций, категорий, моноидов, функторов, монад и т.д.

Это можно сказать про любое приложение в функциональном стиле. А я спрашивал про конкретное.

K>Ну конечно, если брать какую-нибудь убогую библиотеку, да еще и специально писать ужасы — тогда конечно.

Т.е. стандартная библиотека Хаскеля убогая? ) Понятно... )))

А какая у нас нормальная? )

K>Вот как выглядит нормальный код, использующий нормальную библиотеку:
K>...

Практически тоже самое, только убрали описание типов в функциях.

K>Нет, прямой аналог этого кода на C++ написать нельзя, потому что системы контроля эффектов в нем нет.

Ооооо, снова наша таинственная польза от системы контроля эффектов. Которая много раз заявлялась, но ни разу не демонстрировалась... Нуну)))

K>Я вроде бы сразу признал, что преобразование между "нелифтнутым" и "лифтнутым" кодом требует значительной модификации кода. Речь-то была о сравнении "лифтнутого" и кода на обычном императивном языке.

Уже хорошо.

K>Конечно он стал страшнее, по сравнению с "наивной" версией. Но не страшнее плюсовой, синтаксический мусор в которой существует вовсе без всякого смысла и оправдания.

О да, о да. Только в C++ версии нет ни единого оператора/вызова функции не по делу. А в Haskell версии (даже с помощью "нормальной" библиотеки), которая вроде как должна быть вообще без мусора, мы имеем "всего лишь" fmap, V.unsafeFreeze, V.thaw, которые вообще непонятно чем заняты по отношению к прямой функциональности нашего кода. И это если забыть про вынужденно кривой код модификации самого массива.

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

K>Началось все с того, что вы заявили, что проблема неустранимого копирования данных, при передаче их между функциями, для ФП принципиальная и нерешаемая. Я же продемонстрировал, что она не только решаема в принципе, но и решена для широкого класса случаев. Теперь вдруг требуется, чтоб и в процессе оптимизации ни на каком этапе так ненавидимый вами "монадный код" никогда не появлялся. Тут новости плохие, ваши чувства никто не щадит и не собирается, авторы таких библиотек не боятся "монадный код" использовать.

Ну да, решённая с помощью добавления императивного кода. )))

K>Вот так:
K>

K>unsafeFromForeignPtr0 fp n = Vector n fp
K>

K>т.е. Storable.Vector это просто структура, хранящая длину и указатель, который откуда угодно можно получать. Никакого копирования при этом не происходит.

Я немного не об этом. Я про то, что нам потом надо именно к этим данным применить тот наш набор функций. А потом (после того как вернём управление из обработки, ОС обновит буфер и снова вызовет нас) ещё раз и т.д...

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

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

Т.е. некий волшебник берёт наш нетипизированный код и типизирует его на этапе создания приложения? ) Какая классная магия. Можно свободно писать всё что угодно и при этом автоматически будет гарантия отсутствия ошибок. Вот бы во всех языках так...

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

K>>Нет, не реализуются. Без метапрограммирования никаких шаблонов проектирования в коде нет — только результат их применения в голове программиста. Поэтому к уровню кода они никакого значения не имеют.
_>Т.е. например в C# или Java шаблонов проектирования не существует? )))

Нет, не существует. Вы вообще-то процитировали ответ на ваш вопрос — см.выше.

_>Это можно сказать про любое приложение в функциональном стиле. А я спрашивал про конкретное.

Конкретно в текстовом редакторе:
Rope в котором хранится редактируемый текст. Дерево — монада, порядок текстовых блоков — моноид.
Лейаут виджетов — моноид.
Последовательность нажатий на клавиши — функтор.
Ширина окна — аппликативный функтор.
Сериализатор/десериализатор файла настроек — аппликативный функтор.
Парсер для подсветки кода — монада.
IOC-контейнер — монада.
и т.д.

K>>Ну конечно, если брать какую-нибудь убогую библиотеку, да еще и специально писать ужасы — тогда конечно.
_>Т.е. стандартная библиотека Хаскеля убогая? ) Понятно... )))

Вы даже не представляете всю убогость стандартной библиотеки хаскеля — она поражает воображение! Это если считать стандартной библиотекой то, что в репорте описано. Та часть библиотеки array, которую вы использовали ни в каких стандартах не описана, кстати. Более того, на стандартизированном подмножестве хаскеля она даже нереализуема.
Если же считать стандартом де факто набор библиотек из haskell-platform то и используемая мной (vector) и вами (array) библиотеки стандартные, просто array морально устарела за годы до того, как код, на C++ который вы тут приводите, стал стандартизированным.

_>А какая у нас нормальная? )

vector

_>Ооооо, снова наша таинственная польза от системы контроля эффектов. Которая много раз заявлялась, но ни разу не демонстрировалась... Нуну)))

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

_>Уже хорошо.

Я тут это написал еще до того, как начал с вами обсуждать ужасы "монадного кода".

_>Только в C++ версии нет ни единого оператора/вызова функции не по делу.

Разумеется есть. Например cbegin() и cend().

_>А в Haskell версии (даже с помощью "нормальной" библиотеки), которая вроде как должна быть вообще без мусора, мы имеем "всего лишь" fmap, V.unsafeFreeze, V.thaw, которые вообще непонятно чем заняты по отношению к прямой функциональности нашего кода.

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

_>И это если забыть про вынужденно кривой код модификации самого массива.

В чем же его "вынужденная кривизна"?

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

_>Ну да, решённая с помощью добавления императивного кода. )))

Нет. Решена она не с помощью добавления императивного кода. Если пользоваться императивным кодом — тут и решать нечего. Последовательность функций меняющих массив по месту, никаких копирований между ними нет. Я же руками как раз добавил лишние копирования, а компилятор их убрал полностью автоматически.
Вы вообще читаете, что я вам пишу?

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

Я продемонстрировал как, используя существующую библиотеку как базу, реализовать такие примитивы и получить библиотеку с запрашиваемыми вами свойствами. Почему существующие библиотеки, которые устраняют промежуточные данные, работают не так как вы заказывали (не ходят по мутабельному массиву несколько раз, а стараются преобразовать несколько проходов в один) я объяснил.

_>Я немного не об этом. Я про то, что нам потом надо именно к этим данным применить тот наш набор функций. А потом (после того как вернём управление из обработки, ОС обновит буфер и снова вызовет нас) ещё раз и т.д...

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

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

_>Т.е. некий волшебник берёт наш нетипизированный код и типизирует его на этапе создания приложения? ) Какая классная магия. Можно свободно писать всё что угодно и при этом автоматически будет гарантия отсутствия ошибок. Вот бы во всех языках так...

Какая еще магия? Нетипизированный обобщенный код в плюсах сначала специализируется, а только потом типизируется. Во всех остальных языках типизируется обобщенный код. Вот бы в плюсах так, как во всех остальных языках!

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

EP>То есть над одним DSL — Eigen, надстраивается другой — МКЭ. Уровень абстракции повышается, а runtime penalty минимальный, если вообще присутсвует.

И что? Что вы этим примером хотите доказать?

EP>Вы постоянно пытаетесь противопоставить "ФП" и "низкоуровневый код". Как-будто только ФП это высокий уровень. Поэтому я и спросил про C#/Java.

Мы говорим о поддержке ФП в C++. Что удивительного, что под высокоуровневым кодом понимается ФП? Какое отношение к обсуждаемой теме имеет то, бывают ли какие-то другие высокоуровневые подходы?

EP>Конкретный пример — runtime reflection.

Какое это имеет отношение к ФП? Вообще говоря, рефлексия и абстракцией не является — это наоборот инструментов для проделывания в абстракциях дыр. Хотя конечно, на основе рефлексии можно создавать какие-то инструменты для абстрагирования. Для обобщения по структуре языкового "объекта", например. Но непосредственно абстракцией рефлексия не является.

EP>В большинстве случаев достаточно compile-time reflection.
EP>У runtime reflection огромный overhead, а у compile-time — нулевой.

Не собираюсь развивать эту тему про рефлексию, но для какого-нибудь любителя динамики это ваше заявление прозвучит точно так же, как для меня ваши заявления по поддержке ФП: "Конкретный пример — овес. В большинстве случаев достаточно песка." Я-то даже согласен, что в большинстве случаев кт-рефлексии достаточно. Это однако не означает, что наличие кт-рефлексии дает поддержку рт-рефлексии. И наоборот. Но вы, похоже, обо всех фичах судите в такой парадигме: есть песок — ставим галочку рядом с "овес". То, что песок неважная замена овсу вас вообще ни в какой степени не беспокоит. Для вас лично это только плюс. Неприхотливость это достоинство. Но вы поймите, что когда вы кому-то заявляете, что поддержка есть — этот кто-то понимает под словом "поддержка" не осознание ненужности наличия — как вы — а совсем иное.

K>>И где же у указателя эти "пределы"?
EP>В ISO C++.
EP>За этими пределами — here be dragons, в виде undefined behaviour.

И где в абстракции "указатель" эти операции dragons : pointer -> bool и behaviour : pointer -> (undefined + defined)?

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

EP>Я вам показал как поддерживается ФП. И да, для практических целей тормозящая реализация fibs на ленивых списках не нужна.

А тормозящая реализация чего нужна? Продемонстрируйте тогда нетормозящую поддержку ФП — я разве против?

EP>Для более сложных задач — возможно. Но вопрос был про простые задачи.
EP>Было заявлено что fibs это идиоматический hello world, и ленивость это пища ФП. Если же для простейших задач ленивость вредна — то видимо это и не "пища ФП", ведь так?

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

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

EP>Копирование, перемещение и refcounting тоже гарантирует доступность.

Копирование и перемещение можно использовать только в маргинальных юзкейсах. Подсчет ссылок действительно обеспечивает доступность для широкого спектра юзкейсов, вот только управлять памятью в условиях типичной для ФП ее организации (со множеством циклов) не может. С таким же успехом можно заявить, что аллокатор, который никогда не освобождает память, а только выделяет ее все гарантирует. А толку-то? На практике им пользоваться невозможно. Гарантии же как таковой для доступности языковых объектов в плюсах нет в принципе.

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

EP>Есть точные GC — но они менее автоматизированные чем консервативные. При использовании точных нужно заменять T* на gc_ptr<T>, etc.

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

EP>Даже если не требовать prompt finalization, получается что нет никакого UFP-автоматизма — нельзя просто захватить какую-то переменную, нужно ещё и cкобки убирать, которые могут быть выше замыкания несколькими уровнями (что и было в исходном примере).

Да о чем речь — для файла гарантия слабее, чем для "языкового объекта", о чем я сразу и сказал (хотя бы потому, что есть метод закрытия файла у объекта-хендлера), но не слабее, чем в плюсах.
И что неожиданного в том, что инструментарий обеспечения prompt finalization за счет UFP не дает решать UFP без проблем? Был бы в языке аналогичный скобкам ограничитель времени жизни для языковых объектов — конечно о каком-то решении UFP в языке говорить было бы неуместно.

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

K>Нет, не существует. Вы вообще-то процитировали ответ на ваш вопрос — см.выше.

Интересно, тогда что это у нас, например здесь http://ru.wikipedia.org/wiki/Singleton#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80_.D0.BD.D0.B0_C.23?)

K>Конкретно в текстовом редакторе:
K>Rope в котором хранится редактируемый текст. Дерево — монада, порядок текстовых блоков — моноид.
K>Лейаут виджетов — моноид.
K>Последовательность нажатий на клавиши — функтор.
K>Ширина окна — аппликативный функтор.
K>Сериализатор/десериализатор файла настроек — аппликативный функтор.
K>Парсер для подсветки кода — монада.
K>IOC-контейнер — монада.
K>и т.д.

Хы, ну если заменить слово монада на слово процедура, то классический ООП код тоже спокойно будет попадать под такое определение. )))

K>Именно тут я про пользу ничего не говорил. Просто объяснил почему этот код аналогом не является и почему на C++ аналог написать нельзя.

Угу, угу. аналога написать нельзя, но пользы от этого не имеющего аналогов нет. Я приблизительно так себе и представлял... )

K>Польза, впрочем, в обсуждаемом примере уже очевидна — оптимизатор выкинул несколько ненужных копирований (все кроме одного), в результате разницы по производительности между "наивным" примером с иммутабельными массивами и примером с мутабельными почти нет.

Польза в виде борьбы с проблемами, вызванными неудачным дизайном язык — это конечно очень интересно. )))

K>В чем же его "вынужденная кривизна"?

Ууу, там много всего. Хотя первоисточник проблемы общий. Ну если взять этот наш конкретный код... Как насчёт записать его в виде чего-то типа "M.write a 1 (M.read a 1)^2"? )

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

K>Нет. Решена она не с помощью добавления императивного кода. Если пользоваться императивным кодом — тут и решать нечего. Последовательность функций меняющих массив по месту, никаких копирований между ними нет. Я же руками как раз добавил лишние копирования, а компилятор их убрал полностью автоматически.

Фокус в том, что изначальный мой код, который мы и оптимизировали, был вообще без императивных кусков.

Естественно очевидно, что можно было легко оптимизировать тот мой код, переписав его целиком на императивном (монадном) подвиде Хаскеля. Однако это никому не интересно.

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

Это было интересно. Но это не отменяет того факта, что получить оптимизированный код на нормальном Хаскеле не выходит без написания императивного кода. Причём в данном случае это особо чувствуется, т.к. сам код преобразования массива явно безопасный (никаких там системных вызовов и т.п.) и необходимость добавления монад обусловлена исключительно проблемами в дизайне языка.

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

K>Какая еще магия? Нетипизированный обобщенный код в плюсах сначала специализируется, а только потом типизируется. Во всех остальных языках типизируется обобщенный код. Вот бы в плюсах так, как во всех остальных языках!

Это ещё зачем? ) Если такой подход уменьшает наши возможности (Евгений приводил пример где и Хаскель пасует, а про Java/C# вообще можно смешно упоминать) в написание кода, при ровно тех же гарантиях отсутствия ошибок в создаваемом ПО? )

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

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

_>Нет, речь не про такие инструменты. А например про UML и ещё множество других из этой же области.

Uml это проектирование, а не язык программирования. Ты всего то спутал области. Эти инструменты применимы к любому языку программирования, хоть к ассемблеру. Более того — один и тот же набор квадратов одинаково пригоден для любого яп.

I>>А в Хаскеле — запросто.

_>На C++ весь код превратился в одну страницу, причём там код простейший, представляющий собой исключительно вызовы функций библиотечки.
_>На Python'e будет буквально такой же код, как и на C++. Т.е. с точностью до замены скобочек на отступы.
_>На Haskell'е ситуация будет чуть хуже за счёт монадного мусора, но если приравнять его к своеобразному аналогу скобочек, то снова получится буквально такой же код.

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

_>Тогда 1С придумывал математик под кайфом. )))

1С это никакой не ДСЛ.

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

I>Uml это проектирование, а не язык программирования. Ты всего то спутал области. Эти инструменты применимы к любому языку программирования, хоть к ассемблеру. Более того — один и тот же набор квадратов одинаково пригоден для любого яп.

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

I>1С это никакой не ДСЛ.

1С — это много чего в одном флаконе. В том числе и DSL. )

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

I>>Uml это проектирование, а не язык программирования. Ты всего то спутал области. Эти инструменты применимы к любому языку программирования, хоть к ассемблеру. Более того — один и тот же набор квадратов одинаково пригоден для любого яп.

_>Ага, для любого...

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

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

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

Никто в своем уме не разрабатывает диаграмки "для С++", "для Фортрана", "для лиспа Хаскеля".

I>>1С это никакой не ДСЛ.

_>1С — это много чего в одном флаконе. В том числе и DSL. )

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