Comments 20
UFO just landed and posted this here
а что еще умеет делать этот язык, крмое решения этой задачи?
Введение бы какое в язык.
Неделя задач Эйнштейна?
Я правильно понял, что пришлось писать унификацию с нуля не Mercury. Ее нет в Mercury (в общем виде)?
Я тогда не понимаю почему язык зовется логическим, если там нет ни переменных, ни унификации.
Я все время думал что Mercury — строго типизированный Prolog с плюшками… Теперь придется читать про него :) Мне аж интересно стало
Я тогда не понимаю почему язык зовется логическим, если там нет ни переменных, ни унификации.
Я все время думал что Mercury — строго типизированный Prolog с плюшками… Теперь придется читать про него :) Мне аж интересно стало
В mercury есть унификация на уровне pattern matching. Чтобы достичь нечто похожего на унификацию логических переменных действительно надо городить некую надстройку. Строго-типизированными прологами с плюшками были Turbo/PDC/Visual Prolog (до версии 5.2 включительно). Теперь, когда убрали ссылочные домены, получился функциональный язык с недетерминизмом, правда, туда еще ООП вставили.
Хм… последняя статья будет на брейнфаке?
> типизируемый, а значит, более безопасный и быстрый
Это миф.
Это миф.
Похоже, придётся пояснить.
Это утверждение логично разбивается на два.
Первое — „Типизируемый язык более безопасен”. Под безопасностью обычно понимается защищённость программы от ошибок пользователя, где типизация приводит лишь к тому что ошибка появится в другом месте, и защищённость программы от ошибок программиста, где типизация приведёт к тому, что ошибка возникнет в другое время. Но все ошибки всё-равно возникнут и их всё-равно нужно будет исправлять. Разработчики, использующие языки с опциональной типизацией, используют её очень редко, обычно только в виде контракта в интерфейсах библиотек, т.к. справедливо считают что время потраченное на типизацию всего *и* исправление ошибок превосходит время потраченное только на исправление ошибок, хоть и выявленных позднее. Так же не стоит считать что типизпция (даже как в Haskell) избавит вас ото всех ошибок. Самые опасные и трудноуловимые ошибки — логические — никакая система типов не поймает.
Второе — „типизируемый язык более производителен” легко опровергается примером.
en.wikipedia.org/wiki/Stalin_(Scheme_implementation)
Да, c2.com/cgi/wiki?SufficientlySmartCompiler
Это утверждение логично разбивается на два.
Первое — „Типизируемый язык более безопасен”. Под безопасностью обычно понимается защищённость программы от ошибок пользователя, где типизация приводит лишь к тому что ошибка появится в другом месте, и защищённость программы от ошибок программиста, где типизация приведёт к тому, что ошибка возникнет в другое время. Но все ошибки всё-равно возникнут и их всё-равно нужно будет исправлять. Разработчики, использующие языки с опциональной типизацией, используют её очень редко, обычно только в виде контракта в интерфейсах библиотек, т.к. справедливо считают что время потраченное на типизацию всего *и* исправление ошибок превосходит время потраченное только на исправление ошибок, хоть и выявленных позднее. Так же не стоит считать что типизпция (даже как в Haskell) избавит вас ото всех ошибок. Самые опасные и трудноуловимые ошибки — логические — никакая система типов не поймает.
Второе — „типизируемый язык более производителен” легко опровергается примером.
en.wikipedia.org/wiki/Stalin_(Scheme_implementation)
Да, c2.com/cgi/wiki?SufficientlySmartCompiler
>и защищённость программы от ошибок программиста, где типизация приведёт к тому, что ошибка возникнет в другое время. Но все ошибки всё-равно возникнут и их всё-равно нужно будет исправлять.
Именно. Огромная разница, возникнет ошибка на этапе компиляции и в runtime. Представьте, что runtime это уже production система. Есть принцип Fail-Fast который заключается в том, что система должна зафейлиться как можно раньше с момента обнаружения сбоя, чтоб не наделать нехороших дел. В идеале, это должно происходить на этапе компиляции.
Приведу пример, где mercury более безопасен чем ocaml. В mercury case должен охватывать весь домен, иначе не скомпилируется (очень просто: предикат декларирован как детерминируемый (det), а выводится (inferred) как полу-детерминированный (semidet) — ошибка компиляции), а в ocaml match может не охватывать весь домен, будет просто warning и exception в runtime.
>Второе — „типизируемый язык более производителен” легко опровергается примером.
Речь не о теории а о практике. На практике гораздо легче оптимизировать типизируемый язык и именно поэтому типизируемые языки в среднем по скорости обгоняют на порядки нетипизируемые.
Именно. Огромная разница, возникнет ошибка на этапе компиляции и в runtime. Представьте, что runtime это уже production система. Есть принцип Fail-Fast который заключается в том, что система должна зафейлиться как можно раньше с момента обнаружения сбоя, чтоб не наделать нехороших дел. В идеале, это должно происходить на этапе компиляции.
Приведу пример, где mercury более безопасен чем ocaml. В mercury case должен охватывать весь домен, иначе не скомпилируется (очень просто: предикат декларирован как детерминируемый (det), а выводится (inferred) как полу-детерминированный (semidet) — ошибка компиляции), а в ocaml match может не охватывать весь домен, будет просто warning и exception в runtime.
>Второе — „типизируемый язык более производителен” легко опровергается примером.
Речь не о теории а о практике. На практике гораздо легче оптимизировать типизируемый язык и именно поэтому типизируемые языки в среднем по скорости обгоняют на порядки нетипизируемые.
> Представьте, что runtime это уже production система.
Ну да, если вы не пишете тесты, то немного спасёт только типизация. При разработке же никакой разницы когда система упадёт, если смогла вывести достаточно информации для выяснения причины ошибки.
Нетипизированные языки давно вымерли, кроме скриптовых, а динамически-типизируемые отстают далеко не на порядок.
Ну да, если вы не пишете тесты, то немного спасёт только типизация. При разработке же никакой разницы когда система упадёт, если смогла вывести достаточно информации для выяснения причины ошибки.
Нетипизированные языки давно вымерли, кроме скриптовых, а динамически-типизируемые отстают далеко не на порядок.
Реквестирую решение задачи на cmd и shell-скриптах.
Осталось только на C++, Java, C#, Perl и Python написать — и будет отличная коллекция!
Sign up to leave a comment.
Задача Эйнштейна на Mercury