я сахар и все прочие вещи как раз из него в стандарт и идут

Когда я говорю про знание С++ я имею в виду не только синтаксис и стандартную бибилиотеку.

ну я конечно не сахар)

но ты понял

я сахар и все прочие вещи как раз из него в стандарт и идут

Это неправда.

нужно очень хорошо знать boost

Это тоже неправда, но вопрос мой совсем не об этом.

смотря какой уровень компании в которой ты работаешь

в любой более менее серьезной boost обязателен

что-то холиварчик развели

хочешь сделать что-то на хаскель на скорую руку можно посмотреть в сторону веба

а хочешь действительно ощутить мощь хаскеля

в любой более менее серьезной boost обязателен

О. Чат по Хаскелю! Круто.

реализуй или посмотри как реализованы функциональные абстракции в с++

и ужаснись)

Я хорошо себе представялю как они реализованы. И вопрос опять же не об этом был. Но после пассажей про boost, я твоим словам перестаю доверять, извини.

Сравнивать C++ и haskell... Я вернулся в 2013?

Пробовал написать бекенд на плюсах?

Зря я вообще упомянул про C++, меня не интересует именно сравнение.

Пробовал написать бекенд на плюсах?

Не просто пробовал, а написал и даже не один.

Угу. Я тогда продолжать разговор не буду, какой имеет смысл дискуссия с людьми, которые придумывают заслуги? Я сотворил этот мир тогда

Придумывают?

Но это правда. Я С++ программист. Далеко не первый год.

Угу. Я тогда продолжать разговор не буду, какой имеет смысл дискуссия с людьми, которые придумывают заслуги? Я сотворил этот мир тогда

жирновато чет

Все яп не оч, давно же договорились

Но это правда. Я С++ программист. Далеко не первый год.

Ну если бы ты был C++ программистом, то писал бы библиотеки, десктопный софт, системный софт. Что угодно, только не бекенд

Я скорее вот о чём. В Питоне например есть такая приятная фича, которой в других языках нет, множественное присваивание при возврате из функции например a,b = range(2)

Ну если бы ты был C++ программистом, то писал бы библиотеки, десктопный софт, системный софт. Что угодно, только не бекенд

Это блин серьёзно?

синтаксический сахар?

Ну если бы ты был C++ программистом, то писал бы библиотеки, десктопный софт, системный софт. Что угодно, только не бекенд

куча бекенда для игрушек написано на с++

Ну если бы ты был C++ программистом, то писал бы библиотеки, десктопный софт, системный софт. Что угодно, только не бекенд

Я писал всё перечисленное. Бекенды совсем не исключение.

Я писал всё перечисленное. Бекенды совсем не исключение.

товарищ не знает что несет (

Я скорее вот о чём. В Питоне например есть такая приятная фича, которой в других языках нет, множественное присваивание при возврате из функции например a,b = range(2)

Бля, я пишу на питоне каждый день, это далеко не киллер-фича питона

товарищ не знает что несет (

Видимо да, или он думает, что фейсбук, гугл или яндекс бекенд написан НЕ на С++.

куча бекенда для игрушек написано на с++

Для каких ещё игрушек? Ага, nodejs-плюсостек

Видимо да, или он думает, что фейсбук, гугл или яндекс бекенд написан НЕ на С++.

В фейсбуке бекенд написан на php

Для каких ещё игрушек? Ага, nodejs-плюсостек

для чуть менее чем всех ААА тайтлов например )

Бля, я пишу на питоне каждый день, это далеко не киллер-фича питона

Я понимаю, это был пример сахара, который может привлечь новичка.

Я скорее вот о чём. В Питоне например есть такая приятная фича, которой в других языках нет, множественное присваивание при возврате из функции например a,b = range(2)

В Haskell есть паттерн-мэтчинг. Можно написать эквивалетный аналог. Только вместо абстрактного перечисления переменных через запятую ты явно указываешь структуру, из которой были получены объекты let [a, b] = [1..2]

фейсбук на пхп. У яндекса поиск вроде на плюсах

В фейсбуке бекенд написан на php

Ага. Про folly никогда не слышали?

Так поиск это и не бекенд нихуя, это системный софт

Так поиск это и не бекенд нихуя, это системный софт

чет ты изворачиваться начал )

о, я на самом деле не знаю, что такое бэкенд

Чо? Вы вообще понимаете, что такое бекенд?

ща нам расскажут что это такое

пацаны, слушаем гуру

Так поиск это и не бекенд нихуя, это системный софт

Это вопрос терминологии, но даже если и так, непосредственно код, который генерирует ответ web-клиенту на c++ пишут, и я в том числе писал.

В Haskell есть паттерн-мэтчинг. Можно написать эквивалетный аналог. Только вместо абстрактного перечисления переменных через запятую ты явно указываешь структуру, из которой были получены объекты let [a, b] = [1..2]

Спасибо, это ценный ответ.

Это вопрос терминологии, но даже если и так, непосредственно код, который генерирует ответ web-клиенту на c++ пишут, и я в том числе писал.

Скажи где, пойду увеличу свой ботнет, лiл

Мне нужны еще такие фичи. Паттерн матчинга в плюсах нет. Это очень выразительный инструмент.

Что еще?

+- есть в плюсах. На шаблонах, некрасиво, но есть.

Стек монад

Вывод кайндов :3

Не то же, но в каком-то виде метапрограммирование есть.

Стек монад

Это уже относится к самому языку больше.

Это просто то, как пишут на Хаскелле, нежели чем какая-то его оригинальная задумка.

List comprehension например, тоже очень приятная и выразительная вещь.

Неа, стек монад напрямую связан с call-by-need

Я понимаю, но я говорю сейчас про то, что применимо к языкам с eager evalutaion.

Собственно call-by-need это киллер-фича, ни в одном другом продакшн языке его нет

Что еще?

Вещь, которая идёт рука об руку с паттерн-мэтчингом -- алгебраические типы данных. Или же tagged union. В С++ есть обычный union, который для других целей. Но это очень полезная вещь в языке. Она очень хорошо помогает структурировать программу, потому что ты буквально средствами языка делаешь декомпозицию -- разбиваешь на на случаи и обрабатываешь каждый случай параллельно. Что-нибудь базовое: data Either a b = Left a | Right b После программирования на Haskell очень трудно привыкать к менее удобным вариантам, когда функция может вернуть либо одно либо другое. Что-то менее тривиального из недавного: Size тип данных в библиотеке сериализации store data Size a = ConstSize Int | VarSize (a -> Int) Размер объекта может быть либо константным (для оптимизаций полезно) либо переменным. Дополнительным бонусом идёт то, что компилятор проверяет все паттерны на exhaustiveness. То есть на этапе компиляции можно быть уверенным, что реально все случаи обработаны. Это очень удобно, когда код рефакторится и добавляются новые случаи (правда, к сожалению, код можно написать так, что пользы от этой фичи именно в таком случае с рефакторингом не будет :( )

Собственно call-by-need это киллер-фича, ни в одном другом продакшн языке его нет

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

Вещь, которая идёт рука об руку с паттерн-мэтчингом -- алгебраические типы данных. Или же tagged union. В С++ есть обычный union, который для других целей. Но это очень полезная вещь в языке. Она очень хорошо помогает структурировать программу, потому что ты буквально средствами языка делаешь декомпозицию -- разбиваешь на на случаи и обрабатываешь каждый случай параллельно. Что-нибудь базовое: data Either a b = Left a | Right b После программирования на Haskell очень трудно привыкать к менее удобным вариантам, когда функция может вернуть либо одно либо другое. Что-то менее тривиального из недавного: Size тип данных в библиотеке сериализации store data Size a = ConstSize Int | VarSize (a -> Int) Размер объекта может быть либо константным (для оптимизаций полезно) либо переменным. Дополнительным бонусом идёт то, что компилятор проверяет все паттерны на exhaustiveness. То есть на этапе компиляции можно быть уверенным, что реально все случаи обработаны. Это очень удобно, когда код рефакторится и добавляются новые случаи (правда, к сожалению, код можно написать так, что пользы от этой фичи именно в таком случае с рефакторингом не будет :( )

Да, алгебраическиый типы данных, точно. Спасибо.

Вопрос вот какой, правда ли, что на этапе компиляции не всегда известен настоящий тип в сумме, и поэтому это уходит в рантайм?

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

Нельзя вообще никак. У тебя должно быть чистое ядро языка, что call-by-need применить. Надо изолировать эффекты -- либо с помощью монад, либо линейных типов (или их вариаций)

Я скорее вот о чём. В Питоне например есть такая приятная фича, которой в других языках нет, множественное присваивание при возврате из функции например a,b = range(2)

В golang

Нельзя вообще никак. У тебя должно быть чистое ядро языка, что call-by-need применить. Надо изолировать эффекты -- либо с помощью монад, либо линейных типов (или их вариаций)

Именно это я и имел в виду. И разумеется это можно сделать, если придерживаться определённых правил написания программы.

Вопрос вот какой, правда ли, что на этапе компиляции не всегда известен настоящий тип в сумме, и поэтому это уходит в рантайм?

Неправда. Если у тебя вывод типов не может завершится, то компилятор попадёт в инфинити луп

Я скорее вот о чём. В Питоне например есть такая приятная фича, которой в других языках нет, множественное присваивание при возврате из функции например a,b = range(2)

const { a, b } = range(2) es2015+

Неправда. Если у тебя вывод типов не может завершится, то компилятор попадёт в инфинити луп

Нет, я не об этом. У меня конкретный тип может быть известен в рантайме, только.

Именно это я и имел в виду. И разумеется это можно сделать, если придерживаться определённых правил написания программы.

И что ты делать с этим кодом будешь? Если компилятор языка и рантайм не умеет в редукцию графов, но она работать и не будет. Плюс надо подчинить ей все эффекты, что в грязном языке практически невозможно. Да, реально сделать ленивую функцию, но смысл хацкеля именно во всеохватывающем call-by-need

Нет, я не об этом. У меня конкретный тип может быть известен в рантайме, только.

Не может. Все типы должны быть выведены

Тогда я не понимаю.

У меня есть Maybe

Я пишу код для обеих веток.

Само значение получаю из IO

Откуда компилятор заранее знает, какая из веток сработает?

Ему надо скомпилировать обе и где-то оставить место для рантайм информации о том, Just у меня или Nothing

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

Как Хаскелль с этим справляется?

IO тоже имеет тип

Вопрос вот какой, правда ли, что на этапе компиляции не всегда известен настоящий тип в сумме, и поэтому это уходит в рантайм?

разумеется

О, привет.

привет)

Да, я понимаю, что иначе и быть не может, вопрос в том, элиминирует ли Хаскелль эту информацию, если может?

если в результате IO приходят какие-то данные, сразу оговаривается их тип. На этапе компиляции этот тип учитывается

если в результате IO приходят какие-то данные, сразу оговаривается их тип. На этапе компиляции этот тип учитывается

вопрос не про это, вопрос в том, может ли ghc оптимизировать ситуации, когда в compile-time точно известно, какой именно конструктор алгебраического типа используется

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

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

тогда в компайл тайме при использовании этой библиотеки может быть выброшена ветка для Int. Так?

тогда в компайл тайме при использовании этой библиотеки может быть выброшена ветка для Int. Так?

да

я думаю, что можно это контролировать флагами оптимизации

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

скажем так. Я обычно для себя все перевожу на С. Или в данном случае на плюсы. Есть библиотека с перегруженной функцией, которая может принимать инт или стринг. Или может темплейт - и две функции. Суть та же. Если я линкуюсь с этой либой статически, линкер подхватит только одну из двух версий. Если динамически - останутся обе, но используется только одна.