У меня с ELM ни каких проблем не было, сходу начал писать простенькие странички для своих бекендерских задач. JS знал и знаю очень поверхноснотно, заглядывание в чужей JS-код всегда вызывало у меня ужас. ELM выбрал потому что он лучше всего прячет от меня потраха, ни PureScript, ни ScalaJS этого не обеспечивали. До этого делать UI у меня получалось только на TCL/Tk. Правда на том момент у меня был опыт Haskell в продакшене, что сильно помогло.
Я глубоко не разбирался, пока руки не дошли. Когда-то давно наткнулся в книге по ИИ упоминание этого метода машинного обучения, генерирующий программу на Prolog по примерам поведения.
В порядке развлечения, можно тот же Nani Search доделать. Как язык правил для MUD пролог вызладит привлекательным.
У меня есть мысли применить это для программирования макросов, которые могли бы вмешиваться в работу компилятора на момент проверки типов (поиск пути получения объекта нужного типа из доступных объектов), но они пока очень сырые.
Эффективность целью не ставилась. Есть широкий класс игр, которые удобно моделировать на Prolog. Интерпретатор позволяет решать более-менее общие задачи о таких играх.
Важным свойством среды разработки является поддержка Type-Driven Development, в частности поиск в текущем контексте переменной, подходящей по типу для использования в данном месте. В IDEA это реализовано относительно неплохо (по крайней мере для Scala), хотя для коассической реализации в vim/emacs+Idris еще есть куда расти. А что с этим в других IDE?
Я не помню у 8080 или Z80 возможности использования внешнего стека. Более того, это выглядит странно, поскольку усложняет шину памяти без большой пользы, разделить код и данные было бы полезнее.
Трансляция страниц появилась только в i386, в более ранних моделях ее не было. Сейчас самой распространенной архитектурой стала amd64, в которой использование сегментов очень ограничено.
"Потому что исполнение невинных желаний требует расхода ресурсов, которые субъектам неоткуда взять, кроме как из общей среды обитания." - слишком упрощенная модель. В реальности ресурс из окружающей среды надо извлечь, для извлечения эффективна кооперация.
Туплы как способ обработки ошибок - плохая идея. Функция должна возвращать результат ИЛИ (а не И) информацию о сбое. То есть если функция завершилась с ошибкой, компилятор не должен позволить использовать ее результат.
Для этого хорошо подходят алгебраические типы данных, как, например, Result в Rust.
А купить мониторы на сколько сложно? Магазины, доставка?
У меня с ELM ни каких проблем не было, сходу начал писать простенькие странички для своих бекендерских задач. JS знал и знаю очень поверхноснотно, заглядывание в чужей JS-код всегда вызывало у меня ужас. ELM выбрал потому что он лучше всего прячет от меня потраха, ни PureScript, ни ScalaJS этого не обеспечивали. До этого делать UI у меня получалось только на TCL/Tk.
Правда на том момент у меня был опыт Haskell в продакшене, что сильно помогло.
Вообще использование -1 как кода особой ситуации неэлегантно. Для наких случаев придуманы элегантные Алгебраические Типы Данных - Option/Maybe.
А почему бы в качестве аварийного балласта было не испльзовать дополнительный аккумулятор?
А есть у нее какие-нибудь необычные фичи, отличающие ее от сдугих современных ОС?
Я глубоко не разбирался, пока руки не дошли. Когда-то давно наткнулся в книге по ИИ упоминание этого метода машинного обучения, генерирующий программу на Prolog по примерам поведения.
Общие задачи - задачи, в которых условия и ограничения формулируются на языке общего назначения.
В порядке развлечения, можно тот же Nani Search доделать. Как язык правил для MUD пролог вызладит привлекательным.
У меня есть мысли применить это для программирования макросов, которые могли бы вмешиваться в работу компилятора на момент проверки типов (поиск пути получения объекта нужного типа из доступных объектов), но они пока очень сырые.
Эффективность целью не ставилась. Есть широкий класс игр, которые удобно моделировать на Prolog. Интерпретатор позволяет решать более-менее общие задачи о таких играх.
На Физтехе они назывались "насильники" и "пасквилианты". Но бои обычно завершались тем, что ассемблер все равно лучше... :-)
Важным свойством среды разработки является поддержка Type-Driven Development, в частности поиск в текущем контексте переменной, подходящей по типу для использования в данном месте. В IDEA это реализовано относительно неплохо (по крайней мере для Scala), хотя для коассической реализации в vim/emacs+Idris еще есть куда расти. А что с этим в других IDE?
Что бы не случилось, "ехать воевать" совсем не обязательно. Можно пойти в бега, можно даже в тюрьму, чтобы в этом не участвовать.
Чиплеты могут в одном корпусе разместить и процессор, и приличный объем ОЗУ?
Я не помню у 8080 или Z80 возможности использования внешнего стека. Более того, это выглядит странно, поскольку усложняет шину памяти без большой пользы, разделить код и данные было бы полезнее.
Там не было поддержки серментной адресации. Хотя был i86-совместимый процессор Nec V20, поторый позволял запускать код i80 в отдельном сегменте...
Хмм, это было в черновике, я просто уже забыл, что такой объем памяти бывет, но вовремя заметил и исправил. Конечно, там мегабайт.
Да, но там сегментная адресация не поддерживается.
Трансляция страниц появилась только в i386, в более ранних моделях ее не было. Сейчас самой распространенной архитектурой стала amd64, в которой использование сегментов очень ограничено.
"Потому что исполнение невинных желаний требует расхода ресурсов, которые
субъектам неоткуда взять, кроме как из общей среды обитания." - слишком упрощенная модель. В реальности ресурс из окружающей среды надо извлечь, для извлечения эффективна кооперация.
Туплы как способ обработки ошибок - плохая идея. Функция должна возвращать результат ИЛИ (а не И) информацию о сбое. То есть если функция завершилась с ошибкой, компилятор не должен позволить использовать ее результат.
Для этого хорошо подходят алгебраические типы данных, как, например, Result в Rust.