Pull to refresh
2
0
Send message
Слишком тесной интеграцией с GUI можно объяснить почему Smalltalk «не взлетел» как скриптовый язык, но ни почему он «упал» как язык для разработки этих самых GUI-приложений. А потом, если вести отсчёт с начала 2000-х, то GNU Smalltalk, который вполне себе отвязанный от GUI и скриптовый, тогда уже вполне живой был, но в итоге как скриптовый язык в 2000-х «взлетел» Python, а не Smalltalk. Или возьмите те же веб-фреймворки: Seaside появился на пару-тройку лет раньше Rails и Django, но как-то не очень это помогло. Там то слишком тесная интеграция с GUI уж точно проблемой не была.
Ох, опять этот Мартин. :D Но тем не менее, отдаю должное мужику: пускай и с кучей лирических отступлений, но суть он уловил и передал хорошо. «It is just too easy to make a mess.» © Касается, в принципе любого языка с динамической типизацией. 100-200 строчек — полёт нормальный, как начинаются серьёзные объёмы кода, так начинаются неприятности. В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто, так что даже добавить какую-ту небольшую функциональность или что-то несущественное поменять из уже имеющегося становиться настолько сложно, что проще начать всё с нуля. Ну а самое парадоксальное, что это ещё и преподносится как преимущество. Rewritten from scratch! Ну теперь то заживём! Но не проходит и пару лет…

P.S. Меня одного раздражает его манера публичных выступлений?
В самом начале я перепутал название: книга Мартина называется таки «Чистый код», да.
У нас с вами разные «реальные миры».

Такое, конечно, возможно, но что-те не очень верится…

Так вот, затраты времени для меня несопоставимы с полученной выгодой.

Да мне тоже осточертело, но вот прямо сейчас заставить себя отказаться от привычки всё проверять хотя бы «по минимуму» не могу. Когда-то не мог себя приучить к этому, теперь не могу разучиться.

Консенсуса, как я вижу, у нас тут не получилось, но и обмен мнениями — «уже хлеб». :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 монографии издали одной книгой не делает их чем-то иным.

Так речь не идет о ссылках на «мне кажется что», речь идет о ссылках на конкретные статистические наблюдения за индустрией.

Вот! Статистические наблюдения за индустрией — это уже куда более конкретный термин, нежели какие-то там исследования. Тут есть сразу два важных слова: статистические и индустрия. Про первое всё уже сказано и не раз: «Существуют три вида лжи: ложь, наглая ложь и статистика». Про второе: а что если индустрия идёт не туда? Что если попытки оптимизации труда программистов если и нашли какой-то минимум, то только локальный? Что если все эти советы несущественны?
Уточню, что «фантазии» в конечном счёте отольются горькими слезами и при работе с нематериальным миром, вот только не так сразу, как в случае мира материального. В (технический) долг, зачастую, берут одни, а расплачиваются уже другие…
Про батюшку, колокольню и что сопромат не «обманешь»? :D
Как раз эти «поправки» на особенности нематериального мира тут и играют определяющую роль. Фантазируй, твори, машина стерпит. В реальном то мире «фантазёрам» обычно очень быстро «прилетает» от матушки-природы. :D Там то правила игры жёсткие и определяются не человеком, а тут ну такой простор для «творчества», такой простор…
То есть программистам обучение не нужно, я вас правильно понял?

Нет, не правильно. Определённый уровень интеллекта — лишь достаточный критерий, но не необходимый. Учиться надо, но не по «Чистым кодам».

«There are only two hard things in Computer Science: cache invalidation and naming things.» (Phil Karlton, по цитатам, оригинал не найден)

Мне эту чушь обязательно комментировать? Тоже мне фундаментальные проблемы.

Если вы его там не нашли, это не значит, что его там нет.

А Вы правда нашли во всех 450 страницах, да? Там, как минимум, втрое можно сократить без малейшей потери смыслов.

А кто-то где-то говорил, что надо читать МакКоннела и/или Мартина и/или Фаулера и/или Ханта/Томаса вместо Дейкстры?

Берёте случайный ресурс для программистов и смотрите некий список книг, обязательных к прочтению. С 99% вероятностью что-нибудь из Clean или Complete Code там будет, а трудой Дейкстры — нет. И если и будут упомянуты, то в самом низу списка. Так что почти «все-то» почти «везде-то» это говорят. Просто загуглите «must read computer science books» или что-то типа того, чтобы в этом убедиться. Например, на SO есть закрытый топик, там Дейкстру случайно кто-то упомянул, но это упоминание утонуло в море «чистых совершенных кодов» и прочей биллетристики.

«Code complete»
— это устоявшееся выражение, означающее «программист работу закончил».
Даже по ссылке, что Вы дали, которая, кстати, не отражает, что автор вкладывал в название своей книги, нет консенсуса. Кто-то, так же, как и я, считает, что выражения означает какой-то мифический совершенный завершённый код. Так что, простите, не надо «ла-ля»: нет тут никакого устоявшегося выражения.

За Code Complete, очевидно.

Ну Code Complete в целом лучше, чем Clean Code, да. Там действительно много полезных отсылок к монографиям тех же Дейкстры, Вирта, GoF, и прочих. Вот только я про «мне кажется что» не очень понял. Какая разница: читать оригинал с «мне кажется что», или читать книгу, ссылающуюся на этот оригинал? Отсылка к «мне кажется что» посредством цитирования не делает утверждение менее субъективным. И эта Ваша Computer Science пока ещё слишком молодая наука, так что большинство «исследований» в ней таки находятся на этом самом уровне «мне кажется что» и «я считаю что»: обобщение собственного (в лучшем случае) коллективного опыта, социологические опросы. Зачастую, грош цена таким «исследованиям», зато есть чем список литературы набить для создания эффекта научности, да. :)
Про «бумагомарательство» — это, конечно, утрирование было, или, как нынче модно говорить, «наброс», но, ей богу, на 450 страниц у того же Мартина есть явный перебор «тривиальщины», постоянных повторений и откровенной «воды». А по поводу стратегии и тактики, я где-то даже соглашусь с Вами. Но отметьте, что тактика — это всего лишь инструмент реализации стратегии, т.е. первична то именно стратегия. А теперь простой вопрос: сколько по Вашему мнению программистов ознакомились со стратегией (Дейкстра, Вирт) перед тактикой (Мартин, Макконнелл)? Уже отмеченный выше факт, что труды Дейкстры и Вирт — нынче библиографическая редкость как бы намекает на правильный ответ.
Тривиальны для кого?

Да для любого человека с IQ, достаточным для того, чтобы быть программистом. Я понимаю, что нынче программирование «в тренде», и идут туда не только те, кто могут, а повально все, кому кушать хочется. Так, собственно, необходимость в подобного рода «тривиальщине» и возникает.

Вы никогда не слышали про две фундаментальных проблемы computer science?

Первый раз слышу такое словосочетание. Это что ещё за «мем»? Уж будьте добры, просветите. Вообще, основная проблема в программировании — борьба со сложностью. А вот в computer science? Тут надо, конечно, для начало определиться, а что такое вообще этот Ваш «computer science»? Ну и в любом случае, оставь этот убогий термин нашим «коллегам» из-за океана. Дейкстра, между прочим, ещё когда говорил: «Сomputer Science is no more about computers than astronomy is about telescopes.» :D

И что, они теперь бесполезны?

Нет, конечно. Но, во-первых, как я уже сказал, полезного там на 450 страницах — «кот наплакал». А во-вторых, есть вещи куда более фундаментальные и полезные. Этих всяких Мартинов полезно читать после Дейкстры, а не до, и уж тем более не вместо. Тем временем, труды Дейкстры нынче библиографическая редкость, а «бульварного чтива» от Мартина и прочих — хоть отбавляй.

Вас не смущает, что первое издание CC вышло за два года до Java?

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

А что претенциозного в названии Code Complete?

В том что это оксюморон, нет? Очевидно недостижимая цель, причём, заметьте, как не переводи: хоть «Законченный код», хоть «Совершенный». Несуществующие сущности. У книги Мартина ещё вменяемое название, но Макконнелла уже, по-моему, занесло.

Ради того, чтобы можно было взять, открыть нужный раздел, и найти мнение, подтверждение конкретными исследованиями (а не абстрактным «мне кажется, что»).

Это мы сейчас за какую книгу то говорим? За Мартина? Что это там за «исследования» такие? :O
Раньше и ноутбуков не было с промежуточными значениями DPI, а теперь уже есть.
Ещё неплохая книга есть у Вирта: «Систематическое программирование. Введение». Но мне как-то Дейкстра больше по душе пришёлся. Даже могу сказать, намного больше, но это уже, подозреваю, всего-навсего личные пристрастия. А прямо сейчас медленно и вдумчиво читаю «Языки программирования. Концепции и принципы» за авторством Кауфмана. Ещё не дочитал, но уже могу смело советовать в тех же целях: чтобы приподняться с уровня Мартинов-Макконнеллов по наименованию переменных и оптимальному количеству параметров функции (т.е. по сути, кодирования) на уровень более куда более фундаментальных вещей (т.е. собственно программирования).
Я понял, что у Вас много Маков. Но повторю ещё раз: у OS X есть только один режим HiDPI — с масштабированием ровно в 2 раза. Такой подход «работает» хорошо только по той причине, что в экосистеме Apple другого масштабирования не требуется. Но если эту экосистему покинуть, могут быть проблемы. Монитор, скажем, размером 24" с разрешением 1920x1200 действительно не требует HiDPI, а вот монитор того же размера но с разрешением 2560x1440 уже потребует масштабирования для комфортной работы. Но не в 2 раза, а не больше, чем в 1.5. И OS X тут будет бессильна, ибо либо никак и очень мелко, либо в 2 раза и очень крупно. Такие мониторы — не фантастика, Вы их уже сейчас можете купить, если что.
Аргументировать что? Вы сей опус читали? Там большинство «полезных советов» либо тривиальны донельзя (скажем, советы по наименованию), либо языко-специфичны (скажем, советы по использованию исключений для обработки ошибок и панический страх автора перед функциями с более чем двумя параметрами), либо представляют собой возведение более-менее здравой идеи в идиосинкратический абсолют (функции по 5 строк без параметров). Слишком много воды (аж на 450 страниц!), а реально полезных знаний крупицы. Если бы это всё называлось как-нибудь… ну не знаю «Записки стареющего Java-разработчика» и не пиарилось повсюду, то ладно, но уж чересчур претенциозное название и чересчур много шума из ничего. На фундаментальный труд никак не тянет, словоблудие сплошное по большому счёту. Так чего ради было столько бумаги марать?

Information

Rating
Does not participate
Registered
Activity