Мы тоже не минусовали, наоборот: такие вопросы как раз уместны в блоге компании, которая выбрала Haskell! Можно лишний раз рассказать, какой он классненький :)
Если серьёзно, то когда хочется функциональщины, то выбор между двумя "семействами" (Lisp или потомки ML) -- вполне естественный. Из лиспов сейчас живее всех в индустриальной разработке Clojure, из ML-ных, Haskell.
Нет, именно такой выбор не стоял, для нас Haskell обладает целым рядом преимуществ, например, статическая типизация, АТД, удобные для моделирования предметной области, большое количество библиотек и т.д. Я не работала в компании с самого начала, но у нас есть пост, где рассказывается про выбор технологий, так сказать, из первых уст: https://habr.com/ru/company/typeable/blog/554516/
У меня как у разработчика был выбор между Clojure и Haskell, когда захотелось работать на функциональном языке, но на Haskell у меня уже был опыт разработки и уже были предложения работы, так что вакансии на Clojure даже особо не было смысла искать.
Пишем всякие B2B приложения в разных индустриальных областях (финтех, путешествия, биотех), в том числе фронтенд (https://habr.com/ru/company/typeable/blog/548574/). Я всю свою хаскельную карьеру (в сумме 4 года) в основном пишу бэкенды серверов: сходить во внешнюю систему, обработать данные из запроса и полученные из систем, вынуть/сохранить в БД, сформировать и отдать ответ клиенту. Т.е. по большей части как раз взаимодействие с внешним миром. Но на Хаскеле его можно явно отделить от "чистой" логики преобразования данных.
А "как пишется" -- тут ответ будет очень субъективный :) Не нравилось бы, перешла бы на что-то другое, такое уже было: между двумя работами на Хаскеле писала под железо на чистом С, но не зашло.
Прочитав название статьи - подумал было, что это будет про инструменты для разработчика на Хаскеле (типа "лучший плагин для IDE", "как проводить отладку", "как делать GUI"....) - нет в планах такой статьи?
Именно такой в планах нет на данный момент, но будем писать про индустриальное использование Хаскеля в различных областях (по формату будет что-то нашей недавней статьи про использование Лиспа: https://habr.com/ru/company/typeable/blog/581488/)
Какого рода "ревью" имеется в виду в данном случае?
В оригинале "We can handle regression testing very well by reviewing the code as well as automating as many functional and non-functional scenarios as possible.". Я так понимаю, что имеется в виду ревью кода в PR другими участниками команды. Это вместе с прогонкой автоматических тестов позволяет на ранних стадиях выявить потенциальные дефекты.
регрессионное тестирование проводится на критические участки проекта (кейсы для них описываются, конечно же) в рамках тестирования после выкатывания обновленного проекта в лайв
Кстати, у нас так и устроено регресс-тестирование: QA инженеры его проводят после деплоя на pre-prod и production по заранее составленному списку основных сценариев работы пользователя с приложением.
Про экспертные системы писать не планировали, но хотим сделать серию постов, похожих на этот, про разные "экзотические" языки программирования. В том числе речь зайдёт о Прологе.
Спасибо за ссылку! Всё не удалось вместить в пост, чтобы он не разросся в скучный лонгрид, но мы планируем продолжать тему с обзором инструментов на функциональных языках.
В наших проектах мы это не использовали, но выглядит любопытно. Не знаю, насколько корректно сравнивать с Reflex, больше похоже на Yesod или даже Hakyll, к тому же архитектура не такая гибкая (в туториале описывается фиксированная структура проектов). Думаю, если надо что-то быстро накидать типа личного блога, то будет удобно использовать, пока нет нужды делать что-то, выходящее за рамки их архитектуры.
Немного напрягает обилие "программирования мышью" (опять-таки судя по туториалу), из-за такого начинают клепать код, вообще не понимая, что на самом деле происходит. Но это уже моя личная вкусовщина :)
Спасибо! Мы у себя TS+Redux не пробовали, у нас уже была кодобаза на Haskell и хотелось продолжать использовать чисто функциональный язык.
У одного из наших коллег был опыт использования Redux + React Native + TS, и ему реализация той же самой архитектуры в Elm показалась гораздо понятнее и типизация лучше.
Я когда-то писала небольшой туториал по парсерам (https://habr.com/ru/post/436234/), вполне себе прикладная задача. Да и по запросу "haskell туториал" тут находятся посты. Но русскоязычных материалов в целом мало, это факт.
В музее науки в Лондоне есть зал, посвященный IT и CS, и там, помимо прочего, выставлена часть БЭСМ-6, Энигма, разностная машина, на которой работала Ада Лавлейс и разностная машина по чертежам Бэббиджа (построенная уже после его смерти).
«Кейс №1» по сетям до боли напоминает происходившее у нас; вероятно, это тот же универ и те же сети :) Только когда я сдавала, экзаменаторами были аспиранты, которым было лень ходить по аудитории, поэтому ответы искали на странице, по внешнему виду практически идентичной и заранее кем-то заботливо выложенной на свой сервак.
Мой самый запоминающийся опыт: экзамен по правоведению в магистратуре, когда готовиться к гуманитарным предметам уже настолько лень, что даже бомбы от руки писать не хотелось. А материала много, одна вода неструктурированная, списывать я от природы умею плохо, оставалось только бомбить. Поэтому решили с товарищем всех перехитрить и напечатать бомбы рукописным шрифтом, максимально похожим на свой почерк. Был написан скрипт, который в вордовом документе вставлял рандомное число пробелов перед каждой строкой, чтобы строки выглядели «рваными». Но они всё равно казались слишком ровными, а возиться с межстрочным интервалом было лень, поэтому оставили как есть.
Отвечать билет надо было сидя за партой перед лектором, т.е. достаточно далеко, поэтому должно было прокатить. Но что-то пошло не так, когда я отвечала. Лектор не поленился встать и посмотреть поближе на мои «записи». Спросил, написаны ли они от руки и попросил принести ручку, которой я это писала. Терять было нечего, поэтому я показала чёрную ручку, похожую на тонкий фломастер (такие в оранжевом корпусе, они есть практически любого цвета, я ими всегда любила записывать лекции — красиво выходило, и при сканировании/фото всё хорошо видно). Препод понял, что я не сдаюсь, и попросил написать какое-то слово из билета. Тут мне помог многолетний опыт записывания в списки присутствующих на лекциях «мёртвых душ» разными почерками, поэтому я воспроизвела напечатанное слово практически идентично. Препод сдался и стал спрашивать по следующему билету, в итоге даже поставил отл. Я уверена, что он всё и так пропалил, но либо пожалел, либо удивился моей наглости (сама удивилась). Я ему до сих пор за это благодарна и мне всё ещё немного стыдно :)
Во время этого «перформанса» мой друг с такими же псевдорукописными шпорами панически переписывал свою бомбу своей ручкой, сокращая слова настолько, что потом не смог половину из них расшифровать при ответе (но тоже сдал).
Сейчас со скромным опытом преподавания понимаю, насколько любые шпоры заметны и насколько их наличие не имеет значения, особенно на устных экзаменах, где написанный тем или иным способом билет не гарантирует даже тройку. Вообще, огромное спасибо тем преподавателям, которые разрешали пользоваться справочными материалами для подготовки билета, и задавали уточняющие вопросы по доказательствам, а по памяти просили написать только базовые определения и утверждения. Меньше стресса, результат тот же.
Мы тоже не минусовали, наоборот: такие вопросы как раз уместны в блоге компании, которая выбрала Haskell! Можно лишний раз рассказать, какой он классненький :)
Если серьёзно, то когда хочется функциональщины, то выбор между двумя "семействами" (Lisp или потомки ML) -- вполне естественный. Из лиспов сейчас живее всех в индустриальной разработке Clojure, из ML-ных, Haskell.
Нет, именно такой выбор не стоял, для нас Haskell обладает целым рядом преимуществ, например, статическая типизация, АТД, удобные для моделирования предметной области, большое количество библиотек и т.д. Я не работала в компании с самого начала, но у нас есть пост, где рассказывается про выбор технологий, так сказать, из первых уст: https://habr.com/ru/company/typeable/blog/554516/
У меня как у разработчика был выбор между Clojure и Haskell, когда захотелось работать на функциональном языке, но на Haskell у меня уже был опыт разработки и уже были предложения работы, так что вакансии на Clojure даже особо не было смысла искать.
Это развлечение для твиттера!
Пишем всякие B2B приложения в разных индустриальных областях (финтех, путешествия, биотех), в том числе фронтенд (https://habr.com/ru/company/typeable/blog/548574/). Я всю свою хаскельную карьеру (в сумме 4 года) в основном пишу бэкенды серверов: сходить во внешнюю систему, обработать данные из запроса и полученные из систем, вынуть/сохранить в БД, сформировать и отдать ответ клиенту. Т.е. по большей части как раз взаимодействие с внешним миром. Но на Хаскеле его можно явно отделить от "чистой" логики преобразования данных.
А "как пишется" -- тут ответ будет очень субъективный :) Не нравилось бы, перешла бы на что-то другое, такое уже было: между двумя работами на Хаскеле писала под железо на чистом С, но не зашло.
Именно такой в планах нет на данный момент, но будем писать про индустриальное использование Хаскеля в различных областях (по формату будет что-то нашей недавней статьи про использование Лиспа: https://habr.com/ru/company/typeable/blog/581488/)
Спасибо за замечание! Поменяли формулировку.
В оригинале "We can handle regression testing very well by reviewing the code as well as automating as many functional and non-functional scenarios as possible.". Я так понимаю, что имеется в виду ревью кода в PR другими участниками команды. Это вместе с прогонкой автоматических тестов позволяет на ранних стадиях выявить потенциальные дефекты.
Кстати, у нас так и устроено регресс-тестирование: QA инженеры его проводят после деплоя на pre-prod и production по заранее составленному списку основных сценариев работы пользователя с приложением.
Там, оказывается, Clojure: https://www.youtube.com/watch?v=iUC7noGU1mQ&ab_channel=ClojureTV
Про экспертные системы писать не планировали, но хотим сделать серию постов, похожих на этот, про разные "экзотические" языки программирования. В том числе речь зайдёт о Прологе.
Интересный опыт, спасибо, что поделились!
Отличное название у языка :D Спасибо за ссылки!
Скоро будет как минимум ещё одна
Спасибо за ссылку! Всё не удалось вместить в пост, чтобы он не разросся в скучный лонгрид, но мы планируем продолжать тему с обзором инструментов на функциональных языках.
В наших проектах мы это не использовали, но выглядит любопытно. Не знаю, насколько корректно сравнивать с Reflex, больше похоже на Yesod или даже Hakyll, к тому же архитектура не такая гибкая (в туториале описывается фиксированная структура проектов). Думаю, если надо что-то быстро накидать типа личного блога, то будет удобно использовать, пока нет нужды делать что-то, выходящее за рамки их архитектуры.
Немного напрягает обилие "программирования мышью" (опять-таки судя по туториалу), из-за такого начинают клепать код, вообще не понимая, что на самом деле происходит. Но это уже моя личная вкусовщина :)
Спасибо! Мы у себя TS+Redux не пробовали, у нас уже была кодобаза на Haskell и хотелось продолжать использовать чисто функциональный язык.
У одного из наших коллег был опыт использования Redux + React Native + TS, и ему реализация той же самой архитектуры в Elm показалась гораздо понятнее и типизация лучше.
Из моего опыта — стек mtl-трансформеров и Service Handle паттерн, который пробуем сейчас на проекте.
Если без технических подробностей, то мы недавно про Octopod рассказывали, он тоже на Haskell: https://habr.com/ru/company/typeable/blog/541430/
Я когда-то писала небольшой туториал по парсерам (https://habr.com/ru/post/436234/), вполне себе прикладная задача. Да и по запросу "haskell туториал" тут находятся посты. Но русскоязычных материалов в целом мало, это факт.
Будет интересно почитать :) Там, наверное, в каждом более-менее крупном городе можно что-то научное найти.
В музее науки в Лондоне есть зал, посвященный IT и CS, и там, помимо прочего, выставлена часть БЭСМ-6, Энигма, разностная машина, на которой работала Ада Лавлейс и разностная машина по чертежам Бэббиджа (построенная уже после его смерти).
Мой самый запоминающийся опыт: экзамен по правоведению в магистратуре, когда готовиться к гуманитарным предметам уже настолько лень, что даже бомбы от руки писать не хотелось. А материала много, одна вода неструктурированная, списывать я от природы умею плохо, оставалось только бомбить. Поэтому решили с товарищем всех перехитрить и напечатать бомбы рукописным шрифтом, максимально похожим на свой почерк. Был написан скрипт, который в вордовом документе вставлял рандомное число пробелов перед каждой строкой, чтобы строки выглядели «рваными». Но они всё равно казались слишком ровными, а возиться с межстрочным интервалом было лень, поэтому оставили как есть.
Отвечать билет надо было сидя за партой перед лектором, т.е. достаточно далеко, поэтому должно было прокатить. Но что-то пошло не так, когда я отвечала. Лектор не поленился встать и посмотреть поближе на мои «записи». Спросил, написаны ли они от руки и попросил принести ручку, которой я это писала. Терять было нечего, поэтому я показала чёрную ручку, похожую на тонкий фломастер (такие в оранжевом корпусе, они есть практически любого цвета, я ими всегда любила записывать лекции — красиво выходило, и при сканировании/фото всё хорошо видно). Препод понял, что я не сдаюсь, и попросил написать какое-то слово из билета. Тут мне помог многолетний опыт записывания в списки присутствующих на лекциях «мёртвых душ» разными почерками, поэтому я воспроизвела напечатанное слово практически идентично. Препод сдался и стал спрашивать по следующему билету, в итоге даже поставил отл. Я уверена, что он всё и так пропалил, но либо пожалел, либо удивился моей наглости (сама удивилась). Я ему до сих пор за это благодарна и мне всё ещё немного стыдно :)
Во время этого «перформанса» мой друг с такими же псевдорукописными шпорами панически переписывал свою бомбу своей ручкой, сокращая слова настолько, что потом не смог половину из них расшифровать при ответе (но тоже сдал).
Сейчас со скромным опытом преподавания понимаю, насколько любые шпоры заметны и насколько их наличие не имеет значения, особенно на устных экзаменах, где написанный тем или иным способом билет не гарантирует даже тройку. Вообще, огромное спасибо тем преподавателям, которые разрешали пользоваться справочными материалами для подготовки билета, и задавали уточняющие вопросы по доказательствам, а по памяти просили написать только базовые определения и утверждения. Меньше стресса, результат тот же.