OberonCore

Из статьи журнала "Практика функционального программирования":



Исходя из пунктов 2 и 3 и из того что в haskell'e нет присваиваний (изменяемых состояний), делаю вывод что применимость haskell'я весьма ограничена и использовать его в качестве универсального ЯВУ будет весьма затруднительно. Написание исключительно на haskell'e какой-либо достаточно большой программы/системы вследствие указанных выше пунктов было бы крайне затруднено.

Почему?
Во-первых, в Хаскелле таки есть присваивание и мутабельное состояние, причём двух видов: функционально-чистое в монаде State (имитация мутабельного состояния) и императивно-грязное в монаде IO (ввод-вывод).
Кроме того, никто Вам не мешает взять и реализовать такой чиста императивный код на Сях и прилинковать к основной программе на Хаскелле...

А есть на этих State/IO эффективная реализация hash table? А эффективная реализация избитого уже quick sort?


Ну, мне в принципе никто не мешает взять и реализовать весь проект на С++

Вот, нашел сравнение производительность hash table для haskell, ocaml, f#:
http://flyingfrogblog.blogspot.com/2009 ... table.html

Результаты впечатляют:


А ведь тут даже не сравнивалось с версией на С++!

Да, забавен вывод автора:

Стандартный модуль в GHC Data.HashTable.
Насколько эффективна эта реализация -- не могу сказать, не тестировал. Используйте Data.Map -- более идиоматично для Хаскелла

Сортировка списков с помощью стандартной функции Data.List.sort вполне эффективна.

Работают же серьёзные конторы вроде Bluespec, Inc, делают на Хаскелле промышленный софт для разработки чипов.
Или вот Galois в финансовой отрасли используют Хаскелл -- тоже не нарадуются, прям как наши оберонщики...

Зато на Хаскелле элементарно просто написать самый быстрый вариант функции Фибоначчи:
Алгоритм Госпера-Саламина O(log n)...

Про Data.HashTable я кинул ссылочку выше.
А Data.Map это ж аналог std::map из C++. Стоимость вставки и индексакции там O(log(n)), у правильной реализации hash table стоимость для аналогичных операций: O(1). Таки есть разница, да?

Да и какой смысл мне например для Data.Set держать оное множество упорядоченным? Зачем мне определять для моего типа операцию < ? Это ж банальный overkill.

Так часто бывает, что "штучники" выбирают какой-то базовый стабильный инструмент и делают из него для себя "самурайский меч".

Вопрос в тиражируемости-масштабируемости такого подхода. В возможности обучения. В стоимости по совокупности. В масштабах страны, например. Звучит противоречиво - "сделать распространённым штучное производство"? Ничего удивительного. В Новосибирске на круглом столе (и раньше на подобных мероприятиях) такие "зубры", как проф. Терехов - основатели успешных компаний, делающих технологии на экспорт, однозначно говорят: либо Россия будет держать и расширять нишу наукоёмкого ПО, либо не будет иметь никакой. Конкурировать в стиле индусов - бред собачий. У нас нет ресурсов, у нас нет людей, у нас нет такой низкой себестоимости труда, нам мало отпущено времени...
Терехов формулирует это так: "Если для создания программного продукта требуется, чтобы предварительно год работал профессор математики, то это - наши задачи, задачи, которые должны решаться в России... И там знают, что в этом случае, когда ничего не получилось со своими, надо искать русских".

Какой проект?

Отдает чем-то типа "Россия - родина слонов". А просто хороший массовый продукт (неэксклюзивный) - слабо создать? Или как обычно - хорошо можем делать только танки и ракеты, а автомобиль для людей - это слишком просто, пусть японцы такой фигней занимаются.

Надо искать свои сильные стороны... Как, вроде бы, говорят те же японцы в разных боевых искусствах

Речь-то не о том, что кто-то там крут-нипадеццки А о своём месте в разделении труда, куда можно вписаться. Культура массового производства у нас никуда не годится. Её нужно выстраивать годами. И нужно выстраивать Но важно использовать то, что есть. Пока есть.

Потом, что такое "хороший массовый продукт в ПО"? ПО - это что, товар народного потребления? Еда, одежда, автомобиль, наконец? Да дайте удобный набор объединённых сервисов по управлению личной информацией (к тому всё и идёт) - и большинство людей забудет про "рынок ПО" как страшный сон...

Сфера производства ПО раздута в не ту сторону, давайте признаем. Давайте будем учиться производить реальные вещи. Хороший массовый осязаемый продукт. И тут-то и окажется куча реальных запросов от промышленности к программистам. И запросы эти будут как раз сложного, наукоёмкого уровня. ПО - это не товар... Это инструмент. Продолжение интеллектуальных методов. Для проектирования-управления-производства чего-то/чем-то в реальном мире.

Но японцы танки и ракеты не могут создать. Почему нет. Специализация. Причем тут "родина слонов".

Японцам американцы запрещали военную технику делать.
Нам-то кто запрещает?

Если на С++ Вы быстрее получите качественный результат, то им и следует Вам пользоваться в этом случае...

Внешне правильный совет ("выбирать под задачу..") сформулирован крайне примитивно. Надо выбирать что-то не под быстрое получение качественного результата, а под получение качественных результатОВ на протяжении длительного времени.

По моему, это как-то не правильно когда при переходе на другой ЯП некоторые высокоэффективные алгоритмы и структуры данных вдруг становятся либо недоступными, либо резко теряют свою эффективность. Теряют настолько, что вместо O(1) получаем O(n).

Что-то здесь не то...

Вот у меня и возникают сомнения что рассматриваемый инструмент (Haskell) рано или поздно не даст осечку и для достижения качественного результата не придется заниматься грязными хаками на уровне С.

Стандартная практика у хаскеллеров -- высокоуровневая логика на Хаскелле, низкоуровневые оптимизации на сях...

Это вообще стандартная практика сегодня - высокоуровневое скриптование над низкоуровневыми Сями. Для серверных приложений вообще всерьёз альтернатив нет для многих случаев. Потому что Джавы-Шарпы по скорости в совокупности тормозят почти как хороший рантайм скриптового языка... Зато на уровень ниже с них не выйдешь.

Получается маразм - в итоге быстродействие профукивается на тех или иных скриптах. Хотя для практики достаточно разумно приподнять уровень Сей. Т.е. брать Оберон - "Си-Юникс 89-го года"

С одним маленьким но -- си есть везде, оберон -- мало где...