Трёхточечные ремни безопасности были разработаны и впервые внедрены в серийное производство в Volvo. А до этого из-за неудобства использования ремни в серийных авто практически не применялись.
Не могу сказать про Китай, но в европейской пивной традиции хмель появился далеко не сразу. Очень долгое время его заменяли разные наборы трав. В общем, и сейчас, если поискать можно найти грюйт — эль, в где травы используются вместе с или вместо хмеля.
Стоит начать с того, что АТД были созданы не только для возврата значений. Я даже думаю, что об этом вообще не думали, эта возможность получилась вполне естественно вытекающим из системы типов образом. В отличие, кстати, от возможности возврата нескольких значений, которую в любом случае надо было явно заложить в язык.
Более того, АТД легко и просто позволяют кодировать 2 взаимоисключающих значения (именно поэтому они disjoint), то, что нужно, когда нам нужно вернуть значение или причину, по которой его вычисление не удалось. Вы же предлагаете всегда возвращать N значений, которые, чаще всего, взаимоисключающие, помечая отсутствие специальным значением. Согласитесь, что отсутствие значения (когда мы возвращаем одно значение, другого у нас просто нет, оно не null, не nil; оно отсутствует и взять его не откуда) и специальное значение, которое по договорённости означает отсутствие этого самого значения — вещи несколько различающиеся (не говоря уже о том, что второе вообще звучит, как бред).
Я, кажется, каким-то отличным от вас образом понимаю значение слова «костыль».
По-моему, lair под union type имел в виду не то, что вы подумали, а тип-сумму (в том смысле, в котором это понимает теория типов), или алгебраический тип данных. На Haskell это будет выглядеть примерно так
data Maybe a = Just a | Nothing
parseInt :: String -> Maybe Int
parseInt s = ...
Эта запись как раз и значит, что значение этого типа — это или одно (Just a), или другое (Nothing, ничего). Option[A] в Scala работает ровно так же. И никаких toString и прочей ерунды. Если нас интересует не просто отсутствие значения, а какая-то индикация в случае, когда значения нет (ошибка), существует тип Either, который можно параметризовать типами успешного и неуспешного результата (хотя в данном случае они абсолютно равнозначны, есть просто соглашение).
Большое преимущество такого подхода в том, что за правильностью обращения с этими типами следит тайпчекер, а не какой-то линтер, предупреждения которого, в общем-то, можно и проигнорировать. Он же и следит за тем, что мы рассмотрим в конечном итоге все варианты, которые могла вернуть функция (и Just, и Nothing). Никакой динамической типизации это и не снилось.
Заметьте, функция не начинает возвращать несколько значений (если вам так хочется, вы, конечно, можете воспользоваться типом-произведением, иначе кортежем, но технически это будет всё равно одно значение). Не надо изобретать велосипед, эти вещи вполне себе известны давным давно и успешно применяются. Другое дело, что это всё тянет за собой параметрический полиморфизм, сопоставление с образцом, часто нормальную композицию функций, и вообще размышления о компонуемости примитивов в языке. Конечно, проще вернуть два значения (а если захочется 3? какое из них будет ошибкой?), и объявить всё остальное не нужным.
И раз уж вы так уверены, что возврат ошибки превращает чистую функцию в нечистую, расскажите мне, нужна ли коммутация с внешним миром парсеру? Ведь для одного и того же входа с синтаксический ошибкой он будет возвращать всегда одну и ту же ошибку, а для одного и того же верного входа — всегда одно и то же AST?
Ничего не делают. Я ниже запостил фотографию. Пиво просто выливают в ёмкость с большой поверхностью, где оно проводит ночь, обогощаясь дикими микроогранизмами. Дрожжи, которые нужны для ламбиков, водятся только в Бельгии (по крайней мере, ничего другого я не слышал).
Что касается того крика, что вы пили, это, вероятно, был ещё и не вполне настоящий ламбик (о котором идёт речь в статье), а его коммерциализированная версия. Не мудрено, потому что настоящие ламбики очень кислые, это пиво на большого любителя. Но легенды хорошо продают товар, не удивительно, что этим пользуются. Поэтому у нас много коммерческих «ламбиков» (как их производят, если честно, одному богу известно), и почти нельзя найти те самые. Хотя с недавних пор в Питере сравнительно нетрудно найти продукцию пивоварни Boon, к примеру. Как с этим обстоит в Белорусии, я сказать не могу.
Был на этой пивоварне. На мой вкус, у них лучшие ламбики в Бельгии. Жаль будет лишаться такого пива (это ведь касается не только Cantillon, но и Boon и других), хотя запасы, конечно, не моментально иссякнут.
Что вы понимаете под словом «эффективность»? Вы его употребляете в разных контекстах несколько раз.
Параллелизм и конкурентность, действительно, вещи не эквивалентные. Erlang, например, про конкуретность (но, вроде как, Go с ним соперничает в этом). И тут же можно сразу поговорить о том, как работает планировщик в Erlang и в Go. У первого он обеспечивает действительно настоящюю вытесняющую многозадачность, чётко отводя процессам лимит времени (если быть совсем точно, то лимит инструкций) и переключая процессы по достижению этого лимита или раньше (но не позже!). Это обеспечивает невероятную плавность планирования (в купе с механизмами work stealing и настраиваемыми стратегиями распределения работы по планировщикам). Да, ценой некоторой потери в производительности (всё-таки виртуальная машина), но ведь тут речь про регулирование конкуретного доступа к ресурсам, а не числодробление. Я когда год назад искал информацию по тому, как именно работает планировщик в Go, не нашёл ничего, кроме упоминания, что переключение осуществляется на вызовах в runtime. Понятно, что на компилируемом в native-код языке трудно сделать честную вытесняющую многозадачность лёгких потоков, но это так же ставит вопрос, где всё-таки concurrency сделана эффективнее.
Что касается наброса про параллелизм в Haskell, опять же, без определения слова «эффективность» это можно было бы оставить без внимания. Но я просто немного понедоумеваю. Haskell компилируется ровно в тот же самый native-код, что и Go. Треды ОС под планировщиком там ровно такие же. И ровно так же он способен параллельно выполнять код (именно параллельно, до стадии, пока не доделаю, а не пока не попросят освободить ядро). Инструменты для анализа есть. Книга, как делать правильно тоже есть. Где мне этот параллелизм кажется и где отсутствие практических достижений, объясните, пожалуйста?
Фиговый из теслы спорткар. У динамика тухнет после достижения скорости в 100 км/ч. В итоге что имеем:
1. Кузов не как у спорткара, а казалось бы вполне практичный лифтбэк. Но при этом в салоне всё сосредоточено на том, чтобы показать, что мы не как все: нет центрального тоннеля, нет кнопок (один большой сенсорный экран). То, что при этом существенно нивелируется удобство использования автомобиля как такового, это, почему-то, Теслу не волнует.
2. Цифры разгона до сотни радуют, но что потом? Получается какой-то светофорный спорткар: в городе всех унизили (где мощность и динамика не шибко важны), на трассе сдулись (где как раз и нужна скорость и мощность).
Получается, Tesla больше похожа на дорогущую игрушку (которая, кстати, особенным качеством не радует за свои деньги), чем на настоящий спорткар. А в Европе люди практичные. Наиграются сейчас и успокоятся. В BMW, например, всё правильно сделали. Их i-линейка гораздо больше соответствует тому, что европейцы ждут от машины.
Ну это все отчасти правда же, конечно. На дешевых двигателях, где нет ни фазовращателей, ни какого-нибудь valve lift, да ещё и цепной привод, конечно, обычно ничего не ломается. Но ведь нельзя же сравнивать безотказность отложенной технологии с вероятным трудностями при запуске новой. Тем более, что я слышал рассказы про то, как у vw порвало ремень ГРМ или у BMW растянулась цепь и оп — клапаны обниматься с поршнем (то есть в реальной жизни преимущества вроде как и нет такого огромного). С одной стороны, тут, конечно, сам по себе ГРМ не при чем. С другой стороны такой соблазн сэкономить. А механизмы подъема клапанов или деактивации цилиндров вообще ни у одного производителя не вызывают ощущения монументальной надёжности (а в free valve они для реализации вообще ничего дополнительно не требуют).
Тут ведь какая вещь: këonigsegg этим уже очень долго занимается (около 10 лет). ЕМНИП, в лаборатории уже 5-я версия системы. Конечно, как и любая новая технология, при реальном запуске потребует к себе повышенного внимания. Но в том-то и дело, что она вроде как довольно проста (гораздо проще DSG), чтобы сильно много не огрести, и при этом настолько многообещающая, чтобы с ней имело смысл связываться. А DSG, при всех недостатках, все же очень хорошо везет.
Тем временем, у ДВС действительно близится если не прорыв, то довольно существенное улучшение. Këonigsegg готовит к коммерческому применению технологию free valve: клапаны с электромагнитным приводом. Что это означает на практике. Во-первых, полностью уходит потребность во всем ГРМ (с его дорогущими фазовращателями и механизмами регулировки подъема клапанов). Мало того, что это вообще сильно упрощает конструкцию двигателя (а значит повышает его надежность), оно ещё и уменьшает механические потери, повышая эффективность (хоть и не очень сильно). Во-вторых, это позволяет отказаться от дроссельной заслонки. В-третьих, это позволяет бесступенчато и в широких пределах регулировать время открывания-закрывания и величину подъема клапанов. В-четвертых, позволяет вернуться от прямого к распределённому впрыску. Все пункты прямым образом влияют на эффективность двс (при этом упрощая его конструкцию, чего при всех последних улучшениях не происходило), так что порох еще есть.
Существуют. Но как и в вашем примере (некоторые языки не очень-то разделяют виртуальные и невиртуальные функции), правила во многом применимы только к конкретному языку. Например, для Haskell обычным советом (настоятельной рекомендацией) является не изобретать велосипед и не писать явную рекурсию самому, а воспользоваться функциями наподобие fold(l/r)/map/filter и т.п. В Erlang же наоборот, чаще гораздо лучше воспользоваться list comprehension, чем lists:map, потому что для первого компилятор генерирует гораздо более эффективный код. Опять же, из рекомендаций для Haskell, в структурах данных делать поля строгими (чтобы не копить thunk-и), но так как распространённых ленивых языков, кроме Haskell нет, то эту рекомендацию трудно представить применимой для каких-либо ещё функциональных языков.
В любом случае, мне кажется, что пример вы приводите не вполне корректный в рамках общей канвы обсуждения. Вы предлагаете оптимизировать ООП путём отказа от ООП.
Оператор!!! возвращает элемент списка по его номеру (в данном случает n-й элемент). Список fibs — бесконечный список чисел фибоначчи, который мы определяем следующим образом. Первые два элемента — это 0 и 1 (тут должно быть очевидно), а все последующие элементы получаются комбинированием (а именно, сложением; комбинирование осуществляет функция zipWith с помощью своего первого аргумента) самого списка fibs (т.е. 0,1,...) и его хвоста (tail; хвост списка получается откусыванием первого элемента, головы; т.е. 1,...).
Такое проходит только потому, что хаскелль — ленивый язык, и он не вычисляет весь список целиком (если не предпринимать дополнительных телодвижений).
В той же альфе категорию можно отредактировать и, вроде бы, это запоминается (хотя, это приходится делать всё реже, может как раз потому, что обучается), и внесение наличных расходов там тоже есть.
Более того, АТД легко и просто позволяют кодировать 2 взаимоисключающих значения (именно поэтому они disjoint), то, что нужно, когда нам нужно вернуть значение или причину, по которой его вычисление не удалось. Вы же предлагаете всегда возвращать N значений, которые, чаще всего, взаимоисключающие, помечая отсутствие специальным значением. Согласитесь, что отсутствие значения (когда мы возвращаем одно значение, другого у нас просто нет, оно не null, не nil; оно отсутствует и взять его не откуда) и специальное значение, которое по договорённости означает отсутствие этого самого значения — вещи несколько различающиеся (не говоря уже о том, что второе вообще звучит, как бред).
Я, кажется, каким-то отличным от вас образом понимаю значение слова «костыль».
Эта запись как раз и значит, что значение этого типа — это или одно (Just a), или другое (Nothing, ничего). Option[A] в Scala работает ровно так же. И никаких toString и прочей ерунды. Если нас интересует не просто отсутствие значения, а какая-то индикация в случае, когда значения нет (ошибка), существует тип Either, который можно параметризовать типами успешного и неуспешного результата (хотя в данном случае они абсолютно равнозначны, есть просто соглашение).
Большое преимущество такого подхода в том, что за правильностью обращения с этими типами следит тайпчекер, а не какой-то линтер, предупреждения которого, в общем-то, можно и проигнорировать. Он же и следит за тем, что мы рассмотрим в конечном итоге все варианты, которые могла вернуть функция (и Just, и Nothing). Никакой динамической типизации это и не снилось.
Заметьте, функция не начинает возвращать несколько значений (если вам так хочется, вы, конечно, можете воспользоваться типом-произведением, иначе кортежем, но технически это будет всё равно одно значение). Не надо изобретать велосипед, эти вещи вполне себе известны давным давно и успешно применяются. Другое дело, что это всё тянет за собой параметрический полиморфизм, сопоставление с образцом, часто нормальную композицию функций, и вообще размышления о компонуемости примитивов в языке. Конечно, проще вернуть два значения (а если захочется 3? какое из них будет ошибкой?), и объявить всё остальное не нужным.
И раз уж вы так уверены, что возврат ошибки превращает чистую функцию в нечистую, расскажите мне, нужна ли коммутация с внешним миром парсеру? Ведь для одного и того же входа с синтаксический ошибкой он будет возвращать всегда одну и ту же ошибку, а для одного и того же верного входа — всегда одно и то же AST?
Что касается того крика, что вы пили, это, вероятно, был ещё и не вполне настоящий ламбик (о котором идёт речь в статье), а его коммерциализированная версия. Не мудрено, потому что настоящие ламбики очень кислые, это пиво на большого любителя. Но легенды хорошо продают товар, не удивительно, что этим пользуются. Поэтому у нас много коммерческих «ламбиков» (как их производят, если честно, одному богу известно), и почти нельзя найти те самые. Хотя с недавних пор в Питере сравнительно нетрудно найти продукцию пивоварни Boon, к примеру. Как с этим обстоит в Белорусии, я сказать не могу.
Параллелизм и конкурентность, действительно, вещи не эквивалентные. Erlang, например, про конкуретность (но, вроде как, Go с ним соперничает в этом). И тут же можно сразу поговорить о том, как работает планировщик в Erlang и в Go. У первого он обеспечивает действительно настоящюю вытесняющую многозадачность, чётко отводя процессам лимит времени (если быть совсем точно, то лимит инструкций) и переключая процессы по достижению этого лимита или раньше (но не позже!). Это обеспечивает невероятную плавность планирования (в купе с механизмами work stealing и настраиваемыми стратегиями распределения работы по планировщикам). Да, ценой некоторой потери в производительности (всё-таки виртуальная машина), но ведь тут речь про регулирование конкуретного доступа к ресурсам, а не числодробление. Я когда год назад искал информацию по тому, как именно работает планировщик в Go, не нашёл ничего, кроме упоминания, что переключение осуществляется на вызовах в runtime. Понятно, что на компилируемом в native-код языке трудно сделать честную вытесняющую многозадачность лёгких потоков, но это так же ставит вопрос, где всё-таки concurrency сделана эффективнее.
Что касается наброса про параллелизм в Haskell, опять же, без определения слова «эффективность» это можно было бы оставить без внимания. Но я просто немного понедоумеваю. Haskell компилируется ровно в тот же самый native-код, что и Go. Треды ОС под планировщиком там ровно такие же. И ровно так же он способен параллельно выполнять код (именно параллельно, до стадии, пока не доделаю, а не пока не попросят освободить ядро). Инструменты для анализа есть. Книга, как делать правильно тоже есть. Где мне этот параллелизм кажется и где отсутствие практических достижений, объясните, пожалуйста?
1. Кузов не как у спорткара, а казалось бы вполне практичный лифтбэк. Но при этом в салоне всё сосредоточено на том, чтобы показать, что мы не как все: нет центрального тоннеля, нет кнопок (один большой сенсорный экран). То, что при этом существенно нивелируется удобство использования автомобиля как такового, это, почему-то, Теслу не волнует.
2. Цифры разгона до сотни радуют, но что потом? Получается какой-то светофорный спорткар: в городе всех унизили (где мощность и динамика не шибко важны), на трассе сдулись (где как раз и нужна скорость и мощность).
Получается, Tesla больше похожа на дорогущую игрушку (которая, кстати, особенным качеством не радует за свои деньги), чем на настоящий спорткар. А в Европе люди практичные. Наиграются сейчас и успокоятся. В BMW, например, всё правильно сделали. Их i-линейка гораздо больше соответствует тому, что европейцы ждут от машины.
Тут ведь какая вещь: këonigsegg этим уже очень долго занимается (около 10 лет). ЕМНИП, в лаборатории уже 5-я версия системы. Конечно, как и любая новая технология, при реальном запуске потребует к себе повышенного внимания. Но в том-то и дело, что она вроде как довольно проста (гораздо проще DSG), чтобы сильно много не огрести, и при этом настолько многообещающая, чтобы с ней имело смысл связываться. А DSG, при всех недостатках, все же очень хорошо везет.
В любом случае, мне кажется, что пример вы приводите не вполне корректный в рамках общей канвы обсуждения. Вы предлагаете оптимизировать ООП путём отказа от ООП.
zipWithкомбинирует все соответсвующие элементыПоскольку
fibs— бесконечный список,(tail fibs)— тоже бесконечный список. Вот мы и комбинируме два бесконечных списка поэлементно.Такое проходит только потому, что хаскелль — ленивый язык, и он не вычисляет весь список целиком (если не предпринимать дополнительных телодвижений).