OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Ноябрь, 2019 00:24

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 10 Август, 2009 14:18 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Из статьи журнала "Практика функционального программирования":

Цитата:
Апологеты функци-онального программирования объясняют это решение, в частности, тем,
что отказ от изменяемых данных резко повышает корректность программ
и делает их значительно более удобными для анализа с помощью фор-
мальных методов. Это действительно так, и в данной статье мы в этом убе-
димся. Однако полный отказ от изменяемых данных зачастую не оправ-
дан по следующим причинам:

1. Некоторые техники программирования, применяющиеся в функци-
ональных языках без присваиваний (к примеру, ленивые вычисле-
ния), применимы в более традиционных языках, таких как Java или
C++, лишь с огромным трудом.

2. Для некоторых алгоритмов и структур данных не известно или
не существует столь же эффективных аналогов без использования
присваиваний (к примеру, для хэш-таблиц и систем непересекаю-
щихся множеств).

3. Многие предметные области по своей сути содержат изменяемые
объекты (например, банковские счета; элементы систем в задачах
имитационного моделирования, и т. п.), и переформулировка зада-
чи на язык неизменяемых объектов может «извратить» задачу.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 14:50 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Alexey Veselovsky писал(а):
Исходя из пунктов 2 и 3 и из того что в haskell'e нет присваиваний (изменяемых состояний), делаю вывод что применимость haskell'я весьма ограничена и использовать его в качестве универсального ЯВУ будет весьма затруднительно. Написание исключительно на haskell'e какой-либо достаточно большой программы/системы вследствие указанных выше пунктов было бы крайне затруднено.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 15:07 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Geniepro писал(а):
Alexey Veselovsky писал(а):
Исходя из пунктов 2 и 3 и из того что в haskell'e нет присваиваний (изменяемых состояний), делаю вывод что применимость haskell'я весьма ограничена и использовать его в качестве универсального ЯВУ будет весьма затруднительно. Написание исключительно на haskell'e какой-либо достаточно большой программы/системы вследствие указанных выше пунктов было бы крайне затруднено.

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


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

Цитата:
Кроме того, никто Вам не мешает взять и реализовать такой чиста императивный код на Сях и прилинковать к основной программе на Хаскелле...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 15:46 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Вот, нашел сравнение производительность hash table для haskell, ocaml, f#:
http://flyingfrogblog.blogspot.com/2009 ... table.html

Результаты впечатляют:
Код:
Performance:

Haskell: 22.8s
OCaml:    2.82s
F#:       0.706s


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

Да, забавен вывод автора:
Цитата:
If only Haskell programmers could take some time away from writing Fibonacci functions perhaps they could also build some kind of adequate compiler.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 16:11 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Alexey Veselovsky писал(а):
А есть на этих State/IO эффективная реализация hash table?
Стандартный модуль в GHC Data.HashTable.
Насколько эффективна эта реализация -- не могу сказать, не тестировал. Используйте Data.Map -- более идиоматично для Хаскелла

Alexey Veselovsky писал(а):
А эффективная реализация избитого уже quick sort?
Сортировка списков с помощью стандартной функции Data.List.sort вполне эффективна.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 16:21 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Цитата:
If only Haskell programmers could take some time away from writing Fibonacci functions perhaps they could also build some kind of adequate compiler.

Зато на Хаскелле элементарно просто написать самый быстрый вариант функции Фибоначчи:
Код:
type GSt = (Integer, Integer)

instance Num GSt where
    (a,b) * (c,d) = (a*(c+d) + b*c, a*c + b*d)

fib n = fst $ ((1,0) :: GSt) ^ n
Алгоритм Госпера-Саламина O(log n)... :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 16:22 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Geniepro писал(а):
Alexey Veselovsky писал(а):
А есть на этих State/IO эффективная реализация hash table?
Стандартный модуль в GHC Data.HashTable.
Насколько эффективна эта реализация -- не могу сказать, не тестировал. Используйте Data.Map -- более идиоматично для Хаскелла


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 16:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9157
Откуда: Россия, Орёл
Geniepro писал(а):
Или вот Galois в финансовой отрасли используют Хаскелл -- тоже не нарадуются, прям как наши оберонщики... :lol:


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 20:59 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1026
Alexey Veselovsky писал(а):
Ну, мне в принципе никто не мешает взять и реализовать весь проект на С++ ;-)
Какой проект?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 21:39 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Терехов формулирует это так: "Если для создания программного продукта требуется, чтобы предварительно год работал профессор математики, то это - наши задачи, задачи, которые должны решаться в России... И там знают, что в этом случае, когда ничего не получилось со своими, надо искать русских".


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 21:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9157
Откуда: Россия, Орёл
Надо искать свои сильные стороны... Как, вроде бы, говорят те же японцы в разных боевых искусствах :)

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 23:51 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
Vlad писал(а):
Или как обычно - хорошо можем делать только танки и ракеты, а автомобиль для людей - это слишком просто
Но японцы танки и ракеты не могут создать. Почему нет. Специализация. Причем тут "родина слонов".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 08:37 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Info21 писал(а):
Но японцы танки и ракеты не могут создать. Почему нет. Специализация. Причем тут "родина слонов".

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 08:38 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Alexey Veselovsky писал(а):
Ну, мне в принципе никто не мешает взять и реализовать весь проект на С++ ;-)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 10:17 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9157
Откуда: Россия, Орёл
Geniepro писал(а):
Если на С++ Вы быстрее получите качественный результат, то им и следует Вам пользоваться в этом случае...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 10:55 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Geniepro писал(а):
Alexey Veselovsky писал(а):
А есть на этих State/IO эффективная реализация hash table?
Стандартный модуль в GHC Data.HashTable.
Насколько эффективна эта реализация -- не могу сказать, не тестировал. Используйте Data.Map -- более идиоматично для Хаскелла


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 10:59 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Geniepro писал(а):
Если на С++ Вы быстрее получите качественный результат, то им и следует Вам пользоваться в этом случае...


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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 12:05 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Alexey Veselovsky писал(а):
Вот у меня и возникают сомнения что рассматриваемый инструмент (Haskell) рано или поздно не даст осечку и для достижения качественного результата не придется заниматься грязными хаками на уровне С.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 14:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9157
Откуда: Россия, Орёл
Это вообще стандартная практика сегодня - высокоуровневое скриптование над низкоуровневыми Сями. Для серверных приложений вообще всерьёз альтернатив нет для многих случаев. Потому что Джавы-Шарпы по скорости в совокупности тормозят почти как хороший рантайм скриптового языка... Зато на уровень ниже с них не выйдешь.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 15:02 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
... Оберон - "Си-Юникс 89-го года" :)
С одним маленьким но -- си есть везде, оберон -- мало где...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB