Comments 68
UFO just landed and posted this here
Язык и архитектура приложения — это разные вещи. Здесь утверждается именно польза изучения архитектуры, язык при этом вторичен, как мне кажется.
Утверждение актуально для программистов всех языков, как думаете, или только для тех на которых проекты приведеные написаны?
Язык — ничто. Он изучается за считанные дни.
А вот алгоритмы, принципы, паттерны, концепции — это учится долго.
По счастию, алгоритмы, принципы, паттерны, концепции в значительной степени инвариантны, от языка не зависят. Исключений немного.
Язык — ничто. Он изучается за считанные дни.
Согласен, С++ вон за 21 день учится
Ага, объем стандарта языка C++ 17 порядка 1600 страниц.
Освой самостоятельно 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 кв.; Вильямс.
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 кв.; Вильямс.
Ага, объем стандарта языка C++ 17 порядка 1600 страниц.
И кто из действующих программистов С++ знаете эту спецификацию назубок?
Для того, чтобы реально начать работать — достаточно части из этого.
Ну и нужно еще представлять в общих чертах что есть, чтобы, если нужно, — знать где порыться в спецификации еще. Но это «порыться в спецификации еще» может случится и через год, через пару лет после того как вы уже вовсю работаете на С++.
UFO just landed and posted this here
Проблема в том, что нужно еще знать, какую именно часть надо знать.
Если вы проследите ветку беседы, то увидите, что речь идет о непервом языке программирования у конкретного разработчика. А так то да, согласен, что для начинающих выделение главного — существенная проблема.
Уверяю вас, если язык для вас третий-четвертный-..., то такая проблема как «понять какая именно часть прежде всего нужна, с какой начинать изучение, а изучение какой части отложить» разруливается очень быстро.
UFO just landed and posted this here
И этих безжалостных «нюансиков» у него очень много, они временами весьма неочевидны и могут сработать абсолютно непредсказуемо и в совершенно непредсказуемый момент
Да, это грустный недостаток С++, что программисту приходится бороться не только с прикладной проблемой, но и с самим языком.
Однако на практике нет никакой разницы вызвана ли проблема прикладным алгоритмом или особенностями языка — вы и так и так отдебужите это.
И ровно точно так же вы начинаете реже спотыкаться как об язык так и об частоиспользуемые алгоритмы и уже не нуждаетесь в отладке очевидных для вас моментов — это знание приходит просто постепенно.
UFO just landed and posted this here
и правильное использование нюансов. Конечно, если заказчику нужен продукт не сделанный тяп-ляп «лишь бы работало» за копейки, а работающий стабильно, производительно и предсказуемо.
Вы описываете какую-то иную вселенную.
Типично заказчик и понятия о таких вещах не имеет.
Более того, при попытке объяснить заказчику, что «вот тоже самое, но стоит других денег, зато надежно» крайне непросто, если это не какая то специфическая область, где всё зарегламентировано (впрочем, баги как мы знаем и в авиацию проникают), в большистве случаев заказчик просто решит, что разработчик собираетесь надуть и денег взять «за ни за что».
Есть исключение — когда у заказчика столько денег выделено под проект, что ему все равно стоит система в 2 раза дешевле или в 2 раза дороже. Тогда да, тогда можно надежнее.
P.S.:
30 лет опыта разработки.
Сейчас делаем ПО для одного средних размеров европейского банка.
Везде ровно то же самое.
Или ты просто делаешь хорошо (ничего не объясняя про то, что именно дает дополнительную надежность) или, при попытке объяснить, что здесь дороже потому надежнее за счет этого — «на этом» сразу начинают экономить «давайте уберем это, нам нужно чтобы просто работало, не нужно этих ваших изысков, это излишне удорожает проект».
К счастью, я давно уже имею возможность посылать нафиг заказчиков, если они начинают что-то выкруживать сверх меры.
Да, объективно можно сделать дешевле, но это приводит к снижению надежности. Да, мои коллеги подхватят проект и сделают (исключив «ненужные удорожания»). Но это к их совести.
А Си всего на 10 страницах.
Язык — ничто. Он изучается за считанные дни.
Ну, в целом, научиться писать какой-то код на другом языке действительно можно за несколько дней. И получится как в известной фразе: «Программист на Фортране будет на любом языке писать на Фортране».
принципы, паттерны, концепции
В разных языках, внезапно — разные. Иначе можно было бы ограничиться Фортраном и не выдумывать больше тысячи языков за последние полвека.
В разных языках, внезапно — разные.
В наиболее распространненных языках, относящихся к алгоритмическим — ровно одно и то же.
Есть крайне небольшие исключения.
Если вы этого еще не осознали, значит, пока знаете слишком мало языков. Где-нибудь к пятому поймете, что они по сути одинаковы.
P.S.:
Я около 30 лет в программировании.
Работал с очень различными системами разработки ПО. С различными — но на первый взгляд различными.
Уверяю вас концепции, принципи — ровно одни и те же.
А то, что вы считаете за различия…
Ну вот освоили вы клавиатуру компьютера. И что? Теперь отдельный повод для гордости на каждый тип клавиатуры что ли? Что освоили и мембранную и механическую и полноразмерную и короткую и ножничного типа и островную…
С языками те же отличая — небольшие. Трудно освоить только первый, да и пожалуй второй. Затем — уже идет как по накатаной.
Если вы этого еще не осознали, значит, пока знаете слишком мало языков. Где-нибудь к пятому поймете, что они по сути одинаковы.
с естественными языками все то же самое, на самом деле
с естественными языками все то же самое, на самом деле
Ну это сильно несравимые вещи по сложности изучения.
Ну это сильно несравимые вещи по сложности изучения.
Кажется, Вы так говорите, потому что знаете слишком мало естественных языков.
С естественными языками засада в том, что даже если вы освоите грамматику за пару месяцев, словарный запас всё равно придётся набивать годами.
Тут тоже все аналогично — приходится постоянно держать открытым справочник функций стандартной библиотеки.
Стандартные библиотеки обычно не настолько сильно отличаются и не настолько огромны. Обычно всё сводится к «а как здесь называется уже известная функция и в каком порядке идут параметры».
Удачи в использовании такого принципа при переходе с Питона на Паскаль (не говоря уже о Лиспе с Прологом)
А что Лисп настолько инопланетный, что в нём можно делать со строками, числами, списками, файлами и т.д. что-то такое, чего принципиально нельзя сделать на питоне (с поправкой на семантику языка)?
Я не спорю, что принцип у изучения языков программирования и разговорных примерно один и тот же. Я говорю о том, что масштабы несравнимые и именно масштаб — главный источник сложности.
Я не спорю, что принцип у изучения языков программирования и разговорных примерно один и тот же. Я говорю о том, что масштабы несравнимые и именно масштаб — главный источник сложности.
Ну это сильно несравимые вещи по сложности изучения.
Кажется, Вы так говорите, потому что знаете слишком мало естественных языков.
Скорость изучения языка программирования исчиляется днями.
Месяцами — знание с нюансиками.
Самая база знания языка человеческого — месяцы.
С нюансиками — годами.
За ссылки спасибо)
Хотя мне бы в исходниках своего проекта на работе бы разобраться)
Мне представляется, что сейчас более актуален следующий призыв — программисты, изучайте классические теории программирования. Если вы, конечно, не элементарный кодер. Код же только «замыливает» смысл. Поймешь идею — переходи к коду или, что полезнее, создай свой. Нужно заставлять голову думать и работать. И, еще раз, — начинать нужно с идеи, отталкиваясь от [классической] теории программирования.
Теория очень важна, это бесспорно. Но, кмк, вместе с теорией программист обязательно должен изучать чужой (и обязательно качественный) код, для того, чтобы понимать технику реализации алгоритмов, стиль кода, и избавиться от очень вредного желания писать всё самому с нуля, чём у нас страдают очень многие.
Теория очень важнаОна не просто важна — первоочередна. Пример — пожалуйста. Столнулся с тем, что сейчас в среде программистов достаточно популярны, так называемые, корутины. Раньше в теории их называли просто — сопрограммы. Сопрограммы — элементарщина, которую с точки зрения теории и практики давно пора забыть. Но тут, похоже, что-то сломалось — или теория, или головы программистов, обсуждающих код реализации корутин ;)
Если «крутые программисты» изобрели что-то новое, то объясните сначала на уровне теории, что нового в старых-новых «корутинах». Если что-то действительно есть то, что качественно новое, то и назовите это по-новому, чтобы не искажать теорию, и обсуждайте код реализации этого нового.
Если код ставится фактически на один уровень с теорией, то и появляется своеобразный «корутинизм». Итог. Чтобы обосновать «разборку» того или иного кода, эту необходимость нужно объяснить сначала на уровне теории.
Столнулся с тем, что сейчас в среде программистов достаточно популярны, так называемые, корутины.Интересно, как так получилось, что англоязычные разработчики, для которых этот термин как раз старый (корутина = coroutine = сопрограмма), тоже «изобрели что-то новое»? Может дело в том, что эту великомудрую теорию наконец смогли сделать удобной на практике?
Может дело в том, что эту великомудрую теорию наконец смогли сделать удобной на практике?Дело не в практике. Тут, может, действительно достигнут «прорыв». Дело в «великомудрости» теоретического прорыва.
Буквально только что посмотрел фильм об истории авиации. «Англоязычные разработчики» во всех деталях повторили первый самолет Левенталя (так, кажется). Ну, очень им восхищались! Может, и мы перейдем на «перкалевые самолетики» без двигателя. Ну, безумно практически удобно! :)
Для меня лично, «корутины» — это и есть эти самые «самолетики» (точнее, даже планеры).
Современные технологи, думаю, позволят быстро и экономично реализовать технологию добычи огня трением. Может, забросим эти спички-зажигалки? Займемся изучением «кода» добычи огня трением?
Так спички и есть добыча огня трением, разве нет?
Таки да! :) Только более совершенный и более удобный практический «код» давно известной технологии добычи огня. Кстати, (подумал) и в зажигалке тоже, ведь, используется «технология трения» :)
Так мы договоримся до того, что «корутины» — это своеобразная «зажигалка» современного программирования ;) И изучение кода их реализации безумно важно. И даже сложно будет оспорить сей «революционный» сдвиг в современном программировании.
Так мы договоримся до того, что «корутины» — это своеобразная «зажигалка» современного программирования ;) И изучение кода их реализации безумно важно. И даже сложно будет оспорить сей «революционный» сдвиг в современном программировании.
Даже не знаю, с чего продолжить…
А что тогда «зажигалки», если сопрограммы — это добыча огня трением?
А почему не брюзжать, что до сих пор не выбросили каменные рубила — присвоения и условные переходы?
Когда это сопрограммы успели устареть аж на уровне сферовакуумной концепции, для всех сфер и всех языков сразу?
А что тогда «зажигалки», если сопрограммы — это добыча огня трением?
А почему не брюзжать, что до сих пор не выбросили каменные рубила — присвоения и условные переходы?
Когда это сопрограммы успели устареть аж на уровне сферовакуумной концепции, для всех сфер и всех языков сразу?
А почему не брюзжать, что до сих пор не выбросили каменные рубила — присвоения и условные переходы?Можно, конечно, побрюзжать и на эту тему. Есть теоретический вариант, когда они не нужны совсем. Но практически полно еще ситуаций, когда эти «зубила» вполне удобны и эффективны.
Когда это сопрограммы успели устареть аж на уровне сферовакуумной концепции, для всех сфер и всех языков сразу?
Как минимум, когда появились потоки: переключение между процессами стало проще и понятнее.
Может я как-то не правильно понимаю эти понятия, но мне всегда казалось, что они слегка перпендикулярны друг другу.
Как минимум, когда появились потоки: переключение между процессами стало проще и понятнее.
А ещё медленнее. И это если не вспоминать про генераторы, которые потоками нормально не заменяются.
Скорость — фактор проходящий. Не в ней главное. Сопрограммы и потоки — это разное мышление. В сопрограммах нужно фиксировать точки переключения, в потоках вы об этом совсем не думаете. Исправьте, если не так.
Затем, — «перпендикулярно», «нормально» — эмоциональные оценки. Я не поклонник ни корутин, ни потоков и, подозреваю, даже генераторов ;). Могу, кстати, даже предложить то, что заменяет все это вместе. Но речь сейчас не об этом.
Нам предлагают «изучать исходники классических программ». Я не против и этого. Даже — за. Сам этим иногда занимаюсь. Но только, простите, мир развивается. И то, что раньше было классическим, сейчас вполне может быть «голимым отстоем». Глядя только на код, созданный еще и другими, сложно в этом разобраться. Где — идея, ради которой нужно «ковыряться» в чужом коде?
Возьмем, например, давнюю книгу Гради Буча. ООП с примерами применения. Если я понял идею ООП — примеры просто проглядываю и убеждаюсь насколько я ее хорошо и в деталях усвоил. Если не врубился в нее сразу, то ее примеры помогут, думаю, мало. Если не запутают окончательно. Здесь лучше прочитать книжку сначала.
«Учебный код» в обязательном порядке должен сопровождаться формальным изложением заложенной в него идеи. Как говорил один персонаж — я так думаю! :)
Затем, — «перпендикулярно», «нормально» — эмоциональные оценки. Я не поклонник ни корутин, ни потоков и, подозреваю, даже генераторов ;). Могу, кстати, даже предложить то, что заменяет все это вместе. Но речь сейчас не об этом.
Нам предлагают «изучать исходники классических программ». Я не против и этого. Даже — за. Сам этим иногда занимаюсь. Но только, простите, мир развивается. И то, что раньше было классическим, сейчас вполне может быть «голимым отстоем». Глядя только на код, созданный еще и другими, сложно в этом разобраться. Где — идея, ради которой нужно «ковыряться» в чужом коде?
Возьмем, например, давнюю книгу Гради Буча. ООП с примерами применения. Если я понял идею ООП — примеры просто проглядываю и убеждаюсь насколько я ее хорошо и в деталях усвоил. Если не врубился в нее сразу, то ее примеры помогут, думаю, мало. Если не запутают окончательно. Здесь лучше прочитать книжку сначала.
«Учебный код» в обязательном порядке должен сопровождаться формальным изложением заложенной в него идеи. Как говорил один персонаж — я так думаю! :)
Зато при работе с потоками надо очень аккуратно работать с общими данными. А те задачи/обещания/будущие значения, на которых асинхронные сопрограммы работают — сами по себе механизм синхронизации доступа.
И да, вы всё ещё игнорируете генераторы. А там фиксированные точки переключения растут из решаемой задачи, даже если вы со словами "скорость — фактор проходящий" исхитритесь сделать генераторы на потоках — у вас всё равно останутся явные точки переключения.
исхитритесь сделать генераторы на потокахВ том-то и дело, чтобы этим заниматься, нужно объяснить, хотя бы самому себе, зачем это делать. Ради упражнения с кодом и/или освоения процесса кодирования, языка и т.п.?
Но, предположим, вдруг, такая надобность возникла. Тогда нужно делать подобную реализацию так, чтобы разницы не было. И, наверное, «многопоточные генераторы» будут наследовать достоинства и недостатки оригинальных генераторов. Тогда опять же вопрос- зачем этот «изврат»? Если уж есть и так Вам милы генераторы, то лучше уж их и использовать.
Иногда полезно написать что-то с нуля, чтобы понять как оно работает внутри, хотя бы базовый функционал. Нас в универе заставляли писать свои реализации стеков, очередей, списков, деревьев и т.п. Я считаю это был полезный опыт. Просто посмотрев исходный код этого не запомнишь, а если один раз написать, то запоминается очень хорошо.
После прочтения Вашего сообщения студенты, которые не хотят учить «бесполезную теорию», а сразу ходят писать код, поперхнулись чаем.
Супер!
Я просто оставлю это здесь: http://aosabook.org/en/index.html
Проекты, языки, архитектуры самых разных мастей, и всё — из мира Open Source
Да, эта книга упоминается в статье.
Уф, только с третьей попытки обнаружил. Mea culpa
Да, мне тоже было трудно обнаружить. Почему-то ссылка на блог-пост о книге, а не на саму книгу "Архитектура приложений с открытым исходным кодом"
http://aosabook.org/en/index.html
Разделяю идею автора. Но почему игры? почему DOOM? почему бы не начать с банальных suckless?
Почему никто не вспомнил исходники ТеХ от Дональда Кнута, канонический пример literate programming?
Это полный код ядра издательской системы TeX, оформленный в виде книги, которая была сверстана при помощи системы, которая она описывает.
В коде содержится куча структур данных и алгоритмов, включая один из самых совершенных алгоритмов расстановки переносов строк и разбиения текста на страницы. Синтаксис TeX содержит тьюринг-полный язык макросов, поэтому там реализована динамическая память со сборщиком мусора.
Перед каждой функцией идет абзац с комментариями, более того, функции разбиты на фрагменты, название каждого фрагмента максимально подробно описывает его назначение. При этом вся книга занимает всего лишь 500 страниц, с грамотно проработанной структурой и удобными индексами в конце (по ключевым словам, названиям переменных, функций, фрагментов)
За нахождение любой ошибки в коде обещана символическая награда (обычно она перечисляется на благотворительность), которая каждый раз удваивается.
Единственное, что меня удивляет, что там обильно используется goto, интересно найти мнение Кнута на этот счет.
Это полный код ядра издательской системы TeX, оформленный в виде книги, которая была сверстана при помощи системы, которая она описывает.
В коде содержится куча структур данных и алгоритмов, включая один из самых совершенных алгоритмов расстановки переносов строк и разбиения текста на страницы. Синтаксис TeX содержит тьюринг-полный язык макросов, поэтому там реализована динамическая память со сборщиком мусора.
Перед каждой функцией идет абзац с комментариями, более того, функции разбиты на фрагменты, название каждого фрагмента максимально подробно описывает его назначение. При этом вся книга занимает всего лишь 500 страниц, с грамотно проработанной структурой и удобными индексами в конце (по ключевым словам, названиям переменных, функций, фрагментов)
За нахождение любой ошибки в коде обещана символическая награда (обычно она перечисляется на благотворительность), которая каждый раз удваивается.
Единственное, что меня удивляет, что там обильно используется goto, интересно найти мнение Кнута на этот счет.
Да, ваш пример тоже хорош. Я оставил ссылку на сайт suck less как на программы с практчески идеально-проработанном алгоритмом, который как минимум долго не устаревает. Эти программы надо знать всем хотябы не из-за исходного кода, а просто потому что не знать их стыдно и любой велосипед, выполняющий даже частично их функции может восприниматься как неосведомлённость в рабочем окружении. Их список вот тут: https://suckless.org/rocks/. И есть список софта, который suck full, список их здесь: https://suckless.org/sucks/. Найдите про TeX. А вот тут даже приводят в сравнение: http://harmful.cat-v.org/software/
А ваш пример тоже хорош, взял на заметку.
А ваш пример тоже хорош, взял на заметку.
Спасибо!
Дикая подборка у этого Филипса.
Изучать надо не Дум 3, а исходники Квейка. Как с минимумом файлов создать шедевр.
Что касается архитектуры, то она лучшая у движка Ogre3D.
Изучать исходники апполо, нет смысла. Разве что из любопытства как они всю миссию в 2 кб запихнули. Но тогда современные js1k.com гораздо лучше там не то что код но и графику умудряются запихать.
Единственное из-за чего я полез в исходники апполо из-за того чтобы посмотреть как там сделана POST система. Каждый программист должен проверять целостность своей программы и данных. А этому к сожалению не учат.
И вообще код апполо не удовлетворяет современным требованиям наличия нескольких алгоритмов на борту и выбор между ними и прочим требованиям по увеличению надёжности.
Фотошоп 1 версии не чуть не лучше GIMP тоже Г. Но с боку бантик. Уверен что можно найти исходники более лучшие.
Бесик смотрел. Однако ничего выдающегося. Ни тебе теории парсеров ни архитектуры.
Если вы хотите насладится кодом компилятора возьмите LCC вот там правильная архитектура компилятора. sites.google.com/site/lccretargetablecompiler
Из операционных систем рекомендую вот этот проект посмотреть:
Так же рекомендую посмотреть исходники компьютерной библиотекеи для рисования AGGPas. Библиотеки шаблонов для численных вычислений Eigen — она между прочим считается образцовой.
По нейронным сетям рекомендую изучить репозиторий github.com/karpathy/convnetjs
Качественный легко читаемый код без излишеств.
По операционным системам тоже странный выбор. Судя по всему он искал самые старые ОС, так почему не взять Unix? А если по архитектурным решениям, то Minix и ещё была созданная в научных целях ОС от майкрософта забыл название демо в закромах лежит.
И в дагонку можно упомянуть аналог розетского камя для программистов
rosettacode.org
Изучать надо не Дум 3, а исходники Квейка. Как с минимумом файлов создать шедевр.
Что касается архитектуры, то она лучшая у движка Ogre3D.
Изучать исходники апполо, нет смысла. Разве что из любопытства как они всю миссию в 2 кб запихнули. Но тогда современные js1k.com гораздо лучше там не то что код но и графику умудряются запихать.
Единственное из-за чего я полез в исходники апполо из-за того чтобы посмотреть как там сделана POST система. Каждый программист должен проверять целостность своей программы и данных. А этому к сожалению не учат.
И вообще код апполо не удовлетворяет современным требованиям наличия нескольких алгоритмов на борту и выбор между ними и прочим требованиям по увеличению надёжности.
Фотошоп 1 версии не чуть не лучше GIMP тоже Г. Но с боку бантик. Уверен что можно найти исходники более лучшие.
Бесик смотрел. Однако ничего выдающегося. Ни тебе теории парсеров ни архитектуры.
Если вы хотите насладится кодом компилятора возьмите LCC вот там правильная архитектура компилятора. sites.google.com/site/lccretargetablecompiler
Из операционных систем рекомендую вот этот проект посмотреть:
Так же рекомендую посмотреть исходники компьютерной библиотекеи для рисования AGGPas. Библиотеки шаблонов для численных вычислений Eigen — она между прочим считается образцовой.
По нейронным сетям рекомендую изучить репозиторий github.com/karpathy/convnetjs
Качественный легко читаемый код без излишеств.
По операционным системам тоже странный выбор. Судя по всему он искал самые старые ОС, так почему не взять Unix? А если по архитектурным решениям, то Minix и ещё была созданная в научных целях ОС от майкрософта забыл название демо в закромах лежит.
И в дагонку можно упомянуть аналог розетского камя для программистов
rosettacode.org
Зависит от того, зачем вам это нужно. Например, задача для решения которой опробовано несколько разных подходов, с разных сторон, результат? Его нет, возможно, при детальном рассмотрении того, как устроено несколько наиболее значимых программ, удалось бы сделать что-то более совершенное в плане автоматической подстановки тайминга и вытаскивания встроенных субтитров, с технологией OCR
и машинного обучения, однако, не могу сказать что понимаю как устроены программы на языке с++. Очень не хватает детального гайда по VideosubFinder, Aegisub в плане того, как сделать эти программы на с++ от и до и на других языках. С#, python.
Но это лично моё мнение.
Для меня классика это Minix. Когда 1987 году я первый раз читал ее (операционной системы) код — это был полный восторг.
Исходники оригинального SimCity (также известного, как Micropolis) доступны для скачивания
А ссылка точно рабочая? Мне мой браузер рисует страничку «Oops! That page can’t be found.»
Странно, но ссылка побилась уже после публикации. Оригинальный сервер с исходниками сейчас недоступен, я заменил ссылку на sourceforge.
Простите, что-то странное, но по новой ссылке тоже что-то не соображу, как скачать исходники проекта О__о
О, это я должен извиниться, опять не проверил. Они хорошо шифруются :)
Вот ссылка на копию проекта на гитхабе: https://github.com/SimHacker/micropolis (также добавил в пост)
Вот ссылка на копию проекта на гитхабе: https://github.com/SimHacker/micropolis (также добавил в пост)
И ни одной великой программы в статье. В 2020 интересоваться виндовым софтом — ну такое.
Sign up to leave a comment.
Программисты, давайте изучать исходники классических программ