Современные программисты — счастливчики: мы живём в мире, в котором исторические и оказавшие существенное влияние программы имеют открытый код, доступный для изучения. Однако, многие программисты только учатся, и изучают те программы, над которыми работают сами. У нас редко находится время для изучения исторических работ, и курсы программирования редко тратят время на такие вещи.
Мы полагаем, что разработчикам следует изучать исходники программ, оказавших большое влияние, подобно тому, как архитекторы изучают здания, оказавшие влияние на архитектуру (и критикуют их). Чем повторять те же ошибки снова и снова, мы должны изучить большую работу, проделанную до нас, и вынести из неё уроки.
В идеале, нам следует изучать исходные коды великих программ с комментариями и критикой, которая даёт нам информацию о контексте проекта, его сильных и слабых сторонах. Такие комментарии редки, но вот вам несколько отправных точек:
Исходник
Doom 3 — обзор исходника
Исключительная красота исходного кода Doom 3
Исходник
The Virtual AGC Project — исходники различных миссий Аполло, документация и симуляторы.
Virtual AGC — исходники
The Apollo Guidance Computer: доброе и мягкое введение
AGC — библиотека документов
Apollo Guidance Computer: архитектура и принцип действия
Ваш умный тостер недостоин держать свечку компьютеру Аполлона
Исходник
Чёрная книга игрового движка: DOOM
Размышления о разработке DOOM’а
Исходник
Чёрная книга игрового движка: 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)
Мы полагаем, что разработчикам следует изучать исходники программ, оказавших большое влияние, подобно тому, как архитекторы изучают здания, оказавшие влияние на архитектуру (и критикуют их). Чем повторять те же ошибки снова и снова, мы должны изучить большую работу, проделанную до нас, и вынести из неё уроки.
В идеале, нам следует изучать исходные коды великих программ с комментариями и критикой, которая даёт нам информацию о контексте проекта, его сильных и слабых сторонах. Такие комментарии редки, но вот вам несколько отправных точек:
- Doom 3, игра, которую часто хвалят за исключительный дизайн кода
Исходник
Doom 3 — обзор исходника
Исключительная красота исходного кода Doom 3
- Apollo 11 Guidance Computer
Исходник
The Virtual AGC Project — исходники различных миссий Аполло, документация и симуляторы.
Virtual AGC — исходники
The Apollo Guidance Computer: доброе и мягкое введение
AGC — библиотека документов
Apollo Guidance Computer: архитектура и принцип действия
Ваш умный тостер недостоин держать свечку компьютеру Аполлона
- Книга "Архитектура приложений с открытым исходным кодом" может быть использована как руководство, содержащее обзор многих основополагающих проектов с открытым исходным кодом.
- Microsoft BASIC для 6502 — оригинальный исходник
- 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, её исходники доступны:
Исходники Furby
Исходники оригинального SimCity (также известного, как Micropolis) доступны для скачивания
(прим. перев: ссылка в оригинале больше не доступна, вот ссылка на гитхаб: https://github.com/SimHacker/micropolis)
centralhardware
Утверждение актуально для программистов всех языков, как думаете, или только для тех на которых проекты приведеные написаны?
32bit_me Автор
Язык и архитектура приложения — это разные вещи. Здесь утверждается именно польза изучения архитектуры, язык при этом вторичен, как мне кажется.
stilic
Язык — ничто. Он изучается за считанные дни.
А вот алгоритмы, принципы, паттерны, концепции — это учится долго.
По счастию, алгоритмы, принципы, паттерны, концепции в значительной степени инвариантны, от языка не зависят. Исключений немного.
tmn4jq
Согласен, С++ вон за 21 день учится
Andrey_Epifantsev
Ага, объем стандарта языка C++ 17 порядка 1600 страниц.
imotorin
Освой самостоятельно 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 кв.; Вильямс.
32bit_me Автор
stilic
И кто из действующих программистов С++ знаете эту спецификацию назубок?
Для того, чтобы реально начать работать — достаточно части из этого.
Ну и нужно еще представлять в общих чертах что есть, чтобы, если нужно, — знать где порыться в спецификации еще. Но это «порыться в спецификации еще» может случится и через год, через пару лет после того как вы уже вовсю работаете на С++.
F0iL
А иначе потом у таких зубров «да я за считанные дни начну код писать» и получаются программы, работающие стабильно либо не очень в зависимости от фаз луны и вспышек на солнце.
Например, в упомянутом стандарте случаев, которые могут вызвать UB, существует чуть менее чем две сотни. Часть из них довольно логичны, а вот до части из них додуматься по наитию крайне сложно, особенно если до этого вы писали на Java/Scala/Kotlin/C#/F#/Go/Python/PHP/JS/Perl/Delphi/etc, причем компилятор может про них вам не сказать ни слова и ни warning'а, и даже санитайзеры и статические анализаторы не всегда помогут. И проявляться они в одном случае могут, в других нет, а в третьих будут вообще чудеса происходить. И вы с ними обязательно рано или поздно столкнетесь, если будете разрабатывать что-то сколь-более сложное чем hello world. И это я не говорю про безопасность и управление памятью, про производительность (и всякую move-семантику и perfect forwarding), про хорошие практики и Core Guidelines, на одно только вдумчивое чтение и понимание которых у вас уйдет явно больше нескольких дней, и другие вещи.
stilic
Если вы проследите ветку беседы, то увидите, что речь идет о непервом языке программирования у конкретного разработчика. А так то да, согласен, что для начинающих выделение главного — существенная проблема.
Уверяю вас, если язык для вас третий-четвертный-..., то такая проблема как «понять какая именно часть прежде всего нужна, с какой начинать изучение, а изучение какой части отложить» разруливается очень быстро.
F0iL
Если вы прочитаете мой комментарий внимательнее, то заметите, что я как раз говорил не про «первый язык», а наоборот специально акцентировал внимание, что речь идет в том числе о случаях, когда у разработчика есть богатый опыт разработки на других языках:
Как вы сказали ниже,
Проблема в том, что в отличие от перечисленных выше и многих других языков, C++ в принципе часто не прощает незнание «нюансиков». И этих безжалостных «нюансиков» у него очень много, они временами весьма неочевидны и могут сработать абсолютно непредсказуемо и в совершенно непредсказуемый момент.
stilic
Да, это грустный недостаток С++, что программисту приходится бороться не только с прикладной проблемой, но и с самим языком.
Однако на практике нет никакой разницы вызвана ли проблема прикладным алгоритмом или особенностями языка — вы и так и так отдебужите это.
И ровно точно так же вы начинаете реже спотыкаться как об язык так и об частоиспользуемые алгоритмы и уже не нуждаетесь в отладке очевидных для вас моментов — это знание приходит просто постепенно.
F0iL
Вы, возможно, не совсем четко понимаете, что такое undefined behavior.
В случае ошибки в прикладном алгоритме, эта проблема будет стабильно воспроизводима и отлаживаема. Вы можете составить набор автоматических либо ручных тестов чтобы достичь хорошего покрытия и проверить все возможные комбинации, и после этого, если в алгоритме есть ошибка, она при определенном сценарии будет проявляться всегда. И вы отдебужите это.
UB — это совершенно другое. Во многих случаях код с UB будет работать абсолютно корректно и выдавать абсолютно корректные результаты на любых тестах. Но может начать (не обязательно начнет, но именно может) чудить, если вы соберет свою программу с другими опциями компилятора или с другой даже минорной версией компилятора, или если задеплоите ее на другую версию операционной системы, или запустите в другое время суток или в другой день недели, или в момент наблюдения вспышек на солнце и свиста рака на горе. И вы не отдебужите эту проблему даже сделав тысячу тестовых прогонов просто потому, что не будете знать о том, что такая проблема возможна. Да, есть run-time санитайзеры, но во-первых нужно знать об их существовании (а как я уже сказал, для человека, ранее даже очень много писавшего на Java/Scala/Kotlin/C#/F#/Go/Python/PHP/JS/Perl/etc. это совершенно неочевидно, потому что там такой фигни нет, а в книгах и учебных материалах по основам о них обычно не пишут ни слова), а во-вторых, даже эти санитайзеры помогают далеко не всегда и не во всём.
stilic
Вы описываете какую-то иную вселенную.
Типично заказчик и понятия о таких вещах не имеет.
Более того, при попытке объяснить заказчику, что «вот тоже самое, но стоит других денег, зато надежно» крайне непросто, если это не какая то специфическая область, где всё зарегламентировано (впрочем, баги как мы знаем и в авиацию проникают), в большистве случаев заказчик просто решит, что разработчик собираетесь надуть и денег взять «за ни за что».
Есть исключение — когда у заказчика столько денег выделено под проект, что ему все равно стоит система в 2 раза дешевле или в 2 раза дороже. Тогда да, тогда можно надежнее.
P.S.:
30 лет опыта разработки.
Сейчас делаем ПО для одного средних размеров европейского банка.
Везде ровно то же самое.
Или ты просто делаешь хорошо (ничего не объясняя про то, что именно дает дополнительную надежность) или, при попытке объяснить, что здесь дороже потому надежнее за счет этого — «на этом» сразу начинают экономить «давайте уберем это, нам нужно чтобы просто работало, не нужно этих ваших изысков, это излишне удорожает проект».
К счастью, я давно уже имею возможность посылать нафиг заказчиков, если они начинают что-то выкруживать сверх меры.
Да, объективно можно сделать дешевле, но это приводит к снижению надежности. Да, мои коллеги подхватят проект и сделают (исключив «ненужные удорожания»). Но это к их совести.
F0iL
То, что вы описали, справедливо для случаев, когда вы пишете штучный продукт для одного конкретного заказчика.
А если вы производите, например, маршрутизаторы для телеком-операторов, smart-телевизоры, infotainment для автомобилей, софт для видеонаблюдения, утилиты резервного копирования, или даже что-то-as-a-service чем пользуются тысячи людей или компаний, то при выборе типа «продукт/сервис стоит дешево, но адски тормозит, произвольно падает и теряет данные» и «продукт/сервис стоит дорого, но имеет репутацию работающего быстро, надежно и предсказуемо» выбор будет уже не всегда очевиден и далеко не всегда в пользу «лишь бы сэкономить».
saipr
А Си всего на 10 страницах.
nikbond
Ну, в целом, научиться писать какой-то код на другом языке действительно можно за несколько дней. И получится как в известной фразе: «Программист на Фортране будет на любом языке писать на Фортране».
В разных языках, внезапно — разные. Иначе можно было бы ограничиться Фортраном и не выдумывать больше тысячи языков за последние полвека.
stilic
В наиболее распространненных языках, относящихся к алгоритмическим — ровно одно и то же.
Есть крайне небольшие исключения.
Если вы этого еще не осознали, значит, пока знаете слишком мало языков. Где-нибудь к пятому поймете, что они по сути одинаковы.
P.S.:
Я около 30 лет в программировании.
Работал с очень различными системами разработки ПО. С различными — но на первый взгляд различными.
Уверяю вас концепции, принципи — ровно одни и те же.
А то, что вы считаете за различия…
Ну вот освоили вы клавиатуру компьютера. И что? Теперь отдельный повод для гордости на каждый тип клавиатуры что ли? Что освоили и мембранную и механическую и полноразмерную и короткую и ножничного типа и островную…
С языками те же отличая — небольшие. Трудно освоить только первый, да и пожалуй второй. Затем — уже идет как по накатаной.
gecube
с естественными языками все то же самое, на самом деле
stilic
Ну это сильно несравимые вещи по сложности изучения.
gmini
Кажется, Вы так говорите, потому что знаете слишком мало естественных языков.
adictive_max
С естественными языками засада в том, что даже если вы освоите грамматику за пару месяцев, словарный запас всё равно придётся набивать годами.
gmini
Тут тоже все аналогично — приходится постоянно держать открытым справочник функций стандартной библиотеки.
adictive_max
Стандартные библиотеки обычно не настолько сильно отличаются и не настолько огромны. Обычно всё сводится к «а как здесь называется уже известная функция и в каком порядке идут параметры».
gmini
Удачи в использовании такого принципа при переходе с Питона на Паскаль (не говоря уже о Лиспе с Прологом)
adictive_max
А что Лисп настолько инопланетный, что в нём можно делать со строками, числами, списками, файлами и т.д. что-то такое, чего принципиально нельзя сделать на питоне (с поправкой на семантику языка)?
Я не спорю, что принцип у изучения языков программирования и разговорных примерно один и тот же. Я говорю о том, что масштабы несравнимые и именно масштаб — главный источник сложности.
stilic
Скорость изучения языка программирования исчиляется днями.
Месяцами — знание с нюансиками.
Самая база знания языка человеческого — месяцы.
С нюансиками — годами.