Почитал habr.com Как впечатление? Особенно от Nullable Reference Types.

Поживём - увидим
А пока повода рвать волосы на голове я не вижу. Ну разве что язык превращается в крайне сложно изучаемое нечто...
Дополнительные проверки на null на этапе компиляции - не самая плохая штука. Другое дело несколько качественно это можно "в принципе" реализовать...

Igor Korolyov
Ну разве что язык превращается в крайне сложно изучаемое нечто...

Иначе говоря - повышается порог вхождения. С другой стороны, конкуренция между языками всё возрастает. Те же JS и Python позволяют писать быстрее - на реализацию функционала уходит меньшее букв, т.е. в программе меньше бойлерплейт-кода. Мне кажется, если будет Records - стоит задуматься, что бы его использовать. Но, дьявол как всегда - в деталях. А вдруг понадобится внести изменение в код, генерируемый Records? Конечно, можно и отнаследоваться. Но, наверняка появятся какие то атрибуты, влияющие на Record.

Igor Korolyov
Дополнительные проверки на null на этапе компиляции - не самая плохая штука.

Что значит неплохая? IMHO, так должно было быть с самого начала, когда язык разработали.

Igor Korolyov
Другое дело несколько качественно это можно "в принципе" реализовать...

Есть сомнение в способностях тех бородатых дядек, что компилятор пишут?



Исправлено 1 раз(а). Последнее : S-type, 05.06.18 11:22

Любопытная статейка.
Records - да)
мне еще "Оператор switch будет позволять сжатый синтаксис..." понравилось)

И да, Игорь, как и переводчик правы.
Язык превращается в монстра. )))
Но давно создалось впечатление, что это судьба любого развивающегося языка.

S-type

Igor Korolyov
Другое дело несколько качественно это можно "в принципе" реализовать...

Есть сомнение в способностях тех бородатых дядек, что компилятор пишут?

Есть сомнения в компетентности огромной массы индусо-китайцев (в т.ч. и тех что вполне славянской внешности ) язык использующих - не будет ли это для них излишне сложным Любое ограничение усложняет жизнь, в особенности не самым умелым людям. При том что кардинально улучшить качество кода эта штука всё одно не способна...

S-type
Особенно от Nullable Reference Types.

Nullable из коробки есть в Kotlin и позиционируется как основная киллер фича по сравнению с Java. Там насколько я помню все не примитивные переменные по-умолчанию не Nullable, и если нужна поддержка Null, нужно указывать это явно при объявлении. Не уверен, что по-умолчанию так рискнут сделать в финальном релизе 8, так как действительно сломается обратная совместимость. Скорее всего,будет какой-то компромиссный вариант. Сам по себе "Not null" добавляет дополнительную защиту от простреливания ног, так что скорее это плюс, но это при этом требования к коду становятся более строгими.

Range реализован в D. И очень удобен в сочетании с лямбдами, позволяет в одну строчку организовать диапазон, проход по нему, сортировку, фильтрацию и т.д. По-сути в шарп перетягивают удачные решения от конкурентов, для разработчиков со стажем это скорее плюс, но для новичков порог входа увеличивается. Если сейчас взять чистый шарп и яву без фрейморков, то конечно ява будет гораздо проще для первоначального освоения. Но и многословнее. С другой стороны, для совсем начинающих, любой язык со статической типизацией будет для освоения концептуально сложнее динамических языков вроде питона или яваскрипта, и тут уже пофиг что шарп более сложный чем ява.

P.S. И дочитав до конца статью, могу сказать, что не совсем разделяю мнение переводчика. Шарп - вполне язык средней сложности, тот же D концептуально более навороченный. Нельзя назвать простыми функциональные языки, чтение кода на Scala требует гораздо больших усилий, чем код шарпа. С другой стороны, если шарп предполагался как язык массовой промышленной разработки и вот для этого среднестатистического промышленного разработчика он становится слишком сложным, возможно MS стоит и призадуматься, чтобы не потерять нишу. Google вон пошли по другому пути - сделали промышленным языком GO под обезьянку средней сообразительности.





Исправлено 3 раз(а). Последнее : h.i.a., 05.06.18 14:47

h.i.a.
Не уверен, что по-умолчанию так рискнут сделать в финальном релизе 8, так как действительно сломается обратная совместимость. Скорее всего,будет какой-то компромиссный вариант. Сам по себе "Not null" добавляет дополнительную защиту от простреливания ног, так что скорее это плюс, но это при этом требования к коду становятся более строгими.

Компромиссный вариант - это как? Первое, что приходит на ум, это использовать атрибут. Примерно так:


Конечно, при этом обратная совместимость сохранится. Но будет ли это красиво?

blogs.msdn.microsoft.com



Исправлено 1 раз(а). Последнее : S-type, 05.06.18 16:35

Аспид
Любопытная статейка.
Records - да)
мне еще "Оператор switch будет позволять сжатый синтаксис..." понравилось)

По поводу switch присоединяюсь, ибо break в switch не нравится с момента знакомства А лямбда-подобный синтаксис красив и интуитивно понятен.

Аспид
И да, Игорь, как и переводчик правы.
Язык превращается в монстра. )))
Но давно создалось впечатление, что это судьба любого развивающегося языка.

Похоже, повторяется история с VFP - каждое действие можно будет сделать минимум тремя вариантами....



Исправлено 1 раз(а). Последнее : S-type, 05.06.18 16:44

S-type
Компромиссный вариант - это как? Первое, что приходит на ум, это использовать атрибут. Примерно так:

Настройка на уровне проекта или namespace. Просто я с трудом представляю, что в финальном релизе такое могут включить в принудительном порядке. И сколько цензурных слов скажут в адрес MS разработчики проектов, состоящих даже из нескольких десятков тысяч строк кода, не говоря о сотнях. По сути тогда нужен будет автоконвертер проекта, что тоже есть дурной костыль. А что делать со сторонними библиотеками/фрейморками?
У Kotlin то данное поведение было изначально и программистам не нужно было ничего переделывать в своем старом коде.





Исправлено 1 раз(а). Последнее : h.i.a., 05.06.18 18:07

Это планируется всего лишь как warning-и компилятора, т.е. это, конечно же, мозолящее глаза, но никак не breaking change. И даже "явно включаемой" эта штука будет, а не "по умолчанию".
А "не замечать" варнинги, и вообще их подавлять - не было проблемой с самого начала
Проблема в том что реально весьма сложно отследить все use case приводящие (потенциально) к записи null в некоторое свойство...