Уникальная ситуация с прологом. Исторически сложилось так, что на всех компьютерных специальностях его преподают. Вместе с тем, нигде он не используется на практике. Студентам показывают невероятные возможности языка, а потом они уходят в недоумении: «Зачем оно нужно?».
Предположим, что за год работы партнёру даём 10%. Если у нас 10 партнёров, то мы всё отдаём, так получается?
Или если 6 партнёров, то у нас не остаётся контрольного пакета?
Или я чего-то не понимаю?
Мне больше нравится концепция коэффициентов. Например, у основателя коэффициент 10. Партнёрам за год работы даём коэффициент 1. Потом часть прибыли, которая идёт на дивиденды, делится между всеми в соответсвии с их коэффициентами.
Соответственно когда пришёл новый партнёр, доля остальных чуть-чуть поровну уменьшилась. Зато можно приглашать неограниченное число партнёров.
Сплит это конечно хорошо. Но там ещё нужен один ифник для проверки того, что октетов 4. И ещё проверки того, что не встретились посторонние символы. А может тестировщик найдёт и другие проблемы.
Здесь мы получаем автоматическую генерацию сообщений об ошибках. Введена буква? Библиотека внутри сгенерит ошибку «expected digit». 3 октета вместо 4, будет сгенерина ошибка «unexpected eof, expected digit or '.'», если октетов больше 4, будет сгенерина ошибка «unexpected '.', expected eof». И это всё уже внутри этого кода.
Кроме того, этот подход универсален. Эта функция парсит ip адрес, другие функции в этом модуле точно так же парсят более сложные вещи. Ip-адрес конечно можно распарсить сплитом и регекспом. Но, например, выражение со скобками нельзя.
Используя комбинаторы парсеров везде, мы получаем выйгрыш в универсальности.
Есть мнение что об «этих жутких регекспах» действительно можно ничего не знать.
Есть такая штука как комбинаторы парсеров. Они легче понимаются чем регекспы, их легче читать. И они позволяют решать гораздо больше задач. Так как могут парсить контекстно свободные грамматики, которые шире чем регулярные грамматики.
ipAddr :: GenParser Char st Word32
ipAddr = do
as <- many1 digit
let a = read as
when (a > 255) $ fail "ip address octet must be >= 0 && < 256"
char '.'
bs <- many1 digit
let b = read bs
when (b > 255) $ fail "ip address octet must be >= 0 && < 256"
char '.'
cs <- many1 digit
let c = read cs
when (c > 255) $ fail "ip address octet must be >= 0 && < 256"
char '.'
ds <- many1 digit
let d = read ds
when (d > 255) $ fail "ip address octet must be >= 0 && < 256"
eof
return $ shiftL a 24 + shiftL b 16 + shiftL c 8 + d
Если он программирует на с++, то в состоянии использовать питон. Или с#. Или жаву.
Но другую парадигму он не в состоянии быстро начать использовать.
Просто разобраться хотя бы в нескольких концепциях хаскеля занятие не быстрое. А начать писать код с их помощью можно не известно через какое время. Хотелось бы на практике узнать длительность «втягивания» в процесс разработки на хаскеле с нуля.
Никому не нужен в смысле не используется в бизнесе.
Все мейнстримные языки худо-бедно справляются со своими задачами.
Плюс к этому проблема курицы и яйца. На рынке труда нет вакансий инженеров-хаскелистов. Поэтому мало кто интересуется языком. Поэтому никто не использует его в проектах, т.к. боится недостатка кадров. Поэтому на рынке труда нет вакансий.
Или если 6 партнёров, то у нас не остаётся контрольного пакета?
Или я чего-то не понимаю?
Мне больше нравится концепция коэффициентов. Например, у основателя коэффициент 10. Партнёрам за год работы даём коэффициент 1. Потом часть прибыли, которая идёт на дивиденды, делится между всеми в соответсвии с их коэффициентами.
Соответственно когда пришёл новый партнёр, доля остальных чуть-чуть поровну уменьшилась. Зато можно приглашать неограниченное число партнёров.
Потом только разобрался что список это всего лишь список. А его инстанс класса Monad живёт сам по себе, можно о нём ничего не знать.
А Maybe то же самое что None в питоне. Только идеологически правильное.
а вообще сталкивался не понаслышке с этим языком, примерно представляю преимущества и недостатки
Да, интеграция с cabal была бы очень кстати.
Код тоже весьма самобытен, у многих функций нет сигнатур. GHC наверное обливается предупреждениями.
Но это ерунда, главное весь этот гигантский функционал работает. А превести к упорядоченному состоянию постепенно не так уж и сложно.
Сплит это конечно хорошо. Но там ещё нужен один ифник для проверки того, что октетов 4. И ещё проверки того, что не встретились посторонние символы. А может тестировщик найдёт и другие проблемы.
Здесь мы получаем автоматическую генерацию сообщений об ошибках. Введена буква? Библиотека внутри сгенерит ошибку «expected digit». 3 октета вместо 4, будет сгенерина ошибка «unexpected eof, expected digit or '.'», если октетов больше 4, будет сгенерина ошибка «unexpected '.', expected eof». И это всё уже внутри этого кода.
Кроме того, этот подход универсален. Эта функция парсит ip адрес, другие функции в этом модуле точно так же парсят более сложные вещи. Ip-адрес конечно можно распарсить сплитом и регекспом. Но, например, выражение со скобками нельзя.
Используя комбинаторы парсеров везде, мы получаем выйгрыш в универсальности.
Есть такая штука как комбинаторы парсеров. Они легче понимаются чем регекспы, их легче читать. И они позволяют решать гораздо больше задач. Так как могут парсить контекстно свободные грамматики, которые шире чем регулярные грамматики.
Комбинаторы парсеров в питоне, в хаскеле.
Вот и подтверждение тому, что хаскель используют очень ограниченный круг людей.
Но другую парадигму он не в состоянии быстро начать использовать.
Просто разобраться хотя бы в нескольких концепциях хаскеля занятие не быстрое. А начать писать код с их помощью можно не известно через какое время. Хотелось бы на практике узнать длительность «втягивания» в процесс разработки на хаскеле с нуля.
Все мейнстримные языки худо-бедно справляются со своими задачами.
Плюс к этому проблема курицы и яйца. На рынке труда нет вакансий инженеров-хаскелистов. Поэтому мало кто интересуется языком. Поэтому никто не использует его в проектах, т.к. боится недостатка кадров. Поэтому на рынке труда нет вакансий.
бенчмарки не считают что питон лучше подходит в плане производительности
В этой задаче perl или python подошёл бы ничуть не хуже.
Технических проблем, связанных с написанием любого ПО, в хаскеле давно нет.
А никто не использует его просто потому, что он никому не нужен.