Тут просто маркетинговые формулировки вводят в заблуждение. Это нифига не часы — это наручный компьютер. Также как смартфон — это не телефон, а карманный компьютер с функцией телефона. При таких формулировках не было бы претензий к времени автономной работы (точнее, все равно бы были, но уже в другой плоскости).
С одной стороны, число ошибок на строку кода — величина практически постоянная для отдельного программиста. С другой стороны — с увеличением размера кода увеличивается вероятность косвенных ошибок. С третьей стороны — бывает, конечно, по разному, но зачастую с ростом размера кода, который пишется, растет и размер кода, который тем или иным способом генерируется и имеет минимум ошибок. Второй и третий факторы, по идее, примерно друг друга компенсируют и остается просто линейный рост.
У вас просто глаз не намотан — а вот наши законописатели могут найти наркотики, суицид и цп там, где никто другой этого бы не заметил. Трудятся в поте лица — зрение тренируют.
Все помнят то видео с Балмером, и именно этот подход радует в майкрософт больше всего — внимательное отношение к разработчикам. Под все виндоплатформы приятно и комфортно писать. Надеюсь, на замену Балмеру придет человек, который не похерит эту тенденцию.
По сути: Animal[] animals = new Giraffe[10]; — валидно по определению ковариации, но может привести к ошибке, когда в animals попробуем добавить, например, черепаху. По этой причине для дженериков решили избежать этой проблемы и поэтому ковариации для них нет, ну а для массивов не стали убирать из-за обратной совместимости.
У Липперта отличная серия статей на эту тему — начиная отсюда (не знаю, может где-то и переведенное на русский есть).
C# — потомок С++, а вот CLR проектировалась на основе джававской машины. Причем так стремились к точному копированию, что тащили даже ошибки (по мнению Липперта) типа ковариции массивов.
Я большой любитель linq-а, и с вами частично согласен. Но, все-таки, он один не спасает от излишней многословности. Или, например, методы-расширения, которые также должны бы были привнести преимущества функциональщины, по факту не так хорошо работают из-за внушительного синтаксического шума.
Но, в конечном счете, вопрос действительно сводится к тому, кому нравятся скобочки, а кому — нет.
Статья забавная. Но, думаю, зачастую проблема в не в том, что «я не хочу», а в том, что в ентерпрайзе не так просто перейти на функциональный язык в проекте, которому 5+ лет.
Вот бы первую часть, но чуть подробнее и обширнее...
нужно больше технических статей о цвете
А в чем проблема? Молодцы же.
Это та ситуация, когда «достаточно одного раза». Ну и, вообще, они обычно и не разваливаются — просто существуют в почти-рабочем состоянии.
Animal[] animals = new Giraffe[10];— валидно по определению ковариации, но может привести к ошибке, когда в animals попробуем добавить, например, черепаху. По этой причине для дженериков решили избежать этой проблемы и поэтому ковариации для них нет, ну а для массивов не стали убирать из-за обратной совместимости.У Липперта отличная серия статей на эту тему — начиная отсюда (не знаю, может где-то и переведенное на русский есть).
Вообще, я не очень понял, какое глобальное утверждение пытался оспорить автор этой статьей.
Но, в конечном счете, вопрос действительно сводится к тому, кому нравятся скобочки, а кому — нет.