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

Qt или GTK.

Кому в GTK написать, чтобы в GtkTextView сделали поддержку Alt-кодов?

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

Почему не Паскаль:

http://stolyarov.info/guestbook/archive/7/#cmt802

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

В статике каждый раз при обновлении println.a требуется линковка с hello.o. Этого файла нет ни у разработчика println.a, ни тем более у заказчика. Значит каждый раз, когда изменяется println.a необходимо привлекать разработчика hello.o для финальной линковки, то есть разделения не существует.

В динамике изменения println.so не требуют привлечения разработчика hello.o вообще. Это я и называю раздельной разработкой и считаю единственной причиной изобретения динамической линковки с самого начала.

К линуксу модули подгружаются без этого.

Как к линуксу подгружаются модули?

Интеллигентно:

DESCRIPTION
       modprobe intelligently adds or removes a module from the Linux kernel

ни тем более у заказчика

С чего вдруг? Если Заказчику нужна возможность обновления используемых библиотек, то он получить в пакете hello.o, println.a и hello. Если вдруг println под LGPL, то это вообще обязательно.

Значит каждый раз, когда изменяется println.a необходимо привлекать разработчика hello.o для финальной линковки, то есть разделения не существует.

Только если разработчик по какой-то причине не отдаёт hello.o.

А что есть «модуль» для ядра линукс?

Кто-то что-то говорил про открытые исходники?

Чтобы интеллигентно добавить модуль, нужны исходники?

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

Селя ви, как говорят французы. Всё течёт, всё меняется, - как сказал ещё Гераклит Эфесский примерно за 500 лет до н.э. С тех пор, как возникло разделение труда, мы неизбежно используем чужое и зависим от него. Вопрос только в разумном компромиссе между степенью использования чужого и трудозатратами и созданием своего. А то ведь можно дойти до того, чтобы писать программы только исключительно на компьютере, в котором всю комплектуху сам сделал в гараже, включая процессор (есть такие энтузиасты, освоили даже что-то 8-ми битное в гараже делать).

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

Ведь иначе «решать её вместо пары дней пару лет».

Правильно, можно писать свою талассу пять лет или сколько он её пишет или использовать чужие решения пусть даже на нелюбимом им питоне, жабаскрипте и чем ещё (и прочие требования), а своё время потратить на что-то другое. Столяров решил потратить на Талассу. И сделать её доступной другим. Честь ему и хвала, но это не значит, что те, кто решил иначе - «враги народа».

А тот же OpenCV, PyTorch и кучу всего ещё один-два человека вообще не потянут поддерживать в своём проекте.

Нет, не нужны. Возможно, получится менее интеллигентно, но не нужны. Впрочем, там разговор не про модули ядра.

Разработчикам GTK, очевидно.

есть такие энтузиасты, освоили даже что-то 8-ми битное в гараже делать

Имя одного такого энтузиаста сразу приходит на ум - Стив Возняк. Как раз с рассыпухи для 8-битного процессора в гараже начинал.

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

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

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

Я как-бы специально для этого и сделал приписку последнего предложения, чтобы сказать «но это всё не отменяет…» Конечно, поведение обсуждаемого персонажа не достойно преподавателя и наносит ему вред в глазах серьёзной аудитории, но может он и не ищет больше серьёзную аудиторию?

Кто-то что-то говорил про открытые исходники?

Если они есть, то тем более заказчик может пересобрать.

А тот же OpenCV, PyTorch и кучу всего ещё один-два человека вообще не потянут поддерживать в своём проекте.

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

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

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

Но тогда следующий шаг: попросить ChatGPT написать CRM и убедить себя, что полученный результат именно то, чего хотелось. Времени будет потрачено всего полчаса вместо месяца на Питоне или нескольких лет на Си. Экономия.

Разработчикам GTK, очевидно.

И через сколько оно будет принято? Если я даже патч отправлю.

Почему ты меня спрашиваешь? Иди в рассылку GTK, там и спроси.

При реализации проекта определяется, достаточно ли текущего состояния библиотеки для его реализации, и если достаточно, то желательно, чтобы библиотека не менялась.

Речь не просто о том, чтобы рядом приложить рабочий вариант. Он довольно категорично высказался в гостевой http://www.stolyarov.info/guestbook/archive/12#cmt533 :

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

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

Причём OpenCV ещё не самая сложная в этом смысле библиотека, в случае нейросетей только библиотека PyTorch в совокупности занимает несколько гигабайт, небольшая программа в итоге со всеми цепочками зависимостей потянет на 10+ Гб. и я не преувеличиваю. Ещё и с разными версиями под разные GPU. Банально не у всех место найдётся всё это хостить в инете.

И что тут надо сделать, чтобы заслужить одобрение «гуру»? Для начала переписать всё с Python на C++ или C (причём старых версий) или разработать свои библиотеки под свои используемые возможности и т.д. Работы одному человеку лет на 10, а то и 20. И ради чего?

В итоге один человек пишет программу на Python в несколько сот или тысяч строк, тренирует нейросетку, размещает всё это на гитхабе (ага с js), гуглдрайве, каггле, хагинфейсе и тп.. делится с другими своим результатом и идёт дальше. А Столяров исходит на коричневую субстанцию и по поводу гитхаба и по поводу Python и по поводу внешних зависимостей и сидит под корягой, отказываясь от изучения нового.

Но тогда следующий шаг: попросить ChatGPT написать CRM и убедить себя, что полученный результат именно то, чего хотелось. Времени будет потрачено всего полчаса вместо месяца на Питоне или нескольких лет на Си. Экономия.

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

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

Или твоё утверждение было изначально ложным?

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

И тем не менее: почти 30 страниц флуда при нулевом участии виновника вызывают у меня определённый диссонанс. Может пора закопать стюардессу?

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

Или твоё утверждение было изначально ложным?

Я думаю, что тебе стоит научиться читать не через слово. Мое утверждение было таким:

в библиотеках, которые развиваются, багфиксы принимают без проблем и быстро

Твое утверждение:

что у них [в GTK] принимают патчи без проблем и быстро.

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

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

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

Речь про ответственность, а не про хостинг.

Причём OpenCV ещё не самая сложная в этом смысле библиотека, в случае нейросетей только библиотека PyTorch в совокупности занимает несколько гигабайт

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

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

В итоге один человек пишет программу на Python в несколько сот или тысяч строк, тренирует нейросетку

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

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

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

Во-первых, ты заменил конкретное «багфиксы» на более широкий термин «патчи», покрывающий как багфиксы, так и фичи.

Потому что изначально было про патчи. Предыдущие два сообщения:

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

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

ты взял частное «у них», имея в виду GTK.

Так это классический силлогизм. Если для всех развивающихся библиотек утверждение верно и Gtk является развивающейся библиотекой (в том же сообщении это утверждается про Gtk и Qt), то для Gtk утверждение верно.

Если ChatGPT разовьётся до такого уровня, что сможет удовлетворительно работающее CRM выдать за полчаса

У непрограммиста получилось за 2-3 недели: https://habr.com/ru/articles/957792/

то да, именно так 99% и будут делать и тратить своё время на что-то другое им интересное или нужное. И будут правы.

И 99% программ станут такого качества, как по приведённой ссылке.

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

Плохая новость: У нас кончилась еда. Будем есть говно.
Хорошая новость: говна много.

Беда в том, что разработку программы можно оплатить только вскладчину. Хоть деньгами, как разработку MS Windows, хоть временем, как разработку Linux. Если 99% выберут вместо этого «решение от ИИ», то ресурсов оставшегося 1% просто не хватит на разработку качественного ПО (человек может заплатить за Windows 95 полторы сотни долларов, но не может пятнадцать тысяч).

Будут либо аскеты типа Столярова, пишущие себе нужные инструменты, либо потребители гигабайтов заплаток от ИИ.

И вы согласитесь гарантировать работоспособность своей программы с произвольной версией PyTorch?

Нет, конечно. В мире ПО вообще очень редко кто гарантирует работоспособность, это даже почти во всех лицензиях хоть GPL, хоть проприетарных прописывается. Однако я видел и ПО с гарантиями. Но гарантия работоспособности - это опция, сразу добавляющая пару нулей к ценнику, а то может и три нуля. Результат требуется ещё и на сертифицированном оборудовании сертифицированно обученными людьми использовать.

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

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

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

Есть конечно правила хорошего тона, но в целом, если речь про бесплатный OpenSource, то разработчик вообще ничего никому не обязан, кроме, чтобы умышленной вредоносности не было. Есть желание Столярова или кого ещё, чтобы программа была не на Python, а на Си, пусть присылает запрос с пожеланием (feature request), может его когда-то и удовлетворят, а если прям сильно хочется, то это уже за отдельные деньги на заказ.

Потому что изначально было про патчи

Нет, это было про багфикс, потому что речь шла про исправление.

Так это классический силлогизм.

Нет.

то для Gtk утверждение верно

И снова нет.

Попробуй еще раз.

И 99% программ станут такого качества, как по приведённой ссылке.

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

Беда в том, что разработку программы можно оплатить только вскладчину. Хоть деньгами, как разработку MS Windows, хоть временем, как разработку Linux. Если 99% выберут вместо этого «решение от ИИ», то ресурсов оставшегося 1% просто не хватит на разработку качественного ПО (человек может заплатить за Windows 95 полторы сотни долларов, но не может пятнадцать тысяч).

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

Прогресс идёт дальше.

Будут либо аскеты типа Столярова, пишущие себе нужные инструменты, либо потребители гигабайтов заплаток от ИИ.

Посмотрим, возможно утрясётся и не всё так страшно окажется. Кому-то конечно непривычно будет, что даже не гигабайты, а десятки гигабайт тратятся на то, что раньше возможно меньше 1 Мб занимало. Но я ещё помню как ужасались в 90-х размеру win-программ, те кто привык к размерам в несколько в пару-тройку Кб на 8-ми битках.

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

Именно потому, что в таком варианте невозможно использовать 99% общедоступного софта.

Замечу, что в РФ при продаже физическим лицам есть Закон о защите прав потребителей. Там ответственность продавца за порчу имущества есть. В том числе программным обеспечением. https://zpp.rospotrebnadzor.ru/news/federal/561922

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

Если программа не заработала, это полбеды. А если диск отформатировала вместо чтения файла?

кроме, чтобы умышленной вредоносности не было

Ну да. https://habr.com/ru/articles/122020/ https://club.dns-shop.ru/digest/166286-ii-chatgpt-5-3-codex-po-oshibke-udalil-vse-dannyie-s-diska-polzov/

Есть желание Столярова или кого ещё, чтобы программа была не на Python, а на Си, пусть присылает запрос с пожеланием (feature request), может его когда-то и удовлетворят, а если прям сильно хочется, то это уже за отдельные деньги на заказ.

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

Имха у субъекта Столярик есть несколько сторон по критерию адекватности.

Его книги в целом полезны.

При этом у него(хз почему) в части аспектов есть дефект_утёнка во все поля - наряду с годным фундаментом(частью его) он абсолютизирует частности своего пути в профессию(программирование) и как следствие лулзами полны его скрижали

Нет и нет.

Т.е. сравнивать вам не с чем.

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

Т.е. вы считаете правильным начинать курс обучения с неправды? Что им мешало вынести работу с данными утилитами в отдельный блок «Простые утилиты командной строки»? Это и читателям было бы удобнее.

Т.е. сравнивать вам не с чем.

А это важно, если курс оказался хорошим? Ты говорил, что это всё бесполезно, я опроверг.

Т.е. вы считаете правильным начинать курс обучения с неправды?

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

Нету по ссылке. Я хотел сравнить со своей методикой (распаковать qpdf и пропатчить cmap, запаковать обратно или затереть строки /ToUnicode пробелами)

никого уже не удивишь фреймворками в несколько миллионов строк,

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

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

Какие например? Ну генераторы картинок и всякие LLM понятно, но ещё что-то есть?

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

А ты уверен, что нормальный? А сможет ли тот, кто начал с питона потом освоить нормальные языки?

А сможет ли тот, кто начал с питона потом освоить нормальные языки?

Знаю людей, которые смогли. Так что как минимум гипотетически и по крайней мере кто-то — да. При этом я предполагаю, что тем, кто начинал с Паскаля, легче. Но это если они Паскаль осилили. А это сложнее, и не из-за сложности языка, а из-за того, что на Питоне нынче можно сразу перейти к решению насущных мелких задач и улучшению своего экспириенса за компом, а на Паскале… тоже в принципе возможно, конечно, но на практике дольше будешь вариться в чисто учебных задачах.

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

DISCLAIMER: это всё по анекдотическим наблюдениям, никакой статистики на хорошей выборке у меня нет.

Кому в GTK написать, чтобы в GtkTextView сделали поддержку Alt-кодов?

Так это в Windows же. В линуксе Ctrl-Shift-U или Compose key.

Так это в Windows же. В линуксе Ctrl-Shift-U или Compose key.

Разработчики Gtk заявляют, что она переносима. А по факту в Блокноте альт-коды работают, в браузере работают, а в GEdit не работают.

Замечу, что в РФ при продаже физическим лицам есть Закон о защите прав потребителей. Там ответственность продавца за порчу имущества есть. В том числе программным обеспечением. https://zpp.rospotrebnadzor.ru/news/federal/561922

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

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

Кроме того, «недостатки» в терминах ЗОЗПП - это не что попало, а несоответствие обязательным требованиям к продукции (такие есть на софт?) или целям её использования, то есть, невозможность использования по назначению. На практике это означает, что ответственность есть только, если программа не работает в строго заявленных условиях. Порча имущества, если она неумышленная в случае софта тоже крайне сложно подводится под компенсацию.

Ну да. https://habr.com/ru/articles/122020/

Неприятно, но бывает. В случае бесплатного OpenSource даже ЗоЗПП неприменим.

https://club.dns-shop.ru/digest/166286-ii-chatgpt-5-3-codex-po-oshibke-udalil...

ССЗБ, если у ИИ-агента есть права админа и вообще права за пределами песочницы.

Столяров хочет, чтобы было больше хороших программ. Для этого учит студентов, пишет манифесты и объяснения в гостевой.

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

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

Последовавшие за этим «многоядерные» архитектуры представляют собой не более чем количественное развитие, притом в направлении, практически не увеличивающем реальное быстродействие системы. Дело в том, что даже серверные машины, работающие с серьёзной нагрузкой, в основном «упираются» в своей производительности не в скорость работы процессора и тем более не в конкуренцию программ за единственный процессор, а скорее в скорость дисковых обменов и работы шины; ни на то, ни на другое «многоядерность» повлиять не в состоянии. Как правило, все ядра, кроме одного, в системе бо́льшую часть времени простаивают.

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

Но все уже привыкли к программированию на авось и вообще не понимают, чего он хочет.

Столяров, если он действительно «We professional programmers» из его манифеста (отдельно замечу, что даже мне, который далеко не на уровне native знает английский, эти и многие другие места кажутся рунглишем) мог бы научить новые поколения программистов правильному использованию и Python и Javascript и других актуальных языков и фреймворков, вместо чего он просто скопом всё отрицает и требует писать программы на уровне техник 90-х годов.

Ну вот реально, если смотреть на вещи, то что полезного в его табу?! Где в нём про правильную архитектуру вообще?

interpreted execution is for scripting and built-in DSLs only

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

languages that have their 'ecosystems', such as Perl, Python, Ruby and the like, are not allowed

Бред. Хотя бы задумался, а с чего вдруг эти языки и «экосистема» возникли, притом вовсе не от корпораций, а развиваясь в OpenSource сообществе.

'semi-interpreted' languages, such as Java or C#, are not allowed

Тоже бред. Хоят и меньший, но отсекает чуть ли не весь совремённый документооборот

each of your programs must link statically

Угу, на Python Столяров писать запретил, допустим захотел нейросетку написать на C++, использовав C++-вариант PyTorch'а - libtorch, но и тут засада. Вот есть несколько гиг - линкуйся с ними статически. У клиентов могут быть разные GPU c разными вариантами libtorch (для CUDA, для ROCm и др) - вот со всеми и линкуйся. Статически %-)

source tree must be self-containing, all used libraries must reside within it

Это к вопросу о хостинге. Вот все гигабайты и хости.

data not intended to be modifiable by the user, must be bundled into the executable binary

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

Data files 'shipped together' with your program are generally not desirable and must be limited to the data the user is supposed to provide or modify. Data not intended to be supplied or modified by the user, such as icons or other images, must be built into the executable.

Некоторый смысл есть, чтобы иконки и тп. не потерялись где-нибудь по дороге, но в общем-то всё тот же вопрос: какого хрена?

be extremely discriminating with the standard library features

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

no automated software updates

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

no client-side scripting, including JavaScript on websites

С одной стороны я тоже против js на сайтах, но нельзя не признать, что в ряде случаев без него очень сильно неудобнее: на каждый чих (платформу, ОС) не напасёшься делать приложения, да и установка у пользователя отдельного софта для работы с каждым сервисом, где недостаточно возможностей чистого html+css хуже даже с точки зрения безопасности, чем js в браузере.

No multithreading (and shared memory)

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

No data formats with recursive nesting, such as SGML, XML, [X]HTML, JSON etc.

Опять возникает ощущение, что у Столярова какой-то ограниченный опыт. Что он предлагает:

So here's the rule: machine-readable data formats with recursive nesting are forbidden. By the way, according to the theory of databases, the 1NF is sufficient for any purpose, and 1NF only demands all values in a table being atomic.

Из того, что «1NF is sufficient for any purpose» не следует, что они (кстати, что - CSV что ли?) обязаны применяться вместо XML. Опять же, если формат данных нужен только для чтения машиной, то там хоть что угодно может быть, но форматы, вроде XML или Json придумали, чтобы и человеку в принципе можно было читать и редактировать и машине, к тому же, чтобы можно было верифицировать по определённым правилам поступающие данные.

Остальное устал всё подряд комментировать, по поводу требований к ascii идентификаторам и строкам в принципе можно и согласиться даже, но уже требовать ограниченной поддержки Unicode - маразм. То есть, например, по Столярову недопустимо уметь работать с текстами в utf-16? O_o

Далее почти каждый пункт вызывает возражения.

В итоге всё-таки, а при чём тут написание программ на авось или не авось? Это перечень «идеосинкразий» автора, к архитектуре почти не имеющий отношения, кроме разве что насчёт мультипоточности.

Селя ви, как говорят французы.

Но отказываться от поддержки иксов - это как-то совсем дно. Лучше бы от поддержки Windows отказались, если им так хочется сэкономить время/усилия.

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

И сколько бы времени понадобилось чтобы реализовать CMS со свойствами Талассы на чём-то другом? Как бы не больше.

Зато в GEdit работает Ctrl-Shift-U даже под Windows, что гораздо лучше альт-кодов.

Правда Compose ещё лучше, интересно, он работает в Windows или нет?

сможет ли тот, кто начал с питона потом освоить нормальные языки?

Если он начинал с питоновского симулятора risc-v или вообще какой-нибудь выдуманной ЭВМ? А потом набросал на питоне средства разработки программ, которые можно тестировать в этом симуляторе.

Давай предположим стандартный сценарий. Например курсы яндекса по которым сейчас домашние задания задают. Вроде на входе количество записей, затем чередуются строчки с ФИО участника гонок и его результатом, а нужно вывести кто победил.

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

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

Какие например? Ну генераторы картинок и всякие LLM понятно, но ещё что-то есть?

Ну навскидку, просто что в голову пришло сразу:

Секвенирование и анализ ДНК. Можно в одиночку писать обработку гигабайт генетического кода.

Поиск рыночных аномалий. Высокочастотный трейдинг (HFT).

Распознавание медицинских снимков и вообще снимков. Сейчас можно в одиночку написать обработку МРТ с целью поиска определенных заболеваний. Или дефектов в дефектоскопии на производстве.

Игры с фотореализмом в 3D. Движки Unreal Engine, Unity позволяют в одно рыло сделать довольно крутые вещи. Конечно полноценная игра AAA уровня потребует привлечь и актеров и много чего ещё, но есть и инди-проекты.

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

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

Если кто-то купил программу, а она удалила какие-то данные, то вполне. При условии, что покупатель физлицо, разумеется.

В случае бесплатного OpenSource

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

Некоторые положения в его учебнике, как минимум странные (про побочные эффекты), а как максимум и вовсе ошибочные, яркий пример - его отношение к многоядерности и параллельным программам.

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

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

Не бред. По всем серверам, которые мне встречались, так и было. Очень малая суммарная нагрузка на процессор и периодические пики загрузки одного ядра. Единственное исключение: мейнфреймы.

Бред. Хотя бы задумался, а с чего вдруг эти языки и «экосистема» возникли, притом вовсе не от корпораций, а развиваясь в OpenSource сообществе.

Вы же сами выше писали. Потому что в этом сообществе принято, что никто ни за что не отвечает, потому что бесплатно. А «for fun» с экосистемой веселее.

Хоят и меньший, но отсекает чуть ли не весь совремённый документооборот

Его невозможно писать на Си и Коболе? То, что принято писать на Java, не значит, что так лучше.

Вот есть несколько гиг - линкуйся с ними статически. У клиентов могут быть разные GPU c разными вариантами libtorch (для CUDA, для ROCm и др) - вот со всеми и линкуйся. Статически %-)

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

Если кто-то купил программу, а она удалила какие-то данные, то вполне. При условии, что покупатель физлицо, разумеется.

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

Потому что, если в лицензии сказано, что программа поставляется «AS IS», то «AS IS» и есть, можно считать это оговоркой, что у программы есть недостатки и покупатель о них проинформирован.

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

Он сам же утверждает, что параллельная работа часто упирается в I/O, а не процессор, в этом случае проще распределять работу по нескольким асинхронным потокам в рамках одного процесса. В простейшем случае, например, при ожидании ввода пользователя и работе в фоне.

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

Нда, и что же люди дураки такие покупают процессоры с более, чем сотней ядер?

Сейчас например серверы работают с десятками и сотнями докер-контейнеров, в которых крутятся виртуальные машины с сервисами, что-то обрабатывающими. А на десктопе параметр -j часто почти линейно ускоряет компиляцию. Даже архиваторы научились много ядер использовать в работе. Видеостримминг, 3D-рендеринг и тд. всё это не экзотика. Игрушки сейчас умеют использовать несколько ядер, до 6-8 обычно. Хотя больше редко.

А даже если упор в I/O при чтении файла, то всё-равно несколько ядер позволяют быстрее обслуживать это чтение. Одно ядро ждёт чтения, другое (или вообще несколько) - обрабатывают и это часто имеет существенное значение на практике. К тому же с появлением SSD, особенно быстрых SSD не такой уж и малой бывает скорость чтения. Например, пиковая пропускная способность базового модуля DDR5 - 38.4Гб/сек, в двухканальном режиме - 76.8 Гб/сек. Пиковая скорость чтения с SSD Samsung 9100 Pro - 14.8 Гб/сек. Всего в 2-5 раз медленнее RAM.

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

Вы же сами выше писали. Потому что в этом сообществе принято, что никто ни за что не отвечает, потому что бесплатно. А «for fun» с экосистемой веселее.

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

Его невозможно писать на Си и Коболе? То, что принято писать на Java, не значит, что так лучше.

Лучше не лучше, но в здравом уме никто на Си писать корпоративный документооборот не станет. Напишут на java, на C#, даже на Python, но точно не на Си. Даже на C++ не станут. Потому что есть сложившаяся экосистема из библиотек, потому что есть сборщик мусора, необходимость которого в имеративных языках Столяров отрицает, потому что в итоге пишется быстрее и требует меньшей программистской квалификации от разработчиков.

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

Это вообще без комментариев, надо просто видеть работу.