Программисты, давайте изучать исходники классических программ

Автор оригинала: Phillip Johnston
  • Перевод
Современные программисты — счастливчики: мы живём в мире, в котором исторические и оказавшие существенное влияние программы имеют открытый код, доступный для изучения. Однако, многие программисты только учатся, и изучают те программы, над которыми работают сами. У нас редко находится время для изучения исторических работ, и курсы программирования редко тратят время на такие вещи.

Мы полагаем, что разработчикам следует изучать исходники программ, оказавших большое влияние, подобно тому, как архитекторы изучают здания, оказавшие влияние на архитектуру (и критикуют их). Чем повторять те же ошибки снова и снова, мы должны изучить большую работу, проделанную до нас, и вынести из неё уроки.

В идеале, нам следует изучать исходные коды великих программ с комментариями и критикой, которая даёт нам информацию о контексте проекта, его сильных и слабых сторонах. Такие комментарии редки, но вот вам несколько отправных точек:

  • Doom 3, игра, которую часто хвалят за исключительный дизайн кода

Исходник
Doom 3 — обзор исходника
Исключительная красота исходного кода Doom 3

  • Apollo 11 Guidance Computer

Исходник
The Virtual AGC Project — исходники различных миссий Аполло, документация и симуляторы.
Virtual AGC — исходники
The Apollo Guidance Computer: доброе и мягкое введение
AGC — библиотека документов
Apollo Guidance Computer: архитектура и принцип действия
Ваш умный тостер недостоин держать свечку компьютеру Аполлона



  • DOOM (оригинальный)

Исходник
Чёрная книга игрового движка: DOOM
Размышления о разработке DOOM’а

  • Wolfenstein 3D

Исходник
Чёрная книга игрового движка: Wolfenstein 3D

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

Организация «The Historical Source»: репозиторий GitHub в настоящее время содержит архив из 143 программ. Многие из них являются некогда популярными играми, в которые вы, возможно, играли.

Сайт "Чёрная книга игрового движка" содержит подробный разбор движков Doom и Wolfenstein 3D, с исходниками.

Каталог ПО NASA содержит свыше 1000 программных проектов, доступных для публики.

Коллекция Музея Компьютерной Истории содержит исходники исторических программ. Вот выборка из их коллекции исторических исходных кодов:
Adobe Photoshop
Microsoft Word for Windows version 1.1a
Xerox Alto OS и сопутствующие утилиты
Ранняя версия Digital Research CP/M OS
Исходник ранней версии Microsoft MS-DOS
Apple II DOS
Многие люди играли с игрушкой Furby, её исходники доступны:
PDF
Исходники Furby
Исходники оригинального SimCity (также известного, как Micropolis) доступны для скачивания
(прим. перев: ссылка в оригинале больше не доступна, вот ссылка на гитхаб: https://github.com/SimHacker/micropolis)
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 68

    +1

    Утверждение актуально для программистов всех языков, как думаете, или только для тех на которых проекты приведеные написаны?

      +5
      Язык и архитектура приложения — это разные вещи. Здесь утверждается именно польза изучения архитектуры, язык при этом вторичен, как мне кажется.
        0
        Утверждение актуально для программистов всех языков, как думаете, или только для тех на которых проекты приведеные написаны?


        Язык — ничто. Он изучается за считанные дни.

        А вот алгоритмы, принципы, паттерны, концепции — это учится долго.

        По счастию, алгоритмы, принципы, паттерны, концепции в значительной степени инвариантны, от языка не зависят. Исключений немного.
          +20
          Язык — ничто. Он изучается за считанные дни.


          Согласен, С++ вон за 21 день учится
            +4
            Ага, объем стандарта языка C++ 17 порядка 1600 страниц.
              +1
              Освой самостоятельно C++ за 21 день
              5-е издание
              Джесс Либерти, Брэдли Джонс

              Sams Teach Yourself C++ in 21 Days 5/e
              Jesse Liberty, Bradley Jones
              784 стр., с ил.; ISBN 978-5-8459-0926-8, 0-672-32711-2; формат 70x100/16; твердый переплет газетная серия Освой самостоятельно…; 2011, 4 кв.; Вильямс.
              –1
              Ага, объем стандарта языка C++ 17 порядка 1600 страниц.

              И кто из действующих программистов С++ знаете эту спецификацию назубок?

              Для того, чтобы реально начать работать — достаточно части из этого.

              Ну и нужно еще представлять в общих чертах что есть, чтобы, если нужно, — знать где порыться в спецификации еще. Но это «порыться в спецификации еще» может случится и через год, через пару лет после того как вы уже вовсю работаете на С++.
                +4
                Для того, чтобы реально начать работать — достаточно части из этого.
                Проблема в том, что нужно еще знать, какую именно часть надо знать.
                А иначе потом у таких зубров «да я за считанные дни начну код писать» и получаются программы, работающие стабильно либо не очень в зависимости от фаз луны и вспышек на солнце.
                Например, в упомянутом стандарте случаев, которые могут вызвать UB, существует чуть менее чем две сотни. Часть из них довольно логичны, а вот до части из них додуматься по наитию крайне сложно, особенно если до этого вы писали на Java/Scala/Kotlin/C#/F#/Go/Python/PHP/JS/Perl/Delphi/etc, причем компилятор может про них вам не сказать ни слова и ни warning'а, и даже санитайзеры и статические анализаторы не всегда помогут. И проявляться они в одном случае могут, в других нет, а в третьих будут вообще чудеса происходить. И вы с ними обязательно рано или поздно столкнетесь, если будете разрабатывать что-то сколь-более сложное чем hello world. И это я не говорю про безопасность и управление памятью, про производительность (и всякую move-семантику и perfect forwarding), про хорошие практики и Core Guidelines, на одно только вдумчивое чтение и понимание которых у вас уйдет явно больше нескольких дней, и другие вещи.
                  –3
                  Проблема в том, что нужно еще знать, какую именно часть надо знать.


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

                  Уверяю вас, если язык для вас третий-четвертный-..., то такая проблема как «понять какая именно часть прежде всего нужна, с какой начинать изучение, а изучение какой части отложить» разруливается очень быстро.
                    +2
                    Если вы прочитаете мой комментарий внимательнее, то заметите, что я как раз говорил не про «первый язык», а наоборот специально акцентировал внимание, что речь идет в том числе о случаях, когда у разработчика есть богатый опыт разработки на других языках:
                    додуматься по наитию крайне сложно, особенно если до этого вы писали на Java/Scala/Kotlin/C#/F#/Go/Python/PHP/JS/Perl/Delphi/etc

                    Как вы сказали ниже,
                    Скорость изучения языка программирования исчиляется днями.
                    Месяцами — знание с нюансиками.
                    Проблема в том, что в отличие от перечисленных выше и многих других языков, C++ в принципе часто не прощает незнание «нюансиков». И этих безжалостных «нюансиков» у него очень много, они временами весьма неочевидны и могут сработать абсолютно непредсказуемо и в совершенно непредсказуемый момент.
                      –5
                      И этих безжалостных «нюансиков» у него очень много, они временами весьма неочевидны и могут сработать абсолютно непредсказуемо и в совершенно непредсказуемый момент

                      Да, это грустный недостаток С++, что программисту приходится бороться не только с прикладной проблемой, но и с самим языком.

                      Однако на практике нет никакой разницы вызвана ли проблема прикладным алгоритмом или особенностями языка — вы и так и так отдебужите это.

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

                        +3
                        Вы, возможно, не совсем четко понимаете, что такое undefined behavior.
                        В случае ошибки в прикладном алгоритме, эта проблема будет стабильно воспроизводима и отлаживаема. Вы можете составить набор автоматических либо ручных тестов чтобы достичь хорошего покрытия и проверить все возможные комбинации, и после этого, если в алгоритме есть ошибка, она при определенном сценарии будет проявляться всегда. И вы отдебужите это.
                        UB — это совершенно другое. Во многих случаях код с UB будет работать абсолютно корректно и выдавать абсолютно корректные результаты на любых тестах. Но может начать (не обязательно начнет, но именно может) чудить, если вы соберет свою программу с другими опциями компилятора или с другой даже минорной версией компилятора, или если задеплоите ее на другую версию операционной системы, или запустите в другое время суток или в другой день недели, или в момент наблюдения вспышек на солнце и свиста рака на горе. И вы не отдебужите эту проблему даже сделав тысячу тестовых прогонов просто потому, что не будете знать о том, что такая проблема возможна. Да, есть run-time санитайзеры, но во-первых нужно знать об их существовании (а как я уже сказал, для человека, ранее даже очень много писавшего на Java/Scala/Kotlin/C#/F#/Go/Python/PHP/JS/Perl/etc. это совершенно неочевидно, потому что там такой фигни нет, а в книгах и учебных материалах по основам о них обычно не пишут ни слова), а во-вторых, даже эти санитайзеры помогают далеко не всегда и не во всём.
                          –4
                          и правильное использование нюансов. Конечно, если заказчику нужен продукт не сделанный тяп-ляп «лишь бы работало» за копейки, а работающий стабильно, производительно и предсказуемо.


                          Вы описываете какую-то иную вселенную.
                          Типично заказчик и понятия о таких вещах не имеет.

                          Более того, при попытке объяснить заказчику, что «вот тоже самое, но стоит других денег, зато надежно» крайне непросто, если это не какая то специфическая область, где всё зарегламентировано (впрочем, баги как мы знаем и в авиацию проникают), в большистве случаев заказчик просто решит, что разработчик собираетесь надуть и денег взять «за ни за что».

                          Есть исключение — когда у заказчика столько денег выделено под проект, что ему все равно стоит система в 2 раза дешевле или в 2 раза дороже. Тогда да, тогда можно надежнее.

                          P.S.:
                          30 лет опыта разработки.
                          Сейчас делаем ПО для одного средних размеров европейского банка.

                          Везде ровно то же самое.

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

                          К счастью, я давно уже имею возможность посылать нафиг заказчиков, если они начинают что-то выкруживать сверх меры.

                          Да, объективно можно сделать дешевле, но это приводит к снижению надежности. Да, мои коллеги подхватят проект и сделают (исключив «ненужные удорожания»). Но это к их совести.
                            +1
                            То, что вы описали, справедливо для случаев, когда вы пишете штучный продукт для одного конкретного заказчика.
                            А если вы производите, например, маршрутизаторы для телеком-операторов, smart-телевизоры, infotainment для автомобилей, софт для видеонаблюдения, утилиты резервного копирования, или даже что-то-as-a-service чем пользуются тысячи людей или компаний, то при выборе типа «продукт/сервис стоит дешево, но адски тормозит, произвольно падает и теряет данные» и «продукт/сервис стоит дорого, но имеет репутацию работающего быстро, надежно и предсказуемо» выбор будет уже не всегда очевиден и далеко не всегда в пользу «лишь бы сэкономить».
                0

                А Си всего на 10 страницах.

              +3
              Язык — ничто. Он изучается за считанные дни.

              Ну, в целом, научиться писать какой-то код на другом языке действительно можно за несколько дней. И получится как в известной фразе: «Программист на Фортране будет на любом языке писать на Фортране».

              принципы, паттерны, концепции

              В разных языках, внезапно — разные. Иначе можно было бы ограничиться Фортраном и не выдумывать больше тысячи языков за последние полвека.
                0
                В разных языках, внезапно — разные.

                В наиболее распространненных языках, относящихся к алгоритмическим — ровно одно и то же.

                Есть крайне небольшие исключения.

                Если вы этого еще не осознали, значит, пока знаете слишком мало языков. Где-нибудь к пятому поймете, что они по сути одинаковы.

                P.S.:

                Я около 30 лет в программировании.

                Работал с очень различными системами разработки ПО. С различными — но на первый взгляд различными.

                Уверяю вас концепции, принципи — ровно одни и те же.
                А то, что вы считаете за различия…

                Ну вот освоили вы клавиатуру компьютера. И что? Теперь отдельный повод для гордости на каждый тип клавиатуры что ли? Что освоили и мембранную и механическую и полноразмерную и короткую и ножничного типа и островную…

                С языками те же отличая — небольшие. Трудно освоить только первый, да и пожалуй второй. Затем — уже идет как по накатаной.
                  0
                  Если вы этого еще не осознали, значит, пока знаете слишком мало языков. Где-нибудь к пятому поймете, что они по сути одинаковы.

                  с естественными языками все то же самое, на самом деле

                    –2
                    с естественными языками все то же самое, на самом деле


                    Ну это сильно несравимые вещи по сложности изучения.
                      +7
                      Ну это сильно несравимые вещи по сложности изучения.

                      Кажется, Вы так говорите, потому что знаете слишком мало естественных языков.
                        0
                        С естественными языками засада в том, что даже если вы освоите грамматику за пару месяцев, словарный запас всё равно придётся набивать годами.
                          +4
                          Тут тоже все аналогично — приходится постоянно держать открытым справочник функций стандартной библиотеки.
                            –1
                            Стандартные библиотеки обычно не настолько сильно отличаются и не настолько огромны. Обычно всё сводится к «а как здесь называется уже известная функция и в каком порядке идут параметры».
                              +5
                              Удачи в использовании такого принципа при переходе с Питона на Паскаль (не говоря уже о Лиспе с Прологом)
                                –2
                                А что Лисп настолько инопланетный, что в нём можно делать со строками, числами, списками, файлами и т.д. что-то такое, чего принципиально нельзя сделать на питоне (с поправкой на семантику языка)?

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


                          Кажется, Вы так говорите, потому что знаете слишком мало естественных языков.


                          Скорость изучения языка программирования исчиляется днями.
                          Месяцами — знание с нюансиками.

                          Самая база знания языка человеческого — месяцы.
                          С нюансиками — годами.

              +8

              За ссылки спасибо)


              Хотя мне бы в исходниках своего проекта на работе бы разобраться)

                0
                Да, всё упирается в недостаток времени, увы.
                +2
                Мне представляется, что сейчас более актуален следующий призыв — программисты, изучайте классические теории программирования. Если вы, конечно, не элементарный кодер. Код же только «замыливает» смысл. Поймешь идею — переходи к коду или, что полезнее, создай свой. Нужно заставлять голову думать и работать. И, еще раз, — начинать нужно с идеи, отталкиваясь от [классической] теории программирования.
                  +6

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

                    –15
                    Теория очень важна
                    Она не просто важна — первоочередна. Пример — пожалуйста. Столнулся с тем, что сейчас в среде программистов достаточно популярны, так называемые, корутины. Раньше в теории их называли просто — сопрограммы. Сопрограммы — элементарщина, которую с точки зрения теории и практики давно пора забыть. Но тут, похоже, что-то сломалось — или теория, или головы программистов, обсуждающих код реализации корутин ;)
                    Если «крутые программисты» изобрели что-то новое, то объясните сначала на уровне теории, что нового в старых-новых «корутинах». Если что-то действительно есть то, что качественно новое, то и назовите это по-новому, чтобы не искажать теорию, и обсуждайте код реализации этого нового.
                    Если код ставится фактически на один уровень с теорией, то и появляется своеобразный «корутинизм». Итог. Чтобы обосновать «разборку» того или иного кода, эту необходимость нужно объяснить сначала на уровне теории.
                      +8
                      Столнулся с тем, что сейчас в среде программистов достаточно популярны, так называемые, корутины.
                      Интересно, как так получилось, что англоязычные разработчики, для которых этот термин как раз старый (корутина = coroutine = сопрограмма), тоже «изобрели что-то новое»? Может дело в том, что эту великомудрую теорию наконец смогли сделать удобной на практике?
                        –11
                        Может дело в том, что эту великомудрую теорию наконец смогли сделать удобной на практике?
                        Дело не в практике. Тут, может, действительно достигнут «прорыв». Дело в «великомудрости» теоретического прорыва.
                        Буквально только что посмотрел фильм об истории авиации. «Англоязычные разработчики» во всех деталях повторили первый самолет Левенталя (так, кажется). Ну, очень им восхищались! Может, и мы перейдем на «перкалевые самолетики» без двигателя. Ну, безумно практически удобно! :)
                        Для меня лично, «корутины» — это и есть эти самые «самолетики» (точнее, даже планеры).
                        Современные технологи, думаю, позволят быстро и экономично реализовать технологию добычи огня трением. Может, забросим эти спички-зажигалки? Займемся изучением «кода» добычи огня трением?
                          +4
                          Так спички и есть добыча огня трением, разве нет?
                            –6
                            Таки да! :) Только более совершенный и более удобный практический «код» давно известной технологии добычи огня. Кстати, (подумал) и в зажигалке тоже, ведь, используется «технология трения» :)
                            Так мы договоримся до того, что «корутины» — это своеобразная «зажигалка» современного программирования ;) И изучение кода их реализации безумно важно. И даже сложно будет оспорить сей «революционный» сдвиг в современном программировании.
                            +4
                            Даже не знаю, с чего продолжить…
                            А что тогда «зажигалки», если сопрограммы — это добыча огня трением?
                            А почему не брюзжать, что до сих пор не выбросили каменные рубила — присвоения и условные переходы?
                            Когда это сопрограммы успели устареть аж на уровне сферовакуумной концепции, для всех сфер и всех языков сразу?
                              –7
                              А почему не брюзжать, что до сих пор не выбросили каменные рубила — присвоения и условные переходы?
                              Можно, конечно, побрюзжать и на эту тему. Есть теоретический вариант, когда они не нужны совсем. Но практически полно еще ситуаций, когда эти «зубила» вполне удобны и эффективны.
                              Когда это сопрограммы успели устареть аж на уровне сферовакуумной концепции, для всех сфер и всех языков сразу?

                              Как минимум, когда появились потоки: переключение между процессами стало проще и понятнее.
                                +3
                                Может я как-то не правильно понимаю эти понятия, но мне всегда казалось, что они слегка перпендикулярны друг другу.
                                  +6
                                  Как минимум, когда появились потоки: переключение между процессами стало проще и понятнее.

                                  А ещё медленнее. И это если не вспоминать про генераторы, которые потоками нормально не заменяются.

                                    –3
                                    Скорость — фактор проходящий. Не в ней главное. Сопрограммы и потоки — это разное мышление. В сопрограммах нужно фиксировать точки переключения, в потоках вы об этом совсем не думаете. Исправьте, если не так.

                                    Затем, — «перпендикулярно», «нормально» — эмоциональные оценки. Я не поклонник ни корутин, ни потоков и, подозреваю, даже генераторов ;). Могу, кстати, даже предложить то, что заменяет все это вместе. Но речь сейчас не об этом.

                                    Нам предлагают «изучать исходники классических программ». Я не против и этого. Даже — за. Сам этим иногда занимаюсь. Но только, простите, мир развивается. И то, что раньше было классическим, сейчас вполне может быть «голимым отстоем». Глядя только на код, созданный еще и другими, сложно в этом разобраться. Где — идея, ради которой нужно «ковыряться» в чужом коде?

                                    Возьмем, например, давнюю книгу Гради Буча. ООП с примерами применения. Если я понял идею ООП — примеры просто проглядываю и убеждаюсь насколько я ее хорошо и в деталях усвоил. Если не врубился в нее сразу, то ее примеры помогут, думаю, мало. Если не запутают окончательно. Здесь лучше прочитать книжку сначала.

                                    «Учебный код» в обязательном порядке должен сопровождаться формальным изложением заложенной в него идеи. Как говорил один персонаж — я так думаю! :)
                                      +2

                                      Зато при работе с потоками надо очень аккуратно работать с общими данными. А те задачи/обещания/будущие значения, на которых асинхронные сопрограммы работают — сами по себе механизм синхронизации доступа.


                                      И да, вы всё ещё игнорируете генераторы. А там фиксированные точки переключения растут из решаемой задачи, даже если вы со словами "скорость — фактор проходящий" исхитритесь сделать генераторы на потоках — у вас всё равно останутся явные точки переключения.

                                        –6
                                        исхитритесь сделать генераторы на потоках
                                        В том-то и дело, чтобы этим заниматься, нужно объяснить, хотя бы самому себе, зачем это делать. Ради упражнения с кодом и/или освоения процесса кодирования, языка и т.п.?
                                        Но, предположим, вдруг, такая надобность возникла. Тогда нужно делать подобную реализацию так, чтобы разницы не было. И, наверное, «многопоточные генераторы» будут наследовать достоинства и недостатки оригинальных генераторов. Тогда опять же вопрос- зачем этот «изврат»? Если уж есть и так Вам милы генераторы, то лучше уж их и использовать.
                                          +2

                                          Ну так вы же тут утверждаете, что потоки лучше сопрограмм, а не я. Мне и на сопрограммах хорошо.

                                            –7
                                            Так я-то тоже не против. Кому-то комфортно и на деревянных лыжах. Но попробовав Fischer, меня лично, уже подобный «комфорт» не устраивает. Велосипед, даже самый современный, в чем-то тоже и немало проигрывает даже не очень современному автомобилю. Как-то так.
                          +2
                          Иногда полезно написать что-то с нуля, чтобы понять как оно работает внутри, хотя бы базовый функционал. Нас в универе заставляли писать свои реализации стеков, очередей, списков, деревьев и т.п. Я считаю это был полезный опыт. Просто посмотрев исходный код этого не запомнишь, а если один раз написать, то запоминается очень хорошо.
                          0
                          После прочтения Вашего сообщения студенты, которые не хотят учить «бесполезную теорию», а сразу ходят писать код, поперхнулись чаем.
                          +2
                            0

                            Спасибо!

                            +2
                            Супер!
                              +1

                              Я просто оставлю это здесь: http://aosabook.org/en/index.html
                              Проекты, языки, архитектуры самых разных мастей, и всё — из мира Open Source

                                0

                                Да, эта книга упоминается в статье.

                                  0

                                  Уф, только с третьей попытки обнаружил. Mea culpa

                                    0

                                    Да, мне тоже было трудно обнаружить. Почему-то ссылка на блог-пост о книге, а не на саму книгу "Архитектура приложений с открытым исходным кодом"
                                    http://aosabook.org/en/index.html

                                +1
                                Разделяю идею автора. Но почему игры? почему DOOM? почему бы не начать с банальных suckless?
                                  +3
                                  Почему никто не вспомнил исходники ТеХ от Дональда Кнута, канонический пример literate programming?

                                  Это полный код ядра издательской системы TeX, оформленный в виде книги, которая была сверстана при помощи системы, которая она описывает.

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

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

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

                                  Единственное, что меня удивляет, что там обильно используется goto, интересно найти мнение Кнута на этот счет.
                                    +2
                                    Да, ваш пример тоже хорош. Я оставил ссылку на сайт suck less как на программы с практчески идеально-проработанном алгоритмом, который как минимум долго не устаревает. Эти программы надо знать всем хотябы не из-за исходного кода, а просто потому что не знать их стыдно и любой велосипед, выполняющий даже частично их функции может восприниматься как неосведомлённость в рабочем окружении. Их список вот тут: https://suckless.org/rocks/. И есть список софта, который suck full, список их здесь: https://suckless.org/sucks/. Найдите про TeX. А вот тут даже приводят в сравнение: http://harmful.cat-v.org/software/

                                    А ваш пример тоже хорош, взял на заметку.
                                  +1
                                  Спасибо!
                                    +2
                                    Дикая подборка у этого Филипса.

                                    Изучать надо не Дум 3, а исходники Квейка. Как с минимумом файлов создать шедевр.
                                    Что касается архитектуры, то она лучшая у движка Ogre3D.

                                    Изучать исходники апполо, нет смысла. Разве что из любопытства как они всю миссию в 2 кб запихнули. Но тогда современные js1k.com гораздо лучше там не то что код но и графику умудряются запихать.

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

                                    Фотошоп 1 версии не чуть не лучше GIMP тоже Г. Но с боку бантик. Уверен что можно найти исходники более лучшие.

                                    Бесик смотрел. Однако ничего выдающегося. Ни тебе теории парсеров ни архитектуры.
                                    Если вы хотите насладится кодом компилятора возьмите LCC вот там правильная архитектура компилятора. sites.google.com/site/lccretargetablecompiler

                                    Из операционных систем рекомендую вот этот проект посмотреть:

                                    Так же рекомендую посмотреть исходники компьютерной библиотекеи для рисования AGGPas. Библиотеки шаблонов для численных вычислений Eigen — она между прочим считается образцовой.

                                    По нейронным сетям рекомендую изучить репозиторий github.com/karpathy/convnetjs
                                    Качественный легко читаемый код без излишеств.

                                    По операционным системам тоже странный выбор. Судя по всему он искал самые старые ОС, так почему не взять Unix? А если по архитектурным решениям, то Minix и ещё была созданная в научных целях ОС от майкрософта забыл название демо в закромах лежит.

                                    И в дагонку можно упомянуть аналог розетского камя для программистов
                                    rosettacode.org
                                      +1
                                      Изучать надо не Дум 3, а исходники Квейка. Как с минимумом файлов создать шедевр.
                                      Спорный тезис, думовские исходники очень приятно читать, а вот пришитый как пятая нога QuakeC не особо.
                                      0

                                      Зависит от того, зачем вам это нужно. Например, задача для решения которой опробовано несколько разных подходов, с разных сторон, результат? Его нет, возможно, при детальном рассмотрении того, как устроено несколько наиболее значимых программ, удалось бы сделать что-то более совершенное в плане автоматической подстановки тайминга и вытаскивания встроенных субтитров, с технологией OCR
                                      и машинного обучения, однако, не могу сказать что понимаю как устроены программы на языке с++. Очень не хватает детального гайда по VideosubFinder, Aegisub в плане того, как сделать эти программы на с++ от и до и на других языках. С#, python.
                                      Но это лично моё мнение.

                                        +2

                                        Для меня классика это Minix. Когда 1987 году я первый раз читал ее (операционной системы) код — это был полный восторг.

                                          0
                                          Исходники оригинального SimCity (также известного, как Micropolis) доступны для скачивания

                                          А ссылка точно рабочая? Мне мой браузер рисует страничку «Oops! That page can’t be found.»
                                            +1
                                            Странно, но ссылка побилась уже после публикации. Оригинальный сервер с исходниками сейчас недоступен, я заменил ссылку на sourceforge.
                                              0
                                              Простите, что-то странное, но по новой ссылке тоже что-то не соображу, как скачать исходники проекта О__о
                                                0
                                                О, это я должен извиниться, опять не проверил. Они хорошо шифруются :)
                                                Вот ссылка на копию проекта на гитхабе: https://github.com/SimHacker/micropolis (также добавил в пост)
                                                  0
                                                  Да, такое ощущение, что они намеренно делают квест для поиска исходников
                                            –1

                                            И ни одной великой программы в статье. В 2020 интересоваться виндовым софтом — ну такое.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое