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

Блин, они все еще не выпилили gil, и даже нашли для этого оправдание.

Мол, посмотрите на эрланг, как он прекрасно масштабируется и не зависит от железа. Обменивайтесь сообщениями и не плодите потоки...

там же были какие-то движения на тему конкаренси

Но про gil это так, придирки. На самом деле меня всегда отпугивало только одно. До неприличия странная тяга его разработчиков к экспериментам. Мол, а давайте запилим новый синтаксис! И пофиг на оптимизацию, на портирование под другие платформы, на стандартизацию библиотеки стандартной...

ну академический язык же

Даже обидно. Ведь окамл стал самой удачной практической реализацией философии ML, и мог бы завоевать огромную долю рынка.

хаскель тож такой же )

идрис же экспериментальный

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

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

интересно слышать вопросы про идрис в продакшне)

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

Кстати что вы понимаете под академическим?

Вот си это тоже академический язык

Кстати что вы понимаете под академическим?

Если я слишком тупой, чтобы писать на языке, то язык академический

Мне то так казалось что это языки разрабатываемые в университетах в основнос

Если я слишком тупой, чтобы писать на языке, то язык академический

То есть любой язык /s

То есть любой язык /s

Вы победили в конкурсе банальных шутников, берите с полки пирожок

Считаю это надувательством, требую прислать пирожок почтой.

А рассуждение тут достаточно простое: на Хаскеле писать явно проще, чем на многих других языках, соответственно если он слишком сложен, то остальные языки — тем более.

Все ты врешь, никто не пишет, продакшенов нет

Проще не значит, что кто-то пишет

Ошибочная предпосылка, что люди рациональны в выборе технологий

вот с этим 100% соглашусь, никакого рационализма в выборе технологий нету

иначе зачем бы были нужны другие языки кроме хаскеля?:)

ну и Cшичеки:)

Другие языки нужны чтобы утешать хаскелистов, когда Хаскель подводит: "Скажи спасибо, что не на Java пишешь"

Периодически так себя успокаиваю.

Периодически так себя успокаиваю.

А на жизнь зарабатываешь благодаря какому языку программирования?

Haskell.

да хаскелист

у него все норм:)

Да я просто поинтересовался :)

Всё-таки хаскель сила в теме метана где трудно выразить в парадигме ООП и процедурного ада имхо

Хотите попробовать написать на нем редактор векторной графики? :)

Денис то что вы думаете надо разделить на то что взаимодействует с миром и то что от него отделено - но далее мат моделей пока не вижу

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

Вообще намек был на производительность и на потребляемую память

Ну производительность и память об этом все знают - а если забыть что язык ленивый то вообще каюк

Кто то мечтал о том чтобы изначально по умолчании надо было стрикт а не лази

Не помню кто но гднто читал

Но мой личные мнение хаскель сейчас активно развивается и думаю через 5лет вполне будет пригоден для всех если уберут боль?

да, если такими темпами пилить будут то ещё 5 лет и норм )

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

Я например уж и не помню как куик сорт написать на джава а на хаcке даже не учил?

Но мой личные мнение хаскель сейчас активно развивается и думаю через 5лет вполне будет пригоден для всех если уберут боль?

Боль это продолжающийся ад с версиями библиотек?

Нет стэк решает проблемы - боль что трудно выразить ООП в функциональном и с непривично с ide хоть она и ненужна я в консоле все делаю

Зачем выражать ооп в функциональном стиле?

И что именно из этого трудно?

ооп в том виде что оно сейчас в индустрии крутится, по-моему, вредно

Бизнес задачи очень хорошо ложатся

Очень хорошо на фп ложатся

Очень хорошо на фп ложатся

А ООП зачем?

Защитники ООП как я понимаю говорят -всё объект и это ближе к человеческому опыту - а вот функц подход интуитивно не понятен мозгу из-за опыта полученного в результате жизни

Там и DDD далее идет

Хотя по логике можно сказать всё есть функция? итп

ООП == subclass polymorphism

Когда кошка наследуется от собаки и вот это всё

Утрированно конечно

Начиная с какого-то то момента удивления для разума становится слишком много

Да но с помощью композиции с утиной типизацией пытаются убить жёскую связь между "классами"

Хотя в фп как я понимаю например map и есть паттен проектирования причем в деклар стиле

А вместе с генериками вообще сила?

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

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

Ну есть же решения чтобы решить это но конечно это "костыли"

ERROR: S client not available

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

Вот когда кошка начинает от собаки наследоваться

Это уже плохо

Да согласен изначально если пошли не той дорогой и чем дальше в лес тем труднее сменить но из-за этого методики разные скрум с короткими циклами итп чтобы раньше нащупать правильное направление както так

Вот как хаскель например сможет помочь - рефактить на нем отлично

Но вот повторное использование те не кидать всё в один бог файл, разделить на повторно используемые компоненты чтобы не лезть в него- вот как в хаске пока ненащупал?

Ну есть же решения чтобы решить это но конечно это "костыли"

Не лучше ли начать с преимуществ наследования? Они есть вообще?

Я отношусь к той части - кто считает сильно связанное наследование фундаментальным недостатком - но современные языки типа го раст итп отказались (если я неошибаюсь) от этого недостатка

Меньше кода писать иногда

Для меня лично наиболее удачным примером применения принципов наследования в ооп является API Excel.

Бегло пробежавшись по мсдн, быстро уясняешь, что в экселе, по большому счету, все есть диапазон (range), и все сущности можно объединять в коллекции.

На этом для меня достоинства наследования заканчиваются

Причем, глядя на хаскел и окамл, я понимаю, что того же результата можно было достичь (причем, вероятно, меньшими усилиями) с помощью грамотной системы типов. В окамле так и вовсе ООП на типы завязан, что как бы намекает

Интересно есть ли книга типа DDD в функциональном стиле на примере известной книги

Если нет то она я думаю взорвет мир фп

Превратит его в тыкву? :)

Нет думаю очень сильно его продвинет - сделает ближе народу) А если на хаске то вообще его недостатки вылезут как явные

И это наконецто сделает его приятным ) Но надо компании кторые его юзают их опыт а это годы(

Опыт переваривается и вываливается чтото - но не г.....о конечно- надеюсь

Кто нибудь смотрел https://github.com/JPMoresmau/dbIDE?

Я не смотрел, я в виме :D

Товарищи, а вот есть какой-то способ один модуль раскидать по разным файлам?

Я что-то никак не выгуглю

Товарищи, а вот есть какой-то способ один модуль раскидать по разным файлам?

Что это обозначает?

Ну чтобы один модуль был в разных файлах. В clojure можно, например, указывать одно имя неймспейса и потом в него подгрузить какое угодно количество файлов с кодом, которые логически будут в том же неймспейсе. Вот с модулями так нельзя?

Я понимаю, что пример с clojure вообще не про то)

Вагную что: module Foo.Internal.One ... module Foo.Internal.Two ... module Foo ( module Foo.Internal.One module Foo.Internal.Two ) where ...

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

а, вот как это делается

понял, спасибо!

Товарищи, а вот есть какой-то способ один модуль раскидать по разным файлам?

Сам-то понял, чего хочешь?

я все понял и мне уже ответили, спасибо