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