Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

чудовищное качество это «учебника», вызванное полной профнепригодностью его автора - которую тоже продемонстрировали с кучей подтверждающих ссылок и примеров

Так радикально тоже напрасно, его учебник, по-моему, вполне можно рекомендовать для начального и только начального изучения программированию с нуля. Есть и другие подходы, liksys остаивает необходимость для совремённого обучения начинать с Python, а не Паскаля - это тоже нормальный подход. С Паскаля - более академично, с Python - более практично, в обоих вариантах есть свои плюсы.

Но надо держать в уме, что автор концептуально застрял в 90-х - начале нулевых, а в некоторых вопросах и вообще весьма странен.

автор концептуально застрял в 90-х - начале нулевых, а в некоторых вопросах и вообще весьма странен

Ну и смысл тогда

рекомендовать для начального и только начального изучения программированию с нуля

Берёшь https://ocw.mit.edu/collections/introductory-programming/ или https://www.w3schools.com/programming/index.php или какого-нибудь индуса с ютуба, который расскажет про «веб-сарвар» - практически что угодно, даже Scratch и то будет лучше по качеству. Просто потому что программирование это ни разу не rocket science и объяснение вводных концепций человеку даже с весьма средним образованием не требует каких-то специфических ухищрений. И уж совершенно точно разбавление вводного курса авторским идиотизмом и некомпетентностью не сделает его проще, лучше или понятнее.

Проблема с высером Столярика в том что он не ставит задачу «научить программированию», он ставит задачу «научить программировать так как нравится Столярику» - именно отсюда идиотские определения, не имеющие отношения к общепринятым, дохлые языки и полная каша из концепций. Любая дичь ради того чтобы обучаемый ненароком не прочитал что-то ещё и не начал программировать как нормальный профессионал - ведь в этом случае он шустро расстанется с сектой Столярика и гуру утратит очередного фанбоя.

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

любой, пишущий не в строгом соответствии с его идиосинкразиями это предатель и идиот.

Если не «Гений, чо»

http://stolyarov.info/guestbook/archive/13/#cmt201

Но мир-то не стоит на месте, решаемые задачи усложняются, становятся всё более интеллектуальными, сейчас не 90-е годы и никого уже не удивишь фреймворками в несколько миллионов строк, но зато потратив теже около 1000 строчек кода и использовав мощности «вызывающе дебильных» многоядерных процессоров и видеокарт можно решать задачи, за которые в 90-е и даже нулевые никому в одиночку и в голову бы не пришло браться, да и не всякие компании разработчиков взялись бы.

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

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

И он прав. Бездумное использование готового приводит к крайней хрупкости: https://xakep.ru/2016/03/24/left-pad/

И к ограничению функциональности программы, если нашлась библиотека, которая делает почти всё, что нужно, но не всё. Часто предпочитают просто выкинуть то, что не поддерживается библиотекой.

Причём, опять же, при статической линковке я могу доработать библиотеку до состояния, чтобы она полностью соответствовала моей программе. При динамической у меня только API, под которое я обязан прогнуть свою программу.

он медленый: (искать нулевой) он неудобный: (символ исключаем), что можно хуже придумать?

С памятью: я пишу нет заведамо удачного решения, что не ясно?

Читай внимательно - ты же написал что тестируется deb пакет. Какой ещё своей? И почему тестирует разработчик?

А кто должен тестировать? Вот человек написал программу. Хочет её предоставить людям, чтобы пользовались.

Ты не в курсе зачем нужны QA?

Если разработчик единственный, то он и есть QA специалист. Сам разработал, сам протестировал, сам опакетировал. Если разработчик организация, значит у него в штате QA.

Это что-то меняет? В любом случае пакет протухает сразу при выходе нового дистрибутива.

Его аргумент выглядел бы весомее, если бы он действительно взял и выделил это подмножество, посчитал те 2396 алгоритмов из которых используется только 43, организовал библиотеку из этих 43 алгоритмов, перекомпилировал и показал сокращение сегмента data с 3.5MB до 560kB. При этом не забыл посчитать, что на это ушло 76 человеко часов.

Вот это бы был академический подход. А «почему-то практически уверен» - это демагогия.

Сам разработал, сам протестировал, сам опакетировал.

Сам обосрался с каждым из шагов и теперь виноват кто угодно, только не он. Это настолько тупо что я начинаю подозревать в тебе аватар Столярика.

единственный

и сам себе заказчик?

он медленый: (искать нулевой) он неудобный: (символ исключаем), что можно хуже придумать?

Я в вас верю!.. ;))

С памятью: я пишу нет заведамо удачного решения, что не ясно?

Да всё ясно: лишь бы побухтеть...

А я начинаю подозревать в тебе не умеющего читать.

Давай ещё раз. Разработчик написал некую программу, которая, по его мнению, кому-то может быть полезна. Программа на компьютере разработчика зависит от glibc, других зависимостей нет. Как он, по-твоему, должен выложить её на свой сайт, чтобы ты не считал, что он обосрался?

и сам себе заказчик?

Опенсорс же. Заказчик — общество.

должен выложить её на свой сайт

Зачем на свой? Ты про github, codeberg и прочие тоже не в курсе?

зачем на чужой?

Чтобы ещё больше зависеть от чужих сервисов.

Но надо держать в уме, что автор концептуально застрял в 90-х - начале нулевых, а в некоторых вопросах и вообще весьма странен.

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

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

Иначе как туповатым клоуном с регалиями его после этих опусов не назовешь. Что лишний раз показывает нам, чего именно стоят академические регалии этой страны, раз их раздают подобным кретинам.

давно нет необходимости страдать с динамическими библиотеками

Бред. Статически собранный софт не роляет в малых масштабах, пока такого софта единицы. Но как только у тебя весь софт в системе будет статическим, ты охренеешь от трат диска и оперативной памяти, потому что 50-100мб на бинарник станет нормой. И это безотносительно того, что для исправления проблем с безопасностью внутри динамической библиотеки, которую использует весь системный софт, достаточно обновить только библиотеку, а не ждать, пока мейнтейнер конкретной софтины почешется и закроет дыру.

В расте сделали статическую линковку, потому что так проще и удобнее для деплоя серверного софта. А сейчас они работают над динамической по причинам, которые я описал выше.

И он прав. Бездумное использование готового

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

И к ограничению функциональности программы

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

Причём, опять же, при статической линковке я могу доработать библиотеку до состояния

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

А я начинаю подозревать в тебе не умеющего читать.

А я вас предупреждал. Я же предупреждал?

Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий)

Да мне всё интересно, вдруг какую полезную рекомендацию по выкладыванию пакетов смогу добыть.

Продолжаю наблюдение, но столько попкорна в меня уже не лезет :).

Бред. Статически собранный софт не роляет в малых масштабах, пока такого софта единицы. Но как только у тебя весь софт в системе будет статическим, ты охренеешь от трат диска и оперативной памяти, потому что 50-100мб на бинарник станет нормой.

50-100Мб на сжираемую бинарником память и так норма. Бинарников в памяти не больше сотни, для современного компьютера ни о чём. Бинарников на диске порядка пары тысяч. 200 ГБ тоже ни о чём.

В реальности заметно меньше, потому что -flto выкинет ненужное.

Можно таскать с собой свой FLTK, но скорее всего ты этого делать не захочешь, потому что тогда тебе придется следить за ней самому и исправлять в ней баги.

Если на ней написана моя программа и эти баги мешают моей программе, их всё равно мне придётся исправлять.

И яркий тому пример - столь любимый столяровым FLTK, из-за использования которого в TigerVNC не могут реализовать херову гору важных пользовательских фичей.

А линковали бы статически и могли бы дописать всё, чего не хватает.

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

Ага. Написал программу, всё работает. Не хватает пары фичей. Выкидываем FLTK, берём Qt, переписываем всю программу. Потом не хватит ещё какой фичи, можно будет с Qt на Gtk переписать. Зато всегда есть чем заняться…

В подавляющем же большинстве случаев тебе это не понадобится вообще никогда.

Выше ты привёл два примера, когда это надо: исправить в баг в библиотеке, дописать недостающую функциональность в библиотеке.

Что лишний раз показывает нам, чего именно стоят академические регалии этой страны

Не перегибай. Академические регалии везде фрикам могут дать (и дают).

Я думал что уже давно всем очевидно, зачем изобретена динамическая линковка и почему RedHat убил статическую линковку glibc, но оказывается это очевидно не всем. Для меня очевидно, что динамическая линковка придумана для независимой разработки частей продукта разными группами разработчиков. Всё. Никаких других целей не было и нет. Сказка про «сокращение потребляемой памяти» - это старая сказка о заботе о пользователях, котрая легко убивается как и давно используемым форматом в маках, так и недавним распространением контейнеров.

Эту тему обсудили на этом сайте лет двадцать назад, и вот опять! Там ещё вопрос поднимали, существует ли дистр, в котором используется только статическая линковка, и я приводил в пример Cray Linux.

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

А какая разница для разработки от способа линковки? Чтобы те, кто используют библиотеку, не могли её изменять?

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

Сказка про «сокращение потребляемой памяти» - это старая сказка о заботе о пользователях, котрая легко убивается как и давно используемым форматом в маках, так и недавним распространением контейнеров.

Во-первых, нет; во-вторых, часть этих заблуждений в линуксе не применима.

Эту тему обсудили на этом сайте лет двадцать назад, и вот опять!

Потому что вы всё еще заблуждаетесь.

50-100Мб на сжираемую бинарником память и так норма.

Нет.

Бинарников в памяти не больше сотни

Нет.

200 ГБ тоже ни о чём.

Это очень много, учитывая, что типичный NVME сейчас имеет емкость от 1 до 4 терабайт в лучшем случае.

Если на ней написана моя программа и эти баги мешают моей программе, их всё равно мне придётся исправлять.

Отсылаешь патч и исправляешь.

А линковали бы статически и могли бы дописать всё, чего не хватает.

А потом поддерживать свой ни с чем не совместимый велосипед.

Выкидываем FLTK, берём Qt, переписываем всю программу.

Просто вместо того, чтобы писать программу на нормальном тулките, ваша братия берет FLTK, а затем мучительно дополняет его платформозависимыми костылями под иксы, винду и мак. И будем честными, в кишки библиотеки с хорошей архитектурой тебе почти никогда не придется лезть, потому что она будет спроектирована так, чтобы всё нужное торчало наружу и было доступно для переопределения. В крайнем случае - закидываешь патч. А если твоя библиотека настолько дохлая, что патчи там принимают раз в полгода - то и использовать ее, конечно же, не нужно. Там где плохое сопровождение - там и баги.

Выше ты привёл два примера, когда это надо: исправить в баг в библиотеке, дописать недостающую функциональность в библиотеке.

И это всё совершенно не означает, что библиотеку надо таскать с собой. Разрабатываешь софт, патчишь либы, докидываешь патчи в апстрим до релиза.

В любом случае вопрос безопасности и потребляемого места здесь первостепенный.

Независимость. Твои косяки локализованы.

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

Вот только жизнь разрабам библиотеки это не облегчает жизнь никак: приходится очень внимательно следить за стабильностью public API & ABI, заморачиваться с версированием символов итд.

Берёшь https://ocw.mit.edu/collections/introductory-programming/

Вы серьёзно эту х*ту в картинках уровня сельскохозяйственного техникума в Лаосе считаете достойным введением в программирование для ВУЗа с международным именем?!

или https://www.w3schools.com/programming/index.php

Ещё более достойный способ зря потратить время. Если после первого можно хотя бы на Питоне уметь что-то лабать, то это вообще ни уму, ни сердцу.

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

Вы серьёзно эту х*ту в картинках уровня сельскохозяйственного техникума в Лаосе

Это ты с позиции профессора калифорнийского технологического университета судишь, или с позиции бюджетника в усть-урюпинском заборостроительном училище, преподавателем в котором на полставки с трубочистом ты примерно и являешься? Нам действительно надо знать мнение о курсе MIT от человека, который не в состоянии прочитать две страницы мануала по systemctl, чтобы решить свою проблему, и потом бегающего и рассказывающего небылицы по форуму?

Ещё более достойный способ зря потратить время.

Более чем. Не умея в веб ни в зуб ногой, я в него научился по мануалам с w3schools и запилил коммерческий продукт, который меня теперь кормит.

Независимость. Твои косяки локализованы.

Опять не понял. Вот есть две программы с одинаковым кодом и одинаковыми библиотеками. Одна слинкована динамически, вторая статически. В них проявляется одинаковая ошибка. Как она более локализована в первой?

Это правда. Никак. И не должно. Цель была лишь разделить разработку.

Идите дальше. Вот есть проект на, скажем 10000 строк. Вы сделали inline всех функций и процедур и получили один длинный main(). В какой исходник легче внести изменения, в тот, в котором действия разбиты и функционально локализованы, или в одну длинную портянку?

Цель была лишь разделить разработку.

Дык. Разрабам апликух практически без разницы дали им headers + .so или headers + .a. Если что-то и упрощается так это деплоймент фиксов.

Есть ещё schedule, roadmap, budget, human force, FTEs, и вообще независимая поставка всего проекта и подпроектов. Динамическая линковка очевидно позволяет поставлять проект по частям.

Это очень много, учитывая, что типичный NVME сейчас имеет емкость от 1 до 4 терабайт в лучшем случае.

То есть все программы занимают не больше 20% диска. Ни о чём.

Отсылаешь патч и исправляешь.

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

А в статической линковке исправил и сразу отдал пользователю.

А потом поддерживать свой ни с чем не совместимый велосипед.

В чём проблема его поддерживать, если он часть программы?

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

И какую же библиотеку с хорошей архитектурой рекомендуете вместо FLTK?

И это всё совершенно не означает, что библиотеку надо таскать с собой. Разрабатываешь софт, патчишь либы, докидываешь патчи в апстрим до релиза.

И ждёшь, пока этот патч доползёт до разработчика дистрибутива.

В любом случае вопрос безопасности и потребляемого места здесь первостепенный.

Безопасность при статической линковке тоже выше. При динамической для безопасности надо все библиотечные функции считать заведомо вредоносными, так как что там будет у пользователя с учётом LD_PRELOAD заранее неизвестно. При статической весь код можно считать доверенным.

Про потребляемое место я уже написал. Ты предлагаешь жертвовать стабильностью и безопасностью ради экономии в несколько тысяч рублей.

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

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

Динамическая линковка очевидно позволяет поставлять проект по частям.

Статическая тоже. Для запуска программы её всё равно надо слинковать и нет разницы, сделано это один раз при компиляции или каждый раз при запуске.

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

Нам действительно надо знать мнение о курсе MIT от человека, который не в состоянии прочитать две страницы мануала по systemd?

Вам действительно надо знать мнение профессионального педагога, поскольку предлагаемое – это уровень курсов по программированию на Питоне для начинающих, набранных с улицы по объявлению. И то если те после или параллельно будут изучать Питон по нормальному руководству.

Не умея в веб ни в зуб ногой, я в него научился по мануалам с w3schools

Затратя сколько времени? Листали для сравнения другие книги? Заходили в тупик при изучении?

Я же писал про предложенный вводный курс, а не про все материалы.

Ну, вот открыл я курс (https://www.w3schools.com/bash/bash_commands.php) по всем известный Bash. Первый вам вопрос, с какого перепугу они называют «Common Bash Commands» такие общеюниксовые утилиты, как ls, chmod, rm? А echo есть даже в cmd.com.

man bash много полезнее и информативнее.

Посмотрел их материалы про Си. Пользоваться можно, если ничего другого нет.

Подобный способ подачи материала подходить только для учеников с СДВГ, для остальных, способных читать хотя бы 2 страницы текста за раз, это мучение – скармливать мозгу столь крошечные порции.

В случае динамической линковки вы можете независимо править, изменять, дополнять свой код и не зависимы от основного цикла разработки. Скомпилировали - отослали заказчику, изменили, скомпилировали, отослали опять. Не нужно собирать всё.

В случае статической тоже. Для LGPL явно описано, как именно (заказчику отправляются объектные файлы и библиотека, чтобы он мог слинковать). Так что можно и независимо. Разве что часть преимуществ статической при этом исчезает: модифицированную версию так просто не обновить, ответственность за работоспособность программы размывается.

А в статической линковке исправил и сразу отдал пользователю.

Так никто не запрещает линковать статически, как никто не запрещает линковать динамически и поставлять свой коммерческий продукт зараз со всеми библиотеками.

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

вообще независимая поставка всего проекта и подпроектов

Крайне рисковая затея, должен заметить. Даже изменения в конфигурации могут привести к крайне неприятным последствиям - перетестировать всё придётся по-любому, в «mission critical» случаях так точно.

А что делать? когда нужно “mission critical”, тогда один способ, когда нужно «тяп ляп и в прод», тогда другой.

Давайте, я как программист программисту, сейчас набросаю иллюстрацию того, что я имею в виду, хорошо? Эх, давно не брал я в руки шашек … ну ничего, сейчас наваляю что-нибудь.

То есть все программы занимают не больше 20% диска. Ни о чём.

У тебя в двух этих предложениях содержатся взаимоисключающие параграфы.

ждёшь

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

И какую же библиотеку с хорошей архитектурой рекомендуете вместо FLTK?

Qt или GTK.

И ждёшь, пока этот патч доползёт до разработчика дистрибутива.

При разработке ты можешь держать какое угодно окружение. Для продакшна ты выставляешь системные требования. Проблема решена.

Безопасность при статической линковке тоже выше.

Нет. Я уже объяснил, почему, перечитывай заново мои комментарии выше.

При статической весь код можно считать доверенным.

Нельзя.

Вам действительно надо знать мнение профессионального педагога

Это правда. Вот только я пока не вижу в этом треде ни одного комментария от профессионального педогога.

Затратя сколько времени?

Пару недель.

Листали для сравнения другие книги? Заходили в тупик при изучении?

Нет и нет.

с какого перепугу они называют «Common Bash Commands»

Потому что на первых порах там изучают шелл как явление, а потом уже всё остальное.

люди все одинаковые, просто ты считаешь, что академики отличаются.

и если все без исплючения вокруг идиоты, то может ты что то не знаешь?