Создал Вольфрам исскуственный интеллект и спросил «есть ли бог?»
— Мне не хватает ресурсов для ответа на этот вопрос — надо подключить ко мне все суперкомпьтеры и персоналки.
Это было сделато, и Вольфрам снова спросил «есть ли бог?».
— Мне не хватает ресурсов — надо подключить ко мне все встраеваемые устройства.
Когда это было сделано, ИИ ответил на вопрос — «теперь есть».

Производительность.
Хотя может она кластеризоваться умеет? Клестера из Raspberry Pi вполне отлаженое решение :-).

А ни чего, что аргументы zipWith зависят от fib?

А можно ли работать с freebase с помощью SPARQL — напрямую или через шлюз?

xine пропала. Пришлось на smplayer переходить.

Наверно я порекомендую самую большую экзотику. :-)
Жена отказалась сносить винды с ее нетбука (к тому же она переустанавливалась, если определенную кнопку при включении нажать), а там не все файлы проигрывались. Я сам в виндах ни чего не понимаю, но обнаружил что привычный smplayer портирован и туда. Поставил — жена не особо жалуется. Только первый запуск был очень долгий, он какие-то фонты индексировал.

Недавно услышал о CDF — он бы мог многое перенести на клиента.

Хотя лично я предпочел бы более многоуровневые архитектуры. Даже браузер разделил бы на части, по образу Opera mini. Значительную часть вычислений можно было бы выполнять на proxy.

В моих задачах эффективности javascript обычно хватает. Но сам язык на столько громоздок и ужасен, что писать я на нем не могу.
А эффективные языки, типа Scala, Clojure или Haskell кроме того еще и удобны. И я готов смириться с потерей производительности, лишь бы не писать на js.
Правда, пока программирование клиента мне удавалось спихивать на других. Но что так будет всегда я не уверен и пытаюсь разобраться с альтернативами.

Если вызов виртуальный, можно последовательность команд invoke и return выполнить в другом порядке — сначала освободить фрейм вызывающего метода, а потом создать фрейм вызываемого. То есть инлайнить вообще не обязательно.

Пусть у нас функция x, описанная в файле x.scala, последним оператором вызывает вызывает функцию y, описанную в y.scala. Когда компилятор обрабатывает x.scala ему нужен только интерфейс y. Вытаскивание кода функции y, что бы ее заинлайнить в x, усложнит сборку.

Интересно, а Элон Маск этим воспользовался, что бы свои акции прикупить?

А если это вызов виртуального метода другого объекта? Или не виртуального, но из другого модуля компиляции? На уровне JVM это можно соптимизировать, на уровне языка сложнее.

Только рекурсию или вообще хвостовые вызовы?
Scala это умеет не всегда, к сожалению.

Поверх Netbeans я видел только kojo.

Последнее время весь десктоп, который я вижу сделан поверх Eclipse. Включая дорогущие проприетарные софтины.

Кстати, о разных JVMах. А есть ли среди них какой-нибудь оптимизирующий хвостовые вызовы? Я вынужден переходить с функциональных языков на JVMные и некоторые привычки меня сильно подводят. А моделью безопасности Java я все равно не пользуюсь, так как весь код могу контролировать.

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

Thanks!

Странно, что 1 медленнее чем 2.

То, что 5 так тормозит, неприятно, но будем учитывать.

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

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

Гауссган как такой пример не подойдет?
Преподавать у меня плохо получалось — объяснить алгебраические типы Haskell школьникам я не смог. Теперь боюсь, что школьникам будет слишком сложно.
Но попробовать было бы интересно.

Дополнительные степени свободы упрощают поиск маневра, который позволит избежать аварийной ситуации. Так идти по одномерному канату опаснее, чем по плоскости :-).
Правда, у воздушного средства отсутствует возможность просто остановиться…

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