Fesor, по-моему, неточно выразился в самом начала этого треда: C# — никак не лаконичный язык, но он позволяет (местами) писать лаконичный код (за счёт кучи «сахарка», навроде того же LINQ). А с Вами согласен: если единственный способ сделать что-то выразительным (а не просто выразимым) — расширить сам язык, добавив в него новую сущность, а не написать на уже имеющемся языке библиотеку, то с языком таки что-то не так…
Ну а что Вы хотели услышать от одного из апологетов TDD? Опять эти сказки, как TDD спасает мир. «You don't need static type checking if you have 100% unit test coverage.» Вы вот много видели проектов со 100% покрытием? «Therefore, I predict, that as TDD becomes ever more accepted as a necessary professional discipline, dynamic languages will become the preferred languages.» Even more? Мужик не заметил, что hype вокруг TDD уже прошёл? Как, собственно и вокруг динамической типизации. Что поделать, цирк уехал искать новые buzz word'ы, ну а кто в таких случаях остаётся, Вы прекрасно знаете.
P.S. «So says this old C++ programmer.» Вот что меня убивает, что сравнивают как всегда с С++ и его потомками. Ну покажите деду хоть Аду что-ли или Модулу-3. Хотя там в середине есть пассаж «Pascal, I felt, was a language for babies.» после которого писанину этого «взрослого» вообще можно не читать…
По ФП согласен. Вы там важную вещицу упомянули. Очень часто, когда рассуждают, почему ФП не взлетел, начинают ругать Иоганн «нашего» фон Неймана за его богомерзкую архитектуру. Но ведь не только машины (что вторично на самом дело), но и, самое главное, люди мыслят всё-таки преимущественно «императивно». Собственно, машины мы потому такими и построили. Алгоритмическое мышление у большинства особей Homo sapiens ограничено набором инструкций, описывающих порядок действий, и только лишь «издевательство» годами матана способно заставит редких индивидов «думать» алгоритмы в терминах аплликаций функций.
Потому что всё то же самое верно и про Code Complete. Она только длиннее, скучнее и с претензией на большую научность.
Я не считаю мартиновские соглашения по именованию «тривиальнее» макконнеловских. Я и те, и другие считаю вещью даже не второстепенной и тривиальной. Вот я сейчас глянул с свои заметки по книге Мартина, я себе из всей «воды» про именования «отжал» только одно замечание, которое считаю достаточно нетривиальным: про длину имён. «The longer the scope of a variable, the longer is its name; variables in very short scopes should have very short names.» А для классов и функций — наоборот.
Я не говорю, что остальные советы вредны или бесполезны, они просто ну донельзя тривиальны. При их прочтения у меня возникает только один вопрос: «А как вообще может в голову придти делать как-то иначе?» Возможно, кончено, для меня они кажутся тривиальными, потому что есть опыт работы с большими и достаточно формальными (хоть и не программными) текстами на естественном языке, к которым почти все эти правила точно так же применимы. Имена должны быть содержательными, легко произносимыми, удобными для поиска, никаких шуточек и каламбуров, единственный термин для каждой отдельной концепции, и т.д. и т.п. Ну да, ну да, всё так. Но я повторю свою изначальный тезис: это всё ну уровень Дейкстры. Книжки а-ля «Чистый код» могут написать сотни и тысячи авторов (и, собственно, и пишут), а на тексты уровня «Заметок по структурному программированию» способны единицы.
Согласен. В общем и целом, если обобщить, то можно про любой «невзлетевший» язык сказать: «невовремя». Либо слишком поздно, когда ниша уже занята, либо слишком рано, когда ниши ещё и нет совсем.
Слишком тесной интеграцией с GUI можно объяснить почему Smalltalk «не взлетел» как скриптовый язык, но ни почему он «упал» как язык для разработки этих самых GUI-приложений. А потом, если вести отсчёт с начала 2000-х, то GNU Smalltalk, который вполне себе отвязанный от GUI и скриптовый, тогда уже вполне живой был, но в итоге как скриптовый язык в 2000-х «взлетел» Python, а не Smalltalk. Или возьмите те же веб-фреймворки: Seaside появился на пару-тройку лет раньше Rails и Django, но как-то не очень это помогло. Там то слишком тесная интеграция с GUI уж точно проблемой не была.
Такое, конечно, возможно, но что-те не очень верится…
Так вот, затраты времени для меня несопоставимы с полученной выгодой.
Да мне тоже осточертело, но вот прямо сейчас заставить себя отказаться от привычки всё проверять хотя бы «по минимуму» не могу. Когда-то не мог себя приучить к этому, теперь не могу разучиться.
Консенсуса, как я вижу, у нас тут не получилось, но и обмен мнениями — «уже хлеб». :D
… за что его должны побить по рукам рецензент и/или редактор.
В идеальном мире, да, должны. А в реальном, как говориться, Вам никто ничего не должен. Или, вспоминая актуальный ногомяч, как там было у Аршавина? «Ваши ожидания — это Ваши проблемы.» :) Программисты должны писать чистый код — это из той же оперы.
Серьезно? Вы пробовали это проделать для того же МакКоннела?
Я подобной работой занимаюсь каждый день. Иду к PhD (не в области информационных технологий, но не суть) и каждый божий день приходиться блуждать туда-сюда по куче ссылок и читать как минимум abstract'ы того, что цитируют. Поверьте, мир далеко не идеален. Часто цитируют даже не совсем ту работу (пускай и тех авторов), которую бы стоило процитировать (в том смысле, что утверждения, которое пытаются подкрепить цитированием, в цитируемой работе вообще нет ни в каком виде) :D А иногда вообще цитируют (сразу видно) даже не открывав оригинал: все цитируют, и ты цитируй. И ерунда что эти мифические все цитируют совсем в другом контексте. И рецензенты — тоже люди с теми же слабостями, запросто пропускающие чужие умышленные и неумышленные ошибки. Резюмируя: как минимум резюме/выводы цитируемых работ стоит пробегать глазами, чтобы не попасть впросак.
Изначальный посыл был всё-таки про Clean Code, уже потом в качестве ещё одного примера я упомянул Code Complete, а про Pragmatic Programmer я вообще ничего не говорил. Хотя есть стойкое ощущение, что всё это одного поля ягоды, но это скользкая дорожка. Pragmatic Programmer не читал и пока, как следствие, не осуждаю. По второму вопросу, в очередной раз повторю, правильному именованию, документированию кода, основы рефакторинга — это всё существенно только для кодирования. С точки зрения программирования — это «шелуха». А проблема в том, что этой «шелухой» часто подменяют программирование. Впрочем, я уже это говорил в этой теме…
А какой там был изначальный посыл? Как бы то ни было, если Вам так интересно, то мой ответ на вопрос: «Полезно ли учиться по МакКоннелу» очевидно: «Нет, так как там особо нечему учиться.» Пробежать глазами стоит, не более. Мартина даже пробегать глазами не стоит.
Окей, давайте начнем с простого: какое определение монографии вы используете, и где вы его взяли?
ГОСТ 7.60-2003, например, определяет монографию как (стр. 6, п. 3.2.4.3.1.1) «научное или научно-популярное издание, содержащее полное и всестороннее исследование одной проблемы или темы и принадлежащее одному или нескольким авторам». Никаких ограничений на объём тут быть не может, что называется, по определению: проблема проблеме рознь. Рецензирование, впрочем, тут подразумевается, ибо в современном мире издание вряд ли можно считать научным, если его не рецензировали профильные специалисты. Но, как я уже указывал выше, рецензирование имело место.
Конечно, верю на слово. В этом, собственно, смысл рецензируемой (и редактируемой) публикации — проверка источников делается рецензентом и техническим редактором.
Ну не знаю, не знаю. Как по мне, Вы поступаете не совсем правильно: цитирующий автор может запросто (нарочно или нет) исказить смысл цитируемого исследования, некорректно его интерпретировав, например. Так что таки следует читать как минимум выводы или резюме оригинального исследования. И никакое рецензирование Вас от этой обязанности не освобождает: ссылки на оригинальные исследования Вам, собственно, за этим и даны. Доверяй, но проверяй. А иначе, будь по-вашему, их бы давали только рецензентам, а из публичных копий убирали. :)
Если я буду идти по каждой ссылке в книге (а не только по интересным мне или по тем, которые нужны для конкретной дискуссии), я никогда читать не закончу.
Зачем ходить по не интересующим Вас ссылкам я, честно говоря, не очень понимаю. А просмотреть хотя бы резюме по интересующим — это не такая и времязатратная задача. Там всё равно около 1000 страниц читать, эка проблема глазами пробежать десяток другой abstract'ов. :D Конечно, если возникнут сомнения или просто появиться интерес к оригинальному исследованию, его придётся читать. Ну а что делать? Вам ссылки, повторюсь, за этим и даны.
NoSP — монография. «Letters written to myself» — это просто формат. Никаких ограничений по объёму на монографии не накладывается, монография — это по сути просто писанина на одну конкретную тему. Ограничения по объёму появляются только в том случае, когда монографии выполняет какую-то необязательную роль, скажем, когда используется в качестве докторской диссертации. Да и peer review, о чём автор прямо упоминает: «Prior to their publication in book form, the „Notes on Structured Programming“ have been distributed privatly» и далее по тексту «спасибки» ревьюверам. Плюсом там ревьювером был как минимум ещё редактора сери Хоара, который, кстати, в предисловии прямо называет работы, вошедшие в книгу монографиями.
Статистика — это факты, можно спорить с методикой сбора, можно спорить с методикой расчетов или выводами, но опровергать исследование только на основании того, что оно статистическое — глупо.
И точно так же глупо верить результатам статистических исследований, не ознакомившись с ними. Вы оригинальные исследования то читали или просто верите автору «на слово»?
Это применимо почти к любой литературе, написанной человеком на натуральном языке. Он (натуральный язык), знаете ли, избыточен. Интереса ради, можете попробовать применить то же самое к Notes On Structured Programming, эффект получается занятным.
Применимо только в той или иной мере. Бывают такие «песни», из которых «слов не выкинешь». Каждое отдельное предложение в текстах Дейкстры может казаться тривиальным, но в сумме у него получаются очень даже нетривиальные выводы. Вот этого я у всяких Мартинов не вижу: тривиально, тривиально, тривиально, и так далее на 500-1000 страниц. Ску-ко-ти-ща.
То есть вы думаете, автор его придумал из головы?
Я не могу утверждать, что конкретно автор имел ввиду под Code Complete. Переводчики на русский, заметьте, интерпретировали заглавие именно как «Совершенный Код».
У Дейкстры есть хотя бы одна монография?
Ну привет. Упомянутые «Notes on Structured Programming» — вполне себе монография. То, что 3 монографии издали одной книгой не делает их чем-то иным.
Так речь не идет о ссылках на «мне кажется что», речь идет о ссылках на конкретные статистические наблюдения за индустрией.
Вот! Статистические наблюдения за индустрией — это уже куда более конкретный термин, нежели какие-то там исследования. Тут есть сразу два важных слова: статистические и индустрия. Про первое всё уже сказано и не раз: «Существуют три вида лжи: ложь, наглая ложь и статистика». Про второе: а что если индустрия идёт не туда? Что если попытки оптимизации труда программистов если и нашли какой-то минимум, то только локальный? Что если все эти советы несущественны?
Уточню, что «фантазии» в конечном счёте отольются горькими слезами и при работе с нематериальным миром, вот только не так сразу, как в случае мира материального. В (технический) долг, зачастую, берут одни, а расплачиваются уже другие…
P.S. «So says this old C++ programmer.» Вот что меня убивает, что сравнивают как всегда с С++ и его потомками. Ну покажите деду хоть Аду что-ли или Модулу-3. Хотя там в середине есть пассаж «Pascal, I felt, was a language for babies.» после которого писанину этого «взрослого» вообще можно не читать…
Я не считаю мартиновские соглашения по именованию «тривиальнее» макконнеловских. Я и те, и другие считаю вещью даже не второстепенной и тривиальной. Вот я сейчас глянул с свои заметки по книге Мартина, я себе из всей «воды» про именования «отжал» только одно замечание, которое считаю достаточно нетривиальным: про длину имён. «The longer the scope of a variable, the longer is its name; variables in very short scopes should have very short names.» А для классов и функций — наоборот.
Я не говорю, что остальные советы вредны или бесполезны, они просто ну донельзя тривиальны. При их прочтения у меня возникает только один вопрос: «А как вообще может в голову придти делать как-то иначе?» Возможно, кончено, для меня они кажутся тривиальными, потому что есть опыт работы с большими и достаточно формальными (хоть и не программными) текстами на естественном языке, к которым почти все эти правила точно так же применимы. Имена должны быть содержательными, легко произносимыми, удобными для поиска, никаких шуточек и каламбуров, единственный термин для каждой отдельной концепции, и т.д. и т.п. Ну да, ну да, всё так. Но я повторю свою изначальный тезис: это всё ну уровень Дейкстры. Книжки а-ля «Чистый код» могут написать сотни и тысячи авторов (и, собственно, и пишут), а на тексты уровня «Заметок по структурному программированию» способны единицы.
P.S. Меня одного раздражает его манера публичных выступлений?
Такое, конечно, возможно, но что-те не очень верится…
Да мне тоже осточертело, но вот прямо сейчас заставить себя отказаться от привычки всё проверять хотя бы «по минимуму» не могу. Когда-то не мог себя приучить к этому, теперь не могу разучиться.
Консенсуса, как я вижу, у нас тут не получилось, но и обмен мнениями — «уже хлеб». :D
В идеальном мире, да, должны. А в реальном, как говориться, Вам никто ничего не должен. Или, вспоминая актуальный ногомяч, как там было у Аршавина? «Ваши ожидания — это Ваши проблемы.» :) Программисты должны писать чистый код — это из той же оперы.
Я подобной работой занимаюсь каждый день. Иду к PhD (не в области информационных технологий, но не суть) и каждый божий день приходиться блуждать туда-сюда по куче ссылок и читать как минимум abstract'ы того, что цитируют. Поверьте, мир далеко не идеален. Часто цитируют даже не совсем ту работу (пускай и тех авторов), которую бы стоило процитировать (в том смысле, что утверждения, которое пытаются подкрепить цитированием, в цитируемой работе вообще нет ни в каком виде) :D А иногда вообще цитируют (сразу видно) даже не открывав оригинал: все цитируют, и ты цитируй. И ерунда что эти мифические все цитируют совсем в другом контексте. И рецензенты — тоже люди с теми же слабостями, запросто пропускающие чужие умышленные и неумышленные ошибки. Резюмируя: как минимум резюме/выводы цитируемых работ стоит пробегать глазами, чтобы не попасть впросак.
ГОСТ 7.60-2003, например, определяет монографию как (стр. 6, п. 3.2.4.3.1.1) «научное или научно-популярное издание, содержащее полное и всестороннее исследование одной проблемы или темы и принадлежащее одному или нескольким авторам». Никаких ограничений на объём тут быть не может, что называется, по определению: проблема проблеме рознь. Рецензирование, впрочем, тут подразумевается, ибо в современном мире издание вряд ли можно считать научным, если его не рецензировали профильные специалисты. Но, как я уже указывал выше, рецензирование имело место.
Ну не знаю, не знаю. Как по мне, Вы поступаете не совсем правильно: цитирующий автор может запросто (нарочно или нет) исказить смысл цитируемого исследования, некорректно его интерпретировав, например. Так что таки следует читать как минимум выводы или резюме оригинального исследования. И никакое рецензирование Вас от этой обязанности не освобождает: ссылки на оригинальные исследования Вам, собственно, за этим и даны. Доверяй, но проверяй. А иначе, будь по-вашему, их бы давали только рецензентам, а из публичных копий убирали. :)
Зачем ходить по не интересующим Вас ссылкам я, честно говоря, не очень понимаю. А просмотреть хотя бы резюме по интересующим — это не такая и времязатратная задача. Там всё равно около 1000 страниц читать, эка проблема глазами пробежать десяток другой abstract'ов. :D Конечно, если возникнут сомнения или просто появиться интерес к оригинальному исследованию, его придётся читать. Ну а что делать? Вам ссылки, повторюсь, за этим и даны.
И точно так же глупо верить результатам статистических исследований, не ознакомившись с ними. Вы оригинальные исследования то читали или просто верите автору «на слово»?
Применимо только в той или иной мере. Бывают такие «песни», из которых «слов не выкинешь». Каждое отдельное предложение в текстах Дейкстры может казаться тривиальным, но в сумме у него получаются очень даже нетривиальные выводы. Вот этого я у всяких Мартинов не вижу: тривиально, тривиально, тривиально, и так далее на 500-1000 страниц. Ску-ко-ти-ща.
Я не могу утверждать, что конкретно автор имел ввиду под Code Complete. Переводчики на русский, заметьте, интерпретировали заглавие именно как «Совершенный Код».
Ну привет. Упомянутые «Notes on Structured Programming» — вполне себе монография. То, что 3 монографии издали одной книгой не делает их чем-то иным.
Вот! Статистические наблюдения за индустрией — это уже куда более конкретный термин, нежели какие-то там исследования. Тут есть сразу два важных слова: статистические и индустрия. Про первое всё уже сказано и не раз: «Существуют три вида лжи: ложь, наглая ложь и статистика». Про второе: а что если индустрия идёт не туда? Что если попытки оптимизации труда программистов если и нашли какой-то минимум, то только локальный? Что если все эти советы несущественны?