Здравствуйте, 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.");
