Исповедь системного администратора (многа букаф, мат)

Надо было сказать, что тогда это было бы что угодно - но не имя файла! Он бы еще с * и ? имя придумал.

 

апологетам ксеонов и игрушечек привет передает Dying Light 2

 

plist, а не kext.
Plist это "properties list", сериализация некоего словаря в файл. Kext это Kernel Extension, подгружаемый модуль ядра (в простонародье "драйвер" хотя не самое правильное название.
И да text-based xml был одним из нескольких представлений. XML это всего навсего язык программирования^H разметки, и меня реально удивляла/забавляла такая бурная реакция.
Мне, например, глубоко похрен если кто то будет использовать подмножества языка PostScript для рисования примитивных картинок, используя всего 0.1% возможностей. Или писать на Си программу которая только умеет вводить два числа и вычислять их сумму. Я не буду считать такое использование "некошерным" или "оскверняющим высокие принципы".

 

У МС, похоже, всегда была склонность к подходу "а давайте сделаем наши технологии немного несовместимыми, для того чтобы разработчики, пытающиеся использовать их на другие платформы поебались"
Другого логического объяснения множеству фактов я просто не нахожу.
Даже когда в очередном сотрудничестве с Эппл МС получила технологии и форматы трутайп шрифтов - первое что они сделали это "немножко изменили" стандарт, чтобы шрифты под винду не работали на той макоси тех времен.
Сколько лет или десятков лет вижуальник под винду отказывался распознавать общепринятый и уже вошедший в стандарт тип "long long", и заставлял использовать нестандартный "_Int64t" или как он там назывался?

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

 

"Какие важные, жизненно необходимые игровому движку инструкции!"
ЗЫ: Эта "типа игра" оказывается есть и для консолей, т.е. это явно искусственное огранчение.

 

Скорее маркетинг/расчет затрат. Либо поддерживать весьма неновое железо и тратить деньги разработчиков/тестировщиков, либо нет.
У меня древний ноутбук 2014 года (ноут! не десктоп!) и он поддерживает sse 4.2 - только что проверил.
В шкафу валяется ноут 2011 года и ЕМНИМ там тоже был i7/SSE 4.2, это уже железяка старше 10 лет.
Владельцы сильно неонового железа вряд ли внесут заметный вклад в тех, кто игру покупает (а не пиратит).

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

 

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

 

вот это изварщение ближе к теме xml в plist

а вот Си - предназначен для написания _любых_ программ, в т.ч. и той, которую ты описал.
в plist'е же нарушается принцип xml'я - свободу несортированности тегов одного уровня. т.е. в xml главным является структура, а уж в каком порядке - не важно. Следовательно, при какой-либо обработке файла xml нет требования сохранения сортировки.
это как на одном языке написать программу, которая _случайно_ будет работать под другим языком программирования.

или как вырезать гланды через жопу - ну тоже ведь можно! и успешно! и в каком-нить Люксембурге это может стать настолько утилитарной процедурой, что совсем никого ТАМ уже не будет удивлять

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

plist излишне много места отъедает изза требования указывать теги значения : <value>1</value> вместо "1" или даже просто 1.
(лично меня раздражает французский язык за его звук "бордо", записываемый как bordeaux)

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

 

наивный томцкий вьюношо
как тока цена за байт памяти понеслась в минуса, тогда и отпало требование к оптимизации кода.
ты как динозавр наверно должен помнить, когда в микроконтроллерое ROM был 4 Кб, а RAM - 512 байт. Вот было изъебство
а современные быдло- и говнокодеры можно сказать в раю живут

 

только что пообщался с одним из разработчиков, который впендюрил треды к своему величайшему опусу - программе на питоне, которое по subprocess запускает внешнюю программу svn, получает список папок/файлов там, ходит еще внутрь одной папки, снова получает список папок/файлов уже в ней, всё это запихивает в треды и стартует сразу 20-30-50 потоков, которые в своём рвении поглощают ВСЮ ширину канала до этого сервера, так, что закрываются все прочие остальные коннекции... (jenkins, который и запускает программку на ноде - охуевает и теряет эту ноду)

когда стали разбираться, выяснилось, что "экономия" от использования тредов составляет 1 минуту (без тредов 2 минуты, с тредами - 1 минута, сами себе мешают же).
при этом: сборка бинарника на полученных исходниках длится 15-30 минут, упаковка результата длится минут 10, ну и потом ещё минуты 2 будет длиться отправка результата.
и ещё: весь этот процесс требуется запускать РАЗ В НЕДЕЛЮ (а то и месяц)...

кто им мешает подумать над этим ИЗНАЧАЛЬНО?

 

я как динозавр "работал" и с 8-16 байтами RAM - в МК-61
на моём спектруме уже было то ли 32, то ли 48 кБ памяти.
на ЕС-1062 было ещё поболее, а на 1ВМРСХТ уже совсем по-взрослому было: 640кБ

дык подход сейчас такой к программированию - обобществлённый.
переразмеривание возможностей программ и их кусков приводит к перерасходованию машинных ресурсов.
ты, конечно, можешь и сам запендюрить динамический массив указателей на коллбак-функции и уместить его в 148 байт, но работодатели больше ценят умение разбираться в ООП шаблонах проектирования и умение быстро наклепать (поддерживаемый коллективом) код, запуская IDE с плагинами, отнимающее 16 ГБ оперативы.

 

Такие дела

 

"Давным-давно, когда компьютеры были большими, а программы для них - маленькими..."
https://habr.com/en/company/ruvds/blog/685308/

 

Не делай мне дырок в перфоленте

 

Это не извращение. Это нормальное использование малой части возможностей.
99% пользователей МС Офис умеют юзать 1% его возможностей или меньше. Ты будешь истерить что это извращение?

Нет, это у тебя сильно оторвана связь с реальностью. Си это язык для написания операционных систем, переносимых между разными архитектурами. Он для этого создавался и затачивался. Причем - очень древних операционных систем, безо всякого распараллеливания.
ИМХО, сегодня еще может использоваться как язык обучения/понимания того как работает компьютер. Все.
Есть еще нишевые применения вроде "архитектуры с мизерными ресурсами", всякие микроконтроллеры/эмбеддед. Ну и как "латынь" программирования, на которой никто не говорит но знать образованный человек обязан.
За пределами этого домена Си - крайне плохой выбор, как раз из за минималистичности. Компании, которые привели массы хомячков в программирование (те же Эппл и Микрософт) через какое то время начали телодвижения по переходу на С++ и всякие библиотеки классов, а потом и совсем на другие языки (С#, Objective-C, Swift) потому что Си оказался адски неудачным выбором для написания ГУЙни и продуктов посложнее чем "ls"/"tar"/"gzip"
Да, на нем можно в теории написать любую прогу/решить любую задачу (как и на асме и напрямую в машинных кодах), разница минимальна. Но здравомыслящий человек, владеющий достаточно широким ассортиментом инструментов в общем случае на это не пойдет ибо ценит свое время.

Картинка-мем "я нихуя не понял" с пилотом лайнтинга. Plist нарушает правила xml? Ответ только да/нет. Plist проходит валидацию парсерами/линтерами стандарта? Ответ только да/нет.

Ну так он и был проходящим (и не основным) методом стерилизации. Больше для дебагинга, чтобы легко было читать "с диска глазами".

UOTE="mcgru-, post: 1669737, member: 263"]а меня реально удивляет такое бурное отсутствие реакции на явное извращение здравого смысла
программисты - должны ведь быть супер-логичными оптимизаторами.
если программист не стремится к оптимизации кода - он плохой программист. [/QUOTE]

Это, опять таки, от узости кругозора и застревании на уровне переводных книжек 70-х/80-х годов. Тогда (и в начале 90-х) еще можно было оправдываться отсутствием интернета. Но сейчас доступен огромный пласт литературы (если, конечно, не ограничивать себя искусственно только русскоязычной). Еще Кнут сказал:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

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

А вообще полезно взять ну очень древнюю статью 1977 года, где автор подробно разбирает вот таких вот "оптимизаторов" и показывает, насколько много они усилий тратят на "суходрочку" вместо того, чтобы писать выразительный и хорошо читаемый код. Статья по технологиям тех времен но смысл до сих пор не потеряла:
https://dspace.mit.edu/handle/1721.1/5753

 

Люди поняли это сильно сильно раньше.
Просто на западе время программиста стоило дорого а компьютеры были дешевле. А в "позднесоветском" академическом подходе не стоило почти ничего, а компьютеры были дороже. Вот и возник такой "перекос" и "устойчивый миф".
Отчасти еще поддержанный крайне убогими компиляторами и процессорами тогда, и способностью человека в те времена написать в 10 раз более оптимальный код "вручную". Когда прошла эпоха 8086/286 (условно, уверенно компилятор стат обгонять ассемблерщика где то на пентиумах) это стало уже не так, но было уже поздно. "Ложечки нашлись, но осадок остался"

 

Кто понял то? Обычный юзер разницу между словом, байтом и битом не скажет. Вон на Ваню глянь, он до сих пор не понимает разницы между utf8 и utf16. И время программера по прежнему дорого стотит. Просто теперь "программеры" как врачи разделились на кучу специализаций. Правда для обычного человека любой программер == эникейщику. По поводу оптимального кода - первый принцип - не надо думать, что вы умней компилятора и делать предварительную оптимизацию. Не надо думать что вы тут самый умный - здесь все евреи. Базовых алгоритмов и стандартной библиотеки более чем достаточно в 99% случаев.

 

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

 

Я не говорю что ему нужно верить безоговорочно, но параноить - это терять время.

 

У Си и Си++ (как в своё время надмножества Си) есть огромное (хоть и уже мало кому нужное) преимущество - прямой вызов API ОС. Что линуксового, что виндового. Что позволяет писать быстрые проги размером в пару десятков килобайт после компиляции.
После опыта чтения стектрейсов фреймоворков Явы, С/С++ - образец лаконичности.
Питон тоже крутят - отличный язык, но сам по себе дико медленный, зато предназначен для вызова API из библиотек написанных на C++ (и CV, и нейросети).
Node и всё остальное - всё туда же.