Один раз, правда, растянулся на много—много лет и до сих пор тянется — в том смысле, что посмотреть на это можно и сегодня.
Дело вот в чём.
Когда компьютеры были большими, а память у них — маленькой, был этап, на котором захотелось, чтобы цветов стало не 2, 8 или 16, а много. А потому просто пронумеровать в произвольном порядке используемые цвета уже не получилось бы — слишком их дофига. Поэтому цвет стал кодироваться интенсивностью каждого из трёх каналов: красного, зелёного и синего.
Впрочем, цветные телевизоры уже кодировали примерно так же, но тут оно стало аналогичным и в программах тоже. И не в аналоговом, а в цифровом виде: по восемь бит на цвет.
Само по себе оно нормально — пусть будет, например, восьмибитовое слово, почему нет? Однако сейчас любому понятно, что сколько бы градаций у частного случая реализации канала ни было, а сами значения интенсивности к этому привязаны быть не должны. Минимальное значение в канале — 0, а максимальное — 1. Если их кодировать вот так, то «программный код» цвета всегда переведётся в конкретный реальный цвет данного девайса, невзирая на количество градаций. И каждый раз 0 будет означать «канал вообще отключён», 1 — «включён на максимум», 0.5 — «включён наполовину» и так далее.
При этом, если вдруг поменять лежащее в основе всего этого слово с восьмибитного, например, на шестнадцатибитное, то текст программы от этого никак не поменяется.
Но это сейчас всем понятно, а тогда оно ещё не всем, поэтому хардкодинг цвета с привязкой к конкретной реализации на уровне прямо сразу числового диапазона разошёлся не только по программам, но и по интерфейсам. И дизайнеры, этими интерфейсами пользующиеся, к сему привыкли. Поэтому сейчас в куче программ каждый цветовой канал кодируется числами от 0 до 255.
Но ирония в том, что он так кодируется исключительно в интерфейсе, а в самой программе цвет может храниться как угодно, ведь, как правило, оные программы умеют работать не только с одной цветовой схемой, а с овердофига. И цветом, фактически, является совокупность из ссылки на цветовую схему и кода (не обязательно, кстати, трёхчисленного) в этой схеме, что как раз и позволяет, во-первых, правильно отображать эти цвета на любом девайсе, а во-вторых, свободно конвертировать цвета между схемами, если конвертация вообще возможна (грубо говоря, не все цвета, которые достижимы при помощи прожектора, можно повторить на бумаге).
Ну так вот. В интерфейсе есть три поля — для каждого из каналов. А в ОС в это время есть буфер обмена. А у дизайнера (если он, конечно, потратил свои лучшие годы на обучение работе с компьютером, а не на заучивание хер знает чего) есть желание иногда копировать цвета через буфер обмена между программами или даже внутри программы. Три поля — три копипасты. Ясен перец, удобнее с одним полем и одной копипастой.
Не будь предыстории, в этом поле было бы написано что-то типа «75, 15, 201», а к интерфейсу была бы прикручена проверка вводимого, не позволяющая ввести что-то типа «45, 444, хер». Но предыстория распорядилась вписывать туда три канала, склеенные в шестнадцатеричное число. Тогда на каждый из каналов получается по две позиции этого числа и это что-то там типа решает. Всё ещё надо проверять, что не ввели «хер», но как бы на одну проверку из ста стало меньше — типа зашибись экономия. Хотя, конечно, вполне понятно, что просто дизайнеры привыкли видеть это таким, поэтому оно такое.
Однако ирония в том, что в коде программы-то, если там даже используется диапазон не от нуля до одного, а от нуля до 255, всё равно будет написано что-то типа «RGB(75, 15, 201)», которое в тексте программы копипастится точно так же хорошо, как в виде одного шестнадцатеричного числа. И так в программах написано практически всегда (хотя сейчас каналы всё чаще закодированы от нуля до единицы), а потому к интерфейсу пользователя и шестнадцатеричному числу в оном сие уже имеет весьма отдалённое отношение.
Кроме, конечно, того одного—двух раз, когда я имел дело с кодом, в котором некий программист захардкодил цвета, скопированные через буфер обмена из калор-пикера Фотошопа. Да, так тоже можно, и, вообще говоря, всем пох, поскольку внимательно читать какие-то циферки в подавляющем большинстве случаев никто не будет. Однако мне надо было децл подправить оттенок, поэтому я был вынужден их как бы прочитать.
Но если кто-то думает, что для этого мне пришлось на бумажке переводить это число из шестнадцатеричной системы в десятичную, а потом обратно, то он лох и ничего не понимает в компьютерах и программировании, ибо, во-первых, в программе любое число само собой из десятичной и какой угодно другой системы конвертируется в двоичную — только программист этого процесса не видит вообще никогда. А во-вторых, любое число можно одной командой напечатать в шестнадцатеричном (и, вообще говоря, каком угодно другом виде).
Правда, всё это нахер не нужно, а потому все числа в программах в 99,999% случаев написаны в десятичном виде. Если вообще написаны, поскольку хардкодить числа в программах — очень плохая идея.
Но и в том редком случае, когда там всё-таки были захардкожены цвета, я, ясен пень, ничего никуда не переводил. Тем более, на бумажке — я ж не идиот.
Я копипастнул нужное число из программы в калор-пикер Фотошопа, там на глазок подправил оттенок, и копипастнул изменившееся число обратно. В общем, сцуко, ценный навык перевода чисел вручную так и не довелось применить.
Ещё раз я встретил недесятичное число в программе, когда в доставшемся мне коде некий талантливый программист мощно экономил память, записывая булевские значения не в отдельные переменные, а в конкретные биты числа. Так было сэкономлено наверно целых сто байт, а то и вся тысяча, в общем, оно явно того стоило — в те времена, когда даже оперативная память измеряется гигабайтами.
Однако, поскольку программист явно потратил всё время на заучивание таблицы умножения, вместо изготовления десяти функций с понятными именами, которые извлекают или устанавливают нужный бит в рамках программы экономии трёх капель воды в океане, у него там было просто число в некой переменной и невпупенная инструкция, какой бит в ней что означает. При этом то ли последовательность битов в их кодировании какой-то момент сменилась, то ли они какой-то бит решили потом добавить в середину, то ли кто-то заучил наизусть
В общем, всё по школьным канонам: лучше день потерять,
И, конечно, выработанная школой тщательность: стопицот строк кода с захардкоженными числами писать не лень, заучивать, какой бит что означает (чтобы потом всё равно с этим путаться), не лень, но вот завести двадцать функций, которые почти целиком генерит среда разработки, которая потом ещё и их имена подсказывать будет, лень.
Точнее, не столько лень их заводить, сколько лень об этом вообще задуматься — такое вот оно, выработанное школой трудолюбие и развитый ей же интеллект глубоко образованного человека: команды «думать» не было — тут трясти надо. Наверно даже контрольные по номерам битовых флагов сдавали. С оценками в четверть.
Обратно же, если кто-то сейчас решил, что именно вот тут мне-то и пришлось переводить между системами, то нет, не пришлось. Ибо нафиг не надо что-то переводить туда—сюда, даже если используются битовые флаги. Вместо этого, мне пришлось завести эту пару десятков нормально поименованных функций для установки каждого из флагов, на что ушло аж три минуты, а потом тщательно выпиливать все эти «установки по выученному» из тех многих тысяч строк кода, куда их успели распихать трудолюбивые любители школы, на что ушла наверно неделя, ибо места, где номера перепутаны, от мест, где не перепутаны, разумеется, ничем не отличались, а потому каждое приходилось внимательно читать и догадываться, что там имелось в виду.
Гипотетически есть ещё третий раз, когда программист может обнаружить недесятичные системы счисления. Дело в том, что дробная часть числа, которая конечна в десятичной системе счисления, может оказаться бесконечной в двоичной. Поэтому, если число хранится в фиксированной длины ячейках памяти, на этом месте может случиться потеря точности. И очевидные операции могут дать неочевидный результат: сложение двух десятичных дробей вдруг обнаружит какой-то «шум» на отдалённых десятичных знаках.
Это, друзья мои, должен знать каждый программист. Но, благо, сие знание уложилось в один абзац, а почему-то не в полгода тренировок перевода между системами счисления в столбик.
Тем, сцуко, блин, смешнее, когда любители современной школы, как источника знаний, решают блеснуть всей глубиной источника и начинают рассуждать про то, как настоящие правильные программисты что-то там «кодируют в двоичной системе», поскольку «компьютер построен на бинарной логике».
Ну а как ещё-то, если знания об этом почерпнуты из олдовых книг, которые написали авторы, которые даже в те олдовые времена ничего не программировали, а просто что-то где-то услышали и вычленили оттуда главные с их точки зрения сенсации?
Сто пудов, всё так и есть — эти специалисты врать не будут. Не зря же их взяли писать учебники для школы.
Да я, вон, сам в кине видел, как хакеры летают с джойстика между какими-то нарисованными небоскрёбами, чтобы «взломать систему». Зачем создателям фильма врать? Нет, они точно и верно изобразили работу программистов. Это просто те программисты, которые от этого ржут, недостаточно настоящие. Не знают всех тонкостей программистской работы. Невнимательно кино смотрели.
И в школе наверно тоже плохо учились.
doc-файл
← Ctrl ← Alt
Ctrl → Alt →
← Ctrl ← Alt
Ctrl → Alt →