Так ведь без соблюдения LSP получается, что мы вынуждены учитывать возможные реализации класса и как-то подстраиваться под них особым образом по месту их использования, что убивает идею полиморфизма подтипов. Похоже, куда не посмотри нет в жизни счастья.
«безопаснее» и удобнее в моем понимании — это перекладывать на компилятор всю рутинную работу, которую компилятор может со 100% точностью сделать гораздо эффективнее человека. Например: проверка ошибок (не давать изменять readonly-поле), представление компилятором более безопасного и читаемого синтаксиса (ссылки, с их как бы автоматическим разыменованием по сравнению с указатеями), генерация кода по определенному паттерну(типа генерация конечного автомата по async..await-синтаксису) и т. п. Это все из той же оперы. Компьютер практически не делает ошибок(если у него есть строгий корректный алгоритм) по сравнению с человеком в такой рутинной работе. Следовательно, преимущества на лицо: гораздо быстрее получаем корректный результат. Просто нужно иметь возможность это удобно выразить в языке.
П. С. iqiaqqivik, мне как и areht'у хотелось бы пример с пояснением, что вы считаете удобством. Только желательно с упором в «безопасность» т. е. простоту поддержки этого кода другими членами команды.
А может все-таки все наоборот и not-null reference types + optional более явно бы показывало суть, чем текущий дизайн reference types? Если опустить варианты оптимизации производительности через null, как особое значение, то я не вижу не одного случая где бы null'ы делали бы код читабельнее или безопаснее. Можете такой случай привести?
Эта ошибка дизайна языка приводит всего лишь к неудобству и возможно некоторому уменьшению скорость разработки. А проблема с null'ом приводети к ошибкам в программе и страдают не только программисты, но и пользователи.
Понимаете, по вашей логике получается, что т. к. NRE не самая ваша большая проблема, то не нужно чинить этот косяк в дизайне языка.
Not null reference type планировалось добавить в C#7, но потом отложили эту фичу до лучших времен (лучшие времена ожидаются с С#8, но там опять же… кто знает что будет). Вот народ и негодует, что средство для практически автоматического улучшения качества программ и упрощения разработки еще прийдется черт знает сколько ждать.
Про PNaCL в википедии пишту, что mozilla отказалась от его поддержки из-за отсутствия полной спецификации. Так что может и правильно, что не взлетел. Производительность — это конечно хорошо, но кучу проблем с совместимостью на разных браузерах она вряд ли перекрывает.
Так это скорее для поддержания яблочной платформы в tarantool'e сделано, а не потому что swift такой модный, удобный и молодежный. А клиентам tarantool'a за пределами яблочной платформы скорее всего будет удобнее писать хранимые процедуры на lua.
Там виноваты COM и 32-битность самой VS, т. е. 3,5Гб должно хватить всем: и студийному GUI, и Roslyn'у, и Resharper'у, и прочим плагинам студии, что живут в том же процессе.
Извените, но если вы хотите именно «сверхбезопасность» по вычислениям, работе с ресурсами (и памятью в частности) и работе с многопоточностью, то вам однозначно стоит посмотреть в сторону Rust, а не Java. Там эта сверхбезопасность будет на порядок выше. Хотя и надо признаться, что язык еще молодой и разработка на нем будет медленнее раза в 2-3 в силу отсутствия продвинутого туллинга. Но что не сделаешь ради сверхбезопасности? Не так ли?
Простите, а что в этом синтаксисе инкремента и декремента такого полезного по сравнению с i=i+1, чтобы его вообще нужно было вводить в языки? Он на 3-7 символов (в зависимости от того как форматировать выражение) короче? Или просто не как у всех?
П. С. iqiaqqivik, мне как и areht'у хотелось бы пример с пояснением, что вы считаете удобством. Только желательно с упором в «безопасность» т. е. простоту поддержки этого кода другими членами команды.
Not null reference type планировалось добавить в C#7, но потом отложили эту фичу до лучших времен (лучшие времена ожидаются с С#8, но там опять же… кто знает что будет). Вот народ и негодует, что средство для практически автоматического улучшения качества программ и упрощения разработки еще прийдется черт знает сколько ждать.
Извините, я в С'ях не силен, а можно на Rust'e?