Comments 74
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
Странно что нет Дональда Кнута «искусство программирования», обычно его всюду пихают в рекомендацию. Книга для понимания требует некоторого знания математики, но все в пределах вузовской программы. И ее стоит прочитать хотя бы что бы знать что какие-то вещи в принципе существуют и какие вещи как работают, даже если не понятно будет как они применяются на практике.
Мифический человеко-месяц читали, но не поняли откровенно говоря что там такой хайп вокруг негоСчастливый Вы человек, если не поняли. Это означает, что Вам в горящий по срокам проект не пихали принудительно сверху людей не в теме, потом удивлясь на голубом глазу «Ну я ж вам еще полкоманды дополнительно дал за три месяца до окончания, и вы все равно умудрились профакапить сроки! Как так-то?»
Причем это Брукс писал про IBM, где с Devops традиционно хорошо. Особенный смак получается в exUSSR, когда новички вынуждены сами настраивать себе среду разработки, писать айтишникам заявки на доступ к репозиториям и т.д и т.п., дополнительно отвлекая на это своими вопросами силы основной рабочей группы.
Вместо Кнута я бы советовал Кормена и компанию. Без придуманных ЯП и, на мой взгляд, легче читается.
Хотя вру, вообще стоит начинать с Теоретического минимума по CS + грокаем алгоритмы. А если зацепит, то Кормена.
А как проверить, что именно эти книги лучше других? Есть ли какие — то показатели, программы обучения, статистические данные? Или их советуют прочитать только потому, что так сказали прославившиеся в свое время люди в области IT.
Жемчужины программирования — одна из лучших книг из классики как по мне.
Л. Броуди «НАЧАЛЬНЫЙ КУРС ПРОГРАММИРОВАНИЯ НА ЯЗЫКЕ ФОРТ»
С.Н.БАРАНОВ Н.Р. НОЗДРУНОВ «ЯЗЫК ФОРТ И ЕГО РЕАЛИЗАЦИИ»
P.S. + Язык СИ для профессионалов
P.P.S. Некоторое дежявю? Алан Кей: «Какие книги Вы бы посоветовали прочесть тому, кто учится на Computer Science»
мне кажется упущен важный аспект программной инженерии. Для программимта computer science конечно нужен но аспект программной инженерии упускать точно нельзя. Иначе получатся некие абстрактные знания об алгоритмах без связи с реалиями профессии программиста
Кстати, у меня есть ощущение, что ужасающее состояние дел в software engineering (бесконечные войны vendoring VS dependency, постоянные NIH'и которые решают малую проблему ценой уничтожения решения для десятков куда больших проблем и т.д.) во многом проистекают от того, что SE — это ремесло без теории. У нас есть много теории по алгоритмам, но нет никакой теории, которая бы сказала, как организовывать процесс деплоя. Есть best practices (рассказы старейшин) и собственный опыт, и всё.
— Эта библиотека совершенна и ваши хотелки в неё не будут добавлены никогда
— Директор хочет клон известной программы, но чтобы денег заносили нам а не им
— Проект должен быть запущен в эксплуатацию месяц назад
— Нашему отделу закупок занесли, и поэтому вот вам разводные ключи вместо молотков
и многих похожих?
Да и теория не обязана предоставлять вам единственно верный ответ на вопрос «как правильно», особенно если вы не в можете (не умеете, не хотите, не дают) формализовать критерий «правильно».
Эти проблемы решает психиатрия а не программная инженерия
… Одно время считалось, что только психиатрия занимается толпой. А потом пришёл Нэш и у нас есть адская математика, которая позволяет делать прогнозы и предсказуемые изменения без участия собратьев в белом.
ну и как прогнозы? сбываются?
Да. Если вы когда-либо видели столбик посредине входа на эскалатор — это оно, использование психологии толпы для логистической оптимизации. Если посредине входа на эскалатор поставить столбик, пропускная способность вырастет, и существуют модели, которые это позволяют предсказать в числовом выражении.
А вот не найду. В своё время была публикация, что там чуть ли не 25% прирост пропускной способности из-за того, что люди слева-справа заходят (а не по центру) и получается 2 человека за раз, а не один посредине.
Источников сейчас реально не могу найти, но верьте, что читал. Обнаружили именно в симуляторе толпы, который действовал по довольно простой матмодели.
P.S. Почаще бы в московском метро схему в два ряда принудительно использовали.
Потому что вы упускаете очень важный аспект.
Те кто хотят максимизировать загрузку эскалатора в метро исходят из предпосылки, что у всех одинаковая «срочность» добраться до верха.
Если мы введем весовой коэффициент важности каждому пассажиру, то тогда максимизация функции полезности будет при наличии «выделенного канала» для спешащих.
Разброс приоритетов огромный. Я считаю что тот кто опаздывает на самолет, заслуживает больше внимание чем 200 человек, кто просто едет домой попить пивка.
Можно, если не лень, в числах обсчитать.
Да и вообще, ходить по эскалатору — очень полезно для здоровья.
Да и вообще, ходить по эскалатору — очень полезно для здоровья.Но только вверх.
На всех станциях/переходах по стандартному пути работа-дом я хожу по эсклаторам пешком и вверх и вниз. Правда это не потому что я спешу, а потому что мне так удобней. Но вот с этим утверждением я категорически не согласен.
Я считаю что тот кто опаздывает на самолет, заслуживает больше внимание чем 200 человек, кто просто едет домой попить пивка.
Во-первых, по моим измерениям человек идущий пешком вдвое сокращает время преодоления самого эскалатора, т.е. на 50% от исходного.
Во-вторых, если вставать в два ряда, то все идут на 30% быстрее в общем, из-за меньшей очереди на эскалатор. Т.е. может получиться так, что в час-пик в общем получиться быстрее.
В-третьих, мне видится, что соотношение между теми кому действительно быстро надо и теми кто «просто пивка попить» не 1/200, а 1/10000.
В-четвертых, почему вы решили, что чей-то самолет важнее, чем чье-то пиво? Может я на собеседование в компанию мечты спешу, а подниматься зимой пешком на Парке Победы перед собеседованием — не лучшая идея.
В-пятых, на дорогах, опаздывающим на самолет не разрешают использовать мигалку, чтобы успеть, почему в метро разрешать?
В-шестых, я не призываю всегда ездить в два ряда, а только во время пробок в очереди на заход, что иногда итак делают, но недостаточно часто.
При этом я не утверждаю, что это работает так в реальности на средней выборке людей. Но тех, кто лезет вперед, но сам еле ходит, я искренне ненавижу (и не только на эскалаторах).
Я раньше часто поднимался на Киевской и там до 19:00 проблема подойти к эскалатору стояла очень остро(вплоть до 5 минут). А вот когда занимали оба ряда становилось значительно лучше.
Классический аргумент против идущих это справедливое утверждение, что для шага нужно больше времени, чем для стояния. Я же утверждаю, что проблема идущих в недостаточном количестве желающих идти. При том, что несколько минут стоять в узком пространстве это и скучно, и не очень удобно, и не полезно (сбегать по ступенькам вниз тоже не полезно, но подъем норм).
При том я согласен, что есть очень глубокие станции, где идти весь подъем с заявленной выше скоростью, скажем так, челлендж — они вообще вне вопроса (их пройдут единицы).
При том я согласен, что есть очень глубокие станции, где идти весь подъем с заявленной выше скоростью, скажем так, челлендж — они вообще вне вопроса (их пройдут единицы).
А стоять столько времени — испытание для нервов. Приходится часть эскалатора идти, даже если первоначально не хотел.
Если будет достаточное количество желающих и могущих идти — то будет еще быстрее.
P.S. А в чем «неполезность» спуска вниз? Колени?
Да, колени не любят такое. При этом подъем более безопасен и полезен, чем просто ходьба — при постановке на ступеньку нет удара. Хотя интуитивно многим кажется наоборот (по логике, что раз меньше усилие, то меньше и нагрузка).
То же относится к бегу с горки и тд. В детстве было пофиг, но в свои 30+ уже ощущаю дискомфорт при сбегании с горок градусов под 15 и круче. При том, что я не жалуюсь на слабость в суставах и могу держать на плечах вес в 4 собственных какое-то значимое время без каких-либо негативных последствий.
Можно, если не лень, в числах обсчитать.
Можно. Только результат не изменится — увеличивая пропускную способность эскалатора мы уменьшаем очередь к нему, и, как следствие, уменьшаем время ожидания на доступ. Экономия на стоянии в очереди перекрывает экономию на пробежку.
Не, ещё раньше. Там было про абстрактные транспортные потоки и эквилибриум Нэша для игроков в транспортную систему.
Я позитивист, и верю, что такую теорию можно создать. В конце-концов логистику же как-то сумели описать в машинопонятных терминах, так, что оптимизацией занимается именно машина.
Отсутствие теории бьёт нас два раза:
- у нас нет методов нахождения лучших решений
- у нас нет онтологии (словаря) для описания проблемы в совместимом между разными случаями виде.
Например, для вычислительных задач у нас есть мощный аппарат, следуя которому можно говорить на общем языке вне специфики домена. А для SE задач (которые на удивления одинаковы всюду, но всегда идут с лёгким вкусом (flavor) доменной области) — нет. И это главная трагедия SE.
Конкретно на вашем примере, «логистику сумели описать в машинопонятных терминах», но что-то конкурирующих транспортных компаний и всяческих ТИПОВ логистических услуг от этого меньше не стало.
ну это ошибочное утверждение. Теория SE разработана уже давно. просто ей не учат или учат но не всех
Теория или набор best practice?
а вот рекомендации по составлению учебного плана для университетов по специальностям: 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
Там коллекция стандартов. Которые не обладают предсказательной способностью, т.е. не являются полезной теорией.
Стандарты — это форма закостенелых best practices и требований к взаимосовместимости. Теорией они никак не являются, а я говорил про отсутствие теории, т.е. набора логических рассуждений на базе нескольких допущений, которые обладают нетривиальной предсказательной способностью, подтверждающейся экспериментами.
Там не коллекция стандартов.
"есть такое понятие как типовые решения". Безусловно есть, и их и называют best practices. Но это совсем не теория, про которую я говорил.
Вот вы пишите очередной язык программирования. В системе типов у вас есть такая высоколобость, какую только заходите. Лямда-калькулюс, теория категорий, etc, etc. А вот в системе управления зависимостями — пшик и опыт индустрии, вместо теории.
Не, не. Я по-прежнему утверждаю, что SE — ремесло без теории. У нас есть очень хорошая теория о том, как работают компьютеры (конечные автоматы). У нас есть несколько вкусных теорий о том, как писать алгоритмы (теория категорий, лямба-счисление, теория алгоритмов и т.д.). Но SE — это не программирование. SE — это всё то, что "за алгоритмами". Никакая часть теории категорий не требует делать воспроизводимые билды или уметь работать не от рута, если это можно по предметной области.
Вся эта часть свалена в (структурированные) стандарты и best practices (типовые решения, debian policy, RFC, etc, etc).
Вот за этими стандартами нет теории. Они просто "есть" и нет никаких доказательств того, что они оптимальны (или, хотя бы, непротиворечивы). В этом смысле за SE нет теории — объемлющей модели, обладающей нетривиальной предсказательной силой. Такая модель (теория) должна будет начинаться с таких удачных терминов и начальных положений, чтобы быть применимой в реальной жизни. Вот их-то мы пока и не видим.
(автор вообще свой программерский путь начинал с проектов на Java)
конкатенативныe языки, помимо Форт
8th language
P.S. Речи, магистра Йоды, не забыты :)
а еще для юниксоидов — Ричард Стивенсон Advanced Unix Programming, очень доходчиво распотрошил Unix, тожн всем советую.
Керниган Ритчи — устарела, но остается классикой программирования на Си.
Как выше советовали: Кнут III том, нудна… есть много хороших книг по алгоритмам. Мне нравится эта с практической точки зрения proklondike.net/books/cpp/sedzhvik_fundamental_algo1_4.html и более теоретическая, как учебник www.ozon.ru/context/detail/id/33769775
Numerical Recipes — полезный набор процедур вычислительной математики, но не более того.
Какие олдскульные книги вы считаете обязательными к прочтению?
Какие книги не по программированию повысили ваш навык мышления/мировоззрения программиста?
1. Учебник логики Чапланова
2. Умение говорить нет
Уэзерелл "Этюды для программистов"
Алан Кей рекомендует почитать старые и забытые, но важные книги по программированию