Programming
Professional literature
Studying in IT
Reading room
Comments 74
+2
Кому что, лично мне:

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

Странно что нет Дональда Кнута «искусство программирования», обычно его всюду пихают в рекомендацию. Книга для понимания требует некоторого знания математики, но все в пределах вузовской программы. И ее стоит прочитать хотя бы что бы знать что какие-то вещи в принципе существуют и какие вещи как работают, даже если не понятно будет как они применяются на практике.
+9
Мифический человеко-месяц читали, но не поняли откровенно говоря что там такой хайп вокруг него
Счастливый Вы человек, если не поняли. Это означает, что Вам в горящий по срокам проект не пихали принудительно сверху людей не в теме, потом удивлясь на голубом глазу «Ну я ж вам еще полкоманды дополнительно дал за три месяца до окончания, и вы все равно умудрились профакапить сроки! Как так-то?»
Причем это Брукс писал про IBM, где с Devops традиционно хорошо. Особенный смак получается в exUSSR, когда новички вынуждены сами настраивать себе среду разработки, писать айтишникам заявки на доступ к репозиториям и т.д и т.п., дополнительно отвлекая на это своими вопросами силы основной рабочей группы.
+3

Вместо Кнута я бы советовал Кормена и компанию. Без придуманных ЯП и, на мой взгляд, легче читается.
Хотя вру, вообще стоит начинать с Теоретического минимума по CS + грокаем алгоритмы. А если зацепит, то Кормена.

0
Эти гниги написаны талантливыми людьми. Их приятно читать. Каждый извлечет для себя что то полезное. Иногда помогает «вправить» мозги. Спасибо автору за подборку!
-1

А как проверить, что именно эти книги лучше других? Есть ли какие — то показатели, программы обучения, статистические данные? Или их советуют прочитать только потому, что так сказали прославившиеся в свое время люди в области IT.

+6

Мне кажется, что в данном случае это скорее субъективное мнение Алан Кея. Насколько этому мнению доверять — каждый решает сам за себя.

+3

Жемчужины программирования — одна из лучших книг из классики как по мне.

-1
Да, старые языки типа Лиспа или Эрланга имели интересные концепции. Это потом для метапрограммирования стали писать уродливые #define
+2
Ну как бы 1987. Конечно, если сравнивать с совсем уж древними, типа Лиспа или Алгола, то не особо старый. Но с другой стороны, всего на 4 года новее самых первых плюсов.
0

мне кажется упущен важный аспект программной инженерии. Для программимта computer science конечно нужен но аспект программной инженерии упускать точно нельзя. Иначе получатся некие абстрактные знания об алгоритмах без связи с реалиями профессии программиста

+3

Кстати, у меня есть ощущение, что ужасающее состояние дел в software engineering (бесконечные войны vendoring VS dependency, постоянные NIH'и которые решают малую проблему ценой уничтожения решения для десятков куда больших проблем и т.д.) во многом проистекают от того, что SE — это ремесло без теории. У нас есть много теории по алгоритмам, но нет никакой теории, которая бы сказала, как организовывать процесс деплоя. Есть best practices (рассказы старейшин) и собственный опыт, и всё.

0
А что, какая-то теория позволит решить проблемы вида:
— Эта библиотека совершенна и ваши хотелки в неё не будут добавлены никогда
— Директор хочет клон известной программы, но чтобы денег заносили нам а не им
— Проект должен быть запущен в эксплуатацию месяц назад
— Нашему отделу закупок занесли, и поэтому вот вам разводные ключи вместо молотков
и многих похожих?

Да и теория не обязана предоставлять вам единственно верный ответ на вопрос «как правильно», особенно если вы не в можете (не умеете, не хотите, не дают) формализовать критерий «правильно».
0

… Одно время считалось, что только психиатрия занимается толпой. А потом пришёл Нэш и у нас есть адская математика, которая позволяет делать прогнозы и предсказуемые изменения без участия собратьев в белом.

+1
> которая позволяет делать прогнозы
ну и как прогнозы? сбываются?
0

Да. Если вы когда-либо видели столбик посредине входа на эскалатор — это оно, использование психологии толпы для логистической оптимизации. Если посредине входа на эскалатор поставить столбик, пропускная способность вырастет, и существуют модели, которые это позволяют предсказать в числовом выражении.

0
А где про это можно почитать? А то поисковый запрос «столбик посредине входа на эскалатор» ничего толкового не дал. Я ранее предполагал, что это от любителей тележки на эскалаторе катать, что небезопасно.
+1

А вот не найду. В своё время была публикация, что там чуть ли не 25% прирост пропускной способности из-за того, что люди слева-справа заходят (а не по центру) и получается 2 человека за раз, а не один посредине.


Источников сейчас реально не могу найти, но верьте, что читал. Обнаружили именно в симуляторе толпы, который действовал по довольно простой матмодели.

0
Вы не про эту публикацию? Там вроде столбиков не было, только про два ряда. А в торговых центрах, где столбики чаще есть, чем нет, в два ряда, во-первых, тяжело встать, так как сам эскалатор уже, во-вторых, не нужно, потому что большой проблемы с очередями нет.

P.S. Почаще бы в московском метро схему в два ряда принудительно использовали.
+1
В метро не надо.
Потому что вы упускаете очень важный аспект.

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

Если мы введем весовой коэффициент важности каждому пассажиру, то тогда максимизация функции полезности будет при наличии «выделенного канала» для спешащих.

Разброс приоритетов огромный. Я считаю что тот кто опаздывает на самолет, заслуживает больше внимание чем 200 человек, кто просто едет домой попить пивка.

Можно, если не лень, в числах обсчитать.

Да и вообще, ходить по эскалатору — очень полезно для здоровья.
0
Да и вообще, ходить по эскалатору — очень полезно для здоровья.
Но только вверх.
0
Нет, не упускаю.
На всех станциях/переходах по стандартному пути работа-дом я хожу по эсклаторам пешком и вверх и вниз. Правда это не потому что я спешу, а потому что мне так удобней. Но вот с этим утверждением я категорически не согласен.
Я считаю что тот кто опаздывает на самолет, заслуживает больше внимание чем 200 человек, кто просто едет домой попить пивка.

Во-первых, по моим измерениям человек идущий пешком вдвое сокращает время преодоления самого эскалатора, т.е. на 50% от исходного.
Во-вторых, если вставать в два ряда, то все идут на 30% быстрее в общем, из-за меньшей очереди на эскалатор. Т.е. может получиться так, что в час-пик в общем получиться быстрее.
В-третьих, мне видится, что соотношение между теми кому действительно быстро надо и теми кто «просто пивка попить» не 1/200, а 1/10000.
В-четвертых, почему вы решили, что чей-то самолет важнее, чем чье-то пиво? Может я на собеседование в компанию мечты спешу, а подниматься зимой пешком на Парке Победы перед собеседованием — не лучшая идея.
В-пятых, на дорогах, опаздывающим на самолет не разрешают использовать мигалку, чтобы успеть, почему в метро разрешать?
В-шестых, я не призываю всегда ездить в два ряда, а только во время пробок в очереди на заход, что иногда итак делают, но недостаточно часто.
+1
Я иду со скоростью выше, чем собственная скорость эскалатора. То есть, поднимаюсь более, чем вдвое быстрее. Даже если я занимаю вдвое больше места, то пропускная способность вырастет, если ряд идущих будет сплошным (то есть, если желающих идти будет достаточно) и если они будут удовлетворять скоростному режиму.

При этом я не утверждаю, что это работает так в реальности на средней выборке людей. Но тех, кто лезет вперед, но сам еле ходит, я искренне ненавижу (и не только на эскалаторах).
0
Если ряд будет просто сплошным с любым скоростным режимом, то так да — быстрее, но даже на маленьких подъемах он почти никогда не бывает сплошным, зато тех кто подходит к эскалатору слева и потом встает справа — полно.
Я раньше часто поднимался на Киевской и там до 19:00 проблема подойти к эскалатору стояла очень остро(вплоть до 5 минут). А вот когда занимали оба ряда становилось значительно лучше.

0
Под «сплошным» я не имею ввиду каждую ступеньку. Люди даже в правом реду не очень любят стоять настолько вплотную. Но пойнт в другом.

Классический аргумент против идущих это справедливое утверждение, что для шага нужно больше времени, чем для стояния. Я же утверждаю, что проблема идущих в недостаточном количестве желающих идти. При том, что несколько минут стоять в узком пространстве это и скучно, и не очень удобно, и не полезно (сбегать по ступенькам вниз тоже не полезно, но подъем норм).

При том я согласен, что есть очень глубокие станции, где идти весь подъем с заявленной выше скоростью, скажем так, челлендж — они вообще вне вопроса (их пройдут единицы).
0
При том я согласен, что есть очень глубокие станции, где идти весь подъем с заявленной выше скоростью, скажем так, челлендж — они вообще вне вопроса (их пройдут единицы).

А стоять столько времени — испытание для нервов. Приходится часть эскалатора идти, даже если первоначально не хотел.
0
Я с вами полностью согласен, но раз уж большинство предпочитает стоять — то все преодолеют эскалатор и подход к нему быстрее если стоять будут в два рядя. Идеально, если через ступеньку в шахматном порядке.
Если будет достаточное количество желающих и могущих идти — то будет еще быстрее.

P.S. А в чем «неполезность» спуска вниз? Колени?
0
Нужно продвигать идеи. А то мы с одной стороны ноем, что ожирение и диабет, а с другой по лесенке лень подняться.

Да, колени не любят такое. При этом подъем более безопасен и полезен, чем просто ходьба — при постановке на ступеньку нет удара. Хотя интуитивно многим кажется наоборот (по логике, что раз меньше усилие, то меньше и нагрузка).

То же относится к бегу с горки и тд. В детстве было пофиг, но в свои 30+ уже ощущаю дискомфорт при сбегании с горок градусов под 15 и круче. При том, что я не жалуюсь на слабость в суставах и могу держать на плечах вес в 4 собственных какое-то значимое время без каких-либо негативных последствий.
0
Можно, если не лень, в числах обсчитать.

Можно. Только результат не изменится — увеличивая пропускную способность эскалатора мы уменьшаем очередь к нему, и, как следствие, уменьшаем время ожидания на доступ. Экономия на стоянии в очереди перекрывает экономию на пробежку.
+2
Очередь — слева, а пробежка — справа. Тот, кто готов бежать — в очереди не стоит.
0

Не, ещё раньше. Там было про абстрактные транспортные потоки и эквилибриум Нэша для игроков в транспортную систему.

0

Я давно подозревал что упавший в самолетном проходе человек ускоряет эвакуацию а не создает давку

0
Столбики перед эскалаторами я видел только в аэропорту чтобы на эскалатор с тележками н заезжали а перед обычными эскалаторами столбики ставят только придурки умкоторых никогда не было детей на колясках
0

На ступенчатые эскалаторы нельзя с колясками, для этого всегда есть дублирующий лифт.


/Пишу из Европы.

+2

Я позитивист, и верю, что такую теорию можно создать. В конце-концов логистику же как-то сумели описать в машинопонятных терминах, так, что оптимизацией занимается именно машина.


Отсутствие теории бьёт нас два раза:


  • у нас нет методов нахождения лучших решений
  • у нас нет онтологии (словаря) для описания проблемы в совместимом между разными случаями виде.

Например, для вычислительных задач у нас есть мощный аппарат, следуя которому можно говорить на общем языке вне специфики домена. А для SE задач (которые на удивления одинаковы всюду, но всегда идут с лёгким вкусом (flavor) доменной области) — нет. И это главная трагедия SE.

0
Ещё раз. Я своими примерами хотел проиллюстрировать, что все вами перечисленные «проблемы SE» (бесконечные войны vendoring VS dependency, постоянные NIH'и которые решают малую проблему ценой уничтожения решения для десятков куда больших проблем и т.д.) лежат за пределами собственно самого SE. Проблема не в том, что разработчики чего-то не могут, а в том, что тем, кто выделяет деньги, всё это не нужно.

Конкретно на вашем примере, «логистику сумели описать в машинопонятных терминах», но что-то конкурирующих транспортных компаний и всяческих ТИПОВ логистических услуг от этого меньше не стало.
0
> что SE — это ремесло без теории.
ну это ошибочное утверждение. Теория SE разработана уже давно. просто ей не учат или учат но не всех
0
А можно ссылку на эту теорию? Наверняка книги какие-нибудь.
0
теория. если нужна сухая без беллетристики — 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 Engineering
0

Там коллекция стандартов. Которые не обладают предсказательной способностью, т.е. не являются полезной теорией.


Стандарты — это форма закостенелых best practices и требований к взаимосовместимости. Теорией они никак не являются, а я говорил про отсутствие теории, т.е. набора логических рассуждений на базе нескольких допущений, которые обладают нетривиальной предсказательной способностью, подтверждающейся экспериментами.

0

А что там? Там куча диаграмм и ссылок на стандарты, плюс чуть-чуть рассказов "как надо".


К теории, в том виде, которым наслаждаются CS'ники это никак не относится.

0
Что за странное понимание программной инженерии. Там никто рецептами не пользуется. Каждая система и её стейкхолдеры уникальны. Решение всегда строится исходя из требований и ограничений по ресурсам конкретных лиц. Но есть такое понятие как типовые решения, когда можно не изобретать велосипед а переиспользовать что-то, опять же строго в рамках конкретной ситуации. Не понимаю откуда такое настойчивое утверждение про best practices.
0

"есть такое понятие как типовые решения". Безусловно есть, и их и называют best practices. Но это совсем не теория, про которую я говорил.


Вот вы пишите очередной язык программирования. В системе типов у вас есть такая высоколобость, какую только заходите. Лямда-калькулюс, теория категорий, etc, etc. А вот в системе управления зависимостями — пшик и опыт индустрии, вместо теории.

0
Ну так и писали бы про управление зависимостями, а не про «SE — ремесло без теории». По крайней мере я бы не отвлекался на столь провокационную фразу. Мне особо нечего сказать про управление зависимостями к сожалению, хотя казалось бы общей теории хватает — графы, конечные автоматы, мультиагентные системы. Подтягивай что надо.
0

Не, не. Я по-прежнему утверждаю, что SE — ремесло без теории. У нас есть очень хорошая теория о том, как работают компьютеры (конечные автоматы). У нас есть несколько вкусных теорий о том, как писать алгоритмы (теория категорий, лямба-счисление, теория алгоритмов и т.д.). Но SE — это не программирование. SE — это всё то, что "за алгоритмами". Никакая часть теории категорий не требует делать воспроизводимые билды или уметь работать не от рута, если это можно по предметной области.


Вся эта часть свалена в (структурированные) стандарты и best practices (типовые решения, debian policy, RFC, etc, etc).


Вот за этими стандартами нет теории. Они просто "есть" и нет никаких доказательств того, что они оптимальны (или, хотя бы, непротиворечивы). В этом смысле за SE нет теории — объемлющей модели, обладающей нетривиальной предсказательной силой. Такая модель (теория) должна будет начинаться с таких удачных терминов и начальных положений, чтобы быть применимой в реальной жизни. Вот их-то мы пока и не видим.

0
Есть SEMAT если про софт. Но в принципе есть общие подходы к инженерии — системная инженерия, iso 15288, CPS framework. Они вполне применимы к программной инженерии в том числе.
+2
Рефакторинг — от Мартина Фаулерая, обязательная к прочтению всем
а еще для юниксоидов — Ричард Стивенсон Advanced Unix Programming, очень доходчиво распотрошил Unix, тожн всем советую.
Керниган Ритчи — устарела, но остается классикой программирования на Си.
Как выше советовали: Кнут III том, нудна… есть много хороших книг по алгоритмам. Мне нравится эта с практической точки зрения proklondike.net/books/cpp/sedzhvik_fundamental_algo1_4.html и более теоретическая, как учебник www.ozon.ru/context/detail/id/33769775
+1
Пойа Дж. 1) Как решать задачу. 2) Математическое открытие. 3) Математика и правдоподобные рассуждения.

Numerical Recipes — полезный набор процедур вычислительной математики, но не более того.
+1
Какие олдскульные книги вы считаете обязательными к прочтению?
Какие книги не по программированию повысили ваш навык мышления/мировоззрения программиста?


1. Учебник логики Чапланова
2. Умение говорить нет
Only those users with full accounts are able to leave comments. , please.