Погодите, а как это работает? Вода на выходе с мембран имеет более высокую концентрацию солей. Если её повторно пускать, то соли-то всё равно где-то доставать нужно.
Это довольно распространённое заблуждение, что оно всё обязательно нужно.
От того, что у вас была география, вы теперь можете называть столицы стран, куда никогда не поедете. При необходимости ту же информацию вы найдёте в мобильном телефоне. Если у вас нет мобильного телефона в кармане, у вас намного более серьёзные проблемы, чем отсутствие образования по географии.
Школьные знания биологии и анатомии практически бесполезны большинству людей: их не хватит, чтобы отличить фуфломицин от лекарства, а на наше мнение про экологию всё равно всем плевать.
С литературой вы можете выработать общий культурный код (мемы, которые существовали и до введения слова "мем") с другими людьми, тоже читавшими её. Если ваше окружение всё равно не распознает цитаты из "Мастера и Маргариты", или вы вообще не планируете общаться с людьми, это бесполезная трата времени.
Для черчения в 21 веке используется CAD.
Не видел ни одного учебника истории, в котором каждая фраза была бы подтверждена ссылками на первичные исторические данные, и неспроста: учебники по истории на 90% состоят из промывания мозгов в угоду политическому режиму страны, где они были выпущены. По Википедии в школе история не преподают.
Типичные алкоголик-трудовик и обжшник-прапор делают эти предметы в современной школе полностью бесполезными. Школ, где на трудах детей пускают к станкам, а на ОБЖ проводят практику по оказанию первой помощи, практически не осталось.
Не слышал ни разу о случаях, чтобы знания астрономии кому-то пригодились в жизни. Ну разве только с телескопом свиданки устраивать.
Русский, английский, математика, физика и химия у товарища были (хотя вы, кажется, этот список не заметили). Было бы неплохо почертить в CADах, поковырять ардуинки и станки, почитать какой-нибудь полезный худлит (Стругацких, Булычёва, Юдковского, например), поучить на нормальном уровне физиологию, но всё это школа предоставить сейчас не способна.
Давайте устроим минутку арифметики. В прошлом году БАК использовал 100% электроэнергии для разгона до 14 ТэВ, а в этом году они экономят электричество и используют только 80%. Значит, через 4 года БАК перестанет работать совсем.
А у нас-то другое дело: в прошлом году у нас нуклоны, допустим, не разгоняли совсем, а в этом разогнали аж до 3 ГэВ. Значит, через 4667 лет будем почти как БАК, а он там пусть все 4663 года простаивает.
Обеспечив процесс передачи сигнала от светодиода в нейрон, живую клетку, мы в будущем сможем создать связь с необходимым гаджетом
Кто-нибудь, дайте им уже доступ к зарубежным научным журналам. Уже были и передачи сигналов в нейроны (правда, не совсем родопсинами), и культуры человеческих клеток, которые выделяют инсулин по команде от фонарика на мобильном телефоне. Оптогенетика, блин, далеко шагнула.
Теперь у меня есть хороший аргумент почему Хаскелю не место в проде. Будем и дальше писать на более обычных языках. Где все проблемы производительности довольно очевидны.
Так Х-ь в продакшен тащить без надобности никто и не рекомендует. Посмотрите, где его большие компании используют.
Например, Github на нём сделал Semantic для эдакого IntelliSense, поддерживающего дофига языков. У них есть статейка "зачем хаскелл", в которой на много слов объясняется, что они бы на чём-то другом просто не смогли написать по причине большого количества букв. Гитхаб -- вполне бигдата.
Facebook'у нужно было разгребать тонны спама и прочего модерируемого контента, быстро модифицировать код под очередные хитрости спамеров и не ошибаться. Так нужно, что они автора рантайма Haskell наняли процессом руководить. Каждый пост на фейсбуке тоже звучит вполне как бигдата.
Другое дело, что если посмотреть, какой уровень профессионализма должен быть у людей, которые этим занимаются, сразу становится немного грустно.
Для того, чтобы этот вопрос не был при этом и сложным, достаточно просто указывать типы подобных байндингов.
О том же, блин, речь и шла, что вот такие детские грабли положены, и наступать на них ну очень неприятно.
Ну а возвращаясь к нашему исходному вопросу о пригодности х-ля для перекладывания жсонов — как часто при среднем перекладывании этих самых жсонов вам надо делать подобные Фибоначчи, завязывать узлы из двусвязных списков, и заниматься прочими непотребствами, где приходилось бы думать о том, что, когда и как именно будет вычисляться?
Как раз при перекладывании жсонов AST и наступал. Я лично считаю, что тут очень хорошее место для того, чтобы передизайнить язык.
Любой случай, когда у вас имплементация при вызове выбирается на основе типа, принято называть перегрузкой. Спор о терминах -- ну такое. Можно с тем же успехом утверждать, что Java -- не ООП, потому что в ней LSP не работает, или что Си -- функциональный язык, потому что там есть first-class function pointers. Эта казуистика на практике бессмысленна, и вам ничем не поможет.
Апелляции к авторитету — ну такое.
Ну да, апеллировать к автору тайпклассов и HaskellWiki нельзя. Их только неудачники читают, чтобы вас публично уязвить.
Ну, в смысле, я-то как раз понимаю, о чём говорю.
Хорошо, давайте по существу, если Даннинг и Крюгер не позволяют вам разобраться самостоятельно.
Когда тайпклассы имплементят через dictionary passing, получается проблемка: вещи, которые раньше были просто значениями, становятся функциями. Например, когда мы пишем
fib = 0 : 1 : zipWith (+) fib (tail fib)
и для него (гипотетически) выводится тип (Num a) => [a], то на самом деле получается
исполняющийся за экспоненциальное время. Собственно, об этом нам прямым текстом пишут в секции 4.5.5 стандарта языка, которую вы так и не удосужились прочесть.
С тех пор, конечно же, ребята догадались, что мономорфизация/инлайнинг, в общем-то, не сильно хуже, чем dictionary passing, разве только с полиморфной рекурсией не работают, и GHC сейчас компилирует код иначе.
Мемоизация (на самом деле, CAF, но неважно), кстати, довольно часто используется, чтобы гарантировать, что какой-то код исполнился не больше одного раза, и вопрос "не выведутся ли тут типы, которые превратят этот код в экспоненциальный" внезапно становится крайне важным.
Вам бы пришлось узнать, как оно там на самом деле работает, если бы попробовали всё-таки сфокусироваться на этом и написать хоть какой-то тривиальный производительный код. На практике это полезнее, чем разбираться в тонкостях Has.
Очевидно, в том месте, где инстансы матчатся по типу, а не в определении класса.
Тайпклассы — это такой сахарок для передачи словарей функций + алгоритм их разрешения
Это и называется перегрузкой. Вам бы надо обязательно попросить Simon Peyton Jones тоже использовать расово верные эпитеты, а то у него иногда проскакивает. От недостатка образования в ФП, наверное.
Зачем так сделано — действительно непонятно.
Вас не смущает, что чистота — она в, собственно, языке, а стейт (который не стейт, а на самом деле вывод не-most-general-type, который в этой решётке оказывается, удивительно, не единственным) — в движке вывода типов?
Вас не смущает, что вы вообще не представляете, о чём говорите? :)
Ознакомьтесь, пожалуйста, с матчастью хотя бы в haskellwiki и спилите мушку.
Так в Haskell и без Тьюринг-полноты оно недружелюбно. Без MPTC и FunDeps не типизируется и весьма простой код, а с ними как-то более хардкорно, чем хотелось бы ожидать от банальной перегрузки.
К счастью, есть -XNoMonomorphismRestriction
Но он же никак не решает коренную проблему: неявную мемоизацию, включаемую только чисто синтаксически. Вроде бы как язык чистый, а тут какой-то стейт появляется.
рассуждать о производительности в ФП вообще сложновато
Вообще практика показывает, что только в ФП и можно вообще о ней рассуждать, потому что как раз через equational reasoning можно выводить алгебраически (формализмом Бёрда-Меертенса, например) алгоритмы с лучшей асимптотикой, чем в спецификации, а без ФП можно только что-то эдакое наваять и понадеяться, что нигде нет ошибок.
Проблема только в конкретном сорте ФП, с нормальным порядком редукции, который меняет асимптотику от малейших правок и рандомно.
Затем, что новый большой проект на Rust будет компилироваться даже дольше С++, потому что ребята на голубом глазу накоммитили тайпчекер за квадрат от количества определений алгоритмом Робинсона. Именно это, например, не позволило использовать Rust в OpenBSD.
Да, там на первых порах случайно ввели в язык монады, а надо было вводить какие-нибудь эффекты, но тогда люди ещё не знали. И с ленивостью по умолчанию тоже вышло так себе. Ну и там с monomorphism restriction стрёмно немного. И в целом compile-type prolog в тайпклассах это немного не то, чем должен заниматься человек, которому нужно код в продакшен писать.
Зато во всех остальных отношениях Haskell элементарен и прост.
Вы мне напомнили, как в универе нам однажды выдали пример интерпретатора на Си. На таком древнем Си, что он уже даже компиляторами не компилируется. Там типы аргументов объявлялись между ) и {, например.
У стандартизаторов есть такая мысль, что алгоритмы должны работать одинаково во всех случаях. Например, есть более эффективные в обычных применениях алгоритмы сортировки, а ещё можно было бы специализировать сортировку на конкретные типы численные типы и сделать её на них за O(n), но в С++ намеренно сделано не так. Сделано это из соображений стабильности (чтобы не было внезапных лагов как в языках с GC) и безопасности (чтобы нельзя было подобрать предельный случай и поломать приложение).
CoW-строками, потребляют слишком рандомное время на ряд операций. Банальное обращение к элементу может в зависимости от имплементации быть O(log N) или O(N), хотя пользователь ожидает O(1). Именно это стреляет по ногам джаваскриптерам при работе со строками (это же совершенно очевидно, что их нужно сплитить в массив по одной букве перед тяжёлыми вычислениями). Именно поэтому их нет в стандартной библиотеке С++, и не будет.
В плюсах есть finally. Деструктор называется. При большом желании можно даже передавать лямбду в конструктор класса finally, и вызывать её в деструкторе. Более того, деструкторами пользуется приблизительно каждый контейнер в стандартной библиотеке.
А так вы, конечно, правы, и я не понимаю, что вам тут доказать пытаются.
Да я аж офигел, когда увидел, что TypeScript в 5 раз медленнее интерпретирует (?) тот же самый JS код на той же самой VM. Это ж как нагло надо врать статистикой, чтобы миллиону разработчиков говорить такое в лицо?
Погодите, а как это работает? Вода на выходе с мембран имеет более высокую концентрацию солей. Если её повторно пускать, то соли-то всё равно где-то доставать нужно.
Это довольно распространённое заблуждение, что оно всё обязательно нужно.
От того, что у вас была география, вы теперь можете называть столицы стран, куда никогда не поедете. При необходимости ту же информацию вы найдёте в мобильном телефоне. Если у вас нет мобильного телефона в кармане, у вас намного более серьёзные проблемы, чем отсутствие образования по географии.
Школьные знания биологии и анатомии практически бесполезны большинству людей: их не хватит, чтобы отличить фуфломицин от лекарства, а на наше мнение про экологию всё равно всем плевать.
С литературой вы можете выработать общий культурный код (мемы, которые существовали и до введения слова "мем") с другими людьми, тоже читавшими её. Если ваше окружение всё равно не распознает цитаты из "Мастера и Маргариты", или вы вообще не планируете общаться с людьми, это бесполезная трата времени.
Для черчения в 21 веке используется CAD.
Не видел ни одного учебника истории, в котором каждая фраза была бы подтверждена ссылками на первичные исторические данные, и неспроста: учебники по истории на 90% состоят из промывания мозгов в угоду политическому режиму страны, где они были выпущены. По Википедии в школе история не преподают.
Типичные алкоголик-трудовик и обжшник-прапор делают эти предметы в современной школе полностью бесполезными. Школ, где на трудах детей пускают к станкам, а на ОБЖ проводят практику по оказанию первой помощи, практически не осталось.
Не слышал ни разу о случаях, чтобы знания астрономии кому-то пригодились в жизни. Ну разве только с телескопом свиданки устраивать.
Русский, английский, математика, физика и химия у товарища были (хотя вы, кажется, этот список не заметили). Было бы неплохо почертить в CADах, поковырять ардуинки и станки, почитать какой-нибудь полезный худлит (Стругацких, Булычёва, Юдковского, например), поучить на нормальном уровне физиологию, но всё это школа предоставить сейчас не способна.
Великолепная статья. Так что же, всё-таки, делать с госзакупками? Почему в ЕС это работает, а у нас вот так вот?
Давайте устроим минутку арифметики. В прошлом году БАК использовал 100% электроэнергии для разгона до 14 ТэВ, а в этом году они экономят электричество и используют только 80%. Значит, через 4 года БАК перестанет работать совсем.
А у нас-то другое дело: в прошлом году у нас нуклоны, допустим, не разгоняли совсем, а в этом разогнали аж до 3 ГэВ. Значит, через 4667 лет будем почти как БАК, а он там пусть все 4663 года простаивает.
Кто-нибудь, дайте им уже доступ к зарубежным научным журналам. Уже были и передачи сигналов в нейроны (правда, не совсем родопсинами), и культуры человеческих клеток, которые выделяют инсулин по команде от фонарика на мобильном телефоне. Оптогенетика, блин, далеко шагнула.
Так Х-ь в продакшен тащить без надобности никто и не рекомендует. Посмотрите, где его большие компании используют.
Например, Github на нём сделал Semantic для эдакого IntelliSense, поддерживающего дофига языков. У них есть статейка "зачем хаскелл", в которой на много слов объясняется, что они бы на чём-то другом просто не смогли написать по причине большого количества букв. Гитхаб -- вполне бигдата.
Facebook'у нужно было разгребать тонны спама и прочего модерируемого контента, быстро модифицировать код под очередные хитрости спамеров и не ошибаться. Так нужно, что они автора рантайма Haskell наняли процессом руководить. Каждый пост на фейсбуке тоже звучит вполне как бигдата.
Другое дело, что если посмотреть, какой уровень профессионализма должен быть у людей, которые этим занимаются, сразу становится немного грустно.
О том же, блин, речь и шла, что вот такие детские грабли положены, и наступать на них ну очень неприятно.
Как раз при перекладывании
жсоновAST и наступал. Я лично считаю, что тут очень хорошее место для того, чтобы передизайнить язык.Любой случай, когда у вас имплементация при вызове выбирается на основе типа, принято называть перегрузкой. Спор о терминах -- ну такое. Можно с тем же успехом утверждать, что Java -- не ООП, потому что в ней LSP не работает, или что Си -- функциональный язык, потому что там есть first-class function pointers. Эта казуистика на практике бессмысленна, и вам ничем не поможет.
Ну да, апеллировать к автору тайпклассов и HaskellWiki нельзя. Их только неудачники читают, чтобы вас публично уязвить.
Хорошо, давайте по существу, если Даннинг и Крюгер не позволяют вам разобраться самостоятельно.
Когда тайпклассы имплементят через dictionary passing, получается проблемка: вещи, которые раньше были просто значениями, становятся функциями. Например, когда мы пишем
и для него (гипотетически) выводится тип
(Num a) => [a], то на самом деле получаетсяисполняющийся за экспоненциальное время. Собственно, об этом нам прямым текстом пишут в секции 4.5.5 стандарта языка, которую вы так и не удосужились прочесть.
С тех пор, конечно же, ребята догадались, что мономорфизация/инлайнинг, в общем-то, не сильно хуже, чем dictionary passing, разве только с полиморфной рекурсией не работают, и GHC сейчас компилирует код иначе.
Мемоизация (на самом деле, CAF, но неважно), кстати, довольно часто используется, чтобы гарантировать, что какой-то код исполнился не больше одного раза, и вопрос "не выведутся ли тут типы, которые превратят этот код в экспоненциальный" внезапно становится крайне важным.
Вам бы пришлось узнать, как оно там на самом деле работает, если бы попробовали всё-таки сфокусироваться на этом и написать хоть какой-то тривиальный производительный код. На практике это полезнее, чем разбираться в тонкостях
Has.Очевидно, в том месте, где инстансы матчатся по типу, а не в определении класса.
Это и называется перегрузкой. Вам бы надо обязательно попросить Simon Peyton Jones тоже использовать расово верные эпитеты, а то у него иногда проскакивает. От недостатка образования в ФП, наверное.
Вас не смущает, что вы вообще не представляете, о чём говорите? :)
Ознакомьтесь, пожалуйста, с матчастью хотя бы в haskellwiki и спилите мушку.
Так в Haskell и без Тьюринг-полноты оно недружелюбно. Без MPTC и FunDeps не типизируется и весьма простой код, а с ними как-то более хардкорно, чем хотелось бы ожидать от банальной перегрузки.
Но он же никак не решает коренную проблему: неявную мемоизацию, включаемую только чисто синтаксически. Вроде бы как язык чистый, а тут какой-то стейт появляется.
Вообще практика показывает, что только в ФП и можно вообще о ней рассуждать, потому что как раз через equational reasoning можно выводить алгебраически (формализмом Бёрда-Меертенса, например) алгоритмы с лучшей асимптотикой, чем в спецификации, а без ФП можно только что-то эдакое наваять и понадеяться, что нигде нет ошибок.
Проблема только в конкретном сорте ФП, с нормальным порядком редукции, который меняет асимптотику от малейших правок и рандомно.
Затем, что новый большой проект на Rust будет компилироваться даже дольше С++, потому что ребята на голубом глазу накоммитили тайпчекер за квадрат от количества определений алгоритмом Робинсона. Именно это, например, не позволило использовать Rust в OpenBSD.
Да, там на первых порах случайно ввели в язык монады, а надо было вводить какие-нибудь эффекты, но тогда люди ещё не знали. И с ленивостью по умолчанию тоже вышло так себе. Ну и там с monomorphism restriction стрёмно немного. И в целом compile-type prolog в тайпклассах это немного не то, чем должен заниматься человек, которому нужно код в продакшен писать.
Зато во всех остальных отношениях Haskell элементарен и прост.
В коболах есть!
Ха, а вы попробуйте после этого собрать какой-нибудь проект на Node.js!
Вы мне напомнили, как в универе нам однажды выдали пример интерпретатора на Си. На таком древнем Си, что он уже даже компиляторами не компилируется. Там типы аргументов объявлялись между ) и {, например.
Есть даже широкоизвестный закон Проебстинга: компиляторы увеличивают производительность кода в два раза каждые 18 лет.
Использование С++ не имеет никакого смысла, если размер задач не подразумевает миллионные убытки на электроэнергию и вычислительные мощности.
У стандартизаторов есть такая мысль, что алгоритмы должны работать одинаково во всех случаях. Например, есть более эффективные в обычных применениях алгоритмы сортировки, а ещё можно было бы специализировать сортировку на конкретные типы численные типы и сделать её на них за O(n), но в С++ намеренно сделано не так. Сделано это из соображений стабильности (чтобы не было внезапных лагов как в языках с GC) и безопасности (чтобы нельзя было подобрать предельный случай и поломать приложение).
CoW-строками, потребляют слишком рандомное время на ряд операций. Банальное обращение к элементу может в зависимости от имплементации быть O(log N) или O(N), хотя пользователь ожидает O(1). Именно это стреляет по ногам джаваскриптерам при работе со строками (это же совершенно очевидно, что их нужно сплитить в массив по одной букве перед тяжёлыми вычислениями). Именно поэтому их нет в стандартной библиотеке С++, и не будет.
В плюсах есть finally. Деструктор называется. При большом желании можно даже передавать лямбду в конструктор класса finally, и вызывать её в деструкторе. Более того, деструкторами пользуется приблизительно каждый контейнер в стандартной библиотеке.
А так вы, конечно, правы, и я не понимаю, что вам тут доказать пытаются.
Да я аж офигел, когда увидел, что TypeScript в 5 раз медленнее интерпретирует (?) тот же самый JS код на той же самой VM. Это ж как нагло надо врать статистикой, чтобы миллиону разработчиков говорить такое в лицо?
O(n^n) это факториал. Может, там разные порядки чего-то перебираются, кто их знает.