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

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

На виртовском Паскале никто серьёзные программы и в самом деле не писал. Для коммерческих диалектов, главными и основными, которыми была продукция Borland эти ограничения давно не актуальны. Но и Си из Паскаля не сделали. Borland/Delphi - это не этакий Си, а практически Модула-2 с прикрученным ООП.

Значит ошибки просто не возникнет.

На тех версиях glibc, разумеется. Но у пользователя другая версия glibc. И большинство дистрибутивов (например, рассматриваемый Debian) не позволяют простыми способами поставить нужную.

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

В турбо паскале это всё было. Программы для ВМЭТФ (вычислительные методы в экспериментальной и теоретической физике) на Турбо Паскале работали быстрее, чем на Турбо Си.

Делфи это уже не совсем Паскаль, это сильно расширенный диалект.

Нынешний Си тоже сильно расширенный диалект относительно изначального, не говоря уж про Си++.

Турбо Паскаль создавался на Си и имел кучу встроенных модулей, внутри которых был вовсе не Паскаль, а ассемблер.

А какая разница? Си тоже имеет кучу модулей (библиотек), внутри которых ассемблер.

Делфи это уже не совсем Паскаль, это сильно расширенный диалект.

Обучать всё-таки лучше на Delphi, чем на Си или Си++. И на сишном аналоге Delphi (Borland C++ Builder) вообще не помню, чтобы кто-то что-то полезное писал.

На виртовском Паскале никто серьёзные программы и в самом деле не писал

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

А он вообще существовал в виде компилятора, а не описания?

Ранние реализации самого Вирта, вроде CDC Pascal, системы вроде Pascal 2 от Oregon Software. Вживую их не видел, но судя по описаниям довольно близки были к эталону, хотя и имели расширения для работы с графикой и системой. На советских компьютерах ДВК и БК были его клонированные варианты и если погуглить, то получается, что на них был почти классический Паскаль. Такой вот парадокс.

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

В википедии (английской) как раз написано, что

The first Pascal compiler was designed in Zürich for the CDC 6000 series mainframe computer family. Niklaus Wirth reports that a first attempt to implement it in FORTRAN 66 in 1969 was unsuccessful due to FORTRAN 66's inadequacy to express complex data structures. The second attempt was implemented in a C-like language (Scallop by Max Engeli) and then translated by hand (by R. Schild) to Pascal itself for boot-strapping.[13] It was operational by mid-1970.

UCSD - это уже заметно позже.

Так или иначе, на практике, естественно никто с ограничениями классического Паскаля по Вирту не мирился и реализации содержали те или иные расширения и добавления. Модули, кстати, завезли ещё в UCSD в 70-х - узнал, когда писал это сообщение, раньше почему-то думал, что их в него борланды и Apple добавили в районе 1985-го. Но тогда получается, что они появились в отдельных вариантах Паскаля ещё даже до создания языка Модула-2, а не бекпортированы оттуда. Забавно, век живи - век учись.

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

Вот-вот, я кое-что новое о формате PDF узнал, например. Причём в старых книгах кодировка чинится однострочником на sed, в изданиях 2.9 и 2.91 приходится править cmap с перепаковкой с помощью qpdf или аналога.

Кто-то же торгует распечатками на Озоне и авито, ещё и ценник емнип 15-20 тыс.руб.

Да нет, поменьше раз в десять. Но забавно что те, кто печатают, вообще не смотрят, что они печатают, например в распечатки первого издания, которое вышло 10 лет назад.

А когда на ЛОР опубликовали рецепт исправления - очень смешно порвался.

Ссылку можно?

?

https://www.google.com/search?q=Столярик порвался site:linux.org.ru

На тех версиях glibc, разумеется. Но у пользователя другая версия glibc.

Что ты несёшь? Откуда у него другая версия если ты сам написал что уже протестировал с той что есть? Ты не знаешь как работают deb пакеты? Зависимости? Тестирование? Какой аспект современного IT прошёл мимо тебя пока ты входил в 1С по Столярику?

Что ты несёшь? Откуда у него другая версия если ты сам написал что уже протестировал с той что есть?

У пользователя другая.

Разработчик написал программу. У него glibc-2.2. Он проверил, что на всех glibc до 2.2 включительно программа работает. Других у него нет. Выложил программу и ушёл заниматься другими делами.

Через несколько лет ему пишет пользователь, который не может запустить его программу, потому что в его Debian 12 нельзя поставить glibc-2.2, а на той, что есть, программа не работает. И поэтому пользователь считает, что разработчик ему обязан переделать программу для новой версии Debian.

Ты не знаешь как работают deb пакеты? Зависимости? Тестирование?

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

Можешь взять http://archive.debian.org/debian/pool/main/i/iceweasel/firefox_2.0.0.3-1_all.deb и попробовать запустить на любом современном дистрибутиве. А на Windows 11 firefox 2 без проблем запускается.

Можешь взять http://archive.debian.org/debian/pool/main/i/iceweasel/firefox_2.0.0.3-1_all.deb и попробовать запустить на любом современном дистрибутиве

Чейнджлог запустить что ли?

Чейнджлог запустить что ли?

Почему Чейнджлог? Firefox 2. В этом пакете зависимости прописаны.

У пользователя другая.

Откуда у него другая если ты тестировал с той что у него?

А на Windows 11 firefox 2 без проблем запускается

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

Откуда у него другая если ты тестировал с той что у него?

Читай внимательно. Разработчик тестирует с той, которая у него есть. И даже если у пользователя на момент разработки был Debian Sarge с glibc-2.2, теперь ему из-за динамической линковки обновлять дистрибутив нельзя?

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

У виндузятников как раз нет проблем. Проблемы есть у линуксоидов, которые используют дистрибутивы с динамической линковкой: https://forums.fedoraforum.org/showthread.php?21129-Need-help-with-error-while-installing-qmail.

Пожалуйста: https://i.postimg.cc/x1w1QQpR/Screenshot-from-2026-05-11-17-03-59.png

Description:	Ubuntu 22.04.5 LTS

Как именно:

wget http://archive.debian.org/debian/pool/main/i/iceweasel/iceweasel_2.0.0.19-0etch1_amd64.deb \
  http://archive.debian.org/debian/pool/main/libx/libxp/libxp6_1.0.2-2_amd64.deb \
  http://archive.debian.org/debian/pool/main/libp/libpng/libpng12-0_1.2.27-2+lenny5_amd64.deb \
  http://archive.debian.org/debian/pool/main/libj/libjpeg6b/libjpeg62_6b-14_amd64.deb

mkdir OLD

dpkg-deb -x iceweasel_2.0.0.19-0etch1_amd64.deb OLD/
dpkg-deb -x libpng12-0_1.2.27-2+lenny5_amd64.deb OLD/
dpkg-deb -x libxp6_1.0.2-2_amd64.deb OLD/
dpkg-deb -x libjpeg62_6b-14_amd64.deb OLD/

LD_LIBRARY_PATH=./OLD/usr/lib/:./OLD/usr/lib/x86_64-linux-gnu/:./OLD/usr/lib/iceweasel/:$LD_LIBRARY_PATH OLD/usr/lib/iceweasel/firefox-bin

LD_LIBRARY_PATH=./OLD/usr/lib/:./OLD/usr/lib/x86_64-linux-gnu/:./OLD/usr/lib/iceweasel/:$LD_LIBRARY_PATH

Круто. Я был уверен, что libc и gtk придётся подкладывать.

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

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

стандартные паскалевские строки ограничены по размеру 255 или 4гб.

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

и что там такого страшного написано:

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

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

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

Через несколько лет ему пишет пользователь, который не может запустить его программу

Быстро же ваши пользователи реагируют на проблемы...:)))

потому что в его Debian 12 нельзя поставить glibc-2.2, а на той, что есть, программа не работает. И поэтому пользователь считает, что разработчик ему обязан переделать программу для новой версии Debian

Тут «и ежу понятно», что проблема не с «либой», а «с головой у пользователя»: он явно «рыбного супа переел»... :))

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

Что вполне нормально и естественно. Это вообще не проблема, это жизнь... :)

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

Чем??..

стандартные паскалевские строки ограничены по размеру 255 или 4гб.

Ну так и «вперде!» - пишите на Паскале, вас же на С никто не гонит! :)

Так что"с нулём в конце" - это не «худший», а просто «непривычный» и, как следствие, возможно, «неудобный»...

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

Не вижу проблем, вижу только этакий «конфликт привычного с непривычным». :)

Тут «и ежу понятно», что проблема не с «либой», а «с головой у пользователя»: он явно «рыбного супа переел»… :))

Однако, встречаются. https://github.com/stenzek/duckstation/commit/30df16cc767297c544e1311a3de4d10da30fe00c

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

Что вполне нормально и естественно. Это вообще не проблема, это жизнь… :)

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

Полезно для понимания почему нуль-терминейтед — Керниган и остальная лаба это подразделение единственного связиста USA

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

Полезно для понимания почему нуль-терминейтед
Керниган и остальная лаба это подразделение единственного связиста USA

И что??..

Это «не играет». Мне вообще не интересно, «почему», мне достаточно знания о том, «как именно здесь»...

Я тот самый «Эдгар», которому «почему» - «По». :)) Работал и работаю «здесь и сейчас», «в заданных условиях», не заморачиваясь выработкой ни отношения к ним, ни мнения о них - «без нЭрва», в общем. :) Играю по правилам, короче говоря. :))

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

Это для меня всё «лирика», значения не имеющая. Приступая к той или иной задаче, я ознакомляюсь с заданными «здесь и сейчас» «правилами и условиями», и работаю, соблюдая их. :)

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

Однако, встречаются.

Да и «по!».. :))

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

Соглашусь на всё 100% :)

Я бы, вероятно, тоже так и делал, если бы работал «для широких народных масс» - просто чтобы потом меньше проблем «разгребать»... :)

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

Да и пофиг. :)

стандартные паскалевские строки ограничены по размеру 255

Это не стандартные, но типичные.

но типичные

Это тоже не бесспорно...

Куча таких реализаций было в 1970-1980-х. И в рамках стандартного Паскаля, и как extension.

в общем случае нультерминейтед строки и не строки вовсе :)

для реального строкования есть подходящие под задачи rope и прочие прелести

stos/lods Ж_

Я знаю две реализации Паскаля, с версиями которых работал Н.Вирт.

Первая – «боевой» компилятор для серии суперкомпьютеров CDC.

https://www.standardpascal.org/Compiler_text_1984/PascalCompiler.txt

Вторая – «вирусный» переносимый компилятор, от разных версий которого пошли многие классические университетские и коммерческие реализации Паскаля 1970-1980-х. Текст использовался как иллюстрация к книгам Н.Вирта и других авторов о реализации Паскаля.

Собственно компилятор в промежуточный код («Pascal-code»). https://raw.githubusercontent.com/samiam95124/Pascal-P4/refs/heads/master/source/pcomOrg.pas

И интерпретатор этого pascal-кода. https://raw.githubusercontent.com/samiam95124/Pascal-P4/refs/heads/master/source/pintOrg.pas

Насколько я понимаю, от работы над собственно Паскалями Н.Вирт отошёл ещё до выхода первого стандарта.

в общем случае нультерминейтед строки и не строки вовсе :)

Ну, тогда уже «в общем случае» ничто не строки... вовсе, ага... :))

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

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

Программа (на C89 как он хочет) занимает 1000 строчек и тянет пяток библиотек по 5-10 тыс. строк - отлично, у всех всё компилируется и работает. Столяров - молодец!

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

Столяров довольно ярко продемонстрировал непонимание в чём тут проблема и какие задачи какими способами решают совремённые программисты, а не 30-40 лет назад: http://www.stolyarov.info/guestbook/archive/12#cmt533

Он там пишет:

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

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

Вот даже не знаю, что сказать про такую незамутнённость сознания :))

И??.. И каких это «таких»??.. И вовсе они не такие были!.. ;P ;))

Разработчик тестирует с той, которая у него есть.

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

и что там такого страшного написано

Вышло издание 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 и прочие тоже не в курсе?

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