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

Ага, и написал точно такую же

Нет, не такую же. Ты ввел совершенно лишнюю сущность в виде base, которую за каким-то хером возводишь в степень вместо того, чтобы просто и самым очевидным образом ограничить диапазон. В моем варианте банально меньше значков, в которые надо вчитаться и вдуматься чтобы понять, что имел в виду автор и зачем он так написал. Кроме того, ты сам себя запутал и в итоге написал некорректное условие.

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

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

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

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

На случай если нужно будет проверить, является ли число палиндромом в какой-то другой системе счисления, например 16-ричной.

В условиях задачи этого нет. Ты усложнил код на ровном месте.

И я всё еще жду ответ на вопрос, который ты старательно игнорируешь:

Скажи вот мне пожалуйста, кем ты работаешь? Тебя научили столяровские опусы хоть чему-то, чтобы ты мог монетизировать эти знания?

И я всё еще жду ответ на вопрос, который ты старательно игнорируешь

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

достаточно разобрать половину.

А потом собрать обратно. Экономия сомнительная. Последние две строки вычислений, кстати, в моей программе не нужны, поскольку m уже однозначное и можно было присваивать сразу цифре a. В итоге операций, если считать и деления и умножения будет поровну примерно. Но однотипные операции понятнее разнотипных.

Ты усложнил код на ровном месте.

Ну можно было 10, 1000 и 10000 вынести в отдельные константы.

потому что имена переменных должны быть говорящими.

Это если код длинный и переменные используются далеко от того места, где объявлены. Чем твой number лучше простого n?

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

Вовсе не поэтому. У меня изначально было 10000 написано и только потом я исправил на base**4.

Потому что вопрос некорректный

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

А потом собрать обратно. Экономия сомнительная.

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

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

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

Чем твой number лучше простого n?

Тем, что нельзя перепутать его с m.

Вовсе не поэтому. У меня изначально было 10000 написано и только потом я исправил на base**4.

То есть, ты внес сложности в код еще до того, как убедился, что он работает.

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

Тогда почему в математике и физике формулы пишутся через однобуквенные переменные. F=ma, а не Force = mass × acceleration, но это ладно, ещё удобоваримо. А ты попробуй «говорящими именами» уравнение Эйнштейна или Шрёдингера записать.

Или x²+5x-14=0 почему-то пишут, а не unknown_variable × unknown_variable + 5 × unknown_variable - 14 = 0

Странно, да?

Для машины - быстрее

Не исключено, но это важно только в цикле на 100500 итераций, да и то не факт.

и код мой - короче и проще для чтения.

А вот с проще для чтения — нет. На формуле (right / 10 + (right % 10) * 10) спотыкаешься и думаешь что тут происходит. Ну и напиши-ка такую же формулу для трёх или пяти цифр.

Тебе показывают, как надо писать

Кому надо?

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

Где объективно — да, = пропустил после > не ухожу. А по остальному — это не «объективно», а лично твоё мнение.

Тогда почему в математике и физике

Это не физика и не математика, это программирование, причем прикладное. Совершенно отдельная дисциплина.

А вот с проще для чтения — нет.

Проще, проще.

Ну и напиши-ка такую же формулу для трёх или пяти цифр.

Я тут либо цикл заиспользую, либо макросы.

Или x²+5x-14=0 почему-то пишут

Потому что математики ленивые. И учат, как надо лениться, своих учеников.

Тогда почему в математике и физике формулы пишутся через однобуквенные переменные.

Им не приходится шерстить MLOC+ sources на предмет «а где оно используется». Это наверное главная причина использовать «достаточно-уникальные» имена. Ну, и попробуйте разобраться что код делает глядя на него после обфускации - тоже довольно поучительно.

Тогда почему в математике и физике формулы пишутся через однобуквенные переменные.

На это есть разные причины. Основная — так исторически сложилось.

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

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

Так вот, в достаточно простой программе можно как и в физике с математикой обозначить, скажем, координаты на экране привычными x и y, цвет пикселя, например z, а итератор в цикле i — и будет норм. Если к ним добавить какой-нибудь счётчик c и состояния a и b, тоже будет вполне терпимо и понятно. Для совсем простых программ это годится. Но когда у тебя десятки объектов с сотней полей, десятки функций, каждая принимает по несколько аргументов, то этот путь ведёт в совершенно определённую точку — к головной боли — только запутаешься окончательно и всё. Вот тут на помощь и приходят осмысленные имена переменных. Дело ведь не в количестве символов в имени, а в его осмысленности, понятности с первого взгляда. Просто в физике для осмысленности может хватать и одной буквы, а в компьютерной программе, если она не примитивная — не может. Кстати, в областях науки, изучающих значительно более сложные системы, чем физика, одиночными буквами обычно ничего не обозначают — даже в химии на элементы букв не хватает, и они обозначаются то одной то двумя буквами, а в какой-нибудь, скажем, биологии, уже никаких однобуквенных обозначений нет, латынь сплошная длинная.

Я тут либо цикл заиспользую, либо макросы.

Ну напиши. Мне почему-то кажется, что это будет нечитаемо.

Разверну мысль вдобавок ко всему вышесказанному. Проблема однобуквенных переменных в том, что из легко спутать между собой замыленным глезом (что ведет к семантической ошибке), и легко забыть, что делала конкретная переменная. А еще куски кода должны иметь группировку по смыслу. Твой говнокод можно легко превратить в хороший код, если сделать вот так:

rest := number;

d3 := rest mod base;
rest := rest div base;

d2 := rest mod base;
rest := rest div base;

d1 := rest mod base;
rest := rest div base;

d0 := rest mod base;
rest := rest div base;

Или как-то так:

#define NEXT(d) { d = rest % base; rest = rest / base; }
get_next(d3);
get_next(d2);
get_next(d1);
get_next(d0);
#undef NEXT

Или вообще уже цикл.

Если какой-то код дублируется - то его надо выносить в макрос или функцию.

координаты на экране привычными x и y, цвет пикселя, например z, а итератор в цикле i — и будет норм.

Вот-вот! А @liksys этого не понимает.

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

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

Вот-вот! А @liksys этого не понимает.

Я всё прекрасно понимаю и выше уже объяснил. В идущих подряд вычислениях очень легко перепутать i/j/m/n. Поэтому переменные должны быть говорящими и отличимыми друг от друга.

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

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

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

В идущих подряд вычислениях очень легко перепутать i/j/m/n.

Ты уже перепутал get_next и NEXT

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

Поэтому переменные должны быть говорящими и отличимыми друг от друга.

Может быть. Но кстати ты всё-таки написал d0, а не digit0 и кстати в этом случае их было бы правильнее считать с младшего разряда (d0 — коэффициент при 10⁰, d1 при 10¹ и тд)

const int len = 4;
int d[len];
int rest = number;
for (int i = 0; i < len; ++i) {
    d[i] = rest % base;
    rest = rest / base;
}

bool poly = true;
for (int i = 0; i < len / 2; ++i) {
    if (d[i] != d[len - 1 - i]) {
        poly = false;
        break;
    }
}

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

Ты уже перепутал get_next и NEXT

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

А где макрос для твоего подхода?

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

Если требует - упакую в один цикл и уполовиню итерации.

Если длина известна - можно вообще без циклов. Если неизвестна - полтора прохода сделать придётся по-любому. Не?

Ага, типа того. Но опять же, зависит от того, надо ли оптимизировать.

расчехляя саблю

Program palindrome(input,output);
var n : integer
Begin
	write('Enter 4-digit whole number: ');
	readln(n);/* по условию задачи ввод корректен */
	if (n mod 1001 mod 110=0) then 
		writeln(n, ' is a palindrome!')
	else
		writeln(n, ' is not a palindrome, sorry.')
End.

как и в примере с min3 очередное подтверждение что программерам запрещают пользоваться арифметикой - ох лёл

pspsp кстати -y где y четырёхзначное натуральное полиндромище - моей расчехлённой саблей признаётся палиндромом в отличие от двух авторов ранее решений :)

pspsps если минус считать за знакоместо тогда нужно тестить for n<0 :=> abs(n)%101%10==0 Ж)

ВНЕЗАПНО, оказались заблокированы gin-gonic.com и gorm.io. Похоже на заговор )

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

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

Для rust есть mrustc, go сам собирается. С ada сложнее, но вроде есть исходник версии для спарк который транслируется в C. А тут просто самовоспроизводимый компилятор который больше ничем опенсорсным не собрать.

Даже ocaml вроде как собрали полностью из исходного кода, правда, не самый свежий.

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

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

char, наверное, можно, но есть типы int_8t и uint8_t Фиксированные типы необходимы, чтобы избежать тяжёлых ошибок, а то например, обрабатываешь сетевые пакеты, у тебя всё правильно работает, а с другим компилятором внезапно переполнение буфера какое-нибудь.

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

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

Интересно 128-битные целые в C вообще есть?

В стандарте C23 появился тип _BitInt(N) - где N - число бит. Так что теперь (там где он поддерживается) можно писать :

    signed _BitInt(12) a = -1500; //-2048 ... 2047
    unsigned _BitInt(128) b = UINT64_MAX * 10;

В gcc и clang давно уже были расширения с типом __int128

расчехляя саблю

Пришёл qulinxao и всем мастер-класс показал :-)

последний абзац огонь в свете «mod 1001 mod 110» начальной арифметики

гордыня всех обует

d %1
dd %11
ddd %101%10
dddd см в 
ddddd %10001%1010%100 

эх школа

ps[гы гы] - дочитал до последнего абцаца и обнаружил что деление на «11"и его 101... колег не привязано к десятке а привязано к позиционной нотации :)

Теорема: исползуя mod достаточно (n+b) mod для натурально длиной 2n+b и сравнения на нули ( где b из {0,1} )

последний абзац огонь

Беспочвенный апломб посрамлён?

Теорема:

Торопимся. Для нечётных длин as-is точно не работает. Контр пример: 201. Но идея красивая, аплодирую :)

Ой да,

Промеж(с задержкой что соответствующий div меньше base) эхь

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

зы: div (как и скрипач) оказался крестьянской теореме остатков не нужен

Отлично. Но у этого кода есть один небольшой недостаток. Чтобы понять как работает, то что у меня нужно примерно 20 секунд, понять версию @liksys — где-то 200 секунд, а на твою ушло около 2000 секунд.

Ну то есть китайская (или всё-таки крестьянская?!) теорема об остатках конечно есть, но к чему она тут я не понял.

Но суть в том, что остаток от 1001 проверяет сходятся ли первая и последняя цифра, если нет, то в конце будет не ноль, если да, они обнулятся. А остаток от деления на 110 будет равен нулю только если последняя цифра 0 и цифры десятков и сотен совпадает. То есть да, если не проверять диапазон, должно работать.

как и в примере с min3 очередное подтверждение что программерам запрещают пользоваться арифметикой - ох лёл

А где твой код для max(A,B,C)?

По первому абзацу: в этом и заключается образование .

Отлично. Но у этого кода есть один небольшой недостаток. Чтобы понять как работает, то что у меня нужно примерно 20 секунд, понять версию @liksys — где-то 200 секунд, а на твою ушло около 2000 секунд.

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

Мой пример тривиален, очевиден и самодокументируем

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

Сразу сравнивать цифры исходной цепочки.

каких-нибудь обскурных теорем

не жалей

там чтение строки с двух краёв ( по модному two pointers) или даже загоняем последовательность цифр в очередь ( например Кафку) и читаем парами с краёв пока есть и пока равны - если очередь стала короче 2 успех в остальных случаях - не пали ндром

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

psps: если заранее известна длина(2n+b) - то достаточно застекать n цифр и если b=1 drop ( ибо ость остальное) пока стек не пусть читаем и сравниваем с pop пока равны -

стек пуст - пали

нет - бенгали

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

поплачка для нечётных длин

прежде чем делать последнее мод ( на 1(0)+ ) нужно сохранить тот остаток и если он кратен

в питонячней нотации:

a=n%..... %....
d,o=divmod(a,1(0)+) # т.е для b=1 добавляется div и сравнение
return o==0 and d<base

Ж)

Мой пример тривиален, очевиден и самодокументируем

самотестируем и самоверифицируем

Никогда не слышал термин? Теперь слышал.

длина идентификаторов - имена сущьностей это от того «мы покупаем али продаём?»

в математике приходится делать постоянно трансформации крокодилов поэтому чёрточки идеальные имена

словоЖеСодержащееДокументациюНаСебя оно очень полезно для экономии на квалификации сопровожденцев

зыЖ в сырцах golang - очень выверенный подход - если имя сверхлокально (ну там 2 -3 строки то однобукв) и увеличением использования области и имя всё более уникально_информативно

ну для глобальных там есть «очевидные» сокращения(привычные авторам) всёж

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

всёж таки емсквадрат али уравнения Максвелла намеренно лаконичны ибо так проще помнить

так и с именами

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

upd: Notation as a Tool of Thought" 1979 Turing Award lecture Kenneth E. Iverson

http://rkka21.ru/docs/turing-award/ki1979r.pdf

там реально очень точно почему длинное имя это эрзац

Я тут по мотивом твоего скриншота ещё одну программу написал.

Интересно, @liksys и на это скажет, что говнокод и я вообще не умею программировать?

Мне лень в это вникать. Скажу просто, что синтаксис паскаля выглядит максимально уродливо. Но это не твоя вина.

Вкусовщина же. Можешь попросить нейронку переписать один-в-один на C, наверное даже получится. В целом я тут только и делаю что дёргаю функции SDL, так что есть надежда что она не сильно испортит код и он скомпилируется и запустится.

Потому что столяров так сказал, или есть какая-то внятная и обоснованная причина?

Ну например, в Qt прямо рекомендуется то же самое. В программе всё в Latin1, весь юникод выносится в файлы .ts. Да, это не догма, если мультиязычности не предполагается, можно оборачивать те же русские тексты во fromUtf8(). Только некоторые не оборачивают, а потом удивляются, что у них программа в одной ОС кажет нормальный текст, а в другой кракозябры. И обёртку легко забыть, если в ОС разработчика всё нормально. Поэтому выносить не-латиницу в отдельные файлы всё же надёжнее.

В программе всё в Latin1, весь юникод выносится в файлы .ts.

Нет, так делать точно не надо. ASCII и всё. latin1 откроется кракозябрами в less.

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

Как уже выше написали – вкусовщина. И имхо, куда уродливее выглядит описание функций в си-подобных, от которого большинство современных языков (Rust, Go, JavaScript) отказалось.

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

Если тебе синтаксис паскаля - вкусовщина, то у тебя что-то не так со вкусом.

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

Так что решаете в лоб, разбирая число на цифры d1, d2, d3 и d4 и сравнивая if(d1=d4 and d2=d3).