Неофит прочитал учебник Вирта для самых маленьких и решил реализовать то, что сумел понять. Ничего, через несколько лет — с появлением реального опыта реальных разработок — эта блажь у него пройдёт.
Что касается отказоустойчивости, советую заглянуть в: Янг С., «Алгоритмические языки реального времени. Конструирование и разработка» — там разбираются проблемы разных типов реакции на ошибки.
Представляю, что будет с ядерным реактором, автопилотом, управлением баллистической ракетой, если программа в случае фатальной ошибки продолжит свою обычную работу — с совершенно некорректными данными и гарантированно последующей катастрофой.
P.S. У Вирта самое интересное — не банальный метод рекурсивного спуска, которым он реализует лексический анализатор, а очень простой подход к раздельной компиляции и верификации версий компонентов.
На каждом шаге достаточно анализировать только клетки, изменившее своё состояние на предыдущем шаге, и соседние с ними 8 клеток. Это многократно меньше клеток всго игрового поля.
И неизвестно, что будет эффективнее: предельно оптимизировать анализ одной клетки с просмотром всего поля или оптимизировать формирование и обработку списка клеток, которые могут изменить своё состояние на следующем шаге.
Да, одну клетку будем обрабатывать дольше. Но кол-во обрабатываемых клеток на типичном поле будет меньше даже не в разы, а на порядки.
Да, скорость будет плавающей и в худшем случае будет медленнее. Но эти худшие случаи будут встречаться практически только в начальных комбинациях, а дальше всё быстро сведётся к достаточно низкой средней плотности меняющихся на одном шаге клеток.
Слишком упрощено. По такой схеме нанятый генеральный директор компании — тоже пролетарий. Такое ранне-марксистское понимание пролетариата потеряло актуальность с появлением «рабочей аристократии».
Простите, что влезаю: ни с какой стороны не авиаконструктор и любопытно узнать правильный ответ на заданный вами вопрос.
Две дилетантские гипотезы, которые пришли в голову:
1. Внешняя часть лопасти, движущейся от хвоста к носу, превысит скорость звука. Каждая лопасть будет заново преодолевать звуковой барьер на каждом обороте винта. И, полагаю, создать участок лопасти, одинаково хорошо создающий подъёмную силу как в дозвуковом, так и в сверхзвуковом режимах, технологически крайне сложно (если вообще возможно), а экономически совершенно бессмысленно.
2. Ближняя к оси винта часть лопасти, движущейся от носа к хвосту, будет двигаться относительно потока воздуха в обратном направлении и создавать не подъёмную, а прижимную силу. Опять же — компенсация этого эффекта за счёт, например, разделения лопасти по длине на несколько зон с независимым управлением углом атаки лопасти в каждой зоне упрётся в технологии и экономику.
Эти гипотезы приводят к двум следствиям:
1. Существенно увеличившиеся силы, изгибающие лопасти на каждом обороте винта, могут привести к разрушению лопастей.
2. Необходимость компенсации падения подъёмной силы винта и необходимость существенного повышения мощности (и веса) силовой установки для преодоления лопастями звукового барьера могут привести к тому, что вертолёт сможет поднять только себя — на полезный груз ничего не останется.
Помнится, для Win-98SE было несколько «оптимизаторов», якобы сжимающих содержимое RAM. Но и оперативной памяти в системнике тех времён было на два порядка меньше.
Не проще ли — вместо того, чтобы заниматься настройкой тормозящих систему костылей — взять более экономный по потреблению ресурсов дистрибутив Linux с более экономным оконным менеджером? Ставить развесистый Ubuntu при нехватке RAM — мягко говоря, странное решение.
Это всё — про то, как оформить код. Но до того, как заниматься написанием кода, надо сначала найти способ достижения заданной цели (т.е. алгоритм, который этот код будет реализовывать). И если великолепно оформленный — по всем заветам ООП — код, обрабатывающий большой массив данных, имеет вычислительную сложность O(n³) при наличии общеизвестного алгоритма O(n∙log(n)) — это безусловный говнокод, демонстрирующий умение писать код при абсолютном незнании элементарных основ программирования.
Наследование — зло, порождающее хрупкий код. Оно создаёт больше проблем, чем решает. Намного надежнее использовать только интерфейсы — вообще без наследования. Типажи (trait) + интерфейсы обеспечивают в точности те же возможности, но без присущих наследованию проблем. Более того, вскользь упомянутая в статье композиция также является полной и куда более надёжной заменой наследованию.
Мантра «полиморфизм, инкапсуляция, наследование» — это не «киты ООП», а всего лишь наиболее модный из вариантов компонентного программирования (включающего множество разных вариантов ООП). Тот же Go великолепно обходится и без наследования, и даже без классов. И даже JavaScript много лет прекрасно жил без классов — пока корпорации, заведующие стандартизацией JS, не решили удешевить подготовку JS-разработчиков.
Автор статьи почему-то постоянно называет PEP8 «стандартом». Хотя сам PEP8 позиционирует себя не как стандарт, а как руководство, содержащее набор соглашений по написанию кода. Ни о каком «стандарте» в тексте PEP8 речи нет.
Да, PEP8 — самый популярный Code Style для Python. Но чтобы что-то называть «стандартом» одной популярности недостаточно.
И «Чистый код», который в статье тоже назван «стандартом», стандартом никак не является. Это всего лишь личный взгляд Мартина на то, как должен выглядеть идеальный код. Да, взгляд популярный. Но то, что какие-то компании используют подход Мартина — это лишь внутрикорпоративный Code Style, но никак не «стандарт».
N.B. Читать статьи Мартина ещё можно — там он хотя бы в объёме текста ограничен. Но книги — это кошмар: по десять раз повторяет одно и тоже, как дауну. Если вылить воду, толщина его книг уменьшится в несколько раз.
Только вот «Коля» изучал не программирование. Он изучал лишь написание кода на языках программирования. Не то, как находить способы решения программистских задач (т.е. алгоритмы), а то, как записывать алгоритмы в понятной компьютеру форме — без понимания базовых свойств алгоритмов.
Потому, все псевдопсихологические рассуждения в статье не имеют смысла, так как изначально произведена подмена объекта обсуждения.
И подавляющее большинство «онлайн курсов» изучить программирование тоже не помогут: они дрессируют писать типовой код, решающий типовые рутинные задачи, но не дают знания основ программирования.
А такие уж весёлые фильмы Гайдая? Да, они очень смешные. Но если убрать гэги и присмотреться к сюжету — там ведь совсем не весело.
«Невезучие» — тоже невесёлый фильм. Да, смешной. Но никак не весёлый. Впрочем, я видел только версию, урезанную советской цензурой.
Из всех комедий с Ришаром, которые видел, именно «Игрушку» и «Беглецов» считаю лучшими.
P.S. В других комментариях не раз Мэла Брукса вспоминали, но другие его фильмы. Я же напомню про его «12 стульев» — с концовкой совсем не по Ильфу&Петрову. Брукс в своём очень смешном фильме сознательно делает совершенно депрессивный финал.
Или великолепная советская «Интервенция» — которая даже не комедия, а трагифарс. Когда весь фильм смеёшься, а потом — как мордой в стену — с разбегу влетаешь в финал.
Лучшие комедии — они ведь совсем не весёлые. Какое настроение остаётся после просмотра «Игрушки» или «Беглецов» с Пьером Ришаром? И после фильмов Чарли Чаплина веселиться совсем не хочется.
Что касается исходного списка, то меня удивило присутствие примитивной «Матрицы» и отсутствие куда более умной «Экзистенции», присутствие попсовой «Амели» и отсутствие куда более интересных «Деликатесов» того же Жёне.
В целом же, на мой вкус в списке слишком много Голливуда и совершенно не хватает европейского авторского кино — от Феллини до Гринуэя.
PEP8 хорош для пет-проектов. А работая в компании, вы будете оформлять код не по PEP8, а по тому CodeStyle, который утверждён в этой компании.
И вы смешиваете тёплое с мягким — ставя на одну доску правила оформления кода, никак не определяемые синтаксисом языка, и синтаксические конструкции самого языка, которые выглядят, как типизация, а на деле лишь вводят новичка в заблуждение.
Если бы это был реальный контроль типов (хотя бы так, как это сделано в PHP), он бы имел смысл. Но в Python это лишь благое пожелание, не имеющее никакого значения. Например, данный код выполнится и напечатает 5.2:
def f(a: str, b: int) -> bool: return a + b
print (f(1.5, 3.7))
Впрочем, дело даже не в этом, а в том, что учащийся привыкает не обращать внимание на типы и кол-во переменных — когда одна и та же переменная используется для значений разных типов и совершенно разных целей. Но главная проблема — абсолютная лояльность интерпретаторов динамических языков к логическим ошибкам в коде. Ученик будет ошибаться и даже не сможет понять, что ошибся. Более того, он привыкает писать ошибочный код.
Понятно, что языки со статической типизацией — не панацея. Но они на этапе компиляции выявляют те ошибки, которые язык с динамической типизацией не может заметить. Возможностей налажать в языках со строгой статической типизацией многократно меньше. И чем жёстче компилятор относится к сомнительным местам в коде, тем лучше для обучающегося.
N.B. И это одна из причин выбрать именно Go: он считает ошибками то, на что компиляторы других языков не обращают внимания.
Python — один из худших языков для начального изучения программирования. Начиная с того, что Python — как и любой другой язык с динамической типизацией — провоцирует писать говнокод, и заканчивая тем, что используя встроенные в Python составные типы данных невозможно адекватно оценить вычислительную сложность найденного решения задачи. Кроме того, дикое количество синтаксического сахара в Python, позволяющее практически любой алгоритмический примитив записать множеством разных способов, так же не способствует качественному обучению. И это лишь малая часть претензий к Python в роли первого языка программирования.
N.B. Хороший первый язык — предельно маленький, ортогональный, с предельно жёсткой статической типизацией. Из современных учебных языков — Oberon-07, из промышленных — Go.
Книга рассчитана на людей с пытливым умом и целеустременных, начинающих, что не имеют опыта программирования, но имеют пытливый ум и желание изучить Python.
но через четыре строчки:
Первое, на чем хотелось бы обратить ваше внимание — эта книга не для людей, что ранее не программировали. Она рассчитана на тех, кто имеет маломальский опыт программирования на любом из языков программирования и кто желает быстро освоить Python.
Автор старается дать не только абстрагированную от реального мира теорию, но и также связывает её с реальностью. давая практические примеры.
Теория — это те знания (прежде всего, свойства алгоритмов и дискретная математика), которые необходимы программисту для написания эффективного кода — знания, которые не зависят ни от языка программирования, ни круга решаемых задач. Но, как и любой другой учебник языка программирования, данная книга никакой теории, необходимой для изучения программирования, не содержит. Умение же писать код на конкретном языке программирования является прикладной дисциплиной и никакой теории не содержит — как не содержит теории умение пользоваться русским алфавитом.
Тут важен сам факт первого законодательного одобрения права на ремонт: это облегчит продавливание аналогичных законов и для других видов техники.
Хотя, конечно, абсолютным право на ремонт быть не может: вы бы рискнули сделать медицинский рентгеновский снимок аппаратом, отремонтированным в сторонней мастерской или силами самой поликлиники?
А может быть, всё было бы наоборот? Именно нефтедоллары позволил противникам либерализации экономики свернуть проводимые реформы. И, как результат, 15 лет застоя послужили причиной развала сначала экономики, а через несколько лет и страны.
Зачем переводить очередной опус, содержащий в точности тоже самое, что и множество уже опубликованных на Хабре статей и напечатанных учебников JavaScript? Да ещё и пытающийся убедить читателя, что говнокод — это хорошо.
Всё, что снижает читабельность и/или надёжность промышленного кода — говнокод (полагаться на автоматическое приведение типов — безусловное снижение надёжности кода). Это в пет-проектах можно предлагаемым автором трюкачеством заниматься, а в качественном хорошо читаемом коде для получения логических значений будут использоваться не ‼ и Boolean(), а === и !== — о которых в статье вообще не упоминается.
Для первичного ознакомления с алгоритмами лучше взять учебник Вирта — в котором «на пальцах» объясняется концепция вычислительной сложности и сравниваются разные алгоритмы решения одной задачи. А ГА — согласен с автором статьи — типичный научпоп для тех, кто ни в каком виде не собирается заниматься программированием, но хочет иметь хоть какое-то представление о нём.
Что касается отказоустойчивости, советую заглянуть в: Янг С., «Алгоритмические языки реального времени. Конструирование и разработка» — там разбираются проблемы разных типов реакции на ошибки.
Представляю, что будет с ядерным реактором, автопилотом, управлением баллистической ракетой, если программа в случае фатальной ошибки продолжит свою обычную работу — с совершенно некорректными данными и гарантированно последующей катастрофой.
P.S. У Вирта самое интересное — не банальный метод рекурсивного спуска, которым он реализует лексический анализатор, а очень простой подход к раздельной компиляции и верификации версий компонентов.
И неизвестно, что будет эффективнее: предельно оптимизировать анализ одной клетки с просмотром всего поля или оптимизировать формирование и обработку списка клеток, которые могут изменить своё состояние на следующем шаге.
Да, одну клетку будем обрабатывать дольше. Но кол-во обрабатываемых клеток на типичном поле будет меньше даже не в разы, а на порядки.
Да, скорость будет плавающей и в худшем случае будет медленнее. Но эти худшие случаи будут встречаться практически только в начальных комбинациях, а дальше всё быстро сведётся к достаточно низкой средней плотности меняющихся на одном шаге клеток.
Две дилетантские гипотезы, которые пришли в голову:
1. Внешняя часть лопасти, движущейся от хвоста к носу, превысит скорость звука. Каждая лопасть будет заново преодолевать звуковой барьер на каждом обороте винта. И, полагаю, создать участок лопасти, одинаково хорошо создающий подъёмную силу как в дозвуковом, так и в сверхзвуковом режимах, технологически крайне сложно (если вообще возможно), а экономически совершенно бессмысленно.
2. Ближняя к оси винта часть лопасти, движущейся от носа к хвосту, будет двигаться относительно потока воздуха в обратном направлении и создавать не подъёмную, а прижимную силу. Опять же — компенсация этого эффекта за счёт, например, разделения лопасти по длине на несколько зон с независимым управлением углом атаки лопасти в каждой зоне упрётся в технологии и экономику.
Эти гипотезы приводят к двум следствиям:
1. Существенно увеличившиеся силы, изгибающие лопасти на каждом обороте винта, могут привести к разрушению лопастей.
2. Необходимость компенсации падения подъёмной силы винта и необходимость существенного повышения мощности (и веса) силовой установки для преодоления лопастями звукового барьера могут привести к тому, что вертолёт сможет поднять только себя — на полезный груз ничего не останется.
P.S. Ютуб по теме не смотрел.
Не проще ли — вместо того, чтобы заниматься настройкой тормозящих систему костылей — взять более экономный по потреблению ресурсов дистрибутив Linux с более экономным оконным менеджером? Ставить развесистый Ubuntu при нехватке RAM — мягко говоря, странное решение.
Наследование — зло, порождающее хрупкий код. Оно создаёт больше проблем, чем решает. Намного надежнее использовать только интерфейсы — вообще без наследования. Типажи (trait) + интерфейсы обеспечивают в точности те же возможности, но без присущих наследованию проблем. Более того, вскользь упомянутая в статье композиция также является полной и куда более надёжной заменой наследованию.
Мантра «полиморфизм, инкапсуляция, наследование» — это не «киты ООП», а всего лишь наиболее модный из вариантов компонентного программирования (включающего множество разных вариантов ООП). Тот же Go великолепно обходится и без наследования, и даже без классов. И даже JavaScript много лет прекрасно жил без классов — пока корпорации, заведующие стандартизацией JS, не решили удешевить подготовку JS-разработчиков.
Да, PEP8 — самый популярный Code Style для Python. Но чтобы что-то называть «стандартом» одной популярности недостаточно.
И «Чистый код», который в статье тоже назван «стандартом», стандартом никак не является. Это всего лишь личный взгляд Мартина на то, как должен выглядеть идеальный код. Да, взгляд популярный. Но то, что какие-то компании используют подход Мартина — это лишь внутрикорпоративный Code Style, но никак не «стандарт».
N.B. Читать статьи Мартина ещё можно — там он хотя бы в объёме текста ограничен. Но книги — это кошмар: по десять раз повторяет одно и тоже, как дауну. Если вылить воду, толщина его книг уменьшится в несколько раз.
Потому, все псевдопсихологические рассуждения в статье не имеют смысла, так как изначально произведена подмена объекта обсуждения.
И подавляющее большинство «онлайн курсов» изучить программирование тоже не помогут: они дрессируют писать типовой код, решающий типовые рутинные задачи, но не дают знания основ программирования.
«Невезучие» — тоже невесёлый фильм. Да, смешной. Но никак не весёлый. Впрочем, я видел только версию, урезанную советской цензурой.
Из всех комедий с Ришаром, которые видел, именно «Игрушку» и «Беглецов» считаю лучшими.
P.S. В других комментариях не раз Мэла Брукса вспоминали, но другие его фильмы. Я же напомню про его «12 стульев» — с концовкой совсем не по Ильфу&Петрову. Брукс в своём очень смешном фильме сознательно делает совершенно депрессивный финал.
Или великолепная советская «Интервенция» — которая даже не комедия, а трагифарс. Когда весь фильм смеёшься, а потом — как мордой в стену — с разбегу влетаешь в финал.
Что касается исходного списка, то меня удивило присутствие примитивной «Матрицы» и отсутствие куда более умной «Экзистенции», присутствие попсовой «Амели» и отсутствие куда более интересных «Деликатесов» того же Жёне.
В целом же, на мой вкус в списке слишком много Голливуда и совершенно не хватает европейского авторского кино — от Феллини до Гринуэя.
И вы смешиваете тёплое с мягким — ставя на одну доску правила оформления кода, никак не определяемые синтаксисом языка, и синтаксические конструкции самого языка, которые выглядят, как типизация, а на деле лишь вводят новичка в заблуждение.
Впрочем, дело даже не в этом, а в том, что учащийся привыкает не обращать внимание на типы и кол-во переменных — когда одна и та же переменная используется для значений разных типов и совершенно разных целей. Но главная проблема — абсолютная лояльность интерпретаторов динамических языков к логическим ошибкам в коде. Ученик будет ошибаться и даже не сможет понять, что ошибся. Более того, он привыкает писать ошибочный код.
Понятно, что языки со статической типизацией — не панацея. Но они на этапе компиляции выявляют те ошибки, которые язык с динамической типизацией не может заметить. Возможностей налажать в языках со строгой статической типизацией многократно меньше. И чем жёстче компилятор относится к сомнительным местам в коде, тем лучше для обучающегося.
N.B. И это одна из причин выбрать именно Go: он считает ошибками то, на что компиляторы других языков не обращают внимания.
N.B. Хороший первый язык — предельно маленький, ортогональный, с предельно жёсткой статической типизацией. Из современных учебных языков — Oberon-07, из промышленных — Go.
но через четыре строчки:«Вы или крестик снимите, или трусы наденьте» © советский анекдот.
Теория — это те знания (прежде всего, свойства алгоритмов и дискретная математика), которые необходимы программисту для написания эффективного кода — знания, которые не зависят ни от языка программирования, ни круга решаемых задач. Но, как и любой другой учебник языка программирования, данная книга никакой теории, необходимой для изучения программирования, не содержит. Умение же писать код на конкретном языке программирования является прикладной дисциплиной и никакой теории не содержит — как не содержит теории умение пользоваться русским алфавитом.
Тут важен сам факт первого законодательного одобрения права на ремонт: это облегчит продавливание аналогичных законов и для других видов техники.
Хотя, конечно, абсолютным право на ремонт быть не может: вы бы рискнули сделать медицинский рентгеновский снимок аппаратом, отремонтированным в сторонней мастерской или силами самой поликлиники?
Всё, что снижает читабельность и/или надёжность промышленного кода — говнокод (полагаться на автоматическое приведение типов — безусловное снижение надёжности кода). Это в пет-проектах можно предлагаемым автором трюкачеством заниматься, а в качественном хорошо читаемом коде для получения логических значений будут использоваться не ‼ и Boolean(), а === и !== — о которых в статье вообще не упоминается.