Здравствуйте, e.thrash, Вы писали:
ET>Прошло время с его появления. ET>Немерле2 или же взлетает?
На сколько мог, на столько взлетел. Сейчас ситуация с ним невнятная, его развитие после релиза резко затормозилось, судя по всему JetBrains делают ставку на Kotlin Native, но когда он будет готов, непонятно. В целом хороший язык, лучше Java, если разрабатывать для JVM, смысла его не использовать я не вижу. Насчёт перспектив пока непонятно. Надеюсь, разродятся этим native и начнут улучшать язык, там ещё есть, что улучшать.
For the third year in a row, Rust is the most loved programming language among our respondents, followed close behind by Kotlin, a language we asked about for the first time on our survey this year. This means that proportionally, more developers want to continue working with these than other languages.
S>For the third year in a row, Rust is the most loved programming language among our respondents, followed close behind by Kotlin, a language we asked about for the first time on our survey this year. This means that proportionally, more developers want to continue working with these than other languages.
S>Поциент скорее жив...
интересно что больше всего платят за фшарп. где только это есть непонятно
Здравствуйте, e.thrash, Вы писали:
ET>Прошло время с его появления. ET>Немерле2 или же взлетает?
Котлин нашел нишу — разработка для девайсов (телефоны/планшеты). Гугль и (если не ошибаюсь) Эппл признали его первоклассным языком разработки. У Гугла в доках примеры дублируются на котлине. В следующих релизах обещали, что даже тормозить не будет.
С Немерл 2 все банально просто. Нужно бабло. Работы там много. По часу в день это и за 100 лет не сделаешь. Присоеденяйтесь и дело пойдет быстрее. За одно меня подбодрите.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>Нету никаких приложений на Kotlin. Всё.
На самом деле предложения есть. Знаю конторы, которые на нем пишут, лично собеседовался в одну такую контору. Куча кандидатов у которых в резюме стоит Kotlin (хотя, это мы специально сказали посылать резюме таких). Очень активно используется в разработке под андроид, за счет чего и взлетел.
Если что, на рынке есть вакансии даже для Common Lisp. И достаточное количество кандидатов. Про clojure вообще молчу — чуть ли не мейнстрим.
Если у кандидата есть опыт реальной разработки на относительно экзотическом языке — это однозначно плюс 10 к его шансом быть как минимум приглашенным на собеседование в конторы, которые занимаются чем поинтереснее чем формошлепством и саппортом кода черти скольки летней давности.
Дополнительно — куча вакансий экзотические языки не афиширует вообще. В требованиях может быть что то расплывчатое вроде нормальный опыт разработки на любом языке программирования, хорошая алгоритмическая подготовка. Про экзотические языки расскажут на предварительном собеседовании по телефону.
Для компаний, кстати, есть реальная выгода — достаточно платить рыночную зарплату и сотрудник не уйдет. Ибо на Java за те же деньги ему будет уже противно писать, а значительно больше мало кто сможет предложить. За счет экзотического языка получится набрать сотрудников, реально увлеченных программированием, с хорошим кругозором, без проблем сформировать как минимум костяк команды, который не распадется.
Здравствуйте, e.thrash, Вы писали:
ET>Немерле2 или же взлетает?
Занял свою нишу там, где не ждали — в сфере разработки под андроид . Хотя бекэнд на нем тоже иногда кое где пилят. Но в плане бекэнда в будущем он ИМХО сольет Scala 3. Сами ждем сейчас Scala 3, там хороший производят редизайн языка — возможно как выйдет, мигрируем туда. А то сейчас сидим на Ceylon (кстати, в Питере на нем минимум 2 конторы пилят, а я думал только мы ), и как то после новостей про переход их в Eclipse foundation как то уровень развития уже сильно напрягает, год уже почти без релизов и багфиксов, новая Java 9 10 не поддерживается, с последней IDEA плагин не работает ни черта — если не разморозятся, придется слезать. На Java не хочется, а Kotlin кучу фич, к которым привыкли, не поддерживает.
Здравствуйте, D. Mon, Вы писали:
DM>А чем вас Ceylon соблазнил? Какие интересные его возможности используете?
Синтаксис весьма приятен. Система типов прекрасная — union types, intersection types и т.д. Кортежи, деструктуризация, for comprehensions, type aliases, модульность, хранение документации вместе с исходниками в одном месте и хорошая поддержка в IDE и т.д. Правда модульность используем в ограниченной мере, изоляцию модулей выключаем и упаковываем все в fat jar, ибо иначе с десериализацией проблемы — наверное единственное что не используем. Ну и компиляцию в JavaScript тоже не используем, но по причине того, что не найти фронтэндера, любящего статическую типизацию. Если найти согласного на ceylon хорошего фронтэндера, могли б и использовать. Реально, лучший язык из всех, которые я видел — очень грамотно сделан. В первую очередь в плане читаемости, предсказуемости и легкости написания кода. Новичков переучивать практически не приходится, новый сотрудник практически сразу садится и начинает приносить пользу. На деле, используем как улучшенный Kotlin. Все на JVM, потому юзаем джавовые библиотеки, взаимодейтсвие с Java весьма неплохое (хоть и встречаются баги, но обходные пути есть практически всегда).
Кое чего не хватает конечно, и некоторые проблемы тоже имеются. Но когда саппортили нормально, было реально супер — багу зарепортил, на следующий день уже пофиксили и можно пользоваться, я на дев ветке сидел. Выход новой версии языка кстати — тоже минимальные проблемы, бинарная совместимость соблюдалась. Новая версия, кстати, бинарно совместимой не будет, соответственно придется перекомпилять. Дождаться б только этой новой версии, первого апреля коммиты пошли, месяц поработали, и снова все затихло, соответственно когда будет все — хз, и это несколько напрягает.
Из крайне важного — хочется поддержки последней версии IDEA, последней версии Java и большей стабильности плагина. Правда пилит в основном один человек, насколько я понимаю, он несколько подустал и решил взять отпуск на годик, наверно жена запилила .
Здравствуйте, WolfHound, Вы писали:
WH>Такая реализация не поддерживает Type??, а это нужно для нормальной работы генериков.
Не понял, в чем проблема? Я даже не понимаю что означает Type?? — это эквивалент Type | Null | Null, что логически схлопывается в Type | Null. Дополнительно, в Scala 3 typesafe null будет абсолютно такой же.
Генерики работают вполне нормально, единственный их недостаток — это оверхед. Если нужно более шустро, приходится пользоваться джавовыми.
Здравствуйте, elmal, Вы писали:
E>Не понял, в чем проблема? Я даже не понимаю что означает Type?? — это эквивалент Type | Null | Null, что логически схлопывается в Type | Null.
И это большая проблема.
E>Дополнительно, в Scala 3 typesafe null будет абсолютно такой же.
А ссылку можно?
Просто сейчас Option в скале правильный. И они обещают, что старый код будет компилироваться с небольшими изменениями. А такая переделка сломает всё к чёртовой бабушке.
E>Генерики работают вполне нормально, единственный их недостаток — это оверхед. Если нужно более шустро, приходится пользоваться джавовыми.
Это не единственный и даже не главный недостаток.
Главная проблема что если мы имеем
class Map<Key, Value>
{
Value? Get(Key key) {...}
}
Теперь сделаем вот так Map<Type1, Type2?> то при вызове Get мы не сможем различить положили ли мы Null в контейнер или в контейнере нет элемента.
Если же у нас вот такая реализация
variant Option[Value]
{
| Some { Value value; }
| None
}
То у нас будут три варианта
None — в контейнер ничего не положили
Some(None) — в контейнер положили null
Some(Some(value)) — в контейнер положили не null
И при поддержке виртуальной машины это можно даже реализовать без оверхеда.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А ссылку можно? WH>Просто сейчас Option в скале правильный. И они обещают, что старый код будет компилироваться с небольшими изменениями. А такая переделка сломает всё к чёртовой бабушке. https://contributors.scala-lang.org/t/non-nullability-by-default/964
oderskySIP Committee memberJul '17
For the time being, every class type is still nullable, so Boo | Null is the same as Boo. We have plans to change that, but we are not quite there yet. We want to concentrate on stability and easy migration first.
То есть в Scala пока все будет криво, но по крайней мере планы у них есть это выправить. Хоть я и не представляю как это будет возможно дальше выправить.
WH>Теперь сделаем вот так Map<Type1, Type2?> то при вызове Get мы не сможем различить положили ли мы Null в контейнер или в контейнере нет элемента.
Можем. Через contains, если очень нужно. На практике обычно не нужно это, в контейнеры помещаются именно Nullable элементы.
При необходимости, если очень хочется, можно и сигнатуру get сделать как T | Absent, что гораздо более логично. Использование Null при возврате метода для каких то диагностических целей это в любом случае не очень феншуйный стиль программирования. Просто так привыкли.
WH>И при поддержке виртуальной машины это можно даже реализовать без оверхеда.
Если очень нужно, то можно пихать в контейнер тот же Option. Хотя бы обычный джавовый. На самом деле Option он довольно неудобный. Он заставляет юзать монады на ровном месте, в результате читаемость кода оставляет желать лучшего. Обычно когда требуются монады — это проблема именно дизайна языка программирования, а монады это способ обойти его ограничения. И если что, Option никто не отменял, если уж без монад никак, то можно и использовать.
Здравствуйте, elmal, Вы писали:
E>То есть в Scala пока все будет криво, но по крайней мере планы у них есть это выправить. Хоть я и не представляю как это будет возможно дальше выправить.
Ты хотел сказать сделать ещё кривее.
E>Можем. Через contains, если очень нужно.
1)Получаем замедление доступа к элементу в 2 раза на ровном месте.
2)И что намного хуже должны думать про невнятные преобразования типов.
E>На практике обычно не нужно это, в контейнеры помещаются именно Nullable элементы.
На практике я хочу писать генерик код, не думая какие типы мне подсунут.
E>При необходимости, если очень хочется, можно и сигнатуру get сделать как T | Absent, что гораздо более логично.
И ты мне предлагаешь каждый раз, когда у меня есть опциональное значение выдумывать новые слова?
А потом учить все библиотеки работать с этими словами?
E>Использование Null при возврате метода для каких то диагностических целей это в любом случае не очень феншуйный стиль программирования. Просто так привыкли.
Это не диагностика. Это часть логики.
WH>>И при поддержке виртуальной машины это можно даже реализовать без оверхеда. E>Если очень нужно, то можно пихать в контейнер тот же Option. Хотя бы обычный джавовый. На самом деле Option он довольно неудобный. Он заставляет юзать монады на ровном месте, в результате читаемость кода оставляет желать лучшего. Обычно когда требуются монады — это проблема именно дизайна языка программирования, а монады это способ обойти его ограничения. И если что, Option никто не отменял, если уж без монад никак, то можно и использовать.
Ты так говоришь, как будто flow-sensitive typing создаёт меньше шума чем монады.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
E>>На практике обычно не нужно это, в контейнеры помещаются именно Nullable элементы. WH>На практике я хочу писать генерик код, не думая какие типы мне подсунут.
Если брать именно генерик код — никто не мешает. Если брать Java — там такая же проблема с коллекциями (точнее большая). Я эту проблему решаю просто — я в коллекции просто не пихаю Nullable типы. И вообще стараюсь их использовать как можно меньше. В результате никаких сложностей с коллекциями у меня нет. Даже продолжу дальше. Если брать Java — когда реально важна скорость, вообще приходится довольствоваться в основном примитивами и уже выделенными массивами. Да и там уже давно бест практики нулы использовать как можно реже.
WH>И ты мне предлагаешь каждый раз, когда у меня есть опциональное значение выдумывать новые слова?
Это крайне редко используется на практике. Даже на Java для опциональных значений предпочтителен Option, а не null, соответственно уже проблемы с получением из коллекции нет. Если есть легаси код — лучше не подстраиваться под легаси, а выправить.
E>>Использование Null при возврате метода для каких то диагностических целей это в любом случае не очень феншуйный стиль программирования. Просто так привыкли. WH>Это не диагностика. Это часть логики.
Вот только логика на Null оправдана в весьма ограниченном диапазоне случаев. Кстати, именно Ceylon весьма хорошо провоцирует логику, основанную на Null использовать поменьше. Ибо с этими if выглядит некрасиво и многословно как на Java, гораздо предпочтительнее что то вроде getOrDefault. А вот к тому, что тип оператора [] оказывается Item? — вот тут у меня кстати есть претензии к дизайну языка. К счасть есть воркэраунды в виде использования джавовых оберток.
WH>Ты так говоришь, как будто flow-sensitive typing создаёт меньше шума чем монады.
Вообще то я не вижу вообще проблем в flow-sensitive typing. Шума это само по себе не создает вообще. В некоторых случаях (редких), указание явного типа может повысить читаемость, но обычно достаточно просто обеспечивать нормальные наименования.
Здравствуйте, elmal, Вы писали:
E>>>На практике обычно не нужно это, в контейнеры помещаются именно Nullable элементы. WH>>На практике я хочу писать генерик код, не думая какие типы мне подсунут. E>Если брать именно генерик код — никто не мешает.
Те в генерик коде мне нужно использовать один вариант, а во всех остальных другой?
Мы тут говорим о реализации семантики опционального значения.
При этом я говорю про вариант, когда мы можем сделать такую ВМ какую захотим, а не пытаемся натянуть язык на существующую.
У нас есть три варианта:
1)Java style. Все значения ссылочных типов могут содержать нулл.
Кошмар при поддержке. Не работает с вальютипами. Не работает с генериками.
2)Ceylon style. Добавляем Nullable тип. И Nullable значения реализуем как объеденение типов.
Не работает с вальютипами либо нужен боксинг. Не работает с генериками.
3)FP style.
variant Option[Value]
{
| Some { value : Value; }
| None
}
Работает со всеми типами. Не создаёт проблем с генериками.
Для эффективной реализации нужна поддержка низкоуровнего оптимизатора.
Лично я выбираю небольшое усложнение жизни разработчикам бэкенда, а не сильное усложнение жизни всем пользователям языка.
WH>>И ты мне предлагаешь каждый раз, когда у меня есть опциональное значение выдумывать новые слова? E>Это крайне редко используется на практике.
За то если используется, то в твоём варианте всегда создаёт проблемы.
Ибо коллекцию напишет один человек.
Код использующий эту коллекцию другой.
А опциональный тип туда засунет третий.
И хрен ты концы найдёшь почему код не работает.
E>Даже на Java для опциональных значений предпочтителен Option,
Option это единственная реализация, которая не создаёт проблем.
E>Вот только логика на Null оправдана в весьма ограниченном диапазоне случаев.
Логика на опциональных значениях нужно довольно часто.
Проблема начинаются только если опциональность значения не видна на уровне системы типов.
E>Вообще то я не вижу вообще проблем в flow-sensitive typing. Шума это само по себе не создает вообще. В некоторых случаях (редких), указание явного типа может повысить читаемость, но обычно достаточно просто обеспечивать нормальные наименования.
Ну так и с нормальной поддержкой опциональных типов шума тоже не будет.
public Repeat(min : int, max : option[int], fsm : FSM) : FSM
{
if (max is Some(max))
RepeatMinMax(min, max, fsm)
else
RepeatMin(min, fsm)
}
После is идёт полноценное сравнение с образцом.
Так что можно и более сложные выражения писать.
when (declarationSite.Extend is Some(declaration) when declaration.IsToken)
context.Error(ruleRef, "Can't refer to a syntax rule from token.");
Здравствуйте, WolfHound, Вы писали:
WH>2)Ceylon style. Добавляем Nullable тип. И Nullable значения реализуем как объеденение типов. WH>Не работает с вальютипами либо нужен боксинг. Не работает с генериками.
Что значит не работает с вальютипами? В ceylon, как и пока в Java, валуетипов пока нет. Если под валиетипами подразумевать Java примитивы, то прекрасно все работает, если что. Без вопросика все мапится на Java примитивы, с вопросиком мапится на Java boxed type.
С генериками все прекрасно на практике работает. Исключение — есть некоторые неприятности с получением этого типа из конкретно мапы по значению, в результате придется дергать это в некоторых случаях через contains, что немного заставит просесть производительность. Но в узких местах на деое Ceylon коллекции лучше не использовать, а если места совсем узкие, то и Java коллекции становятся проблемой. Я вот щас вообще пытаюсь на DirectByteBuffer до черта переделать, надеясь выграть на оптимизациях вида structures of array vs array of structures, причем пытаюсь это все произвести без модификации остального кода чтоб не ухудшить читаемость. WH>3)FP style. WH>Для эффективной реализации нужна поддержка низкоуровнего оптимизатора.
Так тот же FP style вполне можно использовать и из Ceylon, никто не запрещает. Вот только нужно это все делеко не всегда. Я даже скажу когда FP style предпочтителен — при работе с асинхронными потоками событий через Rx Java. Тут даже во многих случаях альтернативы функциональному подходу нет, даже async await далеко не во всех случаях спасает.
WH>Лично я выбираю небольшое усложнение жизни разработчикам бэкенда, а не сильное усложнение жизни всем пользователям языка. WH>И хрен ты концы найдёшь почему код не работает.
Там нет усложнения жизни всем пользователем языка. Опциональные типа не надо пихать в коллекцию как Null. Лучше в коллекции их вообще не пихать, а если уж приспичило, то никто не мешает пихать их как Option. И вопрос исчерпан. Проблемы могут возникнуть если кто то на Java пихает конкретно в мапу в качестве значения null. Возникает вопрос — а на хрена он это делает, ибо при таком подходе это где нидь далее рухнет что в коде на Java, что в Kotlin, что в Scala, что в Ceylon. Ибо в языках с поддержкой Nullability проблемы как раз возникают именно при взаимодействии с Java, про это один черт приходится помнить, тут без вариантов. Если уже пользуешься поддержкой языка — в ногу попасть это нужно еще умудриться.
Здравствуйте, elmal, Вы писали:
WH>>2)Ceylon style. Добавляем Nullable тип. И Nullable значения реализуем как объеденение типов. WH>>Не работает с вальютипами либо нужен боксинг. Не работает с генериками. E>Что значит не работает с вальютипами? В ceylon, как и пока в Java, валуетипов пока нет. Если под валиетипами подразумевать Java примитивы, то прекрасно все работает, если что. Без вопросика все мапится на Java примитивы, с вопросиком мапится на Java boxed type.
Ты читай на что отвечаешь. Специально для тебя выделил.
А боксинг это медленно и что ещё хуже создаёт нагрузку на ГЦ.
E>С генериками все прекрасно на практике работает. Исключение — есть некоторые неприятности с получением этого типа из конкретно мапы по значению, в результате придется дергать это в некоторых случаях через contains, что немного заставит просесть производительность.
Это если про это не забыть.
Любители С/С++ и/или динамической типизации тоже говорят, что они ничего не забывают.
Но практика показывает обратное.
E>Но в узких местах на деое Ceylon коллекции лучше не использовать, а если места совсем узкие, то и Java коллекции становятся проблемой. Я вот щас вообще пытаюсь на DirectByteBuffer до черта переделать, надеясь выграть на оптимизациях вида structures of array vs array of structures, причем пытаюсь это все произвести без модификации остального кода чтоб не ухудшить читаемость.
Для этого нужна поддержка на уровне языка.
Типа такого. https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md#data-oriented-structures
WH>>3)FP style. WH>>Для эффективной реализации нужна поддержка низкоуровнего оптимизатора. E>Так тот же FP style вполне можно использовать и из Ceylon, никто не запрещает.
Везде должен быть строго один метод работы с опциональными типами.
Ибо конвертация из одного в другой полнейший маразм.
E> Вот только нужно это все делеко не всегда.
Всегда нужно использовать тот вариант, который лучше. И этот вариант объективно лучше.
WH>>Лично я выбираю небольшое усложнение жизни разработчикам бэкенда, а не сильное усложнение жизни всем пользователям языка. WH>>И хрен ты концы найдёшь почему код не работает. E>Там нет усложнения жизни всем пользователем языка.
Как это нет, когда я показал, что есть.
E>Опциональные типа не надо пихать в коллекцию как Null. Лучше в коллекции их вообще не пихать, а если уж приспичило, то никто не мешает пихать их как Option.
Ох. Option это и есть один из вариантов опциональных типов.
Ты похоже не можешь отделить концепцию опциональных типов от одной из трёх реализаций.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Но практика показывает обратное.
Практика показывает, что необходимость в Map<Key,Value?> возникает редко. И когда она возникает, ничего не мешает использовать Map<Key,Option<Value>>. А на практике скорее всего будет Map<Key, Action>, где одним из вариантов Action будет что то вроде doNothing. Без всяких null.
WH>https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md#data-oriented-structures
Хотелось бы. Но когда поддержки нет, интересно чего можно добиться без этой поддержки .
WH>Всегда нужно использовать тот вариант, который лучше. И этот вариант объективно лучше.
Однако в том же Kotlin по умолчанию идет вариант, аналогичный как минимум по синтаксису у Ceylon. Что Kotlin, что Ceylon — они разрабатывались после Scala и с учетом опыта Scala. Ибо Nullability в Scala с точки зрения использования не очень удобно. А в Java уже очень давно этот Optional есть, только выглядит он очень уж как костылем. Собственно уже c восьмерки джавовый подход практически как в Scala, что не мешает его использовать что в Kotlin, что в Ceylon. Только Optional — это как раз не поддержка фичи в языке, а костыль в виде библиотек. И это именно та фича, которой реально не хватает в Scala, и это уже хрен исправить.
WH>Как это нет, когда я показал, что есть.
Это усложнение идет для определенного конкретного случая, который крайне редко нужен на практике.
Здравствуйте, elmal, Вы писали:
WH>>Но практика показывает обратное. E>Практика показывает, что необходимость в Map<Key,Value?> возникает редко. И когда она возникает, ничего не мешает использовать Map<Key,Option<Value>>. А на практике скорее всего будет Map<Key, Action>, где одним из вариантов Action будет что то вроде doNothing. Без всяких null.
На практике есть решение, которое просто всегда работает.
Все те костыли, которые ты тут описываешь заставляют на ровном месте делать лишнюю работу, замедляют исполнение кода, увеличивают расход памяти и сокращают пространство для дизайна программы.
Так что я вообще не могу понять почему ты защищаешь решение, которое строго хуже.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Все те костыли, которые ты тут описываешь заставляют на ровном месте делать лишнюю работу, замедляют исполнение кода, увеличивают расход памяти и сокращают пространство для дизайна программы. WH>Так что я вообще не могу понять почему ты защищаешь решение, которое строго хуже.
Это не костыли. Проблема продвигаемого тобой Scala подхода (и с некоторых пор Java) в том, что он либо многословен, либо чересчур идет с упором на монады. В Kotlin, Ceylon, Swift учли эту проблему, и решили действительно исправить ошибку на миллион долларов — сказав что что является Object, не может быть Null — Null это отдельный вариант иерархии классов. В Scala в самом начале не выправили иерархию, потому там альтернативы Option по крайней мере сейчас нет. В Java это тоже не исправить. В новых языках есть выбор. В случае проблем производительности все можно исправить улучшенной кодогенерацией, хоть это и не просто.
Здравствуйте, elmal, Вы писали:
E>Это не костыли.
Они самые. Ибо работают не всегда.
E>Проблема продвигаемого тобой Scala подхода (и с некоторых пор Java) в том,
Этот подход использует каждый первый функциональный язык программирования, ибо он работает всегда.
А не как подход, который ты защищаешь. Тут играем, тут не играем, а тут рыбу заворачивали.
Ты ведь даже не споришь с тем что проблемы есть.
Просто пытаешься убедить себя, что они случаются редко.
Но и проблемы с null тоже случаются редко. Достаточно быть внимательным.
Ровно твой случай.
Но я не хочу быть внимательным. Я хочу устранять классы ошибок так чтобы от них не оставалось и следа. Чтобы программист просто не мог совершить такие ошибки по невнимательности.
Option это делает. Подход Ceylon нет.
E>что он либо многословен, либо чересчур идет с упором на монады.
В чём многословность то?
E>В Kotlin, Ceylon, Swift учли эту проблему, и решили действительно исправить ошибку на миллион долларов — сказав что что является Object, не может быть Null — Null это отдельный вариант иерархии классов.
И пошли по чуть менее кривому пути, который объективно хуже альтернативы.
E>В Scala в самом начале не выправили иерархию, потому там альтернативы Option по крайней мере сейчас нет.
Всегда работающей альтернативы Option я пока не видел.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Теперь сделаем вот так Map<Type1, Type2?> то при вызове Get мы не сможем различить положили ли мы Null в контейнер или в контейнере нет элемента.
Шо, опять???
WH>И при поддержке виртуальной машины это можно даже реализовать без оверхеда.
Без оверхеда это можно и на прикладном union: None | Null | Value.
