Решайте сами, влияет оно на код, который вы считаете практичным или нет. У меня могут быть другие представления и о практичности, и о степени влияния.

Так может быть вы скрытый хаскелист. (всё, выключаю токсичность)

Так может быть вы скрытый хаскелист. (всё, выключаю токсичность)

Но Algebraic Effects в Haskell нет! 😃

потому что объяснение монады из теории типов - это херня. А вот объяснение "сморите, теперь вы можете писать async/await и избавиться от коллбеков" - это полезное практическое объяснение

Давайте я попробую объяснить почему объяснения типа "смотрите, теперь вы можете писать бла-бла-бла" - это хуйня, а теория типов - намного практичнее. Серьёзно, без наездов и обзывательств. Есть два уровня - синтаксические конструкции, которые мы пишем на языке программирования, и структуры, которые они описывают. Не в смысле структур данных (хотя и это тоже), а в смысле сущностей, связей между ними, правил взаимодействия и ограничений. В ООП некоторые из таких структур называют "паттернами проектирования", и именно поэтому упорно талдычут, что паттерны не зависят от конкретного языка и так далее. Так вот, в Haskell для описания таких структур ("паттернов", отношений между сущностями и правил их взаимодействия) часто используют алгебраические (в смысле "абстрактной" или "высшей" алгебры) структуры: кольца, моноиды, функторы, да, монады, и ещё кое-какие. Преимущество алгебраических структур над "паттернами проектирования" в том, что они подчиняются определённым законам, гарантирующим их корректность. Преимущество теории типов и статической проверки типов - в гарантированном выполнении таких законов. Таким образом, использование корректных (sound) с точки зрения теории типов/теории категорий структур и механизмов обеспечивает корректное (ожидаемое, доказуемое) поведение программы, независимо от того синтаксиса, который используется. Для традиционного кода верно правило "меньше кода - меньше ошибок", поэтому многие программисты так любят "лаконичный синтаксис", но при использовании алгебраических структур и статической проверки их свойств количество ошибок не зависит от количества строк кода. Поэтому многие функциональные программисты любят языки с зависимыми типами, несмотря на то, что писать на них приходится больше.

Странно что в канале раста приходится объяснять, что гарантии от системы типов это важно.

а монады...

Давайте я попробую объяснить почему объяснения типа "смотрите, теперь вы можете писать бла-бла-бла" - это хуйня, а теория типов - намного практичнее. Серьёзно, без наездов и обзывательств. Есть два уровня - синтаксические конструкции, которые мы пишем на языке программирования, и структуры, которые они описывают. Не в смысле структур данных (хотя и это тоже), а в смысле сущностей, связей между ними, правил взаимодействия и ограничений. В ООП некоторые из таких структур называют "паттернами проектирования", и именно поэтому упорно талдычут, что паттерны не зависят от конкретного языка и так далее. Так вот, в Haskell для описания таких структур ("паттернов", отношений между сущностями и правил их взаимодействия) часто используют алгебраические (в смысле "абстрактной" или "высшей" алгебры) структуры: кольца, моноиды, функторы, да, монады, и ещё кое-какие. Преимущество алгебраических структур над "паттернами проектирования" в том, что они подчиняются определённым законам, гарантирующим их корректность. Преимущество теории типов и статической проверки типов - в гарантированном выполнении таких законов. Таким образом, использование корректных (sound) с точки зрения теории типов/теории категорий структур и механизмов обеспечивает корректное (ожидаемое, доказуемое) поведение программы, независимо от того синтаксиса, который используется. Для традиционного кода верно правило "меньше кода - меньше ошибок", поэтому многие программисты так любят "лаконичный синтаксис", но при использовании алгебраических структур и статической проверки их свойств количество ошибок не зависит от количества строк кода. Поэтому многие функциональные программисты любят языки с зависимыми типами, несмотря на то, что писать на них приходится больше.

вопрос не в этом, а втом, чтобы знаеть теоркат чтобы юзать ? operator

вопрос не в этом, а втом, чтобы знаеть теоркат чтобы юзать ? operator

Ох, блин, нужно что-то знать чтобы уметь чем-то пользоваться! Ну его нах! Сегодня новость видел, что мужик построил яхту без всякой там матемитики и инженерии. Ну и что, что затонула - можно же без матана! (Это я включил обратно токсичность.)

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

ну для того, чтобы хуярить do { ... }, вроде 2x phd не надо

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

Покажите мне язык, на котором нельзя писать без 2 PhD, пожалуйста. А то я без единой PhD пишу на Haskell, кой-чего писал на Idris и Coq, читаю Agda - уже начал как-то разочаровываться, нехватает челленджа, нет мотивации получать PhD! 😂

Покажите мне язык, на котором нельзя писать без 2 PhD, пожалуйста. А то я без единой PhD пишу на Haskell, кой-чего писал на Idris и Coq, читаю Agda - уже начал как-то разочаровываться, нехватает челленджа, нет мотивации получать PhD! 😂

GPSS :D

Покажите мне язык, на котором нельзя писать без 2 PhD, пожалуйста. А то я без единой PhD пишу на Haskell, кой-чего писал на Idris и Coq, читаю Agda - уже начал как-то разочаровываться, нехватает челленджа, нет мотивации получать PhD! 😂

GPSS :D

Ну вот такой вундеркинд притащит хаскель или раст в прод а потом уволится, где мне искать замену?

Ну вот такой вундеркинд притащит хаскель или раст в прод а потом уволится, где мне искать замену?

С чего бы? Я на нём делал лабы на заказ, не особо задумывась. Для томских заочников из РЖД.

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

только сука это не должно быть НЕОБХОДИМЫМ качеством для разработки

Корректность программы не должна быть НЕОБХОДИМЫМ качеством для запуска её в прод! Ну, если вам корректность не нужна - очень рад за вас, чего тогда беспокоитесь? 😊

Я до того писал лабы по имитационному моделированию на дельфи. Там тоже ничего особо сложного не было.

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

Ну вот такой вундеркинд притащит хаскель или раст в прод а потом уволится, где мне искать замену?

Корректность программы не должна быть НЕОБХОДИМЫМ качеством для запуска её в прод! Ну, если вам корректность не нужна - очень рад за вас, чего тогда беспокоитесь? 😊

Я начинал программирование именно с паскаля, и он не вызывает у меня отвращения. Другое дело, что gpss мне мозг вынес тем, что там идентификаторы больше 8 символов молча не поддерживались.

Уивительно, но мне замену нашли. Хотя там хаскель не я в прод притащил - меня тоже нашли "на замену"...

зачем вообще академический язык в прод тащить?

у тебя с логикой все ок?

зачем вообще академический язык в прод тащить?

По примеру Шуклина же.

У меня с логикой всё очень хорошо! 😂 В частности, я понимаю, что если мне кричат "покажи пример", это меня всё равно ни к чему не обязывает. 😜 Кроме того, я отвечал на тезис о том, что знание математики не должно быть обязательным для программирования. Да, если это программирование сайтиков или игр - необязательно. Если разработка критических систем (авиация, космос, здравоохранение, энергетика), то должно.

зачем вообще академический язык в прод тащить?

У меня с логикой всё очень хорошо! 😂 В частности, я понимаю, что если мне кричат "покажи пример", это меня всё равно ни к чему не обязывает. 😜 Кроме того, я отвечал на тезис о том, что знание математики не должно быть обязательным для программирования. Да, если это программирование сайтиков или игр - необязательно. Если разработка критических систем (авиация, космос, здравоохранение, энергетика), то должно.