А какая существует связь между переносимостью кода и индентом?

переносимость между редакторами. не все редакторы правильно работают с табами

Понял, спасибо:)

У разных людей Tab разной длины

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

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

radical! :-E

У меня даже в разных языках разные софттабы

> Second round of #CFP is now open for #FnConf18. We are looking for sessions on #Erlang #Elixir #Scala #Clojure #GoLang #APL & other #FunctionalProgramming languages отличный список ФЯ

ГОЛАНГ

Голаны.

& other Functional Programming language, теперь так Хаскель называется

хаскель это просто чуть более продвинутый го

> Second round of #CFP is now open for #FnConf18. We are looking for sessions on #Erlang #Elixir #Scala #Clojure #GoLang #APL & other #FunctionalProgramming languages отличный список ФЯ

>Scala "В мире слепых и одноглазый -- король"

Чуть-чуть более, да

менее продвинутый

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

более ленивый

Страшных слов надо не бояться

Насколько продвинутый Хаскелл?

где-то до конца 80-х - начала 90-х

> GC pauses that bring down your site during peak usage, at the most critical time of business for the company losing tons in revenue; leaked filehandles leading to “too many open files” and crashing your system; exceptions improperly ignored and dropped on the floor

где-то до конца 80-х - начала 90-х

А дальше Haskell не продвигали?

если сделают завтипы до конца 90-х продвинут

А хотя бы в 2010-ых какой язык?

или языки

Линейно-зависимые, Идрис претендует, но не проверено

если сделают завтипы до конца 90-х продвинут

а можно сначала линейные типы?

если сделают завтипы до конца 90-х продвинут

Да ладно, завтипы это 72'ой

ну первый язык с завтипами-то где-то 97-й

Coq 89'ый

так это пруфасситент а не язык

Возможно, что если будет язык с зависимостью от линейных, это уже 2020-е

тут речь про первый язык, вроде идриса

Потому что AFAIK никто до сих пор не знает, как это сделать

Идрис это тоже пруфасистент так-то, просто с фичами языка

Идрис это тоже пруфасистент так-то, просто с фичами языка

Чот мне кажется ровно наоборот

язык с фичами пруфассистента

Пруф ассистент в нём сбоку припёку через рефлекшон расширения

Чот мне кажется ровно наоборот

Он декларируется наоборот. А по факту из агды (которая декларируется именно как пруфасистент в фичами языка) и то лучше язык получается

Он декларируется наоборот. А по факту из агды (которая декларируется именно как пруфасистент в фичами языка) и то лучше язык получается

Субъективненько

ну агда скорее тоже язык с фичами пруфассистента

ну агда скорее тоже язык с фичами пруфассистента

Ну если агда язык, то и идрис, конечно, язык.

ATS 2 - язык?

то что я считаю первым ЯП с завтипами - Cayenne - точноне пруфассистент, даже без терминейшон чекера

Nurpl почему нет тогда?

да, плохой критерий действительно

А кто-нибудь знает, как в Haskell с model checking? Я находил библиотеки, но они какие-то уж очень proof-of-concept :-/

Downloaded ghc-ncurses6-8.4.3. Installing GHC ... Received ExitFailure 2 when running Raw command: /usr/bin/gmake install Run from: /home/jelf/.stack/programs/x86_64-linux/ghc-ncurses6-8.4.3.temp/ghc-8.4.3/ А где у ней логи спрятаны? (это $ stack build офк)

а хотя я могу просто запустить gmake и он в stodut все что надо напишет

@morozzzko будет жить. Поприветствуем!

Downloaded ghc-ncurses6-8.4.3. Installing GHC ... Received ExitFailure 2 when running Raw command: /usr/bin/gmake install Run from: /home/jelf/.stack/programs/x86_64-linux/ghc-ncurses6-8.4.3.temp/ghc-8.4.3/ А где у ней логи спрятаны? (это $ stack build офк)

.stack-work/logs/

.stack-work/logs/

даже папку не создало :(

~/.stack/global-project/.stack-work/logs/?

даже папку не создало :(

это в проекте или глобально?

это в проекте или глобально?

ни там ни там

да и нет глобального проекта

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

ни там ни там

так не бывает. если не в проекте, то ~/.stack/global-project/ должен создаваться

оно же ещё на этапе stack setup упало

а, это же не сборка пакета

это (до)сборка ghc

отож!

надо в .stack/programs/x86_64-linux/ghc-ncurses6-8.4.3.temp/ghc-8.4.3/ поискать логи

я там не нашел :(

но не суть

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

если я буду использовать стаковский yml вместо cabal, у меня не будет проблем с публикацией бибилотеки7

нет

там генерируется кабалфайл

если я буду использовать стаковский yml вместо cabal, у меня не будет проблем с публикацией бибилотеки7

А сейчас подходящее время, чтобы сказать, что не надо использовать ни stack, ни hpack?

@ix_designer будет жить. Поприветствуем!

Всем привет! Есть предложение для разработчиков/начинающих стартаперов. Я – senior product дизайнер по enterprise/SaaS/веб/мобилкам (ui/ux). Сейчас нахожусь в активном поиске работы уже несколько месяцев, потому что мне постоянно то компания, то проекты, то оплата не подходит. Но я не могу не заниматься дизайном и простаивать. Я делаю или бесплатно или очень дорого. Поэтому предложение: Готов бесплатно выделять +-8 часов в неделю на разработку вашего продукта, начиная от полного проектирования по бизнес-процессам/идеям и заканчивая hi-fi мокапами. Вы разработчик, который хочет сделать проект для портфолио с крутым дизайном? Пишите мне. Вы стартапер, у которого нет бюджета на хороший дизайн? Пишите мне. С вас какие-то гарантии, что проект будет в продакшене и отсутствие NDA.

А сейчас подходящее время, чтобы сказать, что не надо использовать ни stack, ни hpack?

если речь про nix то не особо, если чисто тезисы против то подходящее

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

Всем привет! Есть предложение для разработчиков/начинающих стартаперов. Я – senior product дизайнер по enterprise/SaaS/веб/мобилкам (ui/ux). Сейчас нахожусь в активном поиске работы уже несколько месяцев, потому что мне постоянно то компания, то проекты, то оплата не подходит. Но я не могу не заниматься дизайном и простаивать. Я делаю или бесплатно или очень дорого. Поэтому предложение: Готов бесплатно выделять +-8 часов в неделю на разработку вашего продукта, начиная от полного проектирования по бизнес-процессам/идеям и заканчивая hi-fi мокапами. Вы разработчик, который хочет сделать проект для портфолио с крутым дизайном? Пишите мне. Вы стартапер, у которого нет бюджета на хороший дизайн? Пишите мне. С вас какие-то гарантии, что проект будет в продакшене и отсутствие NDA.

Haskell?

Haskell?

Не относится?

реклама не про Хаскель — спам

почему же, человек хочет с закорешиться поработать с хаскелистами) хаскель по АПИ, дизайн через апи подключается - профессиональный ктож не хочет

А сейчас подходящее время, чтобы сказать, что не надо использовать ни stack, ни hpack?

что хпак не надо использовать - вполне подходящее, со стеком не все так однозначно

если речь про nix то не особо, если чисто тезисы против то подходящее

Насколько я знаю, @int_index использует cabal + nix, может быть он может рассказать про workflow.

Я про hpack раньше писал уже.

Выскажу не самое популярное мнение, но мне сильно не нравится hpack. Как по мне, он даёт не так много преимуществ, но поддержка со стороны тулинга и дружелюбность экосистемы уменьшается. А точнее по пунктам: 1. Многим нравится поле общих зависимостей (и не только) в hpack, но в cabal-2.2. это уже впилено, и там можно указать в общей станзе любой кусок станзы. 2. Автоматический поиск модуля: добавить модуль — одна строка. Это не так часто происходит, чтобы было слишком неудобно. К тому же, когда есть модули, которые генерируются пакетами вроде proto-lens, то их всё равно надо добавлять в package.yaml явно, без этого не работает, поэтому проблема всё равно полностью не решается. 3. YAML. Я сам лично не люблю этот формат, мне в нём много не нравится. Например, там были проблемы с парсингом версий, когда они у пакетов похожи на число. В одном multi-package проекте мы использовали hpack, и там дублицирование кода уменьшилось благодаря алиасам в yaml. Но полностью дублирование убрать не удалось, потому что yaml не поддерживает конкатенацию списков. Поэтому общие куски зависимостей между пакетами всё равно нельзя вынести в отдельный файл :( Если уж хочется полноценную и программируемую конфигурацию, тогда лучше использовать dhall. 4. Генерация .cabal файла с новым хешом каждый раз. Если над проектом работает несколько людей, то у них постоянно будут конфликты в этом .cabal файле, если он есть на GitHub. А если его нет на GitHub, то людям, у которых не стоит hpack, будет трудней сбилдить проект, надо прилагать больше усилий, чтобы этот cabal файл сгенерить. Да, stack работает, но вокруг одного stack мир не вертится. То есть как по мне, преимущества довольно сомнительные, но есть недостатки, создаётся раскол в сообществе, ухудшается и без того не самый хороший тулинг. Уж лучше все силы, что были потрачены на создание hpack ушли бы в cabal — добавить в exposed-modules какое-нибудь поле типа automatic, и весь hpack был бы не нужен.