Комментарии 50
Алгоритм Дейкстры [...] относится к «жадным» алгоритмам, то есть достаточно эффективен для поиска путей на относительно небольших графах.
Мимими. Как из первого утверждения ("алгоритм относится к жадным") вытекает второе ("алгоритм достаточно эффективен")? "Жадность" алгоритма — это всего лишь указание на используемую в нем стратегию, эффективность может быть любой.
Теперь "достаточно эффективен [...] на относительно небольших графах". А на больших — не эффективен? А какой вы знаете более эффективный алгоритм, работающий в тех же допущениях, что и алгоритм Дийкстры?
(ну и да, если речь идет о разнице между оригинальным алгоритмом Дийкстры 1959-года (O(V2)) и современными его реализациями (O(E + V log V)), то утверждение "Алгоритм Дейкстры широко применяется и сегодня" неверно, потому что очевидно, что сегодня применяются современные реализации, а не оригинальная)
После прочтения «Заметок по структурному программированию», лично для себя ставлю его на особый и почти недостижимый уровень даже среди «отцов-основателей». Излагает ёмко, чётко, по существу. В ином предложении смыслов поболее, чем в многостраничных фолиантах некоторых «писучих товарищей». Пока ничего подобного по уровню, кроме, разве что, ещё «Основ квантовой механики» Дирака, не читал. А уж современные писульки а-ля «Совершенный код» — это вообще откровенное «бумагомарательство». Бумаге, конечно, вроде как, всё ровно, она, как говорят, «терпит», но вот читатель такого точно не заслуживает.
Пользуясь случаем: кроме «Заметок по структурному программированию» что бы вы советовали прочесть?
Ещё неплохая книга есть у Вирта: «Систематическое программирование. Введение». Но мне как-то Дейкстра больше по душе пришёлся. Даже могу сказать, намного больше, но это уже, подозреваю, всего-навсего личные пристрастия. А прямо сейчас медленно и вдумчиво читаю «Языки программирования. Концепции и принципы» за авторством Кауфмана. Ещё не дочитал, но уже могу смело советовать в тех же целях: чтобы приподняться с уровня Мартинов-Макконнеллов по наименованию переменных и оптимальному количеству параметров функции (т.е. по сути, кодирования) на уровень более куда более фундаментальных вещей (т.е. собственно программирования).
А уж современные писульки а-ля «Совершенный код» — это вообще откровенное «бумагомарательство»
Аргументируйте.
Аргументировать что? Вы сей опус читали? Там большинство «полезных советов» либо тривиальны донельзя (скажем, советы по наименованию), либо языко-специфичны (скажем, советы по использованию исключений для обработки ошибок и панический страх автора перед функциями с более чем двумя параметрами), либо представляют собой возведение более-менее здравой идеи в идиосинкратический абсолют (функции по 5 строк без параметров). Слишком много воды (аж на 450 страниц!), а реально полезных знаний крупицы. Если бы это всё называлось как-нибудь… ну не знаю «Записки стареющего Java-разработчика» и не пиарилось повсюду, то ладно, но уж чересчур претенциозное название и чересчур много шума из ничего. На фундаментальный труд никак не тянет, словоблудие сплошное по большому счёту. Так чего ради было столько бумаги марать?
Аргументировать что? Вы сей опус читали?
Да, конечны.
Там большинство «полезных советов» либо тривиальны донельзя
Тривиальны для кого?
Ну и да, давайте сравним с высказыванием, из, скажем, "On our inability to do much": "we should remain aware of the fact that the extent to which we can read or write a text is very much dependent on its size". Оно не тривиально?
(скажем, советы по наименованию)
Вы никогда не слышали про две фундаментальных проблемы computer science?
либо языко-специфичны (скажем, советы по использованию исключений для обработки ошибок
И что, они теперь бесполезны? Особенно учитывая, во скольких мейнстримных языках есть исключения, и сколько вокруг них войн.
Если бы это всё называлось как-нибудь… ну не знаю «Записки стареющего Java-разработчика»
Вас не смущает, что первое издание CC вышло за два года до Java?
уж чересчур претенциозное название
А что претенциозного в названии Code Complete?
Так чего ради было столько бумаги марать?
Ради того, чтобы можно было взять, открыть нужный раздел, и найти мнение, подтверждение конкретными исследованиями (а не абстрактным "мне кажется, что").
Тривиальны для кого?
Да для любого человека с 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
Да для любого человека с IQ, достаточным для того, чтобы быть программистом.
То есть программистам обучение не нужно, я вас правильно понял?
Первый раз слышу такое словосочетание. Это что ещё за «мем»?
"There are only two hard things in Computer Science: cache invalidation and naming things." (Phil Karlton, по цитатам, оригинал не найден)
Вообще, основная проблема в программировании — борьба со сложностью.
В этом контексте забавно сравнить высказывания МакКоннела ("Managing complexity is the most important technical topic in software development") и Дейкстры ("the art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible").
Нет, конечно.
Вот поэтому книга и существует.
Но, во-первых, как я уже сказал, полезного там на 450 страницах — «кот наплакал».
Если вы его там не нашли, это не значит, что его там нет.
Этих всяких Мартинов полезно читать после Дейкстры, а не до, и уж тем более не вместо.
А кто-то где-то говорил, что надо читать МакКоннела и/или Мартина и/или Фаулера и/или Ханта/Томаса вместо Дейкстры?
труды Дейкстры нынче библиографическая редкость
"Notes on structured programming", как и прочие рукописи Дейкстры, доступны онлайн.
И что это меняет?
То, что ни один стареющй Java-разработчик не принимал участия в написании Code Complete.
А что претенциозного в названии Code Complete?
В том что это оксюморон, нет? Очевидно недостижимая цель
То есть вы проект никогда не сдаете? "Code complete" — это устоявшееся выражение, означающее "программист работу закончил".
Это мы сейчас за какую книгу то говорим?
За Code Complete, очевидно.
То есть программистам обучение не нужно, я вас правильно понял?
Нет, не правильно. Определённый уровень интеллекта — лишь достаточный критерий, но не необходимый. Учиться надо, но не по «Чистым кодам».
«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 пока ещё слишком молодая наука, так что большинство «исследований» в ней таки находятся на этом самом уровне «мне кажется что» и «я считаю что»: обобщение собственного (в лучшем случае) коллективного опыта, социологические опросы. Зачастую, грош цена таким «исследованиям», зато есть чем список литературы набить для создания эффекта научности, да. :)
Учиться надо
Окей, следующий вопрос: вредна ли Code Complete (Pragmatic Programmer, Clean Code, Clean Coder...) при обучении программиста?
Тоже мне фундаментальные проблемы.
Понятно. Я искренне вам завидую, если и та, и другая у вас не встречаются или всегда легко решаются.
(впрочем, исходное высказывание шуточно, если вы вдруг этого не поняли)
Там, как минимум, втрое можно сократить без малейшей потери смыслов.
Это применимо почти к любой литературе, написанной человеком на натуральном языке. Он (натуральный язык), знаете ли, избыточен. Интереса ради, можете попробовать применить то же самое к Notes On Structured Programming, эффект получается занятным.
Берёте случайный ресурс для программистов и смотрите некий список книг, обязательных к прочтению
Меня слабо интересуют "случайные ресурсы для программистов", и я не отвечаю за их высказывания.
Так что, простите, не надо «ла-ля»: нет тут никакого устоявшегося выражения.
То есть вы думаете, автор его придумал из головы? Srsly? Опять-так, если вы чего-то не знаете, это не значит, что его не существует. "A release is called code complete when the development team agrees that no entirely new source code will be added to this release." (Wiki)
Другое дело, что последнее время (ну как, больше десяти лет уже) вообще идет много драк вокруг definition of done, но это уже вопрос процессуальный.
Там действительно много полезных отсылок к монографиям тех же Дейкстры, Вирта, GoF, и прочих
Эм. У Дейкстры есть хотя бы одна монография? В библиографии CC точно ни одной не упоминается. Монография Вирта? Вы про "Algorithms and Data Structures"? Она не цитируется в CC. Ну и да, чем она "фундаментальнее и монографичнее" Ахо-Хопкрофта-Ульмана или Седжвика или Кнута?
Какая разница: читать оригинал с «мне кажется что», или читать книгу, ссылающуюся на этот оригинал?
Так речь не идет о ссылках на "мне кажется что", речь идет о ссылках на конкретные статистические наблюдения за индустрией.
И эта Ваша Computer Science пока ещё слишком молодая наука
О, srsly, ей уже больше полтинника, ее в университетах преподают. Впрочем, я вообще не утверждаю, что это _наука, я считаю, что это дисциплина.
Это применимо почти к любой литературе, написанной человеком на натуральном языке. Он (натуральный язык), знаете ли, избыточен. Интереса ради, можете попробовать применить то же самое к Notes On Structured Programming, эффект получается занятным.
Применимо только в той или иной мере. Бывают такие «песни», из которых «слов не выкинешь». Каждое отдельное предложение в текстах Дейкстры может казаться тривиальным, но в сумме у него получаются очень даже нетривиальные выводы. Вот этого я у всяких Мартинов не вижу: тривиально, тривиально, тривиально, и так далее на 500-1000 страниц. Ску-ко-ти-ща.
То есть вы думаете, автор его придумал из головы?
Я не могу утверждать, что конкретно автор имел ввиду под Code Complete. Переводчики на русский, заметьте, интерпретировали заглавие именно как «Совершенный Код».
У Дейкстры есть хотя бы одна монография?
Ну привет. Упомянутые «Notes on Structured Programming» — вполне себе монография. То, что 3 монографии издали одной книгой не делает их чем-то иным.
Так речь не идет о ссылках на «мне кажется что», речь идет о ссылках на конкретные статистические наблюдения за индустрией.
Вот! Статистические наблюдения за индустрией — это уже куда более конкретный термин, нежели какие-то там исследования. Тут есть сразу два важных слова: статистические и индустрия. Про первое всё уже сказано и не раз: «Существуют три вида лжи: ложь, наглая ложь и статистика». Про второе: а что если индустрия идёт не туда? Что если попытки оптимизации труда программистов если и нашли какой-то минимум, то только локальный? Что если все эти советы несущественны?
Каждое отдельное предложение в текстах Дейкстры может казаться тривиальным, но в сумме у него получаются очень даже нетривиальные выводы.
Например, какие из первой главы NoSP, "On our inability to do much" (просто любопытно)? Кстати, учтите, что сам Дейкстра пишет о NoSP: "I felt that they suffered from a marked verbosity".
Я не могу утверждать, что конкретно автор имел ввиду под Code Complete.
Я привел вам ссылку на Wiki. МакКоннел — из MS, у них была вполне конкретная дисциплина (прослеживающаяся в MSDN), в которой Code complete — это фаза общего жизненного цикла приложения.
Ну привет. Упомянутые «Notes on Structured Programming» — вполне себе монография.
Привет-привет. NoSP — не монография. Во-первых, и в самых важных, так считает сам Дейкстра: "these notes have the status of "Letters written to myself" [...] as a document this is very incomplete". Во-вторых, монография "обычно" предполагает объем немного побольше и, что важнее, peer review.
Про первое всё уже сказано и не раз: «Существуют три вида лжи: ложь, наглая ложь и статистика».
И этот человек еще что-то говорит о "the only two hard things". Статистика — это факты, можно спорить с методикой сбора, можно спорить с методикой расчетов или выводами, но опровергать исследование только на основании того, что оно статистическое — глупо.
Про второе: а что если индустрия идёт не туда?
Тогда вам нужны инструменты определения того, что она идет не туда. Ну и да, вы хотите работать в другой индустрии? Тогда да, книги по этой индустрии вам не нужны.
Что если все эти советы несущественны?
Опыт показывает, что советы, описанные у МакКоннела, могут быть тривиальными (для тех, кто уже выяснил это из другого источника или опытным путем), избыточными (если мы работаем в другой среде), но они пока еще не оказывались несущественными — в том смысле, что они имеют влияние на процесс разработки.
NoSP — монография. «Letters written to myself» — это просто формат. Никаких ограничений по объёму на монографии не накладывается, монография — это по сути просто писанина на одну конкретную тему. Ограничения по объёму появляются только в том случае, когда монографии выполняет какую-то необязательную роль, скажем, когда используется в качестве докторской диссертации. Да и peer review, о чём автор прямо упоминает: «Prior to their publication in book form, the „Notes on Structured Programming“ have been distributed privatly» и далее по тексту «спасибки» ревьюверам. Плюсом там ревьювером был как минимум ещё редактора сери Хоара, который, кстати, в предисловии прямо называет работы, вошедшие в книгу монографиями.
И точно так же глупо верить результатам статистических исследований, не ознакомившись с ними. Вы оригинальные исследования то читали или просто верите автору «на слово»?
Статистика — это факты, можно спорить с методикой сбора, можно спорить с методикой расчетов или выводами, но опровергать исследование только на основании того, что оно статистическое — глупо.
И точно так же глупо верить результатам статистических исследований, не ознакомившись с ними. Вы оригинальные исследования то читали или просто верите автору «на слово»?
NoSP — монография [...] Никаких ограничений по объёму на монографии не накладывается, монография — это по сути просто писанина на одну конкретную тему.
Окей, давайте начнем с простого: какое определение монографии вы используете, и где вы его взяли?
Вы оригинальные исследования то читали или просто верите автору «на слово»?
Конечно, верю на слово. В этом, собственно, смысл рецензируемой (и редактируемой) публикации — проверка источников делается рецензентом и техническим редактором. Если я буду идти по каждой ссылке в книге (а не только по интересным мне или по тем, которые нужны для конкретной дискуссии), я никогда читать не закончу.
Окей, давайте начнем с простого: какое определение монографии вы используете, и где вы его взяли?
ГОСТ 7.60-2003, например, определяет монографию как (стр. 6, п. 3.2.4.3.1.1) «научное или научно-популярное издание, содержащее полное и всестороннее исследование одной проблемы или темы и принадлежащее одному или нескольким авторам». Никаких ограничений на объём тут быть не может, что называется, по определению: проблема проблеме рознь. Рецензирование, впрочем, тут подразумевается, ибо в современном мире издание вряд ли можно считать научным, если его не рецензировали профильные специалисты. Но, как я уже указывал выше, рецензирование имело место.
Конечно, верю на слово. В этом, собственно, смысл рецензируемой (и редактируемой) публикации — проверка источников делается рецензентом и техническим редактором.
Ну не знаю, не знаю. Как по мне, Вы поступаете не совсем правильно: цитирующий автор может запросто (нарочно или нет) исказить смысл цитируемого исследования, некорректно его интерпретировав, например. Так что таки следует читать как минимум выводы или резюме оригинального исследования. И никакое рецензирование Вас от этой обязанности не освобождает: ссылки на оригинальные исследования Вам, собственно, за этим и даны. Доверяй, но проверяй. А иначе, будь по-вашему, их бы давали только рецензентам, а из публичных копий убирали. :)
Если я буду идти по каждой ссылке в книге (а не только по интересным мне или по тем, которые нужны для конкретной дискуссии), я никогда читать не закончу.
Зачем ходить по не интересующим Вас ссылкам я, честно говоря, не очень понимаю. А просмотреть хотя бы резюме по интересующим — это не такая и времязатратная задача. Там всё равно около 1000 страниц читать, эка проблема глазами пробежать десяток другой abstract'ов. :D Конечно, если возникнут сомнения или просто появиться интерес к оригинальному исследованию, его придётся читать. Ну а что делать? Вам ссылки, повторюсь, за этим и даны.
ГОСТ 7.60-2003, например, определяет монографию как (стр. 6, п. 3.2.4.3.1.1) «научное или научно-популярное издание, содержащее полное и всестороннее исследование одной проблемы или темы и принадлежащее одному или нескольким авторам».
Агу. С момента "полное и всестороннее исследование" уже смешно?
Но, как я уже указывал выше, рецензирование имело место.
Раз уж пошла такая пьянка, можете указать, откуда именно вы цитируете фразу "Prior to their publication in book form, the „Notes on Structured Programming“ have been distributed privatly", и почему вы считаете, что она означает peer review?
Как по мне, Вы поступаете не совсем правильно: цитирующий автор может запросто (нарочно или нет) исказить смысл цитируемого исследования, некорректно его интерпретировав, например.
… за что его должны побить по рукам рецензент и/или редактор.
А иначе, будь по-вашему, их бы давали только рецензентам, а из публичных копий убирали
А мне их дают для того, чтобы я мог, если мне интересно, пойти и почитать побольше и поподробнее.
А просмотреть хотя бы резюме по интересующим — это не такая и времязатратная задача.
Серьезно? Вы пробовали это проделать для того же МакКоннела?
эка проблема глазами пробежать десяток другой abstract'ов.
Сколько-сколько? Вообще-то, в МакКоннеле 21 страница библиографии (извините, я сейчас не буду проверять, сколько из нее реально цитируется). Кстати, далеко не вся эта литератора доступна в открытом виде.
Вам ссылки, повторюсь, за этим и даны.
Зачем мне даны ссылки, я уже сказал выше.
… за что его должны побить по рукам рецензент и/или редактор.
В идеальном мире, да, должны. А в реальном, как говориться, Вам никто ничего не должен. Или, вспоминая актуальный ногомяч, как там было у Аршавина? «Ваши ожидания — это Ваши проблемы.» :) Программисты должны писать чистый код — это из той же оперы.
Серьезно? Вы пробовали это проделать для того же МакКоннела?
Я подобной работой занимаюсь каждый день. Иду к PhD (не в области информационных технологий, но не суть) и каждый божий день приходиться блуждать туда-сюда по куче ссылок и читать как минимум abstract'ы того, что цитируют. Поверьте, мир далеко не идеален. Часто цитируют даже не совсем ту работу (пускай и тех авторов), которую бы стоило процитировать (в том смысле, что утверждения, которое пытаются подкрепить цитированием, в цитируемой работе вообще нет ни в каком виде) :D А иногда вообще цитируют (сразу видно) даже не открывав оригинал: все цитируют, и ты цитируй. И ерунда что эти мифические все цитируют совсем в другом контексте. И рецензенты — тоже люди с теми же слабостями, запросто пропускающие чужие умышленные и неумышленные ошибки. Резюмируя: как минимум резюме/выводы цитируемых работ стоит пробегать глазами, чтобы не попасть впросак.
А в реальном, как говориться, Вам никто ничего не должен.
У нас с вами разные "реальные миры".
Программисты должны писать чистый код — это из той же оперы.
Ну, я вот считаю, что я должен писать чистый код.
Я подобной работой занимаюсь каждый день.
Я тоже "подобной работой" в свое время достаточно прозанимался на защитах и рецензировании. Так вот, затраты времени для меня несопоставимы с полученной выгодой.
У нас с вами разные «реальные миры».
Такое, конечно, возможно, но что-те не очень верится…
Так вот, затраты времени для меня несопоставимы с полученной выгодой.
Да мне тоже осточертело, но вот прямо сейчас заставить себя отказаться от привычки всё проверять хотя бы «по минимуму» не могу. Когда-то не мог себя приучить к этому, теперь не могу разучиться.
Консенсуса, как я вижу, у нас тут не получилось, но и обмен мнениями — «уже хлеб». :D
Впрочем, для изначальной темы обсуждения достаточно уже и того, что вопрос "полезно ли учиться по МакКоннелу" благополучно забыт, а обсуждаются только и исключительно монографии Дейкстры и статистические исследования. Что наводит на мысль, что с изначальным посылом вы больше не спорите.
А какой там был изначальный посыл? Как бы то ни было, если Вам так интересно, то мой ответ на вопрос: «Полезно ли учиться по МакКоннелу» очевидно: «Нет, так как там особо нечему учиться.» Пробежать глазами стоит, не более. Мартина даже пробегать глазами не стоит.
А какой там был изначальный посыл?
Первоначальный — что ваше утвеждение "Code Complete — откровенное "бумагомарательство" некорректно. Далее мы пришли к вопросу "вредна ли Code Complete (Pragmatic Programmer, Clean Code, Clean Coder...) при обучении программиста?"
«Полезно ли учиться по МакКоннелу» очевидно: «Нет, так как там особо нечему учиться.»
О, а расскажите мне, пожалуйста, откуда начинающему программисту научиться правильному именованию? Документированию кода? Основам рефакторинга?
Изначальный посыл был всё-таки про Clean Code, уже потом в качестве ещё одного примера я упомянул Code Complete, а про Pragmatic Programmer я вообще ничего не говорил. Хотя есть стойкое ощущение, что всё это одного поля ягоды, но это скользкая дорожка. Pragmatic Programmer не читал и пока, как следствие, не осуждаю. По второму вопросу, в очередной раз повторю, правильному именованию, документированию кода, основы рефакторинга — это всё существенно только для кодирования. С точки зрения программирования — это «шелуха». А проблема в том, что этой «шелухой» часто подменяют программирование. Впрочем, я уже это говорил в этой теме…
Изначальный посыл был всё-таки про Clean Code
Правда? "А уж современные писульки а-ля «Совершенный код»" Ни слова про "Clean Code".
По второму вопросу, в очередной раз повторю, правильному именованию, документированию кода, основы рефакторинга — это всё существенно только для кодирования. С точки зрения программирования — это «шелуха».
Вот только без этой, как вы выражаетесь, "шелухи" программирования не будет. Все эти навыки — обязательное (хотя и не достаточное) предусловие для становления программиста. В частности, если программирование — это управление сложностью, то правильное именование — обязательное условие управления сложностью (вы не можете адекватно воспринимать программу, в которой нарушено именование).
В самом начале я перепутал название: книга Мартина называется таки «Чистый код», да.
Это не мешало вам потом все те же самые претензии высказывать Code Complete (я название упомянул сразу же). Кстати, в названии Clean Code тоже нет ничего претенциозного.
И еще раз кстати: а чем, бишь, мартиновские соглашения по именованию "тривиальнее" макконнеловских? Между прочим, прекрасная глава, еще и существенно менее занудная, нежели у МаКоннела.
Потому что всё то же самое верно и про Code Complete. Она только длиннее, скучнее и с претензией на большую научность.
Я не считаю мартиновские соглашения по именованию «тривиальнее» макконнеловских. Я и те, и другие считаю вещью даже не второстепенной и тривиальной. Вот я сейчас глянул с свои заметки по книге Мартина, я себе из всей «воды» про именования «отжал» только одно замечание, которое считаю достаточно нетривиальным: про длину имён. «The longer the scope of a variable, the longer is its name; variables in very short scopes should have very short names.» А для классов и функций — наоборот.
Я не говорю, что остальные советы вредны или бесполезны, они просто ну донельзя тривиальны. При их прочтения у меня возникает только один вопрос: «А как вообще может в голову придти делать как-то иначе?» Возможно, кончено, для меня они кажутся тривиальными, потому что есть опыт работы с большими и достаточно формальными (хоть и не программными) текстами на естественном языке, к которым почти все эти правила точно так же применимы. Имена должны быть содержательными, легко произносимыми, удобными для поиска, никаких шуточек и каламбуров, единственный термин для каждой отдельной концепции, и т.д. и т.п. Ну да, ну да, всё так. Но я повторю свою изначальный тезис: это всё ну уровень Дейкстры. Книжки а-ля «Чистый код» могут написать сотни и тысячи авторов (и, собственно, и пишут), а на тексты уровня «Заметок по структурному программированию» способны единицы.
Я не считаю мартиновские соглашения по именованию «тривиальнее» макконнеловских. Я и те, и другие считаю вещью даже не второстепенной и тривиальной. Вот я сейчас глянул с свои заметки по книге Мартина, я себе из всей «воды» про именования «отжал» только одно замечание, которое считаю достаточно нетривиальным: про длину имён. «The longer the scope of a variable, the longer is its name; variables in very short scopes should have very short names.» А для классов и функций — наоборот.
Я не говорю, что остальные советы вредны или бесполезны, они просто ну донельзя тривиальны. При их прочтения у меня возникает только один вопрос: «А как вообще может в голову придти делать как-то иначе?» Возможно, кончено, для меня они кажутся тривиальными, потому что есть опыт работы с большими и достаточно формальными (хоть и не программными) текстами на естественном языке, к которым почти все эти правила точно так же применимы. Имена должны быть содержательными, легко произносимыми, удобными для поиска, никаких шуточек и каламбуров, единственный термин для каждой отдельной концепции, и т.д. и т.п. Ну да, ну да, всё так. Но я повторю свою изначальный тезис: это всё ну уровень Дейкстры. Книжки а-ля «Чистый код» могут написать сотни и тысячи авторов (и, собственно, и пишут), а на тексты уровня «Заметок по структурному программированию» способны единицы.
Потому что всё то же самое верно и про Code Complete
Ну значит тот факт, что вы в начале перепутали название, особого значения не имеет (хотя, конечно, и забавен). И, значит, ваш "изначальный посыл" равноприменим к обеим книгам.
Я не считаю мартиновские соглашения по именованию «тривиальнее» макконнеловских. Я и те, и другие считаю вещью даже не второстепенной и тривиальной. Вот я сейчас глянул с свои заметки по книге Мартина, я себе из всей «воды» про именования «отжал» только одно замечание,
Согласитесь, что это что-то говорит о книге только в контексте ваших знаний на момент, когда вы ее читали?
Я не говорю, что остальные советы вредны или бесполезны, они просто ну донельзя тривиальны. При их прочтения у меня возникает только один вопрос: «А как вообще может в голову придти делать как-то иначе?»
Да легко. Я ежедневно вижу код (разного происхождения), который эти советы игнорирует и нарушает.
Но я повторю свою изначальный тезис: это всё ну уровень Дейкстры.
Ну, с этим тезисом я спорить не буду, особенно учитывая что он восхитительно неоднозначен. Дело, однако же, в том, что из этого тезиса никак не вытекает, что Clean Code или Code Complete — "откровенное "бумагомарательство"". Учебники для школы и для ВУЗа — на разных уровнях, и оба этих уровня — не уровень докторской диссертации… и что? Учебники не нужны?
Я повторю единожды уже заданный вопрос: по каким книгам (предпочтительно, конечно, Дейкстры или "уровня Дейкстры") начинающему программисту научиться правильному именованию?
НЛО прилетело и опубликовало эту надпись здесь
Про «бумагомарательство» — это, конечно, утрирование было, или, как нынче модно говорить, «наброс», но, ей богу, на 450 страниц у того же Мартина есть явный перебор «тривиальщины», постоянных повторений и откровенной «воды». А по поводу стратегии и тактики, я где-то даже соглашусь с Вами. Но отметьте, что тактика — это всего лишь инструмент реализации стратегии, т.е. первична то именно стратегия. А теперь простой вопрос: сколько по Вашему мнению программистов ознакомились со стратегией (Дейкстра, Вирт) перед тактикой (Мартин, Макконнелл)? Уже отмеченный выше факт, что труды Дейкстры и Вирт — нынче библиографическая редкость как бы намекает на правильный ответ.
Я бы сказал подругому. Один пишет, что нельзя скручивать медь и алюминий без аргументации. Второй объясняет почему именно нельзя (и не только медь и алюминий, медь с железом тоже классную биметаллическую пару организует) и не забывает описать как их можно все-таки скрутить, если очень приперло, с минимальными жертвами для себя и окружающих.
НЛО прилетело и опубликовало эту надпись здесь
Безотносительно темы спора, чисто по форме… начинаю понимать, почему Alan Kay сказал
I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras.Не знаю, относится ли это непосредственно к Дейкстре… но к некоторым моментам этой переписки — емким, четким и по существу — вполне… ;)
брал вилку слева от себя… приходилось брать вилку и справа от себя… Если вилка требовалась другому философу, ему приходилось ждать, пока она освободится.
Звучит как практическое пособие по созданию Deadlock.
Наоборот, на этом примере им были даны пути разрешения этих самых Deadlock-ов.
Похоже вы путаете «Deadlock» (взаимная блокировка) с синхронизацией доступа. Пример объясняет как синхронизировать доступ к ресурсу. Но делает он это не правильно, так как нарушен принцип установки взаимоотношений между блокировками. Так, например все философы сначала берут правую вилку. Но понятие правая вилка — относительно и у каждого философа своё. И если так случится что все философы сядут за стол одновременно — то они все возьмут «правые» вилки и будут ждать «левые» — вот тут и случиться Deadlock.
Не поверите: этот пример и придуман для того, чтоб продемонстрировать опасности блокировки и способы их избегания. Более того, процитированный текст опускает тот факт, что по условиям философы берут вилки последовательно, так что философ, ожидающий освобождения вилки при этом может держать другую вилку в руке.
Очень надеюсь, что когда-нибудь люди перестанут считать программирование «великим творчеством». Может быть, до Дейкстры это было так, но он сам всё творчество убил, и слава Дейкстре, ни он, ни Вирт, ни Хоар творчество не воскрешали.
Очень странный аргумент. Программирование как ремесло подходит только с задачами где все давно решили обсосали и оно проиндексровалось в гугле. Как только доходит до чуть более нетривиального функционала, это уже походит на творчество. Читая некоторые опусы по embedded системам например можно часто наткнуться как автор очень хитро решает проблему нехватки ресурсов/портов и так далее. Чем это не творчество?
Прямо скажем, странно противопоставлять ремесло и творчество.
Вы же не считаете творчеством строительные работы? Там может творчество архитектора где-то когда-то произошло, но на этапе строительства всё должно быть чётенько и по гостам. Такое вот разделение уровней творческости, с поправкой на особенности нематериального мира.
«Таджикам» 21-го века не нужно быть конструктивистами на рабочем месте.
«Таджикам» 21-го века не нужно быть конструктивистами на рабочем месте.
Как раз эти «поправки» на особенности нематериального мира тут и играют определяющую роль. Фантазируй, твори, машина стерпит. В реальном то мире «фантазёрам» обычно очень быстро «прилетает» от матушки-природы. :D Там то правила игры жёсткие и определяются не человеком, а тут ну такой простор для «творчества», такой простор…
>> Очень надеюсь, что когда-нибудь люди перестанут считать программирование «великим творчеством».
Позвольте ответить цитатой, из одной книги по программированию: ”Программа – это Идея, изложенная программистом на языке программирования".
Таким образом, до тех пор пока задача создания программ будет требовать от программиста интеллектуальных усилий, программирование будет считаться творчеством…
Позвольте ответить цитатой, из одной книги по программированию: ”Программа – это Идея, изложенная программистом на языке программирования".
Таким образом, до тех пор пока задача создания программ будет требовать от программиста интеллектуальных усилий, программирование будет считаться творчеством…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эдсгер Дейкстра: в поисках «кратчайшего пути» к осознанному программированию