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

Если твой компилятор это не схавает, то компилятор - говно, и его надо выкинуть на помойку.

Ладно, я просто намекал, что юникод бывает не только UTF-8, но и UTF-16 и UTF-32, причём в разновидностях с BOM и без BOM и в Little Endian и Big Endian, и это ещё не считая UTF-7 и прочих.

Кстати в книге упоминается Turbo Pascal (в книге 2011 года издания), так что ещё была бы проблемка перекодировки между cp1251 (файлы архивов примеров) и cp866 (в TP под DOS/ntvdm).

Никакая вложенность в данной задаче не требуется

По книжке, это должно быть вот так:

program fuck;
var
	a,b,c:	integer;
begin
	write('Введите три числа: ');
	readln(a,b,c);
	if a > b then
		if a > c then
			writeln(a)
		else
			writeln(c)
	else
		if b > c then
			writeln(b)
		else
			writeln(c);
end.

Вчера это заняло у меня три часа, что бы именно ПОНЯТЬ, почему оно работает. При этом, мне пришлось использовать клода, что бы он буквально на пальцах, на метафорах объяснил, как это всё работает и почему оно работает. То есть без репетитора или клода - было бы невозможно понять. Если бы к этому заданию была бы подводка, было бы легче. Сейчас по памяти написал это за пару минут.

Нет никаких проблем распознать кодировку. А BOM не нужен сам по себе.

Кстати в книге упоминается Turbo Pascal

Проблемы мёртвых языков.

(пример кода)

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

По книжке, это должно быть вот так:

С чего бы? Кто сказал? Это же задание, его можно делать как угодно, если работает. Или в книге есть ответы?

Вчера это заняло у меня три часа, что бы именно ПОНЯТЬ, почему оно работает.

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

С чего бы? Кто сказал? Это же задание, его можно делать как угодно, если работает. Или в книге есть ответы?

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

Так у меня есть ветвления и в этой (1) и в этой (2) версии. Булевы функции там проходят, я посмотрел. Так что and тоже можно.

Просто они без ветки else, но в данном случае она и не требуется. Кстати тебе как по понятности, вариант 1 или 2 понятнее из этих двух?

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

В любом случае, книга Столярова лучше. К тому же издание свежее, а не 2011 год.

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

Ну метафоры тут не нужны на самом деле:

program fuck;
var
	a,b,c:	integer;
begin
	write('Введите три числа: ');
	readln(a,b,c);
	if a > b then
		// Здесь a > b
		if a > c then
			// Здесь a > c
			// И a > b
			// Следовательно, a наибольшее из чисел
			writeln(a)
		else
			// Здесь неверно, что a > c
			// Поэтому a <= c
			// Но всё ещё a > b
			// Так как a больше b, а c равно или больше а, то
			// c это наибольшее из чисел
			writeln(c)
	else
		// Здесь a <= b
		if b > c then
			// Здесь a <= b и b > c
			// Следовательно, b наибольшее из чисел
			writeln(b)
		else
			// Здесь a <= b и b <= c
			// Следовательно, c наибольшее из чисел
			writeln(c);
end.

Это паскаль же, а не C++, откуда ты взял //? Кстати нейронка ту же ошибку делает.

https://wiki.freepascal.org/Comments

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

Тебе дали гаечные ключи и показали как ими пользоваться. И ты вроде бы понял, это рожковый, это накидной, это размеры ключей. Потом тебе сказали: «Иди сними кпп на вон той машине». Ты залез под машину и офигел. А как её снимать то?

Выше человек правильно заметил - знать синтаксис это одно. А уметь в декомпозицию задания - это другое. Если я просидел за заданием три часа, если пришлось использовать ии, значит что? Значит в книге экономили страницы и решили сразу дать вот такое задание, без подводки к нему. Вот и вся претензия. Возможно, у кого лучше работает голова в плане логики, решили бы его быстрее и с меньшим напряжением.

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

1.я(моя) согласен(сна)

2. Ту реально сложный вопрос экономии усилий и вообще какая телеология.

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

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

Вчера это заняло у меня три часа, что бы именно ПОНЯТЬ, почему оно работает

«Как страшно жить!..» ©

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

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

Может вам и правда лучше начать с блок-схем алгоритмов.

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

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

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

liksys - вот тебе пример реальных проблем, которые новички в программировании могут испытывать. А ты тут по быстрому сначала Python, да ещё с ООП, потом Си для понимания конструкций и ускорения вычислений. Да до этого ещё, так сказать, дожить надо. Причём, глубоковложенные if'ы лучше изучать всё же на языке, в котором блоки явно выделяются begin ... end или {}, а то на Python можно и совсем запутаться в их логике, несмотря на красоту отступов.

«книжка не правильная»

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

либо

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

настоящие программирование это навык где достаточно чистого а где нужно грязнить связями через память(пишем а затем читаем)

psps ; этому соответсвуют две ментальные модели

есть конвеер по котором летит состояние - если мы через дерево то это ветвление и состояние(экземпляр) в зависимости от некоторого условия уходит по левой или правой ленте конвеера и где-то в оконцове действие над классифицированым состоянием

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

зы. вопрос удержания в мыслях в каком мы контексте в той или иной строке - без шуток курни:

Дейкстра почему goto это плохо

Хочется напомнить, что Python - третий в череде сходных языков, используемых для обучения студентов более 40 лет. Теоретики такие теоретики.

Нашёл на хабре комент по поводу книги: https://habr.com/en/news/1031636/#comment_29967908

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

" С литералами восьмеричными и шестнадцатеричными ситуация примерно такая же, только компилятор не пытается делать их знаковыми. Иначе говоря, если хватает разрядности unsigned int’а, то он и используется, если же не хватает, компилятор пытается использовать unsigned long и unsigned long long "

Насколько мне известно, в стандарте языка Си другие правила, и такие литералы могут быть по умолчанию знаковыми. Путаница может приводить к undefined behavior при умножении. Вообще в книге мало упоминается undefined behavior.

Или такая неверная информация про типы данных на стр. 17, которая может привести к коварным ошибкам при попытке скомпилировать программу с помощью MSVC или MinGW (но, насколько я знаю, он Windows не любит), и ему на это указывали в гостевой. Вот цитаты из книги:

«Зато на 64-битных платформах «подрос» следующий тип, long; он стал 64-битным, в результате чего совпадает с типом long long. Но здесь мы уже забежали вперёд»

«Отметим ещё один момент: действует соглашение, по которому разрядности числа типа long должно на любой архитектуре хватать для представления указателей»

А на стр. 30 - неверная сигнатура " void *malloc(int size); " для malloc, т.к. он из-за нелюбви к комитетам по стандартизации языка не приемлет даже size_t.

Также там имеются попытки вторгаться в чужую предметную область в разделе «4.10.3. Генерация псевдослучайных чисел». А именно упоминается функция rand для не связанных с безопасностью приложений, в т.ч. метода Монте-Карло, и говорится о том, что «целом псевдослучайные числа имеют распределение, достаточно близкое к равномерному». Но все широко распространённые её реализации содержат грубейшие статистические дефекты и непригодны для каких-либо расчётов вообще. Насколько я знаю, Столярову на это также указывалось.

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

Хочется напомнить, что Python - третий в череде сходных языков, используемых для обучения студентов более 40 лет. Теоретики такие теоретики.

Языку Python менее 40 лет вообще, ты о чём вообще? Насчёт сходности, то с чем он сходен?

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

Этот пример проистекает из некачественности учебного материала и совершенно не опровергает ни один из моих тезисов.

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

Не факт, что именно по идейным.

может привести к коварным ошибкам при попытке скомпилировать программу с помощью MSVC или MinGW (но, насколько я знаю, он Windows не любит)

А не надо писать код, который полагается на конкретную разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

А не надо писать код, который полагается на конкретную разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

Так ведь Столяров в п.4.3.3 т.2. как раз и занимается этим полаганиям, потратив несколько страниц на объяснение, что в MS-DOS int 16 битный, что в i386 - 32-битный, потом про long long. Чтобы проиллюстрировать, что у базовых типов может быть разная разрядность это верно, но неверно, когда он начинает писать, что long совпадает с long long на 64-бит. Потому что не везде совпадает. Фактически то, что пишет Столяров в этом параграфе верно только для x86-х архитектур и только для gcc в Linux. Столяров ни слова не сказал про типы с фиксированной битностью, введённые в C99, те что в <stdint.h> (вроде int32_t и др.). Но это же «комитетские мрази» придумали, поэтому Столяров будет упорно гнать лажу. Которую он принципиально не исправит.

Вообще получается, что если 1-й том в целом можно спокойно рекомендовать для обучения, то уже 2-й с очень большой осмотрительностью. Местами эта книга уже просто вредна даже. И это я ещё по диагонали её читал, вон пункт про типы в Си мимо внимания прошёл, в отличие от комментатора на Хабре.

Так ведь Столяров в п.4.3.3 т.2. как раз и занимается этим полаганиям, потратив несколько страниц на объяснение, что в MS-DOS int 16 битный, что в i386 - 32-битный, потом про long long.

Ну так он разве врёт? int в DOS действительно 16 бит, разве нет? Мне не очень хочется перечитывать, но и так должно быть понятно, что размер не постоянный.

Столяров ни слова не сказал про типы с фиксированной битностью, введённые в C99, те что в <stdint.h> (вроде int32_t и др.).

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

Местами эта книга уже просто вредна даже.

Думаешь? Мне кажется, эти нюансы всё равно с опытом приходят и их так не запомнишь.

Ну так он разве врёт?

Он пишет:

Зато на 64-битных платформах «подрос» следующий тип, long; он стал 64-битным, в результате чего совпадает с типом long long.

Это верно в модели данных LP64, но неверно в LLP64 в Windows. Может быть и ещё где-то неверно.

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

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

Но дело не только в этом, если верить комментатору, то ему на ошибку с long long указывали, но Столярову на неё пофиг.

Не факт, что именно по идейным.

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

А не надо писать код, который полагается на конкретную разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

Какая прелесть. А аппаратно-зависимый код как предлагается писать?

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

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

У этого клоуна есть технические аргументы против этого стандарта?

Он считает, что C99 нарушил философию языка Си, которая по его мнению заключается в том, что язык (компилятор) позволяет генерировать абсолютно предсказуемый и прозрачный ассемблерный код. Что программист в Си может полностью контролировать выделение памяти и использование стека, а VLA скрывает логику, динамическая работа со стеком потенциально опасна. Кроме того, для VLA sizeof оказывается не вычислим при компиляции и генерирует обширный код. Ещё он докопался до inline, объявлении переменных внутри кода и ещё по мелочам, вроде того, что // считает размытием границ между C и C++.

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

полно хуже Столярова «методистов»

и мало кто лучше - вот например Арьков Валентин Юльевич из Угату?(ну Уфимец) - у него очень представительный набор методичек по информатике - и в целом имхо очень реально эффективные в части приобщения к.

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

разрядность элементарных типов, кроме char (он-то надеюсь всегда восьмибитный?)

Бит всегда однобитный?

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

Это верно в модели данных LP64, но неверно в LLP64 в Windows.

Из контекста книги очевидно, что речь идёт о GNU/Linux и FreeBSD. Он мог бы упомянуть, как забавный факт, что в Windows в отличии от нормальных ОС даже это сделано через задницу, но не стал, хотя несколько других забавных фактов о Windows упоминается, например как «я» может устроить EOF у криворуких и нужен флаг b для чтения файлов. Может сам не знал, может не посчитал нужным. В гостевой уточняли?

В книге и в гостевой поиск по ключевому слову LP64 (который захватит и LLP64) ничего не даёт. Я помню, что удивлялся трансанальности Windows в этом вопросе ещё когда 64-битная версия была новостью.

Вообще, использовать сейчас в реальных задачах базовый тип вместо фиксированной битности

А char можно? Ну и в принципе наверное short везде два байта и int везде кроме DOS четыре байта, исходя из того что под 8, 16, 32 бита нужны отдельные целые типы и кроме этих трёх других подходящих базовых нет. А если надо 64 можно везде писать long long на всякий случай, хотя было бы логичнее сделать long 64-битным, а long long 128-битным. Интересно 128-битные целые в C вообще есть?

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

Ой ли. Довольно многочисленная группа людей (включая меня) считает что MS приняла очень дальновидное решение оставив long одинаковыми между 32мя и 64мя битами. Целого класса проблем удалось избежать. А в «самой правильной системе» int64_t в 32ух битах алиасится в long long (ожидаемо), а вот в 64ёх - в long (нежданчик), и это реально проблема. И поправить это уже так просто нельзя потому как ABI.

MS приняла очень дальновидное решение оставив long одинаковыми между 32мя и 64мя битами. Целого класса проблем удалось избежать. А в «самой правильной системе» int64_t в 32ух битах алиасится в long long (ожидаемо), а вот в 64ёх - в long (нежданчик), и это реально проблема. И поправить это уже так просто нельзя потому как ABI.

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

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

Что мешает поискать по его сайтам (http://rebuildworld.net/ и http://stolyarov.info/) и книгами (благо наконец текстовый слой есть штатно и залазить с qpdf больше не нужно)? Я думаешь наизусть все его аргументы помню? Но главное возражение — VLA (stolyarov.info).

Но кстати в той же MS Visual C 6.0 не поддерживается C99, так что вот тебе аргумент не от Столярова, а от его противоположности.

А можно узнать, что за проблемы?

Невозможность «запретить» long который «плавает» (в плюсах для этого есть механизмы) и продолжать использовать int64_t.

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

Ещё раз (следите за руками): очевидные проблемы с RPC long’ов между 32ух и 64ёх битными аппликухами на одном железе, с очевидным решением - забанить long в соответствующем API, и c абсолютно неожиданными фоллаутами при попытке передать int64_t. Так понятнее?

кстати в той же MS Visual C 6.0 не поддерживается C99,

1. В каком году вышел этот компилятор?

2. C99 уже не стандарт.

C99 уже не стандарт.

С here are ли?? Его что, «вымарали» из ISO??.. Нет.

Не самый «свежий» стандарт, возможно (я не знаю, да и не суть), но - стандарт, и стандартом останется....

В каком году вышел этот компилятор?

Под Windows до сих пор MSVC всё компилируют. MinGW правда ещё есть, но с ним свои сложности. Там вместе с компилятором пришлось половину GNU притащить.

Под Windows до сих пор MSVC всё компилируют.

Из студии 6.0 ?

Я откуда знаю? Когда я сидел на Windows, все пользовались 6.0 хотя она уже устарела. А MS VS 2005 занимала целый DVD, что как мне кажется, для компиляции Hello World было избыточно. В итоге я как раз тогда перешел на линукс и там изкоробки gcc куда удобнее был и компилировал не так криво.

Тогда же я поставил Delphi и C++ builder современной на тот момент версии (200x не помню) и оно хотя бы запустилось, но тоже было крайне жирно. Если его закрыл, а потом снова открыл надо ждать секунд 10. А в линуксе открываешь nano / vim / emacs за долю секунды и пишешь код — гораздо удобнее.

Жаль, что преподаватели тогда не знали про FreePascal и о нём я узнал когда курс программирования на паскале уже закончился.

Его что, «вымарали» из ISO??..

Отозвали, заменили и зачеркнули

https://www.iso.org/standard/29237.html

Отозвали, заменили и зачеркнули

От же ж... гммм... супостаты!...

https://www.iso.org/standard/29237.html

Спасибо, но мне оно не надо. :)) На слово поверю... :)

преподаватели тогда не знали про FreePascal

FreePascal уже умеет работать без линукса?

FreePascal уже умеет работать без линукса?

Он с самого начала писался как замена Turbo Pascal. Есть сборки даже под древние КПК и DOS.

https://www.freepascal.org/download.html

работать без линукса?

Но вообще сидеть за Windows и пытаться изучать программирование — время впустую.

AMD64/Intel 64/x86_64

Windows 64-bit
Linux
Mac OS X/OS X/macOS (and cross-compilers for PowerPC(64)/Mac OS X, iOS & iPhoneSimulator, JVM/Java and JVM/Android).
FreeBSD
Solaris

Т.е., чтобы пользоваться на AMD64 FreePascalем нужно сначала установить мегагигабайты чего-нибудь ненужного?