т.к. пишут только факториалы

а факториал это максимум строчек 200 и то если упороться

10k loc это типа 10 000 строчек кода?

да

нету конечно, таких вообще не существует

Почему не существует? В коде ghc очень много строк ;) не уверен, что существовал хотя бы один момент времени, в котором от одного человека было бы 10К строк кода, но думаю, что несколько точно успело написать. Сдам @lightgreen. У него есть ;) У меня, к сожалению, поменьше...

@chshersh потому, что вопрос маловероятно что подразумевает нормальный ответ

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

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

Понял. Тогда я ошибся, у @lightgreen нет. Он нам нужен

вон в большом проекте (который один из тех что пишем), не считая того, что в связанных живущих в других репозиториях у меня 43,278 ++ / 28,624 -- по статам гитхаба

но будто это о чем говорит

все равно показать не смогу и всем придётся поверить

вон в большом проекте (который один из тех что пишем), не считая того, что в связанных живущих в других репозиториях у меня 43,278 ++ / 28,624 -- по статам гитхаба

ничеси цифры

поэтому я дал абсурдный ответ, если человек пришёл потроллить, будет не интересно, если серьёзно, то сформулирует вопрос и тему получше

ну это за год примерно, может полтора

@ilyaraz так в чем именно вопрос?

ну вопроса конкретного у меня нет: но интересно by and large, насколько легко вносить локальные изменения в большой проект

от проекта сильно зависит, во всяком случае приятнее, чем во многих языках

я ничего серьезного на Хаскелле не писал, но а приори кажется, что любое нетривиальное изменение влечет цепочку изменений

есть некоторые нехорошие моменты в дизайне, которые могут привести к тому, что придётся какое-то изменение много где протащить

если накосячить при проектировании

но такие изменения обычно механические

ну да, вроде монаду навесить?

в других языках ты узнаешь о том что эти изменения надо сделать сильно позже

возможно уже на проде

например, если чистый код был, который оказывается не чистым, но это обычно локализовано

или если лишние параметры/state явно таскались и хочется продолжать

впрочем все равно приятнее, чем во многих языках, где боишься что-то тронуть, чтобы все не развалилось

тут можно и достаточно большой рефакторинг делать

может у кого другой опыт

а, товарищи их serakel и hexresearch?

sorry "serokel"

минус фирмы названной от фамилии, очепятаешься и стыдно становится

serokell actually

!!

от блин

совсем стыдно

единственный раз, когда я пытался написать что-то не совсем крошечное, в какой-то момент оказалось, что в самой внутренней функции нужны случайные числа, и было все очень tedious исправлять

то есть это была не катастрофа отнюдь, но кажется, что в больших проектах это все должно умножаться на 10

скорее наоборот

сорри, я не имел ввиду троллить совершенно, но наверняка это стандартная проблема

в больших проектах больше взаимодействий и эффектов видно сразу

в итоге все достаточно модульно получается, и не разбегается по проекту

ок, понял

для меня такое утверждение выглядит удивительным, но остаётся только поверить :)

единственный раз, когда я пытался написать что-то не совсем крошечное, в какой-то момент оказалось, что в самой внутренней функции нужны случайные числа, и было все очень tedious исправлять

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

это те где для остальных нужно написать 16 строк чтобы скомбинировать готовые либы?

(сорри я немного не серьёзен, устал, а завтра опять вставать рано и на капельницы ехать)

но вообще пример выше валидный

ещё валидный - embedded / или какой realtime

ну большинство research кода как раз таково, да (я не промышленный программист, подвизаюсь в "академии")

надо написать high-performance лапши

поэкспериментировать и выкинуть

для такого — haskell, видимо, действительно не хорош, но мой пример со случайными с числами — не из этой области

если сильно high-performance, ещё нужно кучу SIMD и прочей веселухи, не факт, что haskell - best fit

(кодогенерация не в счет)

это те где для остальных нужно написать 16 строк чтобы скомбинировать готовые либы?

Я тоже не серьёзен. Например делаешь разбор грамматики. Казалось кто как не хаскель. Делаешь всю побочную фигню, потом поступаешь к алгоритму CYK И там грид с ссылками на парентов

и?

кстати, а вы знали что Tsuru Capitals оказывается живы и здоровы?

извините за offtop, просто вспомнилось и темы близкие

если сильно high-performance, ещё нужно кучу SIMD и прочей веселухи, не факт, что haskell - best fit

а нет либ, подобных numpy/tensorflow для питона, чтобы high-performance штуки на C/C++ высокоуровнево собирать на haskell?

hmatrix, всякие байндинги к лапакам есть

ERROR: S client not available

но их качество странное

когда на haskell пишешь хочется высокоуровневости при этом, а хорошее решение вроде не нашли

Ну ссылки во все стороны

https://github.com/fpco/inline-c-nag вот типа такого, например

(тут я не эксперт) но _простой_ data analysis, на питонах с пандасами или R plyr и т.п. писать кажется проще

простой в смысле прошёлся и выкинул

а нет либ, подобных numpy/tensorflow для питона, чтобы high-performance штуки на C/C++ высокоуровнево собирать на haskell?

я не думаю, что есть хорошая реализация многомерного массива

в интерактивном режиме

а чем многомерный массив отличается от одномерного, кроме наличия функции индексации?

я как-то смотрел, как high-performance hash tables реализованы (https://hackage.haskell.org/package/hashtables) — и там все было очень низкоуровнево и неприятно

и?

Ну двусвязные списки неприятно делать. Ещё неприятнее когда структура 2мерная

господа, такой вопрос: я хочу в некотором кэше держать exception в течении какого-то короткого времени, чтобы не бомбить IO, если там ошибка какая-то временная. не будет ли у меня каких-то проблем связанных с хранением именно exception? Типа там какой-нибудь большой и толстый stack trace, загадочные утечки памяти и т.п.

нет обычный тип

в общем что обычно случается, то и тут

круто

@qnikst

правильно?

?

Как наш уютный хаскеля чатик наполонили he?

*hr

Да тут и помимо hr, много разных людей. Я вот с чатика clojure сюда перекочевал

а можно ссылку на чатик про clojure,

?

https://t.me/clojure_ru

подскажите, есть какой-то более-менее формальный метод отображения типов-сумм в реляционные таблицы?

гуглится с трудом, всякие sum и union выдают маны по соответствующим функциям из sql

нашёл пару рецептов с использованием триггеров, но это выглядит как костыли

вот в project-m36, который, вроде как, представляет из себя настоящую реализацию реляционной модели, есть поддержка ADT https://github.com/agentm/project-m36/blob/master/docs/new_datatypes.markdown#implementation-for-haskell-types

но тут вопрос - они это через внутренние костыли делают или используют какие-то реляционные фокусы?

Не знаю насчёт формального метода, но в project-m36 используют не особо что-то умное на первый взгляд. В ячейках хранятся объекты типа Atom. Поиск по сорцам показывает, что произвольные ADT хранятся этим конструктором типа Atom: data Atom = ... | ConstructedAtom DataConstructorName AtomType [Atom] То есть по сути просто название конструктора и список полей. Как видно, не очень типобезопасно, ибо без зависимых типов грустно в этом случае (они могли бы помочь). Но у них есть инстансы для Generic, они используют женериковое представление структуры ADT, чтобы конвертировать в такой тип. Если их реализация протестирована норм, то проблем не должно быть.