![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
компьютерное: об учебниках и учебных пособиях
Большинство компьютерных учебников не нравятся мне потому, что они написаны слишком медленно и длинно, слишком долго всё разжёвывают для тупых или неопытных.
Те же из них, которые пробегают материал быстро, обычно упускают всё самое важное, упускают суть того или иного языка программирования, или технологии, или чего угодно ещё, и вместо этого проходят по верхам.
Представьте себе шкалу, в начале которой находится простенькое и примитивное введение в какую-то тему для тех, кто вообще в этом ничего не смыслит; на отметке примерно в треть шкалы — пособие типа “... для чайников” или “... за 21 день”; в середине шкалы — солидный и хороший учебник по данной компьютерной технологии, не предполагающий, однако, от читателя никаких серьёзных знаний ни в чём, кроме разве что самых основ программирования или работы с компьютером; а в самом конце шкалы пусть будет Reference Manual, полный и подробный отчёт о всех аспектах и подробностях данной технологии (например, если это язык — список всех синтаксический конструкций, ключевых слов, встроенных функций). По Reference Manual обычно выучить технологию невозможно, т.к. он предназначен для тех, кто уже её знает и понимает. Или ещё в конце шкалы может быть формальный стандарт, фиксирующий во всех подробностях определённую стандартную версию данной технологии.
Введение этой одномерной метафоры сильно упрощают реальную картину, но тем не менее, воспользуюсь ей. Тогда идеальное для меня учебное пособие лежит где-то на отметке 75-85% данной шкалы. Это быстрое и одновременно глубокое введение в данный предмет для “хакеров” в хорошем смысле этого слова. Оно предполагает, что читающий его человек схватывает тривиальные вещи на лету, и заинтересован в том, чтобы понять не только “как с этим работать”, но и в определённой степени “как это устроено внутри”. Что ему ничего не нужно разжёвывать, а если уж что-то обсуждается долго и подробно, то это действительно сложная и действительно важная для понимания всего предмета вещь. В зависимости от того, о чём оно рассказывает, оно предполагает от читателя хорошее знание и знакомство с началами данной области. Его можно изучить довольно быстро, и вместе с тем понять довольно многое и усвоить главное.
(кстати, иногда бывает так, что формальный стандарт, или что-то близкое к Reference Manual, написаны так хорошо, что их можно использовать в качестве такого пособия. Например, для человека, который примерно понимает, что такое HTML и как его пишут, идеальным пособием для изучения XML в моём понимании является просто W3C-шный стандарт XML. Когда мне понадобилось изучить XML как технологию, я просто распечатал стандарт и прочитал; он написан очень хорошо, и его авторы явно старались обеспечить именно такую возможность: чтобы грамотный человек, которому не нужно разжёвывать очевидное, мог прочитать от начала до конца и выучить данную технологию без предварительного с ней знакомства. Ещё один пример — документация Перла, так называемые PODs; кроме того, что они являются reference manual всего языка, большинство возможностей Перла можно выучить прямо по ним (правда, “с нуля” не выйдет, какое-то начальное, пусть очень примитивное, знакомство с языком должно быть). Я так в своё время и сделал (прочитал первые две главы какого-то учебника Перла и бросил, слишком медленно было; с остальным разобрался, читая программы и документацию языка). В качестве ещё одного примера, на этот раз для сетевых технологий, могут служить многие RFC.)
Для чего я всё это написал? 1. Чтобы упорядочить свои мысли по этому поводу и определить точнее для себя, что я понимаю под идеальным учебным пособием. 2. Чтобы узнать, что по этому поводу думают другие и как они себе представляют идеальный с их точки зрения учебник/учебное пособие/FAQ/что угодно; кто согласен с этим моим представлением, кто не согласен и почему; какие есть хорошие и плохие примеры; и всё, что угодно будет заинтересованным читателям высказать на эту тему.
P.S. Всё вышесказанное не отменяет, конечно, необходимости в учебниках для совсем новичков, которым действительно нужно всё очень подробно объяснять и разжёвывать! И ничего плохо в таких учебниках нет, конечно. Просто я думаю, что тому, у кого уже есть определённый уровень знаний, опыта, смекалки, профессионализма — определяйте как угодно — гораздо лучше подойдёт пособие такого вида, который я описываю в данной записи. Ну или по крайней мере в отношении меня лично это так.
Те же из них, которые пробегают материал быстро, обычно упускают всё самое важное, упускают суть того или иного языка программирования, или технологии, или чего угодно ещё, и вместо этого проходят по верхам.
Представьте себе шкалу, в начале которой находится простенькое и примитивное введение в какую-то тему для тех, кто вообще в этом ничего не смыслит; на отметке примерно в треть шкалы — пособие типа “... для чайников” или “... за 21 день”; в середине шкалы — солидный и хороший учебник по данной компьютерной технологии, не предполагающий, однако, от читателя никаких серьёзных знаний ни в чём, кроме разве что самых основ программирования или работы с компьютером; а в самом конце шкалы пусть будет Reference Manual, полный и подробный отчёт о всех аспектах и подробностях данной технологии (например, если это язык — список всех синтаксический конструкций, ключевых слов, встроенных функций). По Reference Manual обычно выучить технологию невозможно, т.к. он предназначен для тех, кто уже её знает и понимает. Или ещё в конце шкалы может быть формальный стандарт, фиксирующий во всех подробностях определённую стандартную версию данной технологии.
Введение этой одномерной метафоры сильно упрощают реальную картину, но тем не менее, воспользуюсь ей. Тогда идеальное для меня учебное пособие лежит где-то на отметке 75-85% данной шкалы. Это быстрое и одновременно глубокое введение в данный предмет для “хакеров” в хорошем смысле этого слова. Оно предполагает, что читающий его человек схватывает тривиальные вещи на лету, и заинтересован в том, чтобы понять не только “как с этим работать”, но и в определённой степени “как это устроено внутри”. Что ему ничего не нужно разжёвывать, а если уж что-то обсуждается долго и подробно, то это действительно сложная и действительно важная для понимания всего предмета вещь. В зависимости от того, о чём оно рассказывает, оно предполагает от читателя хорошее знание и знакомство с началами данной области. Его можно изучить довольно быстро, и вместе с тем понять довольно многое и усвоить главное.
(кстати, иногда бывает так, что формальный стандарт, или что-то близкое к Reference Manual, написаны так хорошо, что их можно использовать в качестве такого пособия. Например, для человека, который примерно понимает, что такое HTML и как его пишут, идеальным пособием для изучения XML в моём понимании является просто W3C-шный стандарт XML. Когда мне понадобилось изучить XML как технологию, я просто распечатал стандарт и прочитал; он написан очень хорошо, и его авторы явно старались обеспечить именно такую возможность: чтобы грамотный человек, которому не нужно разжёвывать очевидное, мог прочитать от начала до конца и выучить данную технологию без предварительного с ней знакомства. Ещё один пример — документация Перла, так называемые PODs; кроме того, что они являются reference manual всего языка, большинство возможностей Перла можно выучить прямо по ним (правда, “с нуля” не выйдет, какое-то начальное, пусть очень примитивное, знакомство с языком должно быть). Я так в своё время и сделал (прочитал первые две главы какого-то учебника Перла и бросил, слишком медленно было; с остальным разобрался, читая программы и документацию языка). В качестве ещё одного примера, на этот раз для сетевых технологий, могут служить многие RFC.)
Для чего я всё это написал? 1. Чтобы упорядочить свои мысли по этому поводу и определить точнее для себя, что я понимаю под идеальным учебным пособием. 2. Чтобы узнать, что по этому поводу думают другие и как они себе представляют идеальный с их точки зрения учебник/учебное пособие/FAQ/что угодно; кто согласен с этим моим представлением, кто не согласен и почему; какие есть хорошие и плохие примеры; и всё, что угодно будет заинтересованным читателям высказать на эту тему.
P.S. Всё вышесказанное не отменяет, конечно, необходимости в учебниках для совсем новичков, которым действительно нужно всё очень подробно объяснять и разжёвывать! И ничего плохо в таких учебниках нет, конечно. Просто я думаю, что тому, у кого уже есть определённый уровень знаний, опыта, смекалки, профессионализма — определяйте как угодно — гораздо лучше подойдёт пособие такого вида, который я описываю в данной записи. Ну или по крайней мере в отношении меня лично это так.
no subject
Вот мой учебник по С# - где-то на отметке 68%
no subject
no subject
+wikipedia
no subject
Совет =))
второе, все, что не понимаешь -- узнавай у местных гуру или на форумах, форум -- самый лучший способ получить правильный ответ и даже больше, но если дорого время, а оно дорого -- вперед в ирку, желательно буржуйскую, я не хочу сказать, что у нас нет людей, есть конечно и самый лучшие, но там они всегда говорят по теме, а у нас любят пошутить, ну или просто висят трупами, а те малолетки, что сидят на каналах больше читирую книжки для чайников, чем могут реально помочь, а вот буржуи в самый раз в этом вопросе, и даже, если они не скажут все, чего нужно, то уж точно натолкнут на нужную идею.
Ну и последнее, читай литературу из серии (что-то за 24 часа) например C++ за 24 часа. Правда на русском я такое издание видел только один раз в Москве и не купил... Зато имею большую серию этих вещей на буржуйском в ПдФ =)) В сети их можно найти на ряде фтпшников, но лучше всего в осле пошарить... Там раскрывают кучу полезных тем. Будь то программирование, использование систем, администрирование, скрипты, БД или кропта. Это именно литература для быстрого и качественного изучения. Я еще не видел ни одной книги, где так правильно выделялись бы особо важные моменты и при этом на них не тратилось больше 10 минут собственного времени. Используй и радуйся.
dolton 2004
Re: Совет =))
Re: Совет =))
no subject
Для языков программирования или технологий вроде XML, имхо, правильный учебник:
а) ни в коем случае не должен приближаться к reference manual. Иначе проще прочитать мануал.
б) ни в коем случае не должен разжевывать азы. Для этого есть буквари (ну или там, учебники по информатике для нулевого уровня).
в) должен давать общее представление о структуре предмета (основы синтаксиса, внешний вид программы) при помощи примеров.
г) должен концентрироваться на ключевых особенностях системы, не углубляясь в детали и отсылая к reference manual.
д) примеры должны быть краткими. Полные листинги программ мало кому нужны в книге.
Впрочем, я таких учебников не читал. После определённого опыта уже достаточно иметь обзорную статью и reference, чтобы начать работать.
no subject
Есть ли такой учебник (или учебное пособие, это необязательно должна быть книга, может даже быть длинный FAQ или серия статей или что угодно), который Вы предпочли бы прочесть вместо "обзорной статьи и reference"? Вот я считаю, что есть, несмотря на то, что я обычно тоже учу новые вещи по "обзорной статье и reference". Просто потом постфактум я понимаю, что было бы гораздо лучше, если бы какие-то важные и глубокие вещи мне объяснили сразу, вместо того, чтобы я осознавал их важность постепенно. Обзорная статья не может это дать; reference - тем более, кроме тех довольно редких случаев, когда reference сам оформлен в виде документа, помогающего изучить данный предмет.
no subject
С удовольствием прочитал бы что-нибудь фундаментальное про организацию проектов. Только времени всегда не хватает...
no subject
(Anonymous) 2004-08-16 01:17 pm (UTC)(link)Интересно, конечно, было бы послушать, кто читал какие хорошие книжки. Такие, что и перечитывать приятно.
Из языковых, очевидно, Керниган и Ричи по Си. Довольно неплох Строустрап по C++. Kent Dybvig on Scheme. А еще?
Из неязыковых. Про операционки неплох по охвату и точности, хотя и скучноват, Vahalia, _Unix Internals_. А вот Таненбаум в разных изданиях читабелен, на манер юмориста, но слишком тенденциозен и ненадежен.
Radia Perlman's _Internetworking_ совершенно замечательная.
Sedgewick про алгоритмы очень мил.
А больше?
Про распределенные системы вообще как-то ни разу удачных книжек не попадалось.
no subject
По Смоллтоку стандартная Smalltalk 80: The Language очень хороша.
Таненбаум мне тоже не понравился, а лучше ничего я так и не прочитал.
Надо ещё подумать и вспомнить.
no subject
(Anonymous) 2004-08-16 03:26 pm (UTC)(link)"Design and Evolution of C++" - книга не просто "как", а еще и "почему" и какие альтернативы рассматривались.
no subject
no subject
no subject
(Anonymous) 2004-08-16 01:30 pm (UTC)(link)no subject
no subject
no subject
no subject
no subject
http://webmonkey.wired.com/webmonkey/98/15/index0a.html
(когда надо было что-то сделать БЫСТРО :) )
Вообще, CSS, на мой взгляд, не лучший пример для обсуждения учебников - ничего особо глубокого и тонкого там нет, его действительно можно по reference учить.
Хотя, может что и изменилось - я этим последний раз занимался года четыре назад...
no subject
Проблема с СSS в том, что там постоянно выявляются новые баги и появляются новые способы их обхода, да и то, что "по спецификации" должно бы работать, иногда отказывается при определенных условиях. Конечно, никакая буиажная книга за этим не уследит...
no subject
Насчёт XML не знаю, не знаю. По одному стандарту не очень-то, надо бы и примеры посмотреть. Впрочем, без примеров всегда стрёмно.
no subject
Проблема, к сожалению, одна - для одних очевидно одно, а сложно другое, и наоборот. Даже если накопленный багаж похож.
Разве не бывает так, что какая-то вроде бы очевидная вещь в руководстве ну никак не хочет пониматься?
no subject
no subject
no subject
С другой стороны, процесс обучения итеративен, так что имеет смысл создавать группы учебников по одной теме, полный новичок может освоить простой учебник и перейти к более сложному, по той же теме (если есть необходимость) и так - пока не достигнет удовлетворительного уровня. Продвинутый студент может начать сразу с более высокого уровня. Если студент продвинут неравномерно (есть лакуны в знаниях), что более реально, то по соответствующей теме он сможет спустится на более низкий уровень, подтянуть эту тему, подняться обратно на высокий уровень и продолжать.
В идеале - "сетка", по одной координате - сложность, по остальным - области знания. Только трудоемко это. Разве что wikipedia эволюционирует - помимо широты приобретя глубину.
no subject
1) Прочитать высокоуровневый обзор, чтобы усвоить основные концепции. Это упрощает ориентацию в Reference.
2) Прочитать Reference (возможно, читать его по мере надобности, предварительно просмотрев для уяснения возможностей). Это дает представление о имеющихся в языке/технологии возможностях.
3) Читать продвинутую литературу, выхватывая из контекста общие принципы использования, и вникая в описываемые тонкости. Это дает хорошее понимание технологии, необходимое для ее эффективного использования.
Самое интересное, что второй этап можно пропустить (я более-менее ориентируюсь в .NET и даже несколько раз помогал .NET-программерам, при том, что я не написал ни одной строчки на .NETе, а просто читаю блоги майкрософтовцев, обсуждающих детали реализации технологии).
Собственно, идеальный учебник в моем понимании состоит из этих трех частей (пропорция примерно 10/40/50).
no subject
no subject
no subject
no subject
Наверное один хороший учебник
1. Поверхностное введение-обзор
2. Продвинутый подробный-скучноватый мануал
3. Справочник.
Немного частностей. Вот для CSS -- очень хорошо (и достаточно) официального справочника w3c, так же, как и для HTML-XHTML. Официальный мануал по PHP -- тоже самодостаточная вещь включающая в себя все 3 пункта.
А вот XML по мануалу учить, ох уж очень он тягомотен и перегружен лингвистическими поределениями (что-то :: предмет1|предмет2...). Хорошей книжки я по XML так и не прочитал, но пары вводных-дурацких хватило, чтобы можно было официальный референс читать. По XSLT книжка Майкла Кея -- абсолютный маст рид.
По перлу мне очень нравились книжки O'Reilly, в то время как ман-страницы перла казались слишком невнятно организованными.
no subject
Часто раздражают неабстрактные примеры. На полстраницы объяснение некой тонкости, а перед этим на страницу описание задачи, для решения которой нам полезна эта тонкость. Задача типа "Нам нужен класс, описывающий самолет. У него будут методы - летать, сидеть, стоять. Метод "летать" будет позволять ему летать итд." Такие примеры, конечно, иногда полезны, но мне всегда кажется, что их слишком много и что они перегружены деталями. Будто читатель - школьник, которому скучен сам предмет и которого надо развлекать отступлениями про машинки и зверюшек.
Оба эти момента кажутся просто погоней автора за большим объемом.
no subject
А TeXBook Кнута читал уже совсем позже, в основном для интереса и наслаждения.
no subject
no subject
2) иногда полезно прочитать книжку по технологии, в которой 80-90% материала тебе знакомо, не толко затем, чтобы узнать недостающие 10-20% тонкостей, но и для того, чтобы увидеть взаимосвязи знакомого, которые раньше не были очевидны.
no subject
Есть книги, которые читаются как художественная литература (если читателю предмет интересен, конечно). Таких единицы и они как правило не являются полноценным учебником, а скорее концентрируются на достаточно продвинутой теме. Как пример могу порекомендовать "Modern C++ Design" Alexandrescu - эта книга открыла для меня целый пласт языка с которым я считал себя знакомым достаточно хорошо.
Еще мне нравится подход "[More] Effective C++" Meyers: набор автономных небольших статей для людей знакомых с материей в целом. Когда интересует конкретный вопрос - читаешь соответсвующую статью и получаешь достаточно глубокое понимание достаточно узкой темы.
Линейно мыслите,
no subject
no subject
no subject
просто: "всё не так, и вы ничего не понимаете", не подтверждая это
никакими аргументами? И это притом, что я специально в записи
подчеркнул, что понимаю, что моя шкала значительно упрощает реальность,
которая более сложна. Казалось бы, отсюда следует, что повторить, что
она упрощает - значит ничего нового не сказать, а чтобы сказать что-то
новое, нужно привести какие-то аргументы, убеждающие, что она
слишком упрощает, и что "не в этом суть".
Мне это кажется похожим больше не на удачную затравку, а на
пренебрежительный жест, не подкреплённый ничем реальным. Если Вы хотите
сформулировать какую-то более конкретную точку зрения, или привести
какие-то аргументы - это я с удовольствием послушаю.