Этого треда уже нет.
Это копия, сохраненная 4 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 4 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
>>644772
Чистота функций подразумевает, что результат функции зависит от её аргументов и ничего больше. Как там что передаётся - чистоте глубого ортогонально. "Явно через монадки" ты в Хаскелле хуй что заменеджишь, монадки лишь подразумевают упорядочивание сайд-эффектов, но не отмену чистоты. Есть вариант - либо заниматься байтоёбством, используя Foreign вместо нативных структур Хаскеля, либо писать на банальной прелюдии. По моему опыту ручное байтоёбство особых преимуществ не даёт в плане скорости, поэтому пиши всё максимально тупо для начала, а если уж появятся проблемы производительности, тогда их и решай вручную.
>>646867
Не надо декомпозировать в терминах теорката, декомпозируй функциями.
>Чистота функций подразумевает передачу данных как бы по значению.
Чистота функций подразумевает, что результат функции зависит от её аргументов и ничего больше. Как там что передаётся - чистоте глубого ортогонально. "Явно через монадки" ты в Хаскелле хуй что заменеджишь, монадки лишь подразумевают упорядочивание сайд-эффектов, но не отмену чистоты. Есть вариант - либо заниматься байтоёбством, используя Foreign вместо нативных структур Хаскеля, либо писать на банальной прелюдии. По моему опыту ручное байтоёбство особых преимуществ не даёт в плане скорости, поэтому пиши всё максимально тупо для начала, а если уж появятся проблемы производительности, тогда их и решай вручную.
>>646867
Не надо декомпозировать в терминах теорката, декомпозируй функциями.
Ответы>>650810
>>649725 (OP)
Пиздарики. ГДЕ ШАПКУ ПРОЕБАЛИ, УРОДЫ?!
Пиздарики. ГДЕ ШАПКУ ПРОЕБАЛИ, УРОДЫ?!
>>649730
Еще же у функции не должно быть сайдэффектов. Если передавать ссылки (на что-то мутабельное) то отсутсвие сайдэффектов гарантировать нельзя.
> Чистота функций подразумевает, что результат функции зависит от её аргументов и ничего больше.
Еще же у функции не должно быть сайдэффектов. Если передавать ссылки (на что-то мутабельное) то отсутсвие сайдэффектов гарантировать нельзя.
Ответы>>651924
>>650810
У функции не должно быть наблюдаемых сайдэффектов. Наблюдаемый - это как раз и означает, что нельзя определить функцию, результат которой зависит от какого-то внешнего контекста, кроме её параметров. У всех функций в Хаскелле есть сайдэффект - они процессор нагревают. Но наблюсти его Хаскель запрещает. Поэтому результат чистой функции будет тем же, вне зависимости от того, что ты до неё вызывал. Это и есть чистота.
>Еще же у функции не должно быть сайдэффектов.
У функции не должно быть наблюдаемых сайдэффектов. Наблюдаемый - это как раз и означает, что нельзя определить функцию, результат которой зависит от какого-то внешнего контекста, кроме её параметров. У всех функций в Хаскелле есть сайдэффект - они процессор нагревают. Но наблюсти его Хаскель запрещает. Поэтому результат чистой функции будет тем же, вне зависимости от того, что ты до неё вызывал. Это и есть чистота.
Ответы>>718082
>>649725 (OP)
Вопрос про работу на Хаскеле
Вопрос про работу на Хаскеле
Ответы>>655512
Какой смысл учить енту вашу скакалку, если на ней 2 вакансии, и на тех уже требуется опыт коммерческой разработки?
>>654441
Это реально существует или это легенды уровня "имиджборда на Idris"?
Это реально существует или это легенды уровня "имиджборда на Idris"?
>>654379
Пилить стартапы. Применять там, где нет жестких требований к стеку технологий. Для общего развития и паренимания гуд практис.
Пилить стартапы. Применять там, где нет жестких требований к стеку технологий. Для общего развития и паренимания гуд практис.
Ответы>>654783
>>654603
Для стартапов характерно отсутствие денег на чсв-хаскель-даунов и нормальное серверное железо, поэнтому, значится, энтот ваш хуячкель даже Goвну прососнёт в этой области.
Алсо, опознал тред только заглянув в прошлый. ОП там спился от безысходности чтоле?
Для стартапов характерно отсутствие денег на чсв-хаскель-даунов и нормальное серверное железо, поэнтому, значится, энтот ваш хуячкель даже Goвну прососнёт в этой области.
Алсо, опознал тред только заглянув в прошлый. ОП там спился от безысходности чтоле?
Ответы>>654974
>>654783
Ты не находишь, что твой ответ про применимость хачкелля на мой ответ на ответ анона про применимость скалы выглядит несколько странно?
Ребе рекомендовал бы тебе проспаться.
С чего ты решил, что я предлагаю устраиваться на работу в стартап с хачкеллями? Там был юзкейс - у аутиста возникла гениальная идея, меняющая мир, и аутист попиздил воплощать её на скалке, польхуясь сверхбыстрыми фреймворками на акторной модели, программированием на типах, и использованием одного языка во всем стеке. Ребе еще раз рекомендует тебе проспаться.
Ты не находишь, что твой ответ про применимость хачкелля на мой ответ на ответ анона про применимость скалы выглядит несколько странно?
Ребе рекомендовал бы тебе проспаться.
С чего ты решил, что я предлагаю устраиваться на работу в стартап с хачкеллями? Там был юзкейс - у аутиста возникла гениальная идея, меняющая мир, и аутист попиздил воплощать её на скалке, польхуясь сверхбыстрыми фреймворками на акторной модели, программированием на типах, и использованием одного языка во всем стеке. Ребе еще раз рекомендует тебе проспаться.
>>654364
У хаскеллистов нет проблем с трудоустройством, потому что нормальный хаскеллист знает хуеву тучу языков и технологий.
У хаскеллистов нет проблем с трудоустройством, потому что нормальный хаскеллист знает хуеву тучу языков и технологий.
Ответы>>657675
>>654379
Никакго. Если ты на той стадии, когда тебе надо "учить" язык программирования, ты просто еще не сформировался как программист. На Скалу берут не тех, кто "выучил Скалу", а тех, кто может решать задачи выбирая оптимальные инструменты (какие именно тебе дядя не скажет, это же не сопровождение легаси-говна в кровавом энтерпрайзе, где за тебя уже всё решили). Ну да, сегодня они пишут на Скале, скажем потому что под Spark удобнее писать на Скале. Но они так же пишут на R или на Питоне под Jupyter. А завтра какой-нибудь новый язык появится, более подходящий, и эти люди будут писать на нём, и меньше всего их будет волновать то, что они его "не знают".
Язык - это инструмент, как молоток. Изучать язык - это как изучать молоток. "Я выучил этот молоток и теперь буду всю жизнь забивать гвозди этим молотком." "Нам нужен специалист по Молоток 0.200кг слесарный фибергласовая ручка SPRING." "Опишите ваш опыт владения молотком 0.200кг слесарный фибергласовая ручка SPRING." "Перечислите паттерны забивания гвоздей, какими патернами забивания гвоздей вы владеете, мы забиваем гвоздь гвоздь строительный 4х120 мм сколько у вас лет опыта забивания гвозьдя строительного 4х120 мм?" "Я выучу молоток 0.200кг слесарный фибергласовая ручка SPRING и буду успешным, те, кто учат Молоток Kraftool 500г AutoKraft цельнокованый - сосут!" Вот Скала как бы не про это. Хотя, может быть, после того, как весь наш R&D на Скале окончательно уйдёт в энтерпрайз, а мы сами уйдём на новые проекты и новые инструменты, энтерпрайзу потребуются скаладебилы, чтобы всё это сопровождать, и тогда будут искать сеньор-скала-индусов со 100 годами опыта в уёбищных моструозных скала-фреймворках, примерно как сейчас энтерпрайз нанимает быдлокодеров на джаве.
Никакго. Если ты на той стадии, когда тебе надо "учить" язык программирования, ты просто еще не сформировался как программист. На Скалу берут не тех, кто "выучил Скалу", а тех, кто может решать задачи выбирая оптимальные инструменты (какие именно тебе дядя не скажет, это же не сопровождение легаси-говна в кровавом энтерпрайзе, где за тебя уже всё решили). Ну да, сегодня они пишут на Скале, скажем потому что под Spark удобнее писать на Скале. Но они так же пишут на R или на Питоне под Jupyter. А завтра какой-нибудь новый язык появится, более подходящий, и эти люди будут писать на нём, и меньше всего их будет волновать то, что они его "не знают".
Язык - это инструмент, как молоток. Изучать язык - это как изучать молоток. "Я выучил этот молоток и теперь буду всю жизнь забивать гвозди этим молотком." "Нам нужен специалист по Молоток 0.200кг слесарный фибергласовая ручка SPRING." "Опишите ваш опыт владения молотком 0.200кг слесарный фибергласовая ручка SPRING." "Перечислите паттерны забивания гвоздей, какими патернами забивания гвоздей вы владеете, мы забиваем гвоздь гвоздь строительный 4х120 мм сколько у вас лет опыта забивания гвозьдя строительного 4х120 мм?" "Я выучу молоток 0.200кг слесарный фибергласовая ручка SPRING и буду успешным, те, кто учат Молоток Kraftool 500г AutoKraft цельнокованый - сосут!" Вот Скала как бы не про это. Хотя, может быть, после того, как весь наш R&D на Скале окончательно уйдёт в энтерпрайз, а мы сами уйдём на новые проекты и новые инструменты, энтерпрайзу потребуются скаладебилы, чтобы всё это сопровождать, и тогда будут искать сеньор-скала-индусов со 100 годами опыта в уёбищных моструозных скала-фреймворках, примерно как сейчас энтерпрайз нанимает быдлокодеров на джаве.
>>655538
в анусе у тебя молоток, быдлан
в анусе у тебя молоток, быдлан
>>655538
Отлично!
Отлично!
Бля, подъебался с коллбеками в ScalaJS React, которые оказались монадическим типом. Долго пытался подпихивать вместо них обычные лямбды `(arg) => Unit`, и аутировал, отчего нихера не работает, лол. Наконец, прочитал документацию, переписал нахуй единообразно на `(arg) => Callback`, c расстановкой в нужных местах callback.runNow(). Теперь все и выглядит заебок, и понятно как работает. Люблю скалу за такие выкрутасы пейсателей библиотек.
Ответы>>659108
>>655538
Где берут?
>На Скалу берут не тех, кто "выучил Скалу", а тех, кто может решать задачи выбирая оптимальные инструменты
Где берут?
Ответы>>657678
>>655512
Apache/PHP/MySQL/Javascript/CSS/HTML
>потому что нормальный хаскеллист знает хуеву тучу языков и технологий.
Apache/PHP/MySQL/Javascript/CSS/HTML
Ответы>>659109
>>657674
Расшифрую для даунов: пионеры, выучившие захайпенный язычек не нужны. Последние детектирутся наличием отсутствия нормального бекграунда.
>Где берут?
Расшифрую для даунов: пионеры, выучившие захайпенный язычек не нужны. Последние детектирутся наличием отсутствия нормального бекграунда.
Ответы>>657741
>>657741
С чего ты так решил? Я вообще под с JVM на работе не пишу. Будет подходящий сайд-проект, напишу на Скалке, problems?
С чего ты так решил? Я вообще под с JVM на работе не пишу. Будет подходящий сайд-проект, напишу на Скалке, problems?
>>657753
да
да
>>657232
Враппер React-а - какое-то говно ебанное (как и большинство либ на Скале). Автор сделал это даже хуже, чем оригинальный React, затипизировал в усмерть то, что ненадо типизировать, наебашил имплицитов, добавил эти ёбанные коллбеки (сначала я думал, что это как-то связанно с асинхронностью, но потом внезапно посмотрел исходники и понял, что это обычная функция, завёрнутая в его тип, чтобы её "случайно" не вызвали откуда не надо). Дети, не делайте так, как делал автор React-а, это, блядь, какой-то фанбой, который открыл для себя тайп-левел и стал его использовать "потому что может", а не для того, чтобы сделать удобно.
Враппер React-а - какое-то говно ебанное (как и большинство либ на Скале). Автор сделал это даже хуже, чем оригинальный React, затипизировал в усмерть то, что ненадо типизировать, наебашил имплицитов, добавил эти ёбанные коллбеки (сначала я думал, что это как-то связанно с асинхронностью, но потом внезапно посмотрел исходники и понял, что это обычная функция, завёрнутая в его тип, чтобы её "случайно" не вызвали откуда не надо). Дети, не делайте так, как делал автор React-а, это, блядь, какой-то фанбой, который открыл для себя тайп-левел и стал его использовать "потому что может", а не для того, чтобы сделать удобно.
>>657675
Ну эту хуйню он тоже знает, но вряд ли станет использовать.
Ну эту хуйню он тоже знает, но вряд ли станет использовать.
>>659046
Это тред PLT-Бората)
Это тред PLT-Бората)
>>659105
define хачкелист
define хачкелист
>>659108
ЛОЛ. Тоже немного с них поплевался, потом читнул документацию, и понял, что они охуенны.
Вообще, там запилен аналог монады IO
Еще больший ЛОЛ.
Отличный враппер. Еще рекомендую вот эту хуйню вместо Redux - https://github.com/ochrons/diode
С ES6 и Риакт с меня безудержно льется поток мысли, код которого я через неделю не понимаю, со ScalaJS React же все выходит довольно стройно и продуманно, т.к. в нужных местах горячку боя приходится ограничивать и больше думать.
Кстати, псевдотеги в JSX я считал решением нормальным, теперь же понимаю, что в ScalaJS React решение намного лучше.
> добавил эти ёбанные коллбеки
ЛОЛ. Тоже немного с них поплевался, потом читнул документацию, и понял, что они охуенны.
> обычная функция, завёрнутая в его тип
Вообще, там запилен аналог монады IO
> затипизировал в усмерть то, что ненадо типизировать
Еще больший ЛОЛ.
> Враппер React-а - какое-то говно ебанное
Отличный враппер. Еще рекомендую вот эту хуйню вместо Redux - https://github.com/ochrons/diode
С ES6 и Риакт с меня безудержно льется поток мысли, код которого я через неделю не понимаю, со ScalaJS React же все выходит довольно стройно и продуманно, т.к. в нужных местах горячку боя приходится ограничивать и больше думать.
Кстати, псевдотеги в JSX я считал решением нормальным, теперь же понимаю, что в ScalaJS React решение намного лучше.
Ответы>>659179
>>659130
И какую задачу они решают?
Нахуя аналог монады IO в языке, где IO делается без всяких монад? Карго-культ?
Почему ЛОЛ? Профит типизации в том, что она позволяет ловить потенциальные ошибки на этапе конпеляции. Минус типизации в том, что программист должен доказыкать тайп-чекеру, что он прав. Нормальная типизация должна быть нацелена на проверку тех мест, где ошибка наиболее вероятна и на релаксацию в тех местах, где ошибка маловероятна, но доказательство корректности сложно. В Реакте всё наоборот.
>>659131
Джава - отличный язык в своём классе. Встречный вопрос: что лучше, быть примитивной Джавой, но делать всё по высшему классу в своём ОО-мирке, либо быть жалкой пародией на функциональный язык, пытаясь эмулировать Хаскель через говно, жопу и имплициты?
>и понял, что они охуенны.
И какую задачу они решают?
>Вообще, там запилен аналог монады IO
Нахуя аналог монады IO в языке, где IO делается без всяких монад? Карго-культ?
>Еще больший ЛОЛ.
Почему ЛОЛ? Профит типизации в том, что она позволяет ловить потенциальные ошибки на этапе конпеляции. Минус типизации в том, что программист должен доказыкать тайп-чекеру, что он прав. Нормальная типизация должна быть нацелена на проверку тех мест, где ошибка наиболее вероятна и на релаксацию в тех местах, где ошибка маловероятна, но доказательство корректности сложно. В Реакте всё наоборот.
>>659131
Джава - отличный язык в своём классе. Встречный вопрос: что лучше, быть примитивной Джавой, но делать всё по высшему классу в своём ОО-мирке, либо быть жалкой пародией на функциональный язык, пытаясь эмулировать Хаскель через говно, жопу и имплициты?
>>659179
Какую задачу решает монадический тип? Цитирую док по коллбекам:
>И какую задачу они решают?
>Нахуя аналог монады IO в языке, где IO делается без всяких монад? Карго-культ?
Какую задачу решает монадический тип? Цитирую док по коллбекам:
>meant to be run by an event handler or React lifecycle
>>659199
то есть, коллбеки запускаются именно в нужном месте датафлоу.
repetable именно за счет отсутствия побочных эффектов. хороший коллбек - функция, которая принимает коллбек и возвращает композицию коллбеков.
то есть, коллбеки запускаются именно в нужном месте датафлоу.
>repeatable. It can be run more than once.
repetable именно за счет отсутствия побочных эффектов. хороший коллбек - функция, которая принимает коллбек и возвращает композицию коллбеков.
Ответы>>660660
>>659194
F# - честный закос под OCaml. Все шарпоёбы, которые попробовали F# и поняли, что функциональное программирование им по нраву, быстро переметнулись с закоса на оригинал (ибо нахуй пользоваться закосом, если есть оригинал), а когда поняли, что OCaml - говно, переметнулись с него на настоящий функциональный язык. Причем большая часть шарпоёбов OCaml вообще пропустила и сразу начала кодить на Хаскелле. Поэтому F# не сыскал популярности - это переходный язык.
F# - честный закос под OCaml. Все шарпоёбы, которые попробовали F# и поняли, что функциональное программирование им по нраву, быстро переметнулись с закоса на оригинал (ибо нахуй пользоваться закосом, если есть оригинал), а когда поняли, что OCaml - говно, переметнулись с него на настоящий функциональный язык. Причем большая часть шарпоёбов OCaml вообще пропустила и сразу начала кодить на Хаскелле. Поэтому F# не сыскал популярности - это переходный язык.
Ответы>>663969
Ссука, хотел написать длинный ответ, блядская макаба ругается на слова из спам-листа, хуй на нее.
>>659199
Никакой. Конкретно в Хаскелле монада IO решает задачу IO, там по-другому IO не сделать, by design. Какую задачу решают каллбеки во враппере над реактом. Конкретезируй, пожалуста.
>Какую задачу решает монадический тип?
Никакой. Конкретно в Хаскелле монада IO решает задачу IO, там по-другому IO не сделать, by design. Какую задачу решают каллбеки во враппере над реактом. Конкретезируй, пожалуста.
>>659205
Значительная часть действий над враппером возвращают коллбеки, например, setState возвращает коллбек, dispatch экшена в стор возвращает коллбек. Таким образом, в своих обработчиках мы раньше времени не вызываем побочные эффекты, а только комбинируем вычисления, их вызывающие, и передаем их выше по dataflow. Итого, мы меньше раз воздействуем на State, следовательно, и VDom обходится лишних без промежуточных обновлений.
Значительная часть действий над враппером возвращают коллбеки, например, setState возвращает коллбек, dispatch экшена в стор возвращает коллбек. Таким образом, в своих обработчиках мы раньше времени не вызываем побочные эффекты, а только комбинируем вычисления, их вызывающие, и передаем их выше по dataflow. Итого, мы меньше раз воздействуем на State, следовательно, и VDom обходится лишних без промежуточных обновлений.
Ответы>>660660
>>659179
А что, по твоему мнению, в ScalaJS React излишне затипзировано, и его не стоило бы типизировать?
А что, по твоему мнению, в ScalaJS React излишне затипзировано, и его не стоило бы типизировать?
Ответы>>660660
>>659240
Он всё правильно сказал.
Кстати сисярп - тупое гавно как и ява. То что он реализует все твои хотелки, значит лишь что хотелки эти у тебя на уровне пхп-макаки.
Он всё правильно сказал.
Кстати сисярп - тупое гавно как и ява. То что он реализует все твои хотелки, значит лишь что хотелки эти у тебя на уровне пхп-макаки.
Ответы>>660683
>>659194
Просто f# - говнецо то ещё. Он хорош в пердолинге стримов, где и используется, но в остальном он даже хуже окамла. Сам по себе создаёт впечатление черезжопносделанного языка, да ещё и доднет изо всех щелей торчит.
Просто f# - говнецо то ещё. Он хорош в пердолинге стримов, где и используется, но в остальном он даже хуже окамла. Сам по себе создаёт впечатление черезжопносделанного языка, да ещё и доднет изо всех щелей торчит.
Ответы>>659366
Мультипарадигма это такая лалка. Вот хочешь ты написать нормальный императивный код. Но где же break, continue, if с одной веткой, premature return? А ха, ведь все же это нинужно. Или можнозделоть. Ну заебись теперь.
Про функциональные же грабли монадогоспода могут еще больше охуительных историй рассказать.
Про функциональные же грабли монадогоспода могут еще больше охуительных историй рассказать.
>>659554
Аутисты, говноеды, почему до вас так медлено доходит, что ваше дерьмо не нужно?
>Но где же goto? Ну заебись теперь
Аутисты, говноеды, почему до вас так медлено доходит, что ваше дерьмо не нужно?
Ответы>>659683
>>659583
Я бы и goto не сбрасывал со счетов если использовать его умеренно. В сишке особенно. Просто у "евангелистов" старой школы бомбило от этих конструктов потому что они никак не вписываются в их "троечки". Вон они и рассказывали охуительные истории что все это нинужно. А кодерки рты пооткрывали - говно жрут, да добавки просят.
Я бы и goto не сбрасывал со счетов если использовать его умеренно. В сишке особенно. Просто у "евангелистов" старой школы бомбило от этих конструктов потому что они никак не вписываются в их "троечки". Вон они и рассказывали охуительные истории что все это нинужно. А кодерки рты пооткрывали - говно жрут, да добавки просят.
>>659683
Ты бы и собаку со счетов не сбрасывал, говнокодер
Ты бы и собаку со счетов не сбрасывал, говнокодер
>>659683
В общелиспе и сейчас goto активно используется. Правда не напрямую, а в макросах.
В общелиспе и сейчас goto активно используется. Правда не напрямую, а в макросах.
Ответы>>660343
>>659842
Для чего? В Си goto используется только для фалоимитации RAII и в кодогенерированных стейтмашинах.
Для чего? В Си goto используется только для фалоимитации RAII и в кодогенерированных стейтмашинах.
Ответы>>661008
>>659554
whileM, when, чо там у вас еще есть, хасканы?
>break, continue, if с одной веткой, premature return
whileM, when, чо там у вас еще есть, хасканы?
Ответы>>734790
>>659366
Пошел нахуй, клоун.
Пошел нахуй, клоун.
>>659200
Но ведь у каллбеков вполне могут быть сайд-эффекты. Реактовский каллбек - это обычная скала-функция, никто сайдэффекты для них не отменял.
>>659208
Пожалуйста, опиши проблему и способ её решения.
>>659220
Скаловский враппер React-а не сильно затипизирован, он неправильно затипизирован. Скажем так, у компоентов React есть определенный жизненный цикл и не все действия для них корректны в произвольный момент времени. И это нормально для подобных фреймворков, сотни подобных решений в сущетвуют ОО-мирке. Скажем, ты не можешь писать что-то в файл до того, как откроешь его для записи, и тому подобное, никого это особо не смущает при работе с файлами. В скаловском Реакте типизируется жизненный цикл компонента. Это приводит к порождению мусрных классов, вроде ReactComponentB, ReactComponentC, ReactComponentU, ReactComponentM и цепочки коструктора вроде .initialState(..).renderBackend(..).componenDidMount(..).componentWillUnmount(..).propsRequired... Единстсвенное назначение этой хуеты в том, что ты не вызовешь что-то на этапе componenDidMount, что доступно только в renderBackend. Цепочки, кстати, онально типизированы и даже макросы там приплели, поэтому с композабельностью у них проблемы, а в оригинальном Реакте - это просто вызовы методов компонента. Ну и какую проблему в итоге решают эти ональные изъёбства? Ведь если я программирую под React, я более-менее знаком с его архитектурой, и шанс ошибиться в жизненном цикле компонента для меня достаточно низок (жизненный цикл у всех компонентов одинаковый, я скорее в модели данных накосячу). А издержки такой типизации весьма велики.
Но хватит теории, давай перейдём к практике. Практическая задача: я использую Реакт и стороннюю либу, которая рисует графики. Для отрисовки графика я должен передать либе уникальный айдишник html элемента, в котором я хочу этот график отрисовать. Т.е. нужно банально генерировать уникальные айдишники. Решение на оригинальном Реакте:
[code]
React.createClass({
componentWillMount() {
this.id = newId();
},
render() {
return (
<div id={this.id} />
);
}
});
[/code]
Решение на скаловском враппере: есть оно у меня, но я тебе оставлю удовольствие написать его самостоятельно, чтобы ты на собственном опыте убедился, насколько скаловский враппер юзер-френдли
Но ведь у каллбеков вполне могут быть сайд-эффекты. Реактовский каллбек - это обычная скала-функция, никто сайдэффекты для них не отменял.
>>659208
Пожалуйста, опиши проблему и способ её решения.
>>659220
Скаловский враппер React-а не сильно затипизирован, он неправильно затипизирован. Скажем так, у компоентов React есть определенный жизненный цикл и не все действия для них корректны в произвольный момент времени. И это нормально для подобных фреймворков, сотни подобных решений в сущетвуют ОО-мирке. Скажем, ты не можешь писать что-то в файл до того, как откроешь его для записи, и тому подобное, никого это особо не смущает при работе с файлами. В скаловском Реакте типизируется жизненный цикл компонента. Это приводит к порождению мусрных классов, вроде ReactComponentB, ReactComponentC, ReactComponentU, ReactComponentM и цепочки коструктора вроде .initialState(..).renderBackend(..).componenDidMount(..).componentWillUnmount(..).propsRequired... Единстсвенное назначение этой хуеты в том, что ты не вызовешь что-то на этапе componenDidMount, что доступно только в renderBackend. Цепочки, кстати, онально типизированы и даже макросы там приплели, поэтому с композабельностью у них проблемы, а в оригинальном Реакте - это просто вызовы методов компонента. Ну и какую проблему в итоге решают эти ональные изъёбства? Ведь если я программирую под React, я более-менее знаком с его архитектурой, и шанс ошибиться в жизненном цикле компонента для меня достаточно низок (жизненный цикл у всех компонентов одинаковый, я скорее в модели данных накосячу). А издержки такой типизации весьма велики.
Но хватит теории, давай перейдём к практике. Практическая задача: я использую Реакт и стороннюю либу, которая рисует графики. Для отрисовки графика я должен передать либе уникальный айдишник html элемента, в котором я хочу этот график отрисовать. Т.е. нужно банально генерировать уникальные айдишники. Решение на оригинальном Реакте:
[code]
React.createClass({
componentWillMount() {
this.id = newId();
},
render() {
return (
<div id={this.id} />
);
}
});
[/code]
Решение на скаловском враппере: есть оно у меня, но я тебе оставлю удовольствие написать его самостоятельно, чтобы ты на собственном опыте убедился, насколько скаловский враппер юзер-френдли
>>659200
Но ведь у каллбеков вполне могут быть сайд-эффекты. Реактовский каллбек - это обычная скала-функция, никто сайдэффекты для них не отменял.
>>659208
Пожалуйста, опиши проблему и способ её решения.
>>659220
Скаловский враппер React-а не сильно затипизирован, он неправильно затипизирован. Скажем так, у компоентов React есть определенный жизненный цикл и не все действия для них корректны в произвольный момент времени. И это нормально для подобных фреймворков, сотни подобных решений в сущетвуют ОО-мирке. Скажем, ты не можешь писать что-то в файл до того, как откроешь его для записи, и тому подобное, никого это особо не смущает при работе с файлами. В скаловском Реакте типизируется жизненный цикл компонента. Это приводит к порождению мусрных классов, вроде ReactComponentB, ReactComponentC, ReactComponentU, ReactComponentM и цепочки коструктора вроде .initialState(..).renderBackend(..).componenDidMount(..).componentWillUnmount(..).propsRequired... Единстсвенное назначение этой хуеты в том, что ты не вызовешь что-то на этапе componenDidMount, что доступно только в renderBackend. Цепочки, кстати, онально типизированы и даже макросы там приплели, поэтому с композабельностью у них проблемы, а в оригинальном Реакте - это просто вызовы методов компонента. Ну и какую проблему в итоге решают эти ональные изъёбства? Ведь если я программирую под React, я более-менее знаком с его архитектурой, и шанс ошибиться в жизненном цикле компонента для меня достаточно низок (жизненный цикл у всех компонентов одинаковый, я скорее в модели данных накосячу). А издержки такой типизации весьма велики.
Но хватит теории, давай перейдём к практике. Практическая задача: я использую Реакт и стороннюю либу, которая рисует графики. Для отрисовки графика я должен передать либе уникальный айдишник html элемента, в котором я хочу этот график отрисовать. Т.е. нужно банально генерировать уникальные айдишники. Решение на оригинальном Реакте:
[code]
React.createClass({
componentWillMount() {
this.id = newId();
},
render() {
return (
<div id={this.id} />
);
}
});
[/code]
Решение на скаловском враппере: есть оно у меня, но я тебе оставлю удовольствие написать его самостоятельно, чтобы ты на собственном опыте убедился, насколько скаловский враппер юзер-френдли
Но ведь у каллбеков вполне могут быть сайд-эффекты. Реактовский каллбек - это обычная скала-функция, никто сайдэффекты для них не отменял.
>>659208
Пожалуйста, опиши проблему и способ её решения.
>>659220
Скаловский враппер React-а не сильно затипизирован, он неправильно затипизирован. Скажем так, у компоентов React есть определенный жизненный цикл и не все действия для них корректны в произвольный момент времени. И это нормально для подобных фреймворков, сотни подобных решений в сущетвуют ОО-мирке. Скажем, ты не можешь писать что-то в файл до того, как откроешь его для записи, и тому подобное, никого это особо не смущает при работе с файлами. В скаловском Реакте типизируется жизненный цикл компонента. Это приводит к порождению мусрных классов, вроде ReactComponentB, ReactComponentC, ReactComponentU, ReactComponentM и цепочки коструктора вроде .initialState(..).renderBackend(..).componenDidMount(..).componentWillUnmount(..).propsRequired... Единстсвенное назначение этой хуеты в том, что ты не вызовешь что-то на этапе componenDidMount, что доступно только в renderBackend. Цепочки, кстати, онально типизированы и даже макросы там приплели, поэтому с композабельностью у них проблемы, а в оригинальном Реакте - это просто вызовы методов компонента. Ну и какую проблему в итоге решают эти ональные изъёбства? Ведь если я программирую под React, я более-менее знаком с его архитектурой, и шанс ошибиться в жизненном цикле компонента для меня достаточно низок (жизненный цикл у всех компонентов одинаковый, я скорее в модели данных накосячу). А издержки такой типизации весьма велики.
Но хватит теории, давай перейдём к практике. Практическая задача: я использую Реакт и стороннюю либу, которая рисует графики. Для отрисовки графика я должен передать либе уникальный айдишник html элемента, в котором я хочу этот график отрисовать. Т.е. нужно банально генерировать уникальные айдишники. Решение на оригинальном Реакте:
[code]
React.createClass({
componentWillMount() {
this.id = newId();
},
render() {
return (
<div id={this.id} />
);
}
});
[/code]
Решение на скаловском враппере: есть оно у меня, но я тебе оставлю удовольствие написать его самостоятельно, чтобы ты на собственном опыте убедился, насколько скаловский враппер юзер-френдли
Ответы>>667973
>>659296
Не такое тупое. Есть тупое гавно как Ява. Есть попытка TPL-Боратов реализовать аналог функционального языка над Джавой, она называется Скалой и с ней всё понятно (полный проёб юзабилити). Есть Сисярп, который, в целом, слабее Скалы по выразительности, но зато с юзабилити у него всё охуенно - брали лучшие функциональные паттерны и вшивали их в язык, да так, чтобы пользоваться ими было удобно. Есть F# - он очень нужен Микрософту чтобы отработать функциональные паттерны перед тем, как вшивать их в C#, но не очень нужен программистам. В итоге мы имеем:
1. Скалу, где можно любые ональные трюки, но через жопу
2. Сисярп, где не любой онал возможен, но тот, который возможен, сделан удобно и энтерпрайзно
3. Джаву, которая убога, но, зато, хороша и предсказуема в своём убожестве.
>Кстати сисярп - тупое гавно как и ява.
Не такое тупое. Есть тупое гавно как Ява. Есть попытка TPL-Боратов реализовать аналог функционального языка над Джавой, она называется Скалой и с ней всё понятно (полный проёб юзабилити). Есть Сисярп, который, в целом, слабее Скалы по выразительности, но зато с юзабилити у него всё охуенно - брали лучшие функциональные паттерны и вшивали их в язык, да так, чтобы пользоваться ими было удобно. Есть F# - он очень нужен Микрософту чтобы отработать функциональные паттерны перед тем, как вшивать их в C#, но не очень нужен программистам. В итоге мы имеем:
1. Скалу, где можно любые ональные трюки, но через жопу
2. Сисярп, где не любой онал возможен, но тот, который возможен, сделан удобно и энтерпрайзно
3. Джаву, которая убога, но, зато, хороша и предсказуема в своём убожестве.
Ответы>>663969
>>660343
Ну, например, циклы через них реализуются (loop, dotimes, dolist и т.д.). Для фсм тоже.
Ну, например, циклы через них реализуются (loop, dotimes, dolist и т.д.). Для фсм тоже.
>>660683
Фантазер-теоретик ИТТ. Я писал на этих языках (кроме F#, на нём наверное вакансий меньше чем на Хаскеле, в Киеве их вообще не видел) и по юзабилити C# близко не стоит со скалой.
Подробнее с этого момента, желательно со ссылками.
>>659205
Это не так, можно (и раньше было) на продолжениях.
>>659202
Очень часто (почти всегда) платформа значит больше чем чистота парадигмы.
>>659194
Он не сыскал популярности из-за закрытой платформы и почти польного отсутствия маркетинга.
>>659179
Ты же не писал на джаве, челик, иначе о каком высшем классе идет речь?
Тут свобода выбора: хочешь эмулировать хакель - эмулируешь сам или берешь уже сэмулированный - scalaz/cats, не хочешь - не эмулируешь, пишешь идиоматичный скала код.
Фантазер-теоретик ИТТ. Я писал на этих языках (кроме F#, на нём наверное вакансий меньше чем на Хаскеле, в Киеве их вообще не видел) и по юзабилити C# близко не стоит со скалой.
>Есть F# - он очень нужен Микрософту чтобы отработать функциональные паттерны перед тем, как вшивать их в C#, но не очень нужен программистам
Подробнее с этого момента, желательно со ссылками.
>>659205
>там по-другому IO не сделать, by design
Это не так, можно (и раньше было) на продолжениях.
>>659202
> поняли, что функциональное программирование им по нраву
Очень часто (почти всегда) платформа значит больше чем чистота парадигмы.
>>659194
>F# такой популярности не сыскал, как раз потому что C# уже неплох и все хотелки реализует
Он не сыскал популярности из-за закрытой платформы и почти польного отсутствия маркетинга.
>>659179
>что лучше, быть примитивной Джавой, но делать всё по высшему классу в своём ОО-мирке
Ты же не писал на джаве, челик, иначе о каком высшем классе идет речь?
>жалкой пародией на функциональный язык, пытаясь эмулировать Хаскель через говно, жопу и имплициты?
Тут свобода выбора: хочешь эмулировать хакель - эмулируешь сам или берешь уже сэмулированный - scalaz/cats, не хочешь - не эмулируешь, пишешь идиоматичный скала код.
Ответы>>667156
Что взять для сайтов на Haskell?
Ответы>>667169
>>661112
Всё познаётся в сравнении, по сравнению с говном и уксус сладок.
>>663969
Спасибо, я тоже руководитель разработки.
Вот именно, сравни Slick c LINQ.
Async Workflow. Проверили на F#, поняли, что нужно, добавили в C#, причем на уровне языка, сделали заметно лучше, народ доволен.
Нет. Или покажи код.
Блядь, ну почему какой-то сраный уёбок в анонимном чате объясняет мне на чем я писал и на чем я не писал? Ну как же так? Ты, может быть, длинну моего члена сейчас так же назовёшь? Ну напиши мне "Ты же не писал на джаве, а член у тебя 18 сантиметров", и завтра я проснусь и пойму, что я нихуя не писал на джаве, и вообще не руководитель разработки, зато член у меня - 18 сантиметров, а не восемь, как сейчас. Я тебе даже благодарен за это буду.
Всё познаётся в сравнении, по сравнению с говном и уксус сладок.
>>663969
>Фантазер-теоретик
Спасибо, я тоже руководитель разработки.
>по юзабилити C# близко не стоит со скалой
Вот именно, сравни Slick c LINQ.
>Подробнее с этого момента, желательно со ссылками.
Async Workflow. Проверили на F#, поняли, что нужно, добавили в C#, причем на уровне языка, сделали заметно лучше, народ доволен.
>Это не так, можно (и раньше было) на продолжениях.
Нет. Или покажи код.
>Ты же не писал на джаве
Блядь, ну почему какой-то сраный уёбок в анонимном чате объясняет мне на чем я писал и на чем я не писал? Ну как же так? Ты, может быть, длинну моего члена сейчас так же назовёшь? Ну напиши мне "Ты же не писал на джаве, а член у тебя 18 сантиметров", и завтра я проснусь и пойму, что я нихуя не писал на джаве, и вообще не руководитель разработки, зато член у меня - 18 сантиметров, а не восемь, как сейчас. Я тебе даже благодарен за это буду.
Ответы>>667455
>>667015
Я бы ответил Yesod, очевидно. Хотя нахуй писать сайты на Хаскелле - отдельный вопрос. Если у тебя возникло желание писать сайты на Хаскелле, значит у тебя есть на это причины, т.е. ты его, как миниум, достаточно хорошо знаешь. Если ты его достаточно хорошо знаешь, значит ты в курсе и про Yesod. Если ты задаешь при этом вопрос "Что взять для сайтов на Haskell?" значит ты нихуя не знаешь языка и его инфраструктуры и спрашиваешь "я нихуя не знаю Хаскель, но как на нём писать сайты?" Ну и нахуй тебе Хаскель, пиши сайты на том, что знаешь.
Я бы ответил Yesod, очевидно. Хотя нахуй писать сайты на Хаскелле - отдельный вопрос. Если у тебя возникло желание писать сайты на Хаскелле, значит у тебя есть на это причины, т.е. ты его, как миниум, достаточно хорошо знаешь. Если ты его достаточно хорошо знаешь, значит ты в курсе и про Yesod. Если ты задаешь при этом вопрос "Что взять для сайтов на Haskell?" значит ты нихуя не знаешь языка и его инфраструктуры и спрашиваешь "я нихуя не знаю Хаскель, но как на нём писать сайты?" Ну и нахуй тебе Хаскель, пиши сайты на том, что знаешь.
>>667156
Одно другому не мешает. Можно педалить какую-то хуйню на шарпе и теоретизировать о других языках, чем ты и занимаешься.
Ок. А как поняли что нужно? Или как бы поняли что не нужно? Где вообще про эту "обкатку" фич можно почитать?
Ты про Entity Framework? Любитель подолбиться в жопу ORM'ами?
https://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-standard-prelude-circa-1994/
Хуй знает, писал так писал, просто такое впечатление складывается после слов о том что язык с типами вне объектной иерархии и отсутствием наследования реализации делает
>Фантазер-теоретик
>руководитель разработки
Одно другому не мешает. Можно педалить какую-то хуйню на шарпе и теоретизировать о других языках, чем ты и занимаешься.
>Async Workflow. Проверили на F#, поняли, что нужно, добавили в C#, причем на уровне языка, сделали заметно лучше, народ доволен.
Ок. А как поняли что нужно? Или как бы поняли что не нужно? Где вообще про эту "обкатку" фич можно почитать?
>Вот именно, сравни Slick c LINQ.
Ты про Entity Framework? Любитель подолбиться в жопу ORM'ами?
>Нет. Или покажи код.
https://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-standard-prelude-circa-1994/
>Ты же не писал на джаве
Хуй знает, писал так писал, просто такое впечатление складывается после слов о том что язык с типами вне объектной иерархии и отсутствием наследования реализации делает
>всё по высшему классу в своём ОО-мирке
>>667645
Есть разбросанные по интернету курсы вроде того, что на stepic или school of haskell, ну и блог посты типа 24 days of hackage или описывающие отдельные расширения/либы/опыты программиста.
Есть разбросанные по интернету курсы вроде того, что на stepic или school of haskell, ну и блог посты типа 24 days of hackage или описывающие отдельные расширения/либы/опыты программиста.
>>667645
Ну и тайпклассопедия с хаскел вики, конечно
Ну и тайпклассопедия с хаскел вики, конечно
>>660660
Просто не стоит обмазывать скалу жс-говном, лучше взять чистые скала-решения, вроде ScalaRx и ScalaTags
мимо
Просто не стоит обмазывать скалу жс-говном, лучше взять чистые скала-решения, вроде ScalaRx и ScalaTags
мимо
https://youtu.be/5t4WntcsZZo?t=1744
Вот где реальная движуха, а не ваш пердолинг с комбинаторами комбинаторов. Оправдывайтесь, мрази.
Вот где реальная движуха, а не ваш пердолинг с комбинаторами комбинаторов. Оправдывайтесь, мрази.
>>669308
на 29:05 самая мякотка
на 29:05 самая мякотка
>>669308
ниочём вообще
ниочём вообще
Несколько лет назад был срач, Functional Dependencies vs. Type Families. Очень часто приводились доводы, что TF круче FD во всех отношениях.
Но победили в результате FD. mtl основана на FD. Вся инфраструктура Кметта основана на FD.
Почему так получилось?
Но победили в результате FD. mtl основана на FD. Вся инфраструктура Кметта основана на FD.
Почему так получилось?
>>671698
Двачую вопрос. В Mercury тоже, кстати, отказались от TF в пользу FD.
Мне кажется, что FD более общий концепт, который может быть применён хоть в реляционной теории, хоть где ещё, в то время как TF просто костыль для языков с хаскель-подобной системой типов.
Двачую вопрос. В Mercury тоже, кстати, отказались от TF в пользу FD.
Мне кажется, что FD более общий концепт, который может быть применён хоть в реляционной теории, хоть где ещё, в то время как TF просто костыль для языков с хаскель-подобной системой типов.
>>671698
Тому що нет инжективных TF. А для случая `class Foo a b | a -> b` они не нужны вовсе.
Они для хазохизма и всяких servantов
Тому що нет инжективных TF. А для случая `class Foo a b | a -> b` они не нужны вовсе.
Они для хазохизма и всяких servantов
А бамп, не?
>>671698
Адепты TF постоянно рассказывали про то, что FD - это частный случай TF. Но в FD можно сделать class Yoba a b | a -> b, b ->a. Как это делать в TF я так и не понял. Да, в TF можно вообще убрать один параметр тайпкласса, если у тебя зависимость только в одну сторону, т.е. сделть class Yoba a where type YobaB a, что удобно и ускоряет работу тайпчекера. Но в некоторых случаях FD явно удобнее. Поэтому оба подхода следует оставить и использовать наиболее подходящий по случаю.
>Почему так получилось?
Адепты TF постоянно рассказывали про то, что FD - это частный случай TF. Но в FD можно сделать class Yoba a b | a -> b, b ->a. Как это делать в TF я так и не понял. Да, в TF можно вообще убрать один параметр тайпкласса, если у тебя зависимость только в одну сторону, т.е. сделть class Yoba a where type YobaB a, что удобно и ускоряет работу тайпчекера. Но в некоторых случаях FD явно удобнее. Поэтому оба подхода следует оставить и использовать наиболее подходящий по случаю.
Знатоки, посоветуйте нормальную либу для FRP. "Нормальная" для меня значит по крайней мере доведенная до рабочего состояния.
Ответы>>696905
>>694654
Reactive Banana, Reflex
Reactive Banana, Reflex
50 Кб, 600x365
Считанные дни остались до релиза GHC 8.0.1, cчитанные тикеты осталось закрыть. 20 коммитов было замерджено за понедельник в ветку 8.0, 20 коммитов за один день, Карл, и это не считая либ! Snoyberg, Conal Elliott, Ben Gamari, Thomas Miedema, Simon PJ, Joachim Breitner, Richard Eisenberg и многие другие мастера не покладают своих рук, чтобы дать тебе этот инструмент! Десятки статей, нашедших воплощение в коде, сотни высококлассных программистов, тысячи автоматических тестов, это The Glorious Haskell Compiler 8.0.1, намеченный в апреле. Апрель, месяц весны, месяц любви, ты влюбишься в этот компилятор, я тебе обещаю.
Что он подарит нам, как изменит наш подход к программированию? Прежде всего, 8.0.1 - это первый шаг, первая фаза интеграции полноценных зависимых типов в практически уже индустриальный компилятор: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 Да, мы знаем, как сделать зависимые типы пргодными для практического использования, у нас есть roadmap и мы сделаем это. Как всегда, на самом высоком уровне, под брендом Haskell и ставшими уже привычными для вас стандартами качества Haskell.
Что он подарит нам, как изменит наш подход к программированию? Прежде всего, 8.0.1 - это первый шаг, первая фаза интеграции полноценных зависимых типов в практически уже индустриальный компилятор: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 Да, мы знаем, как сделать зависимые типы пргодными для практического использования, у нас есть roadmap и мы сделаем это. Как всегда, на самом высоком уровне, под брендом Haskell и ставшими уже привычными для вас стандартами качества Haskell.
>>649725 (OP)
есть ли шансы у с++ макаки перекатиться в хаскель?
что читать посоветуете, чтобы не совсем для нубов, но понять все аспекты языка и начать что-то писать на нем?
есть ли шансы у с++ макаки перекатиться в хаскель?
что читать посоветуете, чтобы не совсем для нубов, но понять все аспекты языка и начать что-то писать на нем?
>>716349
Что значит "перекатится"? Писать для себя - изи. А работу на нём найти практически нереально, даже опытным хаскелистам - её просто нет.
Что значит "перекатится"? Писать для себя - изи. А работу на нём найти практически нереально, даже опытным хаскелистам - её просто нет.
Ответы>>718084
>>716349
Не надо с++ макаке перекатываться в Хаскель. Хаскель никак не отменяет сепепе, сепепе - это низкоуровневый язык, почти такой же, как се, может быть в чём-то удобнее, но задачи решает почти те же. Поэтому сепепе-макака должна не перекатываться в Хаскель, а осваивать Хаскель в дополнение к сепепе. Ну вот глянь для примера на хаскелевские хешь-табилцы: https://github.com/gregorycollins/hashtables Ой, что там у нас, 88.8% кода на Хаскелле, а 10.6% - на се. И что там у нас на се? Ой, SSE4 для вычисления хешей и линейного поиска. Ну т.е. может ли в природе существовать абстрактная хаскель-макака, которая кроме Хаскеля ни на чем не программирует? Нет, не может, любая реальная хаскель-макака - это макака, которая знает Хаскель, но так же в любой момент не стремается написать немного кода на се. В конце концов хаскель-кабал прямо из коробки сешный код компилирует, что намекает, и даже в чистом Хаскеле не считается каким-то моветоном использовать сишный препроцессор. Поэтому тут нет никакого "перекатиться", что-то тебе после освоения Хаскеля тебе уже не захочется писать на сепепе и ты будешь делать это чисто на Хаскеле. А что-то ты так и будешь писать на сепепе или вообще на чистом се.
>есть ли шансы у с++ макаки перекатиться в хаскель?
Не надо с++ макаке перекатываться в Хаскель. Хаскель никак не отменяет сепепе, сепепе - это низкоуровневый язык, почти такой же, как се, может быть в чём-то удобнее, но задачи решает почти те же. Поэтому сепепе-макака должна не перекатываться в Хаскель, а осваивать Хаскель в дополнение к сепепе. Ну вот глянь для примера на хаскелевские хешь-табилцы: https://github.com/gregorycollins/hashtables Ой, что там у нас, 88.8% кода на Хаскелле, а 10.6% - на се. И что там у нас на се? Ой, SSE4 для вычисления хешей и линейного поиска. Ну т.е. может ли в природе существовать абстрактная хаскель-макака, которая кроме Хаскеля ни на чем не программирует? Нет, не может, любая реальная хаскель-макака - это макака, которая знает Хаскель, но так же в любой момент не стремается написать немного кода на се. В конце концов хаскель-кабал прямо из коробки сешный код компилирует, что намекает, и даже в чистом Хаскеле не считается каким-то моветоном использовать сишный препроцессор. Поэтому тут нет никакого "перекатиться", что-то тебе после освоения Хаскеля тебе уже не захочется писать на сепепе и ты будешь делать это чисто на Хаскеле. А что-то ты так и будешь писать на сепепе или вообще на чистом се.
>>651924
Чет мне этот пост напомнил какую-то фантастическую книжку. Там люди получили по радио от инопланетян с другой звезды код какой-то программы. Долго ссались ее запускать (мало ли что она там делать будет, вдруг весь инторнет захватит), в итоге запилили специальный компьютер, который был так спроектирован что при наличии любых сайдэффектов тут же плавился нахуй. Не система самоуничтожения у него была (ибо вдруг ее злобная алиенская программа тоже взломает?) а именно сам физический принцип устройства.
>У всех функций в Хаскелле есть сайдэффект - они процессор нагревают
Чет мне этот пост напомнил какую-то фантастическую книжку. Там люди получили по радио от инопланетян с другой звезды код какой-то программы. Долго ссались ее запускать (мало ли что она там делать будет, вдруг весь инторнет захватит), в итоге запилили специальный компьютер, который был так спроектирован что при наличии любых сайдэффектов тут же плавился нахуй. Не система самоуничтожения у него была (ибо вдруг ее злобная алиенская программа тоже взломает?) а именно сам физический принцип устройства.
Ответы>>718097
>>717790
А мне сегодня очередная вакансия по Хаскелю упала в почту. Правда не из России, а из Нидерландов. Ну в Нидерланды мне ехать лень. С другой стороны, в России я работаю скала-программистом. И знаете кто эту вакансию создал? Мой начальник. Т.е. до него в конторе никто на Скале не писал, и Скала была такой же изотерической хуйнёй, как и Хаскель. А потом пришел мой начальник, и сказал, что теперь будет Скала. И написал программы на ней, и начал нанимать программистов. Т.е. чувак захотел, чувак сделал. И теперь там Скала. Ну а вы продолжайте ныть, что мол на Хаскелле нет вакансий. Да, для вас их нет, вакансии не появляются, их делают. Пока ты не сам способен создавать вакансии, учи, что от тебя большие дядки требуют и не выёбывайся с Хаскелем или там чем-то еще, знай своё место, студент)
> её просто нет
А мне сегодня очередная вакансия по Хаскелю упала в почту. Правда не из России, а из Нидерландов. Ну в Нидерланды мне ехать лень. С другой стороны, в России я работаю скала-программистом. И знаете кто эту вакансию создал? Мой начальник. Т.е. до него в конторе никто на Скале не писал, и Скала была такой же изотерической хуйнёй, как и Хаскель. А потом пришел мой начальник, и сказал, что теперь будет Скала. И написал программы на ней, и начал нанимать программистов. Т.е. чувак захотел, чувак сделал. И теперь там Скала. Ну а вы продолжайте ныть, что мол на Хаскелле нет вакансий. Да, для вас их нет, вакансии не появляются, их делают. Пока ты не сам способен создавать вакансии, учи, что от тебя большие дядки требуют и не выёбывайся с Хаскелем или там чем-то еще, знай своё место, студент)
>>718082
Я бы почитал твою книжку. Но на самом деле в своём посте я сделал акцент на "наблюдаемый" эффект как раз потому, что у любой программы сайдэффект есть. Ну чисто физически. А "наблюдаемый" означает именно то, что програма способна наблюсти свой эффект и её результат может зависеть от этого наблюдения. Ну т.е. в Хаскелле предложили афинно-центральные преобразования https://wiki.haskell.org/Top_level_mutable_state Вполне себе сайдэффекты, но такие, что результат работы программы от них не зависит.
Я бы почитал твою книжку. Но на самом деле в своём посте я сделал акцент на "наблюдаемый" эффект как раз потому, что у любой программы сайдэффект есть. Ну чисто физически. А "наблюдаемый" означает именно то, что програма способна наблюсти свой эффект и её результат может зависеть от этого наблюдения. Ну т.е. в Хаскелле предложили афинно-центральные преобразования https://wiki.haskell.org/Top_level_mutable_state Вполне себе сайдэффекты, но такие, что результат работы программы от них не зависит.
>>718084
Перестал дрочить на языки после 5 лет опыта. Предметная область и решаемые задачи - вот что гораздо интереснее.
Перестал дрочить на языки после 5 лет опыта. Предметная область и решаемые задачи - вот что гораздо интереснее.
Ответы>>720024
>>720021
Ну дык мне еще на жизнь надо было зарабатывать, семью кормить.
Хелловордами на мамкиных борщах далеко не уедешь, лол.
Ну дык мне еще на жизнь надо было зарабатывать, семью кормить.
Хелловордами на мамкиных борщах далеко не уедешь, лол.
>>718084
Сравнил скалку, под которую всё давно есть и борщегонный аппарат. Это надо быть либо очень богатым, либо безрассудным - чтобы вдруг переходить на непроверенные никем инструменты и проверять в бою.
Сравнил скалку, под которую всё давно есть и борщегонный аппарат. Это надо быть либо очень богатым, либо безрассудным - чтобы вдруг переходить на непроверенные никем инструменты и проверять в бою.
>>720658
Можно примеры того, что есть под скалу, и нет под хачкиль, и при этом сильно нужно? Мне правда интересно, я не троль
>под которую всё давно есть
Можно примеры того, что есть под скалу, и нет под хачкиль, и при этом сильно нужно? Мне правда интересно, я не троль
>>720006
Я давно не дрочу на языки, но просто когда надо какой-нибудь machine learning закодить на чем-то, отличном от Хаскеля, это как в говне обволяться. Нет, я это прекрасно делаю, в том-то и отличие нормального программиста от студента, что нормальный программист любую задачу решит на любой технологической платформе. И пока студенты кукарекают "ко-ко-ко надо всё переписать!!1" я просто вижу, что действительно надо бизнесу и делаю это, и бизнес доволен, ведь ему похуй, что внутри, ему надо чтобы было быстро, дешево и удобно. Но чисто для себя, а не для бизнеса, обмазываясь каким-нибудь говном, вроде скалы или сепепе, я думаю, "Господи, ну до чего же это всё убого".
>>720658
Охенно под неё всё есть, недавно резали на модули скалаговнокод, потому что баг в компиляторе. Ну да, порезали, баг обошли, заработало. Но ты какой-то дебил, если сравниваешь эти два инструмента. Тот уровень качества, который в Хаскелле является абсолютно неприемлемым, то, что Хаскель-сообщество вообще никогда под никаким предлогом не выпустит, потому что сделано хуёво, в мирке Скала считается нормальным.
Скалу и Хаскель сравнивать по качеству исполнения, это, блядь, я даже не знаю, это либо троллинг, либо троллинг, других вариантов нет.
Я давно не дрочу на языки, но просто когда надо какой-нибудь machine learning закодить на чем-то, отличном от Хаскеля, это как в говне обволяться. Нет, я это прекрасно делаю, в том-то и отличие нормального программиста от студента, что нормальный программист любую задачу решит на любой технологической платформе. И пока студенты кукарекают "ко-ко-ко надо всё переписать!!1" я просто вижу, что действительно надо бизнесу и делаю это, и бизнес доволен, ведь ему похуй, что внутри, ему надо чтобы было быстро, дешево и удобно. Но чисто для себя, а не для бизнеса, обмазываясь каким-нибудь говном, вроде скалы или сепепе, я думаю, "Господи, ну до чего же это всё убого".
>>720658
Охенно под неё всё есть, недавно резали на модули скалаговнокод, потому что баг в компиляторе. Ну да, порезали, баг обошли, заработало. Но ты какой-то дебил, если сравниваешь эти два инструмента. Тот уровень качества, который в Хаскелле является абсолютно неприемлемым, то, что Хаскель-сообщество вообще никогда под никаким предлогом не выпустит, потому что сделано хуёво, в мирке Скала считается нормальным.
Скалу и Хаскель сравнивать по качеству исполнения, это, блядь, я даже не знаю, это либо троллинг, либо троллинг, других вариантов нет.
>>721480
Охуеть проблема. Если ты ни разу не натыкался на баги в компиляторах других языков то ты какой-то хуевый программист с маленьким опытом.
>потому что баг в компиляторе
Охуеть проблема. Если ты ни разу не натыкался на баги в компиляторах других языков то ты какой-то хуевый программист с маленьким опытом.
Ответы>>721610
>>721480
На хаскеле есть machine learning? Ломающие новости.
Ой да не пизди. Тонны багов, просто они реже встречаются, потому что на хаскеле, внезапно, никто не пишет.
> machine learning закодить на чем-то, отличном от Хаскеля
На хаскеле есть machine learning? Ломающие новости.
>Тот уровень качества, который в Хаскелле является абсолютно неприемлемым, то, что Хаскель-сообщество вообще никогда под никаким предлогом не выпустит, потому что сделано хуёво, в мирке Скала считается нормальным.
Ой да не пизди. Тонны багов, просто они реже встречаются, потому что на хаскеле, внезапно, никто не пишет.
Ответы>>721610
О чем тред, аноны? Нихуя не понимаю! ФП-СРАЧ-ТРЕД?
>>721500
В нормальных языках компилятор тестируют перед выпуском. Если скалу и другое говно выпускают в таком виде, так это только указывает на качество этого говна.
>>721537
Потому что их количество ничтожно мало по сравнению со Скалой. И большинство - даже не баги, а небольшие регрессии.
В нормальных языках компилятор тестируют перед выпуском. Если скалу и другое говно выпускают в таком виде, так это только указывает на качество этого говна.
>>721537
>Тонны багов, просто они реже встречаются
Потому что их количество ничтожно мало по сравнению со Скалой. И большинство - даже не баги, а небольшие регрессии.
Ответы>>721619
>>721560
Х.з. я с ними не связывался. Не ехать же в Нидерланды.
Х.з. я с ними не связывался. Не ехать же в Нидерланды.
>>721610
Мало кода -> мало багов. Это то самое there are only two kinds of languages: the ones people complain about and the ones nobody uses.
Лично я находил баги в каждой библиотеке которую юзал. При том, что на других языках это редкость.
>отому что их количество ничтожно мало по сравнению со Скалой.
Мало кода -> мало багов. Это то самое there are only two kinds of languages: the ones people complain about and the ones nobody uses.
Лично я находил баги в каждой библиотеке которую юзал. При том, что на других языках это редкость.
Ответы>>723106
>>721619
Это не совсем правильно. Лучше так: меньше мест, подверженных ошибкам -> меньше ошибок.
Насколько помнится, лицокнига использует систему фильтров сообщений на хаскеле и плюсах, и за время работы всплыло только несколько багов.
Вот пруфец https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/
По-моему, это действительно говорит о качестве. В конце-концов, GHC пишут люди, неспешно осваивающие гранты на GHC, а не макаки, трясущиеся за подачку от работодателя.
>Мало кода -> мало багов.
Это не совсем правильно. Лучше так: меньше мест, подверженных ошибкам -> меньше ошибок.
Насколько помнится, лицокнига использует систему фильтров сообщений на хаскеле и плюсах, и за время работы всплыло только несколько багов.
Вот пруфец https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/
По-моему, это действительно говорит о качестве. В конце-концов, GHC пишут люди, неспешно осваивающие гранты на GHC, а не макаки, трясущиеся за подачку от работодателя.
>>649725 (OP)
Эй, профессионалы, а шо там с производительностью GHC, фиксят или всем похуй? Наталкивался как-то на тред на реддите
Эй, профессионалы, а шо там с производительностью GHC, фиксят или всем похуй? Наталкивался как-то на тред на реддите
Ответы>>735491
>>723106
Ради справедливости замечу, что это нихуя не показатель качества. Ученые на гранты могут годами вариться в собственном соку, высирая абсолютно ненужное и неюзабельное говно. Главное чтобы отчеты были в порядке и заявки на новые гранты вовремя подавались, ну и тема была актуальная.
Наблюдал это на примере Мейера и его Eiffel
>В конце-концов, GHC пишут люди, неспешно осваивающие гранты на GHC, а не макаки, трясущиеся за подачку от работодателя.
Ради справедливости замечу, что это нихуя не показатель качества. Ученые на гранты могут годами вариться в собственном соку, высирая абсолютно ненужное и неюзабельное говно. Главное чтобы отчеты были в порядке и заявки на новые гранты вовремя подавались, ну и тема была актуальная.
Наблюдал это на примере Мейера и его Eiffel
Шапка №103
Очередной тред про самый лучший язык для JVM.
Лучшая книга по Скале: http://www.ozon.ru/context/detail/id/31921731/
Учебник по Скале на русском: http://twitter.github.io/scala_school/ru/index.html
Второй учебник по Скале на русском: http://twitter.github.io/effectivescala/index-ru.html
Курс по fp на Скале для слоупоков: https://www.coursera.org/course/progfun
Список годноты: https://github.com/lauris/awesome-scala
Презентации летнего ScalaDays: https://www.parleys.com/channel/53a7d269e4b0543940d9e535/presentations?sort=views&state=public
Два недавних форка компилятора, один от тайплевела и второй от баттхертнутого:
https://github.com/typelevel/scala (https://github.com/typelevel/scala/wiki/Differences)
https://github.com/paulp/policy
Завтра ищешь в интернете книжку Programming in Scala. Похуй если ничего не поймешь. Затем идешь на scala-lang.org и изучаешь стандартную библиотеку от корки до корки. Потом зубришь, именно, сука, вызубриваешь конвенцию по написанию скала кода - от EPFL естественно, чтобы от зубов отскакивало. Когда напишешь свой первый клон Twittera, по пути изучив основы дискретного и лямбда исчисления, скачиваешь и изучаешь любой асинхронный скала вебсервер, рекомендую Play!. Как переделаешь твиттер клон, чтобы выдавал по крайней мере 5 тысяч запросов в секунду, можешь идти дальше - тебя ждет увлекательный мир хайлоада. Apache Hadoop и Spark, сверхбыстрые асинхронные key-value хранилища, NoSQL и прочие мира открытого исходного кода приблуды. Отсос хиккующих питонистов / просто неудачников типа годаунов или рубифанбоев, сосут по жизни, не заставит себя ждать и уже через пол года ты будешь подворачивать штаны, есть маффины, запивая смузи и любая баба будет течь от упоминания твоей зарплаты.
Очередной тред про самый лучший язык для JVM.
Лучшая книга по Скале: http://www.ozon.ru/context/detail/id/31921731/
Учебник по Скале на русском: http://twitter.github.io/scala_school/ru/index.html
Второй учебник по Скале на русском: http://twitter.github.io/effectivescala/index-ru.html
Курс по fp на Скале для слоупоков: https://www.coursera.org/course/progfun
Список годноты: https://github.com/lauris/awesome-scala
Презентации летнего ScalaDays: https://www.parleys.com/channel/53a7d269e4b0543940d9e535/presentations?sort=views&state=public
Два недавних форка компилятора, один от тайплевела и второй от баттхертнутого:
https://github.com/typelevel/scala (https://github.com/typelevel/scala/wiki/Differences)
https://github.com/paulp/policy
Завтра ищешь в интернете книжку Programming in Scala. Похуй если ничего не поймешь. Затем идешь на scala-lang.org и изучаешь стандартную библиотеку от корки до корки. Потом зубришь, именно, сука, вызубриваешь конвенцию по написанию скала кода - от EPFL естественно, чтобы от зубов отскакивало. Когда напишешь свой первый клон Twittera, по пути изучив основы дискретного и лямбда исчисления, скачиваешь и изучаешь любой асинхронный скала вебсервер, рекомендую Play!. Как переделаешь твиттер клон, чтобы выдавал по крайней мере 5 тысяч запросов в секунду, можешь идти дальше - тебя ждет увлекательный мир хайлоада. Apache Hadoop и Spark, сверхбыстрые асинхронные key-value хранилища, NoSQL и прочие мира открытого исходного кода приблуды. Отсос хиккующих питонистов / просто неудачников типа годаунов или рубифанбоев, сосут по жизни, не заставит себя ждать и уже через пол года ты будешь подворачивать штаны, есть маффины, запивая смузи и любая баба будет течь от упоминания твоей зарплаты.
>>723106
А скалу по-твоему кто пишет, пионер?
>В конце-концов, GHC пишут люди, неспешно осваивающие гранты на GHC
А скалу по-твоему кто пишет, пионер?
>>660429
ContT
ContT
>>659554
Так нормальный или императивный? Ты уж определись.
Так нормальный или императивный? Ты уж определись.
>>659554
Мультипарадигма разная бывает. Вон в общелиспе хошь в гоуту ебись, а хошь и пандорические захваты делай.
Мультипарадигма разная бывает. Вон в общелиспе хошь в гоуту ебись, а хошь и пандорические захваты делай.
Good news, everyone! В кабал добавили Nix-like local builds:
http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/
Попробовать можно хоть сейчас, поставив свежий кабал с hackage.
http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/
Попробовать можно хоть сейчас, поставив свежий кабал с hackage.
Ответы>>735498
>>728592
Фиксят, деградация производительности GHC считается багом. Чего не скажешь про Скалу, там время компиляции уходит в небеса, но всем похуй, лишь бы свистоперделок навернуть.
Фиксят, деградация производительности GHC считается багом. Чего не скажешь про Скалу, там время компиляции уходит в небеса, но всем похуй, лишь бы свистоперделок навернуть.
>>734894
Какие задачи решает? Собираю Stack-ом, зависимость есть, брат жив, самостоятельный деплой GHC у меня скорее по историческим причинам и потому что плагины для Атома его юзали. Раньше. Теперь вроде им тоже Stack-а достаточно. Поэтому планирую вообще снести свой GHC, и оставить только Stack. Вот нафиг мне думать, какой GHC установить, что там за кабалинсталить, если Stack всё это делает одной командой и это просто работает?
Какие задачи решает? Собираю Stack-ом, зависимость есть, брат жив, самостоятельный деплой GHC у меня скорее по историческим причинам и потому что плагины для Атома его юзали. Раньше. Теперь вроде им тоже Stack-а достаточно. Поэтому планирую вообще снести свой GHC, и оставить только Stack. Вот нафиг мне думать, какой GHC установить, что там за кабалинсталить, если Stack всё это делает одной командой и это просто работает?
Ответы>>738733
>>735498
Глобально запоминает зависимости при сборке, так что если тебе еще раз надо собрать что-то, требующее либа-14.88, она не будет второй раз компилироваться IIRC
>Какие задачи решает?
Глобально запоминает зависимости при сборке, так что если тебе еще раз надо собрать что-то, требующее либа-14.88, она не будет второй раз компилироваться IIRC
Ответы>>740956
>>738733
Если ты про reproducible build, то Стек именно это и делает.
Это вообще ортогонально, и было решено в самом всратом алголе мохнатого года. Я вообще затрудняюсь назвать язык, который будет перекомпилировать модуль, если он уже скомпелирован, ну кроме С++ конечно же. Но С++ - не язык, а Лисп с типами.
>Глобально запоминает зависимости при сборке
Если ты про reproducible build, то Стек именно это и делает.
>так что если тебе еще раз надо собрать что-то, требующее либа-14.88, она не будет второй раз компилироваться
Это вообще ортогонально, и было решено в самом всратом алголе мохнатого года. Я вообще затрудняюсь назвать язык, который будет перекомпилировать модуль, если он уже скомпелирован, ну кроме С++ конечно же. Но С++ - не язык, а Лисп с типами.
Ответы>>741483
Недавно пришлось перечитать кучу статей про монады, чтобы подобрать нормальную схему типизации для своей проги, нашел несколько вещей, которые не очень широко известны, но довольно занимательны:
1. Оказывается параметризованные монады Atkey полностью эквивалентны индексированным монадам McBride. Есть доказательство, что одни выражаются через другие: https://www.eyrie.org/~zednenem/2012/07/29/paramonads. Это не очень распространённое знание, даже бородатые хаскеллисты до сих пор думают, что монадки McBride более гибкие, но это не так, они совершенно одинаковые. Далее, в статье утверждается, что параметризованные монады вообще не нужны, потому что нет генерализованных алгоритмов над ними. И я с этим согласен, они действительно не добавляют ничего нового. Но добавляют весьма приятный сахарок, в том плане, что все хаскеллиты привыкли к монадическому синтаксису и в любой непонятной ситуации хуярят монаду на автомате. И если нужно как-то упорядочить вызовы функций, то почему бы не использовать параметрическую монаду и привычный синтаксис чисто ради однообразия, пусть даже она не нужна, строго говоря?
2. Оказывается есть аналог mtl: http://okmij.org/ftp/Haskell/extensible/ Без лифтинга. Впрочем, другой аналог mtl без лифтинга можно хуярить на индексированных монадах: http://www.muddsnyder.com/pubs/monadfactory.pdf, но он не отменяет проблем производительности mtl. В целом можно так классифицировать эти два подхода: оба решают проблему квадратичного роста инстансов. Как mlt, так и вторая либа приводит к тому, что продятся вложенные замыкания на монадических bind-ах, зато любой вызов non-proper морфизма происходит напрямую. А первая либа гарантирует, что будет только одно замыкание, но вызов non-proper морфизмов реализуется через паттерн chain-of-responsibility, также она полиморфна по порядку монадок в стеке (т.е. ту монадку, к которой обращяются чаще, можно расположить ближе, в итоге обращения к ней будут быстрее). Т.е. имеет смысл выбирать тот или иной паттерн в зависимости от того, как ваша либа используется, это может оказать заметное влияние на производительность.
1. Оказывается параметризованные монады Atkey полностью эквивалентны индексированным монадам McBride. Есть доказательство, что одни выражаются через другие: https://www.eyrie.org/~zednenem/2012/07/29/paramonads. Это не очень распространённое знание, даже бородатые хаскеллисты до сих пор думают, что монадки McBride более гибкие, но это не так, они совершенно одинаковые. Далее, в статье утверждается, что параметризованные монады вообще не нужны, потому что нет генерализованных алгоритмов над ними. И я с этим согласен, они действительно не добавляют ничего нового. Но добавляют весьма приятный сахарок, в том плане, что все хаскеллиты привыкли к монадическому синтаксису и в любой непонятной ситуации хуярят монаду на автомате. И если нужно как-то упорядочить вызовы функций, то почему бы не использовать параметрическую монаду и привычный синтаксис чисто ради однообразия, пусть даже она не нужна, строго говоря?
2. Оказывается есть аналог mtl: http://okmij.org/ftp/Haskell/extensible/ Без лифтинга. Впрочем, другой аналог mtl без лифтинга можно хуярить на индексированных монадах: http://www.muddsnyder.com/pubs/monadfactory.pdf, но он не отменяет проблем производительности mtl. В целом можно так классифицировать эти два подхода: оба решают проблему квадратичного роста инстансов. Как mlt, так и вторая либа приводит к тому, что продятся вложенные замыкания на монадических bind-ах, зато любой вызов non-proper морфизма происходит напрямую. А первая либа гарантирует, что будет только одно замыкание, но вызов non-proper морфизмов реализуется через паттерн chain-of-responsibility, также она полиморфна по порядку монадок в стеке (т.е. ту монадку, к которой обращяются чаще, можно расположить ближе, в итоге обращения к ней будут быстрее). Т.е. имеет смысл выбирать тот или иной паттерн в зависимости от того, как ваша либа используется, это может оказать заметное влияние на производительность.
Недавно пришлось перечитать кучу статей про монады, чтобы подобрать нормальную схему типизации для своей проги, нашел несколько вещей, которые не очень широко известны, но довольно занимательны:
1. Оказывается параметризованные монады Atkey полностью эквивалентны индексированным монадам McBride. Есть доказательство, что одни выражаются через другие: https://www.eyrie.org/~zednenem/2012/07/29/paramonads. Это не очень распространённое знание, даже бородатые хаскеллисты до сих пор думают, что монадки McBride более гибкие, но это не так, они совершенно одинаковые. Далее, в статье утверждается, что параметризованные монады вообще не нужны, потому что нет генерализованных алгоритмов над ними. И я с этим согласен, они действительно не добавляют ничего нового. Но добавляют весьма приятный сахарок, в том плане, что все хаскеллиты привыкли к монадическому синтаксису и в любой непонятной ситуации хуярят монаду на автомате. И если нужно как-то упорядочить вызовы функций, то почему бы не использовать параметрическую монаду и привычный синтаксис чисто ради однообразия, пусть даже она не нужна, строго говоря?
2. Оказывается есть аналог mtl: http://okmij.org/ftp/Haskell/extensible/ Без лифтинга. Впрочем, другой аналог mtl без лифтинга можно хуярить на индексированных монадах: http://www.muddsnyder.com/pubs/monadfactory.pdf, но он не отменяет проблем производительности mtl. В целом можно так классифицировать эти два подхода: оба решают проблему квадратичного роста инстансов. Как mlt, так и вторая либа приводит к тому, что продятся вложенные замыкания на монадических bind-ах, зато любой вызов non-proper морфизма происходит напрямую. А первая либа гарантирует, что будет только одно замыкание, но вызов non-proper морфизмов реализуется через паттерн chain-of-responsibility, также она полиморфна по порядку монадок в стеке (т.е. ту монадку, к которой обращяются чаще, можно расположить ближе, в итоге обращения к ней будут быстрее). Т.е. имеет смысл выбирать тот или иной паттерн в зависимости от того, как ваша либа используется, это может оказать заметное влияние на производительность.
1. Оказывается параметризованные монады Atkey полностью эквивалентны индексированным монадам McBride. Есть доказательство, что одни выражаются через другие: https://www.eyrie.org/~zednenem/2012/07/29/paramonads. Это не очень распространённое знание, даже бородатые хаскеллисты до сих пор думают, что монадки McBride более гибкие, но это не так, они совершенно одинаковые. Далее, в статье утверждается, что параметризованные монады вообще не нужны, потому что нет генерализованных алгоритмов над ними. И я с этим согласен, они действительно не добавляют ничего нового. Но добавляют весьма приятный сахарок, в том плане, что все хаскеллиты привыкли к монадическому синтаксису и в любой непонятной ситуации хуярят монаду на автомате. И если нужно как-то упорядочить вызовы функций, то почему бы не использовать параметрическую монаду и привычный синтаксис чисто ради однообразия, пусть даже она не нужна, строго говоря?
2. Оказывается есть аналог mtl: http://okmij.org/ftp/Haskell/extensible/ Без лифтинга. Впрочем, другой аналог mtl без лифтинга можно хуярить на индексированных монадах: http://www.muddsnyder.com/pubs/monadfactory.pdf, но он не отменяет проблем производительности mtl. В целом можно так классифицировать эти два подхода: оба решают проблему квадратичного роста инстансов. Как mlt, так и вторая либа приводит к тому, что продятся вложенные замыкания на монадических bind-ах, зато любой вызов non-proper морфизма происходит напрямую. А первая либа гарантирует, что будет только одно замыкание, но вызов non-proper морфизмов реализуется через паттерн chain-of-responsibility, также она полиморфна по порядку монадок в стеке (т.е. ту монадку, к которой обращяются чаще, можно расположить ближе, в итоге обращения к ней будут быстрее). Т.е. имеет смысл выбирать тот или иной паттерн в зависимости от того, как ваша либа используется, это может оказать заметное влияние на производительность.
>>741023
А теперь быстро объяснил мне, почему все то же самое нельзя сделать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C#.
А теперь быстро объяснил мне, почему все то же самое нельзя сделать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C#.
>>742175
Я должен здесь увидеть какую - то тонкую аналогию? Типа её здесь и нет вовсе. Если ты это не понимаешь, то никакие моноиды в эндоморфизмах тебе не помогут. (Подсказка: высокоуровневые и низкоуровневые языки программирования).
Анончик задал грамотный вопрос, а ты со свистом сливаешь.
Я должен здесь увидеть какую - то тонкую аналогию? Типа её здесь и нет вовсе. Если ты это не понимаешь, то никакие моноиды в эндоморфизмах тебе не помогут. (Подсказка: высокоуровневые и низкоуровневые языки программирования).
Анончик задал грамотный вопрос, а ты со свистом сливаешь.
Ответы>>742235
>>742175
Жаль, что этот хаскелист порвался так быстро, а как же напомнить, что, если программа на Haskell скомпилировалась, то она в 95% случаев работает так, как ожидается?
>>А теперь быстро обьяснил мне почему всё это нельзя реализовать средствами ассемблера
Жаль, что этот хаскелист порвался так быстро, а как же напомнить, что, если программа на Haskell скомпилировалась, то она в 95% случаев работает так, как ожидается?
Ответы>>742235
>>742181
>>742191
Не семени.
Что "то же самое"? Параметризованные монады Atkey, которые полностью эквивалентны индексированным монадам McBride?
Это как если бы анон#1 рассказывал про интерфейсы и абстрактные классы, а анон#2 спрашивал, почему то же самое нельзя. сделать средствами структурного программирования. Очень грамотный вопрос.
>>742191
Не семени.
>Всё то же самое
Что "то же самое"? Параметризованные монады Atkey, которые полностью эквивалентны индексированным монадам McBride?
Это как если бы анон#1 рассказывал про интерфейсы и абстрактные классы, а анон#2 спрашивал, почему то же самое нельзя. сделать средствами структурного программирования. Очень грамотный вопрос.
>>742235
А самое смешное в твоей аналогии - это можно сделать средствами структурного программирования, и выйдет лучше, чем с ооп.
А самое смешное в твоей аналогии - это можно сделать средствами структурного программирования, и выйдет лучше, чем с ооп.
>>742241
Что это, блджад?! Меня бесит твоя тупость
Что это, блджад?! Меня бесит твоя тупость
>>742250
>>742235
Это нам известно. Они вообще едва ли есть в промышленных языках. Поконкретнее можно?
Без кококо махания руками и туманных аналогий, пожалуйста.
>>742235
Это нам известно. Они вообще едва ли есть в промышленных языках. Поконкретнее можно?
>почему все то же самое нельзя сделать с помощью классов, коллекций
Без кококо махания руками и туманных аналогий, пожалуйста.
Ответы>>742344
>>742295
ООП конечно много ругают, может и за дело, но мне все равно кажется интересным, как можно писать действительно большие, огромные программные системы без ООП?
ООП конечно много ругают, может и за дело, но мне все равно кажется интересным, как можно писать действительно большие, огромные программные системы без ООП?
>>742292
>почему все то же самое нельзя сделать с помощью классов, коллекций
>Спрашивает о "том же самом", хотя из контекста вывести что же такое "то же самое" нельзя.
>На это было указано дважды
>Всё равно спрашивает, почему "то же самое" нельзя реализовать какими-то средствами
Ответы>>742374
>>742299
Ты это на полном серьёзе в треде функци-анальщиков спрашиваешь?
Ты это на полном серьёзе в треде функци-анальщиков спрашиваешь?
>>742374
Вдогонку. Только пожалуйста без мутных аналогий, а по существу.
Вдогонку. Только пожалуйста без мутных аналогий, а по существу.
>>742374
Пока что ты петух
То же самое нельзя сделать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C# потому что происходит что-то, а ещё кое-что. Понял, говно? Помахал тебе руками за щеку, проверяй
Пока что ты петух
То же самое нельзя сделать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C# потому что происходит что-то, а ещё кое-что. Понял, говно? Помахал тебе руками за щеку, проверяй
Ответы>>742487
>>742480
Ух-ты! Аргументация достойная лучших тредов /b! Как и ожидалось - ты никчемная макака нацепившая очки, толком не разбирающаяся в предмете. Чего я не ожидал, так это насколько звонко ты порвешься. Это все адепты такие, или ты один попался, необычайно вонючий?
Ух-ты! Аргументация достойная лучших тредов /b! Как и ожидалось - ты никчемная макака нацепившая очки, толком не разбирающаяся в предмете. Чего я не ожидал, так это насколько звонко ты порвешься. Это все адепты такие, или ты один попался, необычайно вонючий?
Ответы>>742501
>>742487
Ладно. Ты побдил, няша, то же самоечто бы это ни значило удобнее и лучше реализовывать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C#. Теперь иди к своим друзям в крестотред и расскажи о своей решительной победе над тупыми хаскель-задротами
>>742492
Конечно. Можно удалить все комментарии например
Ладно. Ты побдил, няша, то же самоечто бы это ни значило удобнее и лучше реализовывать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C#. Теперь иди к своим друзям в крестотред и расскажи о своей решительной победе над тупыми хаскель-задротами
>>742492
Конечно. Можно удалить все комментарии например
Ответы>>742503
Почему хаскелисты рвутся так быстро?
Ответы>>742508
>>742504
Очевидно, что это не настоящий хаскеллист. Умный и опытный товарищ сам бы понял и объяснить смог. Нес бы просвещение, так сказать. А это клоун подражатель какой-то.
Очевидно, что это не настоящий хаскеллист. Умный и опытный товарищ сам бы понял и объяснить смог. Нес бы просвещение, так сказать. А это клоун подражатель какой-то.
>>741898
В хаскеле все дружно решают выдуманную ими самими проблему - жизни при изоляции IO. В Java и C# таких проблем просто не возникает, так же, как не возникает проблем со сборкой мусора, к примеру - потому что есть сборщик. Поэтому и задач у монад почти нет, не говоря уже о том, чтобы их параметризировать.
В хаскеле все дружно решают выдуманную ими самими проблему - жизни при изоляции IO. В Java и C# таких проблем просто не возникает, так же, как не возникает проблем со сборкой мусора, к примеру - потому что есть сборщик. Поэтому и задач у монад почти нет, не говоря уже о том, чтобы их параметризировать.
>>742503
Но ООП это ведь не про экономию строк, а скорее, про организацию и сокрытие реализации подсистем. И всё это выливается в большее количество строк: обьявления классов, интерфейсов, конструкторов, и прочего. HelloWorld на Сях будет раза в три меньше чем на Джаве
>>742545
Ваше мнение очень важно для нас. Держите нас вкурсе.
Но ООП это ведь не про экономию строк, а скорее, про организацию и сокрытие реализации подсистем. И всё это выливается в большее количество строк: обьявления классов, интерфейсов, конструкторов, и прочего. HelloWorld на Сях будет раза в три меньше чем на Джаве
>>742545
Ваше мнение очень важно для нас. Держите нас вкурсе.
Ответы>>742731
>>742717
Попробуй заценить такой язык, как Kotlin, это типа Java XXI века, только пока она компилится под JDK 1.6, ну это вопрос времени. Там нет мудянки с бойлерплейтом, как в классической джаве (где надо руками прописывать все геттеры и сеттеры, ну не совсем руками, но суть такая). В Kotlin классы для сущностей (data class) объявляются одной строкой и к ним генерятся все необходимые стандартные методы (геттеры, сеттеры).
И строк в таком коде процентов на 30 мекньше, чем на джаве. Да, возможно, в хаскельном коде строк меньше, но мне лично морально тяжело читать кашу из кучи стрелок и букв a, b, f, t (при чем в двух подряд идущих строках они могут значить разное).
Все говорят, мол, монады, функторы, шмункторы, но на самом деле в Хаскеле сложна общая эзотеричность кода, а не какая-то кастрированная ТК.
Попробуй заценить такой язык, как Kotlin, это типа Java XXI века, только пока она компилится под JDK 1.6, ну это вопрос времени. Там нет мудянки с бойлерплейтом, как в классической джаве (где надо руками прописывать все геттеры и сеттеры, ну не совсем руками, но суть такая). В Kotlin классы для сущностей (data class) объявляются одной строкой и к ним генерятся все необходимые стандартные методы (геттеры, сеттеры).
И строк в таком коде процентов на 30 мекньше, чем на джаве. Да, возможно, в хаскельном коде строк меньше, но мне лично морально тяжело читать кашу из кучи стрелок и букв a, b, f, t (при чем в двух подряд идущих строках они могут значить разное).
Все говорят, мол, монады, функторы, шмункторы, но на самом деле в Хаскеле сложна общая эзотеричность кода, а не какая-то кастрированная ТК.
Ответы>>742854
>>742731
Зачем нужна ещё одна скала?
С какой стороны посмотреть. Если бы ты знал как больно после хачкеля писать на языке без автоматического вывода типов.
> Java XXI века
Зачем нужна ещё одна скала?
> Хаскеле сложна
С какой стороны посмотреть. Если бы ты знал как больно после хачкеля писать на языке без автоматического вывода типов.
>>742854
Прикинь, знаю. А если бы ты писал промышленные системы, а не приложения уровня лаб и хелловорлд, то знал бы что существенными становятся другие факторы разработки. И что х3 -x10 выигрыш в числе строк для 100LOC приложения становится выигрышом x2-x5 для 1KLOC или x1.5-x2 для 10KLOC (примерные числа отражающие тренд). Выводы сам способен сделать?
Мощь функционального программирования не в числе строк программы, а в доказательствах которые выполняет компилятор.
Прикинь, знаю. А если бы ты писал промышленные системы, а не приложения уровня лаб и хелловорлд, то знал бы что существенными становятся другие факторы разработки. И что х3 -x10 выигрыш в числе строк для 100LOC приложения становится выигрышом x2-x5 для 1KLOC или x1.5-x2 для 10KLOC (примерные числа отражающие тренд). Выводы сам способен сделать?
Мощь функционального программирования не в числе строк программы, а в доказательствах которые выполняет компилятор.
Ответы>>743157
>>742854
Затем, что в Kotlin на несколько порядков меньше ФП-дерьма.
Ну он сейчас есть везде, кроме Джавы (да и там в лямбдах есть).
>Зачем нужна ещё одна скала?
Затем, что в Kotlin на несколько порядков меньше ФП-дерьма.
> С какой стороны посмотреть. Если бы ты знал как больно после хачкеля писать на языке без автоматического вывода типов.
Ну он сейчас есть везде, кроме Джавы (да и там в лямбдах есть).
>>743034
То есть на несколько порядков больше императивного дерьма, так что твоя недоджява-недоскала не нужна.
Даже в скале нет такого как в хачкеле, для рекурсивных функций не выводится например.
> >Зачем нужна ещё одна скала?
> Затем, что в Kotlin на несколько порядков меньше ФП-дерьма.
То есть на несколько порядков больше императивного дерьма, так что твоя недоджява-недоскала не нужна.
> Ну он сейчас есть везде, кроме Джавы (да и там в лямбдах есть).
Даже в скале нет такого как в хачкеле, для рекурсивных функций не выводится например.
Ответы>>743193
>>743034
В жабе кстати тоже планируют запилить локальный вывод. И если быть корректным - он уже есть (в пределах вывода дженериков и лямбд).
В жабе кстати тоже планируют запилить локальный вывод. И если быть корректным - он уже есть (в пределах вывода дженериков и лямбд).
Так кто - то может объяснить почему описанное этим >>741023
Последний анончик сначала порвался, а потом обратив все в интернет-олимпиаду начал маняврировать.
Есть адекваты ИТТ?
>нельзя сделать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C#.
Последний анончик сначала порвался, а потом обратив все в интернет-олимпиаду начал маняврировать.
Есть адекваты ИТТ?
Ответы>>743154
>>743075
Ты можешь обьяснить что именно ты хочешь сделать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C#, зелень ебливая? Параметрезированные монады? В джваве и сишаре нету монад, так что параметризированные сделать точно не получится.
>описанное этим
Ты можешь обьяснить что именно ты хочешь сделать с помощью классов, коллекций (и, возможно, еще каких-то стандартных средств языка) в Java или C#, зелень ебливая? Параметрезированные монады? В джваве и сишаре нету монад, так что параметризированные сделать точно не получится.
Ответы>>743186
>>742975
Пишу приложения уровня лаб и хелловорлд. Тем не менее, то, что существенными становятся другие факторы разработки для меня очевидно.
Мощь статической, сильной и выразительной системы типов, ты хотел сказать?
Пишу приложения уровня лаб и хелловорлд. Тем не менее, то, что существенными становятся другие факторы разработки для меня очевидно.
>Мощь функционального программирования
Мощь статической, сильной и выразительной системы типов, ты хотел сказать?
>>743154
Меня интересует решение проблем. В смысле - какие проблемы решают эти монады которым даже имя дали. К примеру, я представляю для чего нужна Maybe или State. И какой аналог могу / не могу сконструировать вне хаскелла.
Твое дрочево монад ради монад или ЧСВ мне не особо интересно.
Про лямбда-куб слышал? Вот оказывается что наиболее продвинутые системы типов в функциональных языках и развиты.
Меня интересует решение проблем. В смысле - какие проблемы решают эти монады которым даже имя дали. К примеру, я представляю для чего нужна Maybe или State. И какой аналог могу / не могу сконструировать вне хаскелла.
Твое дрочево монад ради монад или ЧСВ мне не особо интересно.
> Мощь статической, сильной и выразительной системы типов
Про лямбда-куб слышал? Вот оказывается что наиболее продвинутые системы типов в функциональных языках и развиты.
>>743044
То есть на несколько порядков меньше эзотеричного write-only bullshit'а.
Мне программы на Scala вообще напоминают гон молодого оленя, если в Хацкеле еще есть какой-то закос под псевдоматематическую строгость, то тут просто разгул, какое-то бесилово.
Да просто это никому не нужно при адекватной системе типов (как в большинстве современных ООП-языков). Лично я считаю, что выведение типов - это возможность писать
Вместо
Ну и чтобы в лямбдах не надо было указывать тип, ну и в функции мог вывестись тип по return. Всякие остальные изъебства нахуй не всрались.
>То есть на несколько порядков больше императивного дерьма, так что твоя недоджява-недоскала не нужна.
То есть на несколько порядков меньше эзотеричного write-only bullshit'а.
Мне программы на Scala вообще напоминают гон молодого оленя, если в Хацкеле еще есть какой-то закос под псевдоматематическую строгость, то тут просто разгул, какое-то бесилово.
> Даже в скале нет такого как в хачкеле, для рекурсивных функций не выводится например.
Да просто это никому не нужно при адекватной системе типов (как в большинстве современных ООП-языков). Лично я считаю, что выведение типов - это возможность писать
> s = "Fuck you"
Вместо
> String s = "Fuck you"
Ну и чтобы в лямбдах не надо было указывать тип, ну и в функции мог вывестись тип по return. Всякие остальные изъебства нахуй не всрались.
Ответы>>743203
>>743186
Монады решают только проблемы, искусственно привнесенные ограничениями ФП (чистота, иммутабельность). Больше они ровным счетом ничего не решают.
Да Maybe/Optional - это полезная штука, позволяющая избегать null pointer exception, но ее можно использовать без этой монадической чертовщины.
>Меня интересует решение проблем. В смысле - какие проблемы решают эти монады которым даже имя дали
Монады решают только проблемы, искусственно привнесенные ограничениями ФП (чистота, иммутабельность). Больше они ровным счетом ничего не решают.
Да Maybe/Optional - это полезная штука, позволяющая избегать null pointer exception, но ее можно использовать без этой монадической чертовщины.
Ответы>>743291
>>743193
Наоборот, больше. Чем код императивнее, тем хуже он читается.
Видимо твое покалеченное сознание просто не осилило нормальный код без говнопаттернов и фабрик бобов.
> То есть на несколько порядков меньше эзотеричного write-only bullshit'а.
Наоборот, больше. Чем код императивнее, тем хуже он читается.
> Мне программы на Scala вообще напоминают гон молодого оленя, если в Хацкеле еще есть какой-то закос под псевдоматематическую строгость, то тут просто разгул, какое-то бесилово.
Видимо твое покалеченное сознание просто не осилило нормальный код без говнопаттернов и фабрик бобов.
Ответы>>743374
>>742545
Скажем так, IO можно сделать через монадки. Да, IO является монадой. Но, скажем, в Джаве File является классом. Говорить, что монады нужны для IO, это всё равно, что говорить, что классы нужны для работы с файлами. Ну еще можно привести в пример паскаль, где классов нет, но можно работать с файлами и заявить, что джависты решают своими классами надуманные проблемы.
Скажем так, IO можно сделать через монадки. Да, IO является монадой. Но, скажем, в Джаве File является классом. Говорить, что монады нужны для IO, это всё равно, что говорить, что классы нужны для работы с файлами. Ну еще можно привести в пример паскаль, где классов нет, но можно работать с файлами и заявить, что джависты решают своими классами надуманные проблемы.
Ответы>>743442
>>743034
Его практически нигде нет. То, что есть в Скале - это убогое говно, которое адово тормозит почти никогда нормально не работает.
>Ну он сейчас есть везде, кроме Джавы (да и там в лямбдах есть).
Его практически нигде нет. То, что есть в Скале - это убогое говно, которое адово тормозит почти никогда нормально не работает.
>>743186
Можешь считать, что это представление hoare logic. Т.е. есть предусловия и постусловия, которые представлены параметрами монады, компилятор проверяет, что у линкуемых действий пред- и постусловия корректны. Ну а аналоги mtl нужны для того, чтобы обеспечить композабельность и расширяемость монадок без ебучего лифтинга.
>какие проблемы решают эти монады
Можешь считать, что это представление hoare logic. Т.е. есть предусловия и постусловия, которые представлены параметрами монады, компилятор проверяет, что у линкуемых действий пред- и постусловия корректны. Ну а аналоги mtl нужны для того, чтобы обеспечить композабельность и расширяемость монадок без ебучего лифтинга.
>>743195
Скажи мне, что вызвало у тебя в голове такое разжижение мозгов, помоги людям которые хотели бы этого избежать
>Монадическая чертовщина
>Для того чтобы тип был монадой, для него должно быть определено две ДВЕ, КАРЛ!операции
Скажи мне, что вызвало у тебя в голове такое разжижение мозгов, помоги людям которые хотели бы этого избежать
Ответы>>743387
>>743203
Нет, это не так.
Типичный императивный код довольно сносно отображает течение процесса, как правило, имена объектов и функций в нем имеют осмысленный характер. Это я про нормальный императивный код, конечно, а не про высер школьника.
Функциональный код страдает обилием загадочных букв a, b, f, t и т.д. при чем в двух соседних строках они могут означать совершенно разные сущности, это не говоря про более экзотические символы типа >>=, >=< и прочие <|*|>. Это относится к нормальному коду, который можно встретить в тутах по Хаскеллу или Скале.
К тому же, в функциональном коде многие вещи делаются далеко не так очевидно, как в императивном. Что уж говорить, даже унтуитивное понятие цикла в нем замещено значительно более сложной (как в вычислительном плане, так и в плане мыслительной деятельности, требуемой на написание/прочтение кода).
покалеченно сознание только у тех, кто дрочит на стрелки и плюсики в квадратных скобочках.
>Наоборот, больше. Чем код императивнее, тем хуже он читается.
Нет, это не так.
Типичный императивный код довольно сносно отображает течение процесса, как правило, имена объектов и функций в нем имеют осмысленный характер. Это я про нормальный императивный код, конечно, а не про высер школьника.
Функциональный код страдает обилием загадочных букв a, b, f, t и т.д. при чем в двух соседних строках они могут означать совершенно разные сущности, это не говоря про более экзотические символы типа >>=, >=< и прочие <|*|>. Это относится к нормальному коду, который можно встретить в тутах по Хаскеллу или Скале.
К тому же, в функциональном коде многие вещи делаются далеко не так очевидно, как в императивном. Что уж говорить, даже унтуитивное понятие цикла в нем замещено значительно более сложной (как в вычислительном плане, так и в плане мыслительной деятельности, требуемой на написание/прочтение кода).
> Видимо твое покалеченное сознание просто не осилило нормальный код без говнопаттернов и фабрик бобов.
покалеченно сознание только у тех, кто дрочит на стрелки и плюсики в квадратных скобочках.
>>743291
Тем, что для выполнения привычных и простых действий надо изъебываться так, как это описывает любая книга типа learn you a haskell.
Есть много вещей, которые определяются одной формулой/одним предложением, но по сути своей нетривиальны. Монады - классический пример.
Тем, что для выполнения привычных и простых действий надо изъебываться так, как это описывает любая книга типа learn you a haskell.
Есть много вещей, которые определяются одной формулой/одним предложением, но по сути своей нетривиальны. Монады - классический пример.
Всё таки решил вкатиться, хотя всегда считал что хаскель плохо применим в реальных промышленных проектах, в том числе и собственных.
А вкатиться решил потому что якобы хаскель прочищает мозги от налёта ООП/императивного программирования. Давно замечал, что исключительную полезность для мозгов давали концепции, которые были для меня новы
А вкатиться решил потому что якобы хаскель прочищает мозги от налёта ООП/императивного программирования. Давно замечал, что исключительную полезность для мозгов давали концепции, которые были для меня новы
>>743244
Пиздец, ну так и есть. Только ты опустил первые 2 слова зачем-то.
1. В хаскеле монады нужны для IO.
2. В джаве классы нужны для работы с файлами.
И вопрос "как мне сделать то же самое в джаве" лишен смысла - если тебе нужна статическая корректность, то ты из любого места Java-программы можешь написать Runtime.getRuntime().exec("format c:"); и монады тебе не помогут ничем, поэтому тебе придется писать DSL.
>Говорить, что монады нужны для IO, это всё равно, что говорить, что классы нужны для работы с файлами.
Пиздец, ну так и есть. Только ты опустил первые 2 слова зачем-то.
1. В хаскеле монады нужны для IO.
2. В джаве классы нужны для работы с файлами.
И вопрос "как мне сделать то же самое в джаве" лишен смысла - если тебе нужна статическая корректность, то ты из любого места Java-программы можешь написать Runtime.getRuntime().exec("format c:"); и монады тебе не помогут ничем, поэтому тебе придется писать DSL.
>>743256
Ух-ты. Отличная инициатива. И объяснение доходчивое. Спасиб за объяснение.
Ух-ты. Отличная инициатива. И объяснение доходчивое. Спасиб за объяснение.
>>743374
Охуительные истории. Вылить бы тебе на еблет си-портянок, и посмотреть как ты будешь их читать.
> Нет, это не так.
Охуительные истории. Вылить бы тебе на еблет си-портянок, и посмотреть как ты будешь их читать.
>>743374
Пиздец, ясно короче всё с тобой.
> К тому же, в функциональном коде многие вещи делаются далеко не так очевидно, как в императивном.
> унтуитивное понятие цикла в нем замещено значительно более сложной (как в вычислительном плане, так и в плане мыслительной деятельности, требуемой на написание/прочтение кода).
Пиздец, ясно короче всё с тобой.
Ответы>>744052
>>743981
Я тот анончик, который вытягивал разъяснение про использование монад Atkey.
Если бы ты меньше вонял и ругался, а аргументированно излагал как >>743256, то может быть у твоих слов был бы какой-то вес.
А пока что это на уровне
Пока что ты разве что ты только красиво ебаната изображаешь. А может и не изображаешь - хуй тебя разберешь.
Я тот анончик, который вытягивал разъяснение про использование монад Atkey.
Если бы ты меньше вонял и ругался, а аргументированно излагал как >>743256, то может быть у твоих слов был бы какой-то вес.
А пока что это на уровне
> Нет, это не так.
Пока что ты разве что ты только красиво ебаната изображаешь. А может и не изображаешь - хуй тебя разберешь.
>>743374
Подозреваю в тебе самом ебучего школьника, у которого кругом пидарасы. На самом деле это не так. Потому что как раз "осмысленный характер" названий процедур низначит совершенно ничего - для кого-то он осмысленный, для кого-то - не осмысленный и за каждым названием может скрываться что угодно и в двух соседних строках они могут означать совершенно разные сущности. А символы >>=, >=< и прочие <|*|> (половину из которых ты сам придума) - это как раз комбинаторы стандартных тайпклассов, для которых заданы теоремы и означают они везде строго одно и то же. Ты просто не знаешь Хаскеля, но пытаешься про него рассуждать с высоты своего невежества.
>Это я про нормальный императивный код, конечно, а не про высер школьника.
Подозреваю в тебе самом ебучего школьника, у которого кругом пидарасы. На самом деле это не так. Потому что как раз "осмысленный характер" названий процедур низначит совершенно ничего - для кого-то он осмысленный, для кого-то - не осмысленный и за каждым названием может скрываться что угодно и в двух соседних строках они могут означать совершенно разные сущности. А символы >>=, >=< и прочие <|*|> (половину из которых ты сам придума) - это как раз комбинаторы стандартных тайпклассов, для которых заданы теоремы и означают они везде строго одно и то же. Ты просто не знаешь Хаскеля, но пытаешься про него рассуждать с высоты своего невежества.
Ответы>>744434
>>744148
Ты перепутал хуй с трамвайной ручкой. То, что ты написал называется self-explained кодом и я не говорю, что императивный код по умолчанию такой. Просто кому-то, кто читает твой код или тебе лично проще запомнить название, которое кратко отражает действие, выполняемое процедурой (или то, что одержит объект).
Поверь, если заменить слова "тайпклассы" на "ненужная хуйня" в соответствующем склонении, получится то же самое.
Хаскель наворачивает кучу всякого говна и поверх этого всякие ебаные комбинаторы и теоремы.
>Потому что как раз "осмысленный характер" названий процедур низначит совершенно ничего - для кого-то он осмысленный, для кого-то - не осмысленный и за каждым названием может скрываться что угодно
Ты перепутал хуй с трамвайной ручкой. То, что ты написал называется self-explained кодом и я не говорю, что императивный код по умолчанию такой. Просто кому-то, кто читает твой код или тебе лично проще запомнить название, которое кратко отражает действие, выполняемое процедурой (или то, что одержит объект).
> это как раз комбинаторы стандартных тайпклассов, для которых заданы теоремы и означают они везде строго одно и то же.
Поверь, если заменить слова "тайпклассы" на "ненужная хуйня" в соответствующем склонении, получится то же самое.
Хаскель наворачивает кучу всякого говна и поверх этого всякие ебаные комбинаторы и теоремы.
Ответы>>744497
38 Кб, 750x427
Ответы>>744594
>>744434
Для дауна-аутиста вроде тебя - возможно. Что может быть более естественным и самоочевидным чем тайпкласс? ООП-дегенераты не знали что такое тайпкласс, но даже они чувствовали необходимость в нём, хоть и не могли обьяснить её в рамках своего примитивного мировосприятия. И поэтому придумали дефективного уродца - интерфейс, с которым по сей день и живут в манямирке.
>Поверь, если заменить слова "тайпклассы" на "ненужная хуйня" в соответствующем склонении, получится то же самое
Для дауна-аутиста вроде тебя - возможно. Что может быть более естественным и самоочевидным чем тайпкласс? ООП-дегенераты не знали что такое тайпкласс, но даже они чувствовали необходимость в нём, хоть и не могли обьяснить её в рамках своего примитивного мировосприятия. И поэтому придумали дефективного уродца - интерфейс, с которым по сей день и живут в манямирке.
>>744441
Зачем ты принес сюда этого старого вонючего прото-ватника? Идеи для слайдов этот пердучий мудак спиздил, должно быть, отсюда http://math.mit.edu/~dspivak/informatics/talks/galois.pdf
Зачем ты принес сюда этого старого вонючего прото-ватника? Идеи для слайдов этот пердучий мудак спиздил, должно быть, отсюда http://math.mit.edu/~dspivak/informatics/talks/galois.pdf
>>744497
Мне жаль, но тайпклассы - это попытка занести необходимые при разработке концепции в дефективные ФП-языки.
Собственно, даже ФПшники признают, что тайпкласс - это тот же интерфейс в Java, просто с функциональными закидонами. Зато никто не объясняет интерфейсы Джавы как отражение хаскельных тайпклассов.
>Для дауна-аутиста вроде тебя - возможно. Что может быть более естественным и самоочевидным чем тайпкласс? ООП-дегенераты не знали что такое тайпкласс, но даже они чувствовали необходимость в нём, хоть и не могли обьяснить её в рамках своего примитивного мировосприятия. И поэтому придумали дефективного уродца - интерфейс, с которым по сей день и живут в манямирке.
Мне жаль, но тайпклассы - это попытка занести необходимые при разработке концепции в дефективные ФП-языки.
Собственно, даже ФПшники признают, что тайпкласс - это тот же интерфейс в Java, просто с функциональными закидонами. Зато никто не объясняет интерфейсы Джавы как отражение хаскельных тайпклассов.
>>744594
Спасибо за ссылку это не сарказм
>>744630
Можно пример признания?
Хочу обмазаться зависимыми типами и даже написать целую программу их использованием. Проясните за Idris: насколько оно готово (для обучения, не для продакшена)? сильно хуже агды? у компилятора идрис есть бекенд в жс: он выдает сколько-нибудь работоспособный код или нет?
Насколько все-таки хаскель далек от зависимых типов?
Спасибо за ссылку это не сарказм
>>744630
>даже ФПшники признают
Можно пример признания?
Хочу обмазаться зависимыми типами и даже написать целую программу их использованием. Проясните за Idris: насколько оно готово (для обучения, не для продакшена)? сильно хуже агды? у компилятора идрис есть бекенд в жс: он выдает сколько-нибудь работоспособный код или нет?
Насколько все-таки хаскель далек от зависимых типов?
>>744654
Это как раз не забавно. Грешно смеяться над убожеством. А это то что получается в результате пропихивания.
Это как раз не забавно. Грешно смеяться над убожеством. А это то что получается в результате пропихивания.
Игнорируйте петушиных адептов императивной динамико-дрисни и они уйдут
>>744646
Обещали уже вот-вот запилить в GHC 8.*
>>744646
Обещали уже вот-вот запилить в GHC 8.*
>>744630
дауненок не вкурсе, что хаскель старше жабы
дауненок не вкурсе, что хаскель старше жабы
>>669308
Самые бессмысленные 58 минут в моей жизни. Насрал мудель. Нахуя ты этого петуха притащил?
Самые бессмысленные 58 минут в моей жизни. Насрал мудель. Нахуя ты этого петуха притащил?
Ответы>>745469
>>745407
Ты тупой, нет? У меня ссылка открылась где-то на середине, т/е либо это было не 58 минут, либо ты перемотал на начало и действительно целый час до тебя доходило, что это видео не для тебя.
Алсо, сам видео не смотрел - но выяснил, что речь о Dafny. Вещь годная, пробовал, собирается под маком, но к сожалению из опций IDE только Visual Studio под оффтопик.
Ты тупой, нет? У меня ссылка открылась где-то на середине, т/е либо это было не 58 минут, либо ты перемотал на начало и действительно целый час до тебя доходило, что это видео не для тебя.
Алсо, сам видео не смотрел - но выяснил, что речь о Dafny. Вещь годная, пробовал, собирается под маком, но к сожалению из опций IDE только Visual Studio под оффтопик.
Ответы>>745865
>>744594
Краткое содержание слайдов:
или это краткое содержание всех работ по теории категорий?
Краткое содержание слайдов:
> Смотрите кажется что я просто ковыряюсь в жопе - а на самом деле я использую теорию категорий!
или это краткое содержание всех работ по теории категорий?
Ответы>>745961
>>745961
Любой червь-пидор >>> сикулеговно, не могущее ни в модульность, ни в типы, ни в нихуя. Нелепый коболовысер, мне просто омерзительно иметь что-либо общее с этой хуйней.
>ORM
Любой червь-пидор >>> сикулеговно, не могущее ни в модульность, ни в типы, ни в нихуя. Нелепый коболовысер, мне просто омерзительно иметь что-либо общее с этой хуйней.
>>746074
>Любой червь-пидор >>> оопговно, не могущее ни в модульность, ни в типы, ни в нихуя. Нелепый коболовысер, мне просто омерзительно иметь что-либо общее с этой хуйней.
Ответы>>746250
>>746189>>746224
Даже в обоссанной жабке есть f-bound полиморфизм, а в сикуле ничего кроме "хуй"+""""+"пизда"""+пизда+""""+хуйхуй.
Даже в обоссанной жабке есть f-bound полиморфизм, а в сикуле ничего кроме "хуй"+""""+"пизда"""+пизда+""""+хуйхуй.
Ответы>>746603
>>746250
Сравнил жопу с пальцем, молодец. Язык общего назначения с DSL.
Сравнил жопу с пальцем, молодец. Язык общего назначения с DSL.
>>649725 (OP)
Анон, как вкатиться в GHCJS? Нихуя не понимат
Анон, как вкатиться в GHCJS? Нихуя не понимат
Ответы>>747719
>>747703
Пиши свой мини жкваре или фреймворк для работы с формами, хотя бы. Потом по дерьму как по маслу пойдет.
Пиши свой мини жкваре или фреймворк для работы с формами, хотя бы. Потом по дерьму как по маслу пойдет.
97 Кб, 466x604
Если кратко - то языки выбирают не тогда, когда задача уже есть. Их выбирают загодя и обкатывают. Когда задача вот она стоит перед предприятием - только то, что обкатано.
Выбор языка определяется в основном не "задачей", а наличием команды. Задачи набираются под имеющиеся проверенные команды, команды набираются под имеющихся проверенных техлидов и освоенный ими (пока были джуниорами, миддлами и сеньорами-кодерами) и "испытанный" технологический стек. Под "испытанностью" подразумевается либо использование в пилотном проекте, либо использованием конкурентов. Если "соседи" по индустрии пишут игры на С++ - то один этот факт (при наличии С++ лида) может определить выбор С++ как языка.
Работать на одном стеке гораздо выгоднее, чем каждый раз его менять. Если предприятие начинает использовать какой-то стек по причинам выше (а не "исходя из задачи") - то дальше работает только на нём. Там же целый завод по выпуску ПО - отлаженные технологические процессы, построенные цеха, настроенная инфраструктура, сработавшиеся с друг другом специалисты разных профилей в рамках стека (админы-QA-девы-аналитики-эйчары-пмы и т п). Соответственно, выбора языка на уровне предприятия как такового нет.
На уровне программиста ровно то же самое. Выбираете специализацию и дальше её углубляете. Учат язык в ходе работы над проектом разве что начинающие (и попавшие в пилотный проект - см. выше). Ещё есть небольшой шанс сеньору пойти джуниором не по своей специализации, своего рода индивидуальный аналог пилотного проекта.
Таким образом, изучение нового языка и его испытание в пилотных проектах связяно с задачами совершенно косвенно. Задачи редко можно отложить на год, чтобы за это время подготовить команду. Т.е. освоение нового языка - это стратегический задел.
В моём случае С++ я знал "со школы", а "заделами" являлось изучение Perl (это был 1998 год, PHP был относительно маргинальным, а Perl - проверенным решением) и Haskell.
Пилотным для Perl был проект сайта брачного агентства, который сделал одногруппник, а я мейнтейнил (т.е. заметьте, безрисково!). JS учил в проекте с одногруппником, который более-менее его знал. А Haskell я учил по сути все 15 лет последние, с пилотной обкаткой на опенсорсных хобби HNC и N2O.hs и небольших утилитках в продакшене.
Опять же, уровень знаний теории позволяет претендовать на участие в командах мирового уровня, использующих Haskell, как следующей ступеньке карьерной лестницы.
А на текущей - брать сеньора в команду не по его специализации является моветоном. И наоборот - я как приличный сеньор всегда найду работу по специализации. А внезапных смен языка на текущем месте работы не бывает, см. выше.
Т.е. я намеренно, в течение 15 лет сменял специализацию. "Элитизм" тут проистекает из зарплат порядка 100 дол в час, достижимых на ниве хаскель кодерства.
По С++ для таких зарплат требуется уровень vit_r а то и выше - т.е. кодерством не заработать, нужно очень высококлассное ПМ-ство и техлидство, я это не потяну. А математика - запросто. Там спрос небольшой, но и предложение небольшое, математику без задротства не освоить, а задротов относительно мало в популяции.
"Язык под задачу" может выбрать разве что технически продвинутый аутсорсер. Т.е., исходя из наиболее подходящего стека, найти готовую команду в виде субподрядчика, у которого этот стек - основная специализация.
Короче, "языки под задачи" - это для
а) джуниоров, берущихся за что попало;
б) начинающих контор, берущихся за что попало;
в) при поиске субподрядчика.
http://nponeccop.livejournal.com/488373.html
Выбор языка определяется в основном не "задачей", а наличием команды. Задачи набираются под имеющиеся проверенные команды, команды набираются под имеющихся проверенных техлидов и освоенный ими (пока были джуниорами, миддлами и сеньорами-кодерами) и "испытанный" технологический стек. Под "испытанностью" подразумевается либо использование в пилотном проекте, либо использованием конкурентов. Если "соседи" по индустрии пишут игры на С++ - то один этот факт (при наличии С++ лида) может определить выбор С++ как языка.
Работать на одном стеке гораздо выгоднее, чем каждый раз его менять. Если предприятие начинает использовать какой-то стек по причинам выше (а не "исходя из задачи") - то дальше работает только на нём. Там же целый завод по выпуску ПО - отлаженные технологические процессы, построенные цеха, настроенная инфраструктура, сработавшиеся с друг другом специалисты разных профилей в рамках стека (админы-QA-девы-аналитики-эйчары-пмы и т п). Соответственно, выбора языка на уровне предприятия как такового нет.
На уровне программиста ровно то же самое. Выбираете специализацию и дальше её углубляете. Учат язык в ходе работы над проектом разве что начинающие (и попавшие в пилотный проект - см. выше). Ещё есть небольшой шанс сеньору пойти джуниором не по своей специализации, своего рода индивидуальный аналог пилотного проекта.
Таким образом, изучение нового языка и его испытание в пилотных проектах связяно с задачами совершенно косвенно. Задачи редко можно отложить на год, чтобы за это время подготовить команду. Т.е. освоение нового языка - это стратегический задел.
В моём случае С++ я знал "со школы", а "заделами" являлось изучение Perl (это был 1998 год, PHP был относительно маргинальным, а Perl - проверенным решением) и Haskell.
Пилотным для Perl был проект сайта брачного агентства, который сделал одногруппник, а я мейнтейнил (т.е. заметьте, безрисково!). JS учил в проекте с одногруппником, который более-менее его знал. А Haskell я учил по сути все 15 лет последние, с пилотной обкаткой на опенсорсных хобби HNC и N2O.hs и небольших утилитках в продакшене.
Опять же, уровень знаний теории позволяет претендовать на участие в командах мирового уровня, использующих Haskell, как следующей ступеньке карьерной лестницы.
А на текущей - брать сеньора в команду не по его специализации является моветоном. И наоборот - я как приличный сеньор всегда найду работу по специализации. А внезапных смен языка на текущем месте работы не бывает, см. выше.
Т.е. я намеренно, в течение 15 лет сменял специализацию. "Элитизм" тут проистекает из зарплат порядка 100 дол в час, достижимых на ниве хаскель кодерства.
По С++ для таких зарплат требуется уровень vit_r а то и выше - т.е. кодерством не заработать, нужно очень высококлассное ПМ-ство и техлидство, я это не потяну. А математика - запросто. Там спрос небольшой, но и предложение небольшое, математику без задротства не освоить, а задротов относительно мало в популяции.
"Язык под задачу" может выбрать разве что технически продвинутый аутсорсер. Т.е., исходя из наиболее подходящего стека, найти готовую команду в виде субподрядчика, у которого этот стек - основная специализация.
Короче, "языки под задачи" - это для
а) джуниоров, берущихся за что попало;
б) начинающих контор, берущихся за что попало;
в) при поиске субподрядчика.
http://nponeccop.livejournal.com/488373.html
97 Кб, 466x604
Если кратко - то языки выбирают не тогда, когда задача уже есть. Их выбирают загодя и обкатывают. Когда задача вот она стоит перед предприятием - только то, что обкатано.
Выбор языка определяется в основном не "задачей", а наличием команды. Задачи набираются под имеющиеся проверенные команды, команды набираются под имеющихся проверенных техлидов и освоенный ими (пока были джуниорами, миддлами и сеньорами-кодерами) и "испытанный" технологический стек. Под "испытанностью" подразумевается либо использование в пилотном проекте, либо использованием конкурентов. Если "соседи" по индустрии пишут игры на С++ - то один этот факт (при наличии С++ лида) может определить выбор С++ как языка.
Работать на одном стеке гораздо выгоднее, чем каждый раз его менять. Если предприятие начинает использовать какой-то стек по причинам выше (а не "исходя из задачи") - то дальше работает только на нём. Там же целый завод по выпуску ПО - отлаженные технологические процессы, построенные цеха, настроенная инфраструктура, сработавшиеся с друг другом специалисты разных профилей в рамках стека (админы-QA-девы-аналитики-эйчары-пмы и т п). Соответственно, выбора языка на уровне предприятия как такового нет.
На уровне программиста ровно то же самое. Выбираете специализацию и дальше её углубляете. Учат язык в ходе работы над проектом разве что начинающие (и попавшие в пилотный проект - см. выше). Ещё есть небольшой шанс сеньору пойти джуниором не по своей специализации, своего рода индивидуальный аналог пилотного проекта.
Таким образом, изучение нового языка и его испытание в пилотных проектах связяно с задачами совершенно косвенно. Задачи редко можно отложить на год, чтобы за это время подготовить команду. Т.е. освоение нового языка - это стратегический задел.
В моём случае С++ я знал "со школы", а "заделами" являлось изучение Perl (это был 1998 год, PHP был относительно маргинальным, а Perl - проверенным решением) и Haskell.
Пилотным для Perl был проект сайта брачного агентства, который сделал одногруппник, а я мейнтейнил (т.е. заметьте, безрисково!). JS учил в проекте с одногруппником, который более-менее его знал. А Haskell я учил по сути все 15 лет последние, с пилотной обкаткой на опенсорсных хобби HNC и N2O.hs и небольших утилитках в продакшене.
Опять же, уровень знаний теории позволяет претендовать на участие в командах мирового уровня, использующих Haskell, как следующей ступеньке карьерной лестницы.
А на текущей - брать сеньора в команду не по его специализации является моветоном. И наоборот - я как приличный сеньор всегда найду работу по специализации. А внезапных смен языка на текущем месте работы не бывает, см. выше.
Т.е. я намеренно, в течение 15 лет сменял специализацию. "Элитизм" тут проистекает из зарплат порядка 100 дол в час, достижимых на ниве хаскель кодерства.
По С++ для таких зарплат требуется уровень vit_r а то и выше - т.е. кодерством не заработать, нужно очень высококлассное ПМ-ство и техлидство, я это не потяну. А математика - запросто. Там спрос небольшой, но и предложение небольшое, математику без задротства не освоить, а задротов относительно мало в популяции.
"Язык под задачу" может выбрать разве что технически продвинутый аутсорсер. Т.е., исходя из наиболее подходящего стека, найти готовую команду в виде субподрядчика, у которого этот стек - основная специализация.
Короче, "языки под задачи" - это для
а) джуниоров, берущихся за что попало;
б) начинающих контор, берущихся за что попало;
в) при поиске субподрядчика.
http://nponeccop.livejournal.com/488373.html
Выбор языка определяется в основном не "задачей", а наличием команды. Задачи набираются под имеющиеся проверенные команды, команды набираются под имеющихся проверенных техлидов и освоенный ими (пока были джуниорами, миддлами и сеньорами-кодерами) и "испытанный" технологический стек. Под "испытанностью" подразумевается либо использование в пилотном проекте, либо использованием конкурентов. Если "соседи" по индустрии пишут игры на С++ - то один этот факт (при наличии С++ лида) может определить выбор С++ как языка.
Работать на одном стеке гораздо выгоднее, чем каждый раз его менять. Если предприятие начинает использовать какой-то стек по причинам выше (а не "исходя из задачи") - то дальше работает только на нём. Там же целый завод по выпуску ПО - отлаженные технологические процессы, построенные цеха, настроенная инфраструктура, сработавшиеся с друг другом специалисты разных профилей в рамках стека (админы-QA-девы-аналитики-эйчары-пмы и т п). Соответственно, выбора языка на уровне предприятия как такового нет.
На уровне программиста ровно то же самое. Выбираете специализацию и дальше её углубляете. Учат язык в ходе работы над проектом разве что начинающие (и попавшие в пилотный проект - см. выше). Ещё есть небольшой шанс сеньору пойти джуниором не по своей специализации, своего рода индивидуальный аналог пилотного проекта.
Таким образом, изучение нового языка и его испытание в пилотных проектах связяно с задачами совершенно косвенно. Задачи редко можно отложить на год, чтобы за это время подготовить команду. Т.е. освоение нового языка - это стратегический задел.
В моём случае С++ я знал "со школы", а "заделами" являлось изучение Perl (это был 1998 год, PHP был относительно маргинальным, а Perl - проверенным решением) и Haskell.
Пилотным для Perl был проект сайта брачного агентства, который сделал одногруппник, а я мейнтейнил (т.е. заметьте, безрисково!). JS учил в проекте с одногруппником, который более-менее его знал. А Haskell я учил по сути все 15 лет последние, с пилотной обкаткой на опенсорсных хобби HNC и N2O.hs и небольших утилитках в продакшене.
Опять же, уровень знаний теории позволяет претендовать на участие в командах мирового уровня, использующих Haskell, как следующей ступеньке карьерной лестницы.
А на текущей - брать сеньора в команду не по его специализации является моветоном. И наоборот - я как приличный сеньор всегда найду работу по специализации. А внезапных смен языка на текущем месте работы не бывает, см. выше.
Т.е. я намеренно, в течение 15 лет сменял специализацию. "Элитизм" тут проистекает из зарплат порядка 100 дол в час, достижимых на ниве хаскель кодерства.
По С++ для таких зарплат требуется уровень vit_r а то и выше - т.е. кодерством не заработать, нужно очень высококлассное ПМ-ство и техлидство, я это не потяну. А математика - запросто. Там спрос небольшой, но и предложение небольшое, математику без задротства не освоить, а задротов относительно мало в популяции.
"Язык под задачу" может выбрать разве что технически продвинутый аутсорсер. Т.е., исходя из наиболее подходящего стека, найти готовую команду в виде субподрядчика, у которого этот стек - основная специализация.
Короче, "языки под задачи" - это для
а) джуниоров, берущихся за что попало;
б) начинающих контор, берущихся за что попало;
в) при поиске субподрядчика.
http://nponeccop.livejournal.com/488373.html
>>747839
а у вас тут весело. то nponeccop, то ivan-gandhi, такое впечатление что не pr читаю, а френдленту.
а у вас тут весело. то nponeccop, то ivan-gandhi, такое впечатление что не pr читаю, а френдленту.
928 Кб, 3968x2232
>>747839
Сделал мой день, содомит.
> "Элитизм" тут проистекает из зарплат порядка 100 дол в час, достижимых на ниве хаскель кодерства.
Сделал мой день, содомит.
Ответы>>748189
>>748064
Пёстрая у вас лента, однако. Из уродов и людей. Тоже иногда захожу почитать Ганди, посмотреть как в животном запале он обличает всё что не согласуется с его протоватническими настроениями. На редкость гадливый старичок.
Пёстрая у вас лента, однако. Из уродов и людей. Тоже иногда захожу почитать Ганди, посмотреть как в животном запале он обличает всё что не согласуется с его протоватническими настроениями. На редкость гадливый старичок.
>>748183
Ты странный. Судя по комментарию, ты не любишь ни хаскелла, ни борщ (да еще так аппетитно сервированный). И кто тут извращенец?
Ты странный. Судя по комментарию, ты не любишь ни хаскелла, ни борщ (да еще так аппетитно сервированный). И кто тут извращенец?
Ответы>>748206
>>748064
почитал, оба дурачки. Тот который пишет про 15 лет освоения хаскеля просто туповат. За 15 лет можно выдающимся ученым стать, а он все велосипед пердолит. Отсутствие ума пытается задротством компенсировать.
почитал, оба дурачки. Тот который пишет про 15 лет освоения хаскеля просто туповат. За 15 лет можно выдающимся ученым стать, а он все велосипед пердолит. Отсутствие ума пытается задротством компенсировать.
>>748189
Это всего лишь стеб над "зарплатами порядка 100 дол в час". Таких даже у востребованных в энтерпрайзе эрланге и кожуре нет.
Это всего лишь стеб над "зарплатами порядка 100 дол в час". Таких даже у востребованных в энтерпрайзе эрланге и кожуре нет.
Ответы>>753243
8 Кб, 459x335
Группа ученых под руководством Дэниела Лебреро из Лаборатории Торговых Программных Интерфейсов британской компании IG Markets Ltd провела статистическое исследование о связи числа баг-репортов и языков программирования на базе информации об открытых проектах на сайте "Центр деятельности мерзавцев" (GitHub.com, организация разрешена в России, за исключением некоторых периодов, когда она запрещена). Выяснилось, что наличие статической типизации и продвинутой системы типов не помогает в уменьшении ошибок, а порой даже вредит, в то время как меньше всего ошибок получается в программах на максимально простых языках.
Теперь научно доказано, что theiced был прав: типы не нужны, а писать надо на Кложури. А также Эрланге и Го. Адептам сложных языков и развитых систем типов надлежит раскаяться, одуматься и перестать уже своими надуманными неработающими идеями отвлекать благородных донов, занятых TDD.
http://thedeemon.livejournal.com/112666.html
Теперь научно доказано, что theiced был прав: типы не нужны, а писать надо на Кложури. А также Эрланге и Го. Адептам сложных языков и развитых систем типов надлежит раскаяться, одуматься и перестать уже своими надуманными неработающими идеями отвлекать благородных донов, занятых TDD.
http://thedeemon.livejournal.com/112666.html
>>749662
На паскале меньше всего ошибок так как на нем только лабы делают. Это просто список популярности языков.
На паскале меньше всего ошибок так как на нем только лабы делают. Это просто список популярности языков.
Ответы>>749994
>>749971
Я пофиксил, не благодари:
-Невнятные потуги на аналитику
+Языков, использовавшихся в популярных проектах.
Я пофиксил, не благодари:
-Невнятные потуги на аналитику
+Языков, использовавшихся в популярных проектах.
>>749978
Не нашёл никакого упоминания о завтипах.
Не нашёл никакого упоминания о завтипах.
>>749662
В голос.
> "Центр деятельности мерзавцев" (GitHub.com, организация разрешена в России, за исключением некоторых периодов, когда она запрещена)
В голос.
Ответы>>752701
>>750251
Еще и с подливой небось, животное?
Еще и с подливой небось, животное?
>>744630
Тайпклассы выразительнее интерфейсов, если их и сравнивают с интерфейсами, так только чтобы у ОО-даунов было хоть какое-то доступное их уровню понимание. С той же целью ОО-даунам говорят, что монада - это массив.
>Собственно, даже ФПшники признают, что тайпкласс - это тот же интерфейс в Java
Тайпклассы выразительнее интерфейсов, если их и сравнивают с интерфейсами, так только чтобы у ОО-даунов было хоть какое-то доступное их уровню понимание. С той же целью ОО-даунам говорят, что монада - это массив.
>>746074
ORM-говно тоже не может в модульность. В модульность могут построители запросов, типа LINQ, Slick и куча поделок на Хаскелле. Но что интересно, эти поделки на Хаскелле пилят, и вроде всё с ними заебись, но потом они надоедают автору и остаются гнить на хакадже никому нахуй не нужные. Через несколько лет кто-то новый, молодой, шутливый пилит новую поделку, которая еще круче предыдущих, но в итоге она повторяет судьбу предшественников. А разгадка проста - нет задач. Ну т.е. охуенно как нужен парсер json-а или командной строки, охуенно нужны притти-принтеры, quickcheck ой как нужен, а еще criterion, чтобы производительность мерить, без этих двух либ почти никакой Хаскель-проект не обходится. Еще хешь-таблицы быстрые нужны и векторы, mtl нужен, куда без него, байтстринги, бинарная сериализация, аттопарсек тоже частенько бывает полезен. А ОРМ-гона не очень-то нужны. Ведь можно просто написать SQL-запрос, и никакой фундаментальной разницы, типа жизнь без ORM/жизнь с ORM/жизнь с самописной недо-ORM, которая запилина чисто под нужды проекта нет. 20% либ решают 80% задач, ORM к этим 20% не относится.
ORM-говно тоже не может в модульность. В модульность могут построители запросов, типа LINQ, Slick и куча поделок на Хаскелле. Но что интересно, эти поделки на Хаскелле пилят, и вроде всё с ними заебись, но потом они надоедают автору и остаются гнить на хакадже никому нахуй не нужные. Через несколько лет кто-то новый, молодой, шутливый пилит новую поделку, которая еще круче предыдущих, но в итоге она повторяет судьбу предшественников. А разгадка проста - нет задач. Ну т.е. охуенно как нужен парсер json-а или командной строки, охуенно нужны притти-принтеры, quickcheck ой как нужен, а еще criterion, чтобы производительность мерить, без этих двух либ почти никакой Хаскель-проект не обходится. Еще хешь-таблицы быстрые нужны и векторы, mtl нужен, куда без него, байтстринги, бинарная сериализация, аттопарсек тоже частенько бывает полезен. А ОРМ-гона не очень-то нужны. Ведь можно просто написать SQL-запрос, и никакой фундаментальной разницы, типа жизнь без ORM/жизнь с ORM/жизнь с самописной недо-ORM, которая запилина чисто под нужды проекта нет. 20% либ решают 80% задач, ORM к этим 20% не относится.
>>748206
Эрлан и Кложура маргинальнее Хаскеля. С разморозкой. На дворе 2016.
>Таких даже у востребованных в энтерпрайзе эрланге и кожуре
Эрлан и Кложура маргинальнее Хаскеля. С разморозкой. На дворе 2016.
>>749662
Уже Сшные {} в сравнении с OCaml'ом должны давать уменьшение плотности ошибок в 2 раза. А если мы добавим функцию return, обязательные include, шапку коммента сверху, то можно добиться и 3-х кратного уменьшения плотности ошибок.
Уже Сшные {} в сравнении с OCaml'ом должны давать уменьшение плотности ошибок в 2 раза. А если мы добавим функцию return, обязательные include, шапку коммента сверху, то можно добиться и 3-х кратного уменьшения плотности ошибок.
Ответы>>753289
>>753245
А тоньше нельзя?
А тоньше нельзя?
>>744646
Агда - dep-types говно с юникодом, написанное на Хаскелле.
Идрис - dep-types говно без юникода, написанное на Хаскелле.
Как ты сам понимаешь, выбор мкжду этими двумя инструментам диктуется твоим отношением к юникоду.
>сильно хуже агды?
Агда - dep-types говно с юникодом, написанное на Хаскелле.
Идрис - dep-types говно без юникода, написанное на Хаскелле.
Как ты сам понимаешь, выбор мкжду этими двумя инструментам диктуется твоим отношением к юникоду.
Бамп
Ответы>>767009
>>767009
Кто, я?
Кто, я?
Тред утонул или удален.
Это копия, сохраненная 4 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 4 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.