Вначале хотел спросить, зачем System.out?.println вызывается через safe-call, если out вроде как не может быть null, но поигравшись с компилятором понял, почему так. Тогда вопрос другой, а вообще есть ли возможность для референс типов вызывать методы по старому, без safe-call (настройки компилятора, или что-то в этом духе)? Есть ощущение, что далеко не всегда это необходимо, а код вопросы могут засорить основательно.
ну как я уже говорил, Roslyn на самом деле не совсем для расширения языка делается, это уж мои проблемы, что я попытался использовать его таким неспецификационным образом.)
Возможно поэтому получилось коряво. Возможно это можно сделать как-то по другому и без использования Рослина, но я, честно, не знаю. Просто хотелось попробовать Roslyn, а писать какой-то банальный code fix не очень хотелось.
а еще идея: может стоит в настройках дать возможность задать желаемую точность отображения решения, чтобы не пугать людей пятнадцатью цифрами после запятой? Будет смотреться аккуратнее мне кажется.
на самом деле, мне кажется шутка уходит корнями в эту статью Спольски . Где-то на Хабре вроде был перевод. Там он довольно подробно объясняет, почему обучение CS должно вестись именного на сях и асме, а не на жаве Ее строгость мало относится к CS в целом, а лишь к одной ее малой части под названием ООП. В рамках CS в целом это скорее не строгость, а ограниченность.
А насчет красивости это вообще холиварный вопрос, но уж вряд ли жава и шарп могут считаться хоть в чем-то красивее C, haskell или python (как дотнетчик говорю)
. Вы же пытаетесь доказать что «мы не сделаем идеала, так давайте писать говнокод».
Процитируйте это место в моих постах пожалуйста.
Я ничего не начинал, я пытался объяснить, что между теорией и практикой (суть зарабатыванием денег) есть большой гэп. И серебрянной пули-таки нет. Стремление к прекрасному всегда хорошо, но нет никаких догм и иногда бывает полезно нарушить любые правила, и выйдет лучше.
Что значит стоило бы знать? Как аспиранту мне их знать нафиг не надо, я физ-мат, как разработчику-профессионалу — я их и так знаю. Но знать и использовать разные вещи. Не все из перечисленного автором так уж однозначно плохо даже в самом наичистейшем ООП, которого в природе не существует. Вот что все тут пытаются автору доказать уже 300 комментов))
Да какая разница, кто сколько зарабатывает? Я сам не пхпшник, а дотнетчик, но к сути это отношения не имеет. Крутые системщики или лисперы зарабатывают еще больше джавистов и дотнетчиков, но на наши ООП принципы они плевали с высокой колокольни. А серебряной пули все равно нет)
Мне кажется, вы заблуждаетесь относительно аудитории Хабра. Суть в том, что человек пытается пропихнуть некоторый набор советов разной (очень разной) степени полезности, одни из которых банальны и ясны даже школьникам, а другие совершенно неоднозначны, как какую-то истину, сошедшую с небес и запечатленную на скрижалях, и толком не может привести разумных аргументов в пользу многих из советов.
Я знаю все из предложенных автором советов, но одни я поддерживаю безоговорочно, другие могу поддержать в зависимости от ситуации, а третьи вообще считаю вредными. Как например разделение данных (паблик-свойств) и методов их обработки в разные классы. Автор подкрепляет свои убеждения невнятными доводами про инкапсуляцию и некоторыми авторитетами, но я сходу могу назвать других авторитетов, которые понимают инкапсуляцию совсем по-другому. Но у автора это похоже в голове не укладывается.
Именно из-за этого возник холивар. И я вас уверяю, на Хабре достаточно людей, которые не понаслышке знают, что такое юнит-тестирование и читали макконнела с фаулером и далеко не только их. Просто автор мне кажется находится в состоянии аффекта от открывшихся ему знаний и считает это чашей Грааля, а тут люди еще просто деньги зарабатывают и давно знают, что серебряной пули нет. Банальный конфликт теоретиков и практиков.
Хорошие книжки даны в статье, жаль давно прочитаны. А можно автору в ответ посоветовать еще два печатных труда, для расширения, так сказать, сознания, тьфу, познания:
1. Fred Brooks — No Silver Bullet — Essence and Accidents of Software Engineering
2. Robert Glass — Creative Programming.
Прочитав, автор возможно прийдет к выводу, что все формальные методы очень противоречивы и сильно неустойчивы. Сегодня модно одно, завтра другое, послезавтра третье, но каждый раз все представляют это как то самое единственное, что поднимет программирование на совершенно новый уровень (ну вот как сейчас автор) — структурное программирование, ООП, юнит-тестирование, дальше еще сто названий различных техник, и.т.д. и.т.п. Но каждый раз оказывается, что конечно это все штуки полезные, и помогающие в определенных ситуациях, но никак не панацея. Поэтому надо свободнее и спокойнее ко всему относиться.
Вначале хотел спросить, зачем System.out?.println вызывается через safe-call, если out вроде как не может быть null, но поигравшись с компилятором понял, почему так. Тогда вопрос другой, а вообще есть ли возможность для референс типов вызывать методы по старому, без safe-call (настройки компилятора, или что-то в этом духе)? Есть ощущение, что далеко не всегда это необходимо, а код вопросы могут засорить основательно.
</2012>не шло</body>, ага!Security Essentials? Ждем в Европе повторения эпопеи с IE?
во втором, если предполагается, что ChainTest — булево поле, то вроде нормально:
Да я думаю, это не единственные каверзные случаи :) Просто не было такой задачи, выискать все каверзные случаи.
Возможно поэтому получилось коряво. Возможно это можно сделать как-то по другому и без использования Рослина, но я, честно, не знаю. Просто хотелось попробовать Roslyn, а писать какой-то банальный code fix не очень хотелось.
А насчет красивости это вообще холиварный вопрос, но уж вряд ли жава и шарп могут считаться хоть в чем-то красивее C, haskell или python (как дотнетчик говорю)
Процитируйте это место в моих постах пожалуйста.
Я ничего не начинал, я пытался объяснить, что между теорией и практикой (суть зарабатыванием денег) есть большой гэп. И серебрянной пули-таки нет. Стремление к прекрасному всегда хорошо, но нет никаких догм и иногда бывает полезно нарушить любые правила, и выйдет лучше.
Да какая разница, кто сколько зарабатывает? Я сам не пхпшник, а дотнетчик, но к сути это отношения не имеет. Крутые системщики или лисперы зарабатывают еще больше джавистов и дотнетчиков, но на наши ООП принципы они плевали с высокой колокольни. А серебряной пули все равно нет)
Я знаю все из предложенных автором советов, но одни я поддерживаю безоговорочно, другие могу поддержать в зависимости от ситуации, а третьи вообще считаю вредными. Как например разделение данных (паблик-свойств) и методов их обработки в разные классы. Автор подкрепляет свои убеждения невнятными доводами про инкапсуляцию и некоторыми авторитетами, но я сходу могу назвать других авторитетов, которые понимают инкапсуляцию совсем по-другому. Но у автора это похоже в голове не укладывается.
Именно из-за этого возник холивар. И я вас уверяю, на Хабре достаточно людей, которые не понаслышке знают, что такое юнит-тестирование и читали макконнела с фаулером и далеко не только их. Просто автор мне кажется находится в состоянии аффекта от открывшихся ему знаний и считает это чашей Грааля, а тут люди еще просто деньги зарабатывают и давно знают, что серебряной пули нет. Банальный конфликт теоретиков и практиков.
1. Fred Brooks — No Silver Bullet — Essence and Accidents of Software Engineering
2. Robert Glass — Creative Programming.
Прочитав, автор возможно прийдет к выводу, что все формальные методы очень противоречивы и сильно неустойчивы. Сегодня модно одно, завтра другое, послезавтра третье, но каждый раз все представляют это как то самое единственное, что поднимет программирование на совершенно новый уровень (ну вот как сейчас автор) — структурное программирование, ООП, юнит-тестирование, дальше еще сто названий различных техник, и.т.д. и.т.п. Но каждый раз оказывается, что конечно это все штуки полезные, и помогающие в определенных ситуациях, но никак не панацея. Поэтому надо свободнее и спокойнее ко всему относиться.