Алан Кей — это магистр Йода для ИТишников. Он стоял у истоков создания первого персонального компьютера (Xerox Alto), языка SmallTalk и концепции «объектно-ориентированного программирования». Он уже много высказывался о своем взгляде на образование в сфере Computer Science и советовал книги тем, кто хочет углубить свои познания:
- Алан Кей: как бы я преподавал Computer Science 101
- Алан Кей: «Какие книги Вы бы посоветовали прочесть тому, кто учится на Computer Science»
- Алан Кей (и коллективный интеллект Хабра): какие книги формируют мышление тру инженера
- Алан Кей и Марвин Мински: Computer Science уже имеет «грамматику». Нужна «литература»
Недавно на Quora опять подняли эту тему и обсуждение вышло на первое место на Hacker News. Предлагаю вашему вниманию «новый» список суперстарых и фундаментальных книг по программированию и мышлению программиста от Алана Кея.
Lisp 1.5 Programmers Manual
by John McCarthy, 1962
Книга — абсолютный чемпион и пожизненный лидер рейтинга всех списков книг от Алана Кея. Этой версии языка уже нет, но книга — великолепна.
ещё восемь раритетов:
Computation: Finite and Infinite Machines
by Marvin Minsky, 1967
Марвин Минский «Вычисления и автоматы» (рус, djvu).
Advances in Programming and Non-Numerical Computation
ред. L. Fox, 1966
The Mythical Man-Month
by Fred Brooks, 1975
Мифический человеко-месяц (PDF, 171 стр)
The Sciences of the Artificial
by Herb Simon
The Sciences of the Artificial (PDF, 241 стр)
Книга Герберта Саймона (лауреата премии Тьюринга и Нобелевской премии) на русском (djvu).
Герберт Саймон не читал газет и не смотрел телевизор, поскольку считал, что если случится что-то действительно важное, ему об этом кто-то обязательно расскажет, так что не стоит зря тратить время на СМИ.
— Википедия
A Programming Language
by Ken Iverson, 1962
Control Structures for Programming Languages
by Dave Fisher, 1970
Control Structures for Programming Languages (PDF, 216 стр)
The Metaоbject Protocol
by Kiczales
Joe Armstrong’s PhD thesis
Джо Армстронг, создатель Erlang.
Joe Armstrong's PhD thesis (PDF, 295 стр)
P.S.
Два вопроса хабрачитателям:
- Какие олдскульные книги вы считаете обязательными к прочтению?
- Какие книги не по программированию повысили ваш навык мышления/мировоззрения программиста?
Комментарии (69)
edogs
11.08.2019 21:17+1Мифический человеко-месяц читали, но не поняли откровенно говоря что там такой хайп вокруг него. Много околоочевидной теории которая в реальных кейсах малоприменима, даже несмотря на некоторые казалось бы практические кейсы.
Странно что нет Дональда Кнута «искусство программирования», обычно его всюду пихают в рекомендацию. Книга для понимания требует некоторого знания математики, но все в пределах вузовской программы. И ее стоит прочитать хотя бы что бы знать что какие-то вещи в принципе существуют и какие вещи как работают, даже если не понятно будет как они применяются на практике.
DarkTiger
11.08.2019 22:16+5Мифический человеко-месяц читали, но не поняли откровенно говоря что там такой хайп вокруг него
Счастливый Вы человек, если не поняли. Это означает, что Вам в горящий по срокам проект не пихали принудительно сверху людей не в теме, потом удивлясь на голубом глазу «Ну я ж вам еще полкоманды дополнительно дал за три месяца до окончания, и вы все равно умудрились профакапить сроки! Как так-то?»
Причем это Брукс писал про IBM, где с Devops традиционно хорошо. Особенный смак получается в exUSSR, когда новички вынуждены сами настраивать себе среду разработки, писать айтишникам заявки на доступ к репозиториям и т.д и т.п., дополнительно отвлекая на это своими вопросами силы основной рабочей группы.
JekaMas
12.08.2019 02:36+2Вместо Кнута я бы советовал Кормена и компанию. Без придуманных ЯП и, на мой взгляд, легче читается.
Хотя вру, вообще стоит начинать с Теоретического минимума по CS + грокаем алгоритмы. А если зацепит, то Кормена.
ericgrig
11.08.2019 21:25Эти гниги написаны талантливыми людьми. Их приятно читать. Каждый извлечет для себя что то полезное. Иногда помогает «вправить» мозги. Спасибо автору за подборку!
Griboks
11.08.2019 22:41А как проверить, что именно эти книги лучше других? Есть ли какие — то показатели, программы обучения, статистические данные? Или их советуют прочитать только потому, что так сказали прославившиеся в свое время люди в области IT.
shaukote
11.08.2019 23:52+1Мне кажется, что в данном случае это скорее субъективное мнение Алан Кея. Насколько этому мнению доверять — каждый решает сам за себя.
QtRoS
12.08.2019 00:21+1Жемчужины программирования — одна из лучших книг из классики как по мне.
MagisterLudi Автор
12.08.2019 01:02
Бентли Дж. «Жемчужины программирования» (2-е издание) (2002, DjVu)
Первая публикация: 1986 г.
snamef
12.08.2019 02:58Да, старые языки типа Лиспа или Эрланга имели интересные концепции. Это потом для метапрограммирования стали писать уродливые #define
KoCMoHaBT61
12.08.2019 06:36Старый язык Эрланг?
adictive_max
12.08.2019 07:03Ну как бы 1987. Конечно, если сравнивать с совсем уж древними, типа Лиспа или Алгола, то не особо старый. Но с другой стороны, всего на 4 года новее самых первых плюсов.
FForth
12.08.2019 03:40+1ЛЕО БРОУДИ «СПОСОБ МЫШЛЕНИЯ — ФОРТ ЯЗЫК И ФИЛОСОФИЯ ДЛЯ РЕШЕНИЯ ЗАДАЧ»
Л. Броуди «НАЧАЛЬНЫЙ КУРС ПРОГРАММИРОВАНИЯ НА ЯЗЫКЕ ФОРТ»
С.Н.БАРАНОВ Н.Р. НОЗДРУНОВ «ЯЗЫК ФОРТ И ЕГО РЕАЛИЗАЦИИ»
P.S. + Язык СИ для профессионалов
P.P.S. Некоторое дежявю? Алан Кей: «Какие книги Вы бы посоветовали прочесть тому, кто учится на Computer Science»
webmascon
12.08.2019 06:44мне кажется упущен важный аспект программной инженерии. Для программимта computer science конечно нужен но аспект программной инженерии упускать точно нельзя. Иначе получатся некие абстрактные знания об алгоритмах без связи с реалиями профессии программиста
amarao
12.08.2019 11:55Кстати, у меня есть ощущение, что ужасающее состояние дел в software engineering (бесконечные войны vendoring VS dependency, постоянные NIH'и которые решают малую проблему ценой уничтожения решения для десятков куда больших проблем и т.д.) во многом проистекают от того, что SE — это ремесло без теории. У нас есть много теории по алгоритмам, но нет никакой теории, которая бы сказала, как организовывать процесс деплоя. Есть best practices (рассказы старейшин) и собственный опыт, и всё.
adictive_max
12.08.2019 12:37А что, какая-то теория позволит решить проблемы вида:
— Эта библиотека совершенна и ваши хотелки в неё не будут добавлены никогда
— Директор хочет клон известной программы, но чтобы денег заносили нам а не им
— Проект должен быть запущен в эксплуатацию месяц назад
— Нашему отделу закупок занесли, и поэтому вот вам разводные ключи вместо молотков
и многих похожих?
Да и теория не обязана предоставлять вам единственно верный ответ на вопрос «как правильно», особенно если вы не в можете (не умеете, не хотите, не дают) формализовать критерий «правильно».webmascon
12.08.2019 13:25-1Эти проблемы решает психиатрия а не программная инженерия
amarao
12.08.2019 14:05+1… Одно время считалось, что только психиатрия занимается толпой. А потом пришёл Нэш и у нас есть адская математика, которая позволяет делать прогнозы и предсказуемые изменения без участия собратьев в белом.
webmascon
12.08.2019 14:48> которая позволяет делать прогнозы
ну и как прогнозы? сбываются?amarao
12.08.2019 15:07Да. Если вы когда-либо видели столбик посредине входа на эскалатор — это оно, использование психологии толпы для логистической оптимизации. Если посредине входа на эскалатор поставить столбик, пропускная способность вырастет, и существуют модели, которые это позволяют предсказать в числовом выражении.
v2kxyz
12.08.2019 15:39А где про это можно почитать? А то поисковый запрос «столбик посредине входа на эскалатор» ничего толкового не дал. Я ранее предполагал, что это от любителей тележки на эскалаторе катать, что небезопасно.
amarao
12.08.2019 16:04+1А вот не найду. В своё время была публикация, что там чуть ли не 25% прирост пропускной способности из-за того, что люди слева-справа заходят (а не по центру) и получается 2 человека за раз, а не один посредине.
Источников сейчас реально не могу найти, но верьте, что читал. Обнаружили именно в симуляторе толпы, который действовал по довольно простой матмодели.
v2kxyz
12.08.2019 18:38Вы не про эту публикацию? Там вроде столбиков не было, только про два ряда. А в торговых центрах, где столбики чаще есть, чем нет, в два ряда, во-первых, тяжело встать, так как сам эскалатор уже, во-вторых, не нужно, потому что большой проблемы с очередями нет.
P.S. Почаще бы в московском метро схему в два ряда принудительно использовали.MagisterLudi Автор
12.08.2019 18:44+1В метро не надо.
Потому что вы упускаете очень важный аспект.
Те кто хотят максимизировать загрузку эскалатора в метро исходят из предпосылки, что у всех одинаковая «срочность» добраться до верха.
Если мы введем весовой коэффициент важности каждому пассажиру, то тогда максимизация функции полезности будет при наличии «выделенного канала» для спешащих.
Разброс приоритетов огромный. Я считаю что тот кто опаздывает на самолет, заслуживает больше внимание чем 200 человек, кто просто едет домой попить пивка.
Можно, если не лень, в числах обсчитать.
Да и вообще, ходить по эскалатору — очень полезно для здоровья.BigBeaver
12.08.2019 19:34Да и вообще, ходить по эскалатору — очень полезно для здоровья.
Но только вверх.
v2kxyz
12.08.2019 20:47Нет, не упускаю.
На всех станциях/переходах по стандартному пути работа-дом я хожу по эсклаторам пешком и вверх и вниз. Правда это не потому что я спешу, а потому что мне так удобней. Но вот с этим утверждением я категорически не согласен.
Я считаю что тот кто опаздывает на самолет, заслуживает больше внимание чем 200 человек, кто просто едет домой попить пивка.
Во-первых, по моим измерениям человек идущий пешком вдвое сокращает время преодоления самого эскалатора, т.е. на 50% от исходного.
Во-вторых, если вставать в два ряда, то все идут на 30% быстрее в общем, из-за меньшей очереди на эскалатор. Т.е. может получиться так, что в час-пик в общем получиться быстрее.
В-третьих, мне видится, что соотношение между теми кому действительно быстро надо и теми кто «просто пивка попить» не 1/200, а 1/10000.
В-четвертых, почему вы решили, что чей-то самолет важнее, чем чье-то пиво? Может я на собеседование в компанию мечты спешу, а подниматься зимой пешком на Парке Победы перед собеседованием — не лучшая идея.
В-пятых, на дорогах, опаздывающим на самолет не разрешают использовать мигалку, чтобы успеть, почему в метро разрешать?
В-шестых, я не призываю всегда ездить в два ряда, а только во время пробок в очереди на заход, что иногда итак делают, но недостаточно часто.BigBeaver
13.08.2019 18:50+1Я иду со скоростью выше, чем собственная скорость эскалатора. То есть, поднимаюсь более, чем вдвое быстрее. Даже если я занимаю вдвое больше места, то пропускная способность вырастет, если ряд идущих будет сплошным (то есть, если желающих идти будет достаточно) и если они будут удовлетворять скоростному режиму.
При этом я не утверждаю, что это работает так в реальности на средней выборке людей. Но тех, кто лезет вперед, но сам еле ходит, я искренне ненавижу (и не только на эскалаторах).v2kxyz
13.08.2019 20:52Если ряд будет просто сплошным с любым скоростным режимом, то так да — быстрее, но даже на маленьких подъемах он почти никогда не бывает сплошным, зато тех кто подходит к эскалатору слева и потом встает справа — полно.
Я раньше часто поднимался на Киевской и там до 19:00 проблема подойти к эскалатору стояла очень остро(вплоть до 5 минут). А вот когда занимали оба ряда становилось значительно лучше.
BigBeaver
14.08.2019 10:34Под «сплошным» я не имею ввиду каждую ступеньку. Люди даже в правом реду не очень любят стоять настолько вплотную. Но пойнт в другом.
Классический аргумент против идущих это справедливое утверждение, что для шага нужно больше времени, чем для стояния. Я же утверждаю, что проблема идущих в недостаточном количестве желающих идти. При том, что несколько минут стоять в узком пространстве это и скучно, и не очень удобно, и не полезно (сбегать по ступенькам вниз тоже не полезно, но подъем норм).
При том я согласен, что есть очень глубокие станции, где идти весь подъем с заявленной выше скоростью, скажем так, челлендж — они вообще вне вопроса (их пройдут единицы).Zenitchik
14.08.2019 15:17При том я согласен, что есть очень глубокие станции, где идти весь подъем с заявленной выше скоростью, скажем так, челлендж — они вообще вне вопроса (их пройдут единицы).
А стоять столько времени — испытание для нервов. Приходится часть эскалатора идти, даже если первоначально не хотел.
Ogra
13.08.2019 06:19Можно, если не лень, в числах обсчитать.
Можно. Только результат не изменится — увеличивая пропускную способность эскалатора мы уменьшаем очередь к нему, и, как следствие, уменьшаем время ожидания на доступ. Экономия на стоянии в очереди перекрывает экономию на пробежку.
amarao
13.08.2019 10:51Не, ещё раньше. Там было про абстрактные транспортные потоки и эквилибриум Нэша для игроков в транспортную систему.
homocomputeris
14.08.2019 12:20webmascon
15.08.2019 01:22Я давно подозревал что упавший в самолетном проходе человек ускоряет эвакуацию а не создает давку
webmascon
13.08.2019 00:50Столбики перед эскалаторами я видел только в аэропорту чтобы на эскалатор с тележками н заезжали а перед обычными эскалаторами столбики ставят только придурки умкоторых никогда не было детей на колясках
amarao
12.08.2019 14:03+1Я позитивист, и верю, что такую теорию можно создать. В конце-концов логистику же как-то сумели описать в машинопонятных терминах, так, что оптимизацией занимается именно машина.
Отсутствие теории бьёт нас два раза:
- у нас нет методов нахождения лучших решений
- у нас нет онтологии (словаря) для описания проблемы в совместимом между разными случаями виде.
Например, для вычислительных задач у нас есть мощный аппарат, следуя которому можно говорить на общем языке вне специфики домена. А для SE задач (которые на удивления одинаковы всюду, но всегда идут с лёгким вкусом (flavor) доменной области) — нет. И это главная трагедия SE.
adictive_max
12.08.2019 17:09Ещё раз. Я своими примерами хотел проиллюстрировать, что все вами перечисленные «проблемы SE» (бесконечные войны vendoring VS dependency, постоянные NIH'и которые решают малую проблему ценой уничтожения решения для десятков куда больших проблем и т.д.) лежат за пределами собственно самого SE. Проблема не в том, что разработчики чего-то не могут, а в том, что тем, кто выделяет деньги, всё это не нужно.
Конкретно на вашем примере, «логистику сумели описать в машинопонятных терминах», но что-то конкурирующих транспортных компаний и всяческих ТИПОВ логистических услуг от этого меньше не стало.
webmascon
12.08.2019 12:38> что SE — это ремесло без теории.
ну это ошибочное утверждение. Теория SE разработана уже давно. просто ей не учат или учат но не всехv2kxyz
12.08.2019 15:35А можно ссылку на эту теорию? Наверняка книги какие-нибудь.
webmascon
13.08.2019 00:53+1стив макконнелл professional software development
amarao
13.08.2019 10:50Теория или набор best practice?
webmascon
13.08.2019 15:44теория. если нужна сухая без беллетристики — SWEBOK — свод знаний которые требуются программному инженеру чтобы называться программным инженером.
а вот рекомендации по составлению учебного плана для университетов по специальностям: www.acm.org/education/curricula-recommendations
Software Engineering в частности:
— SE2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering
— GSwE2009: Curriculum Guidelines for Graduate Degree Programs in Software Engineering
— SE2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineeringamarao
13.08.2019 16:14Там коллекция стандартов. Которые не обладают предсказательной способностью, т.е. не являются полезной теорией.
Стандарты — это форма закостенелых best practices и требований к взаимосовместимости. Теорией они никак не являются, а я говорил про отсутствие теории, т.е. набора логических рассуждений на базе нескольких допущений, которые обладают нетривиальной предсказательной способностью, подтверждающейся экспериментами.
MazayAl
14.08.2019 10:30Что за странное понимание программной инженерии. Там никто рецептами не пользуется. Каждая система и её стейкхолдеры уникальны. Решение всегда строится исходя из требований и ограничений по ресурсам конкретных лиц. Но есть такое понятие как типовые решения, когда можно не изобретать велосипед а переиспользовать что-то, опять же строго в рамках конкретной ситуации. Не понимаю откуда такое настойчивое утверждение про best practices.
amarao
14.08.2019 11:31"есть такое понятие как типовые решения". Безусловно есть, и их и называют best practices. Но это совсем не теория, про которую я говорил.
Вот вы пишите очередной язык программирования. В системе типов у вас есть такая высоколобость, какую только заходите. Лямда-калькулюс, теория категорий, etc, etc. А вот в системе управления зависимостями — пшик и опыт индустрии, вместо теории.
MazayAl
14.08.2019 10:19Есть SEMAT если про софт. Но в принципе есть общие подходы к инженерии — системная инженерия, iso 15288, CPS framework. Они вполне применимы к программной инженерии в том числе.
aik
12.08.2019 07:00На форте Йода программировал же :)
FForth
14.08.2019 11:41Factor programming language язык на идеях Forth + Lisp
(автор вообще свой программерский путь начинал с проектов на Java)
конкатенативныe языки, помимо Форт
8th language
P.S. Речи, магистра Йоды, не забыты :)
Alexandre
12.08.2019 10:36Рефакторинг — от Мартина Фаулерая, обязательная к прочтению всем
а еще для юниксоидов — Ричард Стивенсон Advanced Unix Programming, очень доходчиво распотрошил Unix, тожн всем советую.
Керниган Ритчи — устарела, но остается классикой программирования на Си.
Как выше советовали: Кнут III том, нудна… есть много хороших книг по алгоритмам. Мне нравится эта с практической точки зрения proklondike.net/books/cpp/sedzhvik_fundamental_algo1_4.html и более теоретическая, как учебник www.ozon.ru/context/detail/id/33769775
Kyushu
12.08.2019 12:06Пойа Дж. 1) Как решать задачу. 2) Математическое открытие. 3) Математика и правдоподобные рассуждения.
Numerical Recipes — полезный набор процедур вычислительной математики, но не более того.
Andrey_Rogovsky
12.08.2019 13:01Какие олдскульные книги вы считаете обязательными к прочтению?
Какие книги не по программированию повысили ваш навык мышления/мировоззрения программиста?
1. Учебник логики Чапланова
2. Умение говорить нет
bk_Andragon
12.08.2019 13:45+1СИКП (примеры на том же Лиспе)
webmascon
13.08.2019 00:54А вы ее сами читали?
timofeevka
Кому что, лично мне:
Numerical Recipes
in Fortran 77
The Art of Scientific Computing
William H. Press
Harvard-Smithsonian Center for Astrophysics
Saul A. Teukolsky
Department of Physics, Cornell University
William T. Vetterling
Polaroid Corporation
Brian P. Flannery
EXXON Research and Engineering Company