Забавные новости 0й-Ti :)

даа, это не Ассемблер, чёрт ногу сломит

 

Юзал. Это по-моему теперь самый популярный кряк на винду. И он лежит на гитхабе.
Разрабы в общих чертах описали используемые методы https://massgrave.dev/kms38

 

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

--- Сообщение объединено, 7 май 2024 ---

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

 

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

--- Сообщение объединено, 10 май 2024 ---

короче всю утиную типизацию и интерпретаторы на мыло отправил ради перформанса.

--- Сообщение объединено, 10 май 2024 ---

а лисп тем временем продолжает жить

 

Да, он не понимает клинкод. Проблема в том, что обе стороны конфликта (и адепты клинкода и адепты на 2 процента более быстрых циклов) не понимают одной важной вещи: если код будет идеально чистым, то он будет гораздо медленнее, чем он мог бы быть; если код будет идеально быстрым, то его будет слишком сложно поддерживать. В реальном мире нет идеального ни одного, ни другого, но почему-то одни продолжают навязывать одно, а другие - другое.

 

Идеальный код не надо поддерживать, и мир вокруг него не меняется. Вот тогда он может позволить себе топовый перформанс. Есть ситуации, где улучшение на процент приводит к увеличению прибыли, но это редко. Клинкод это про то, как "х%к х%я и в прод" с костылями, которые меньше навредят в дальнейшем. Именно что с костылями, а не совсем без них. Просто садиться за код надо в последнюю очередь, и нормально качестсвенно отрабатывать аналитикам и архитектору. Но это не очевидно с позиции кодера, вот и вечные зарубы у спецов. Как бы так соломку подложить, прежде чем выяснится что эффективно бежали не в ту сторону, и теперь надо разворачиваться.

 

вот возьмём, к примеру, dry (don't repeat yourself) - очень плохая идея..
допустим, у нас 10 фунок пользуют одну базовую и нам нужно написать 11ую, коя тоже должна пользовать ту базовую, но нам необходимо внести изменения в базовую для удовлетворения нужд новой функи. что делать??? можно зафигачить изменения в базовую и сношаться с отладчиком по всему древу зависимостей. А можно скопировать базовую и сделать серию минорных изменений под новую функу.. то бишь мы проводим Атомизацию Кода и лишаем себе туЕвой Хучи печалей + АК помогает спид-апу проги и улучшает её портабельность + улучшаем читабельность кода, лишая себя мути доп условных ветвлений. Короче, правила спид-апа кода гораздо ближе к Чистому Коду, чем тот замшелый клинкод. потом - чем Тебе те свичи не нравятся - пользуй инлайн функи ==>> вот Тебе читабельность да спид-ап в одном флаконе

 

UbIvItS, если про атомарность - так я только за. Чем не нарвятся свичи. Если я хз какой потом новый тип придумает заказчик, то это однозначный повод залепить диспатчер по типу, внутри которого по требованиям интерфейса должен быть метод. И когда надо будет добавить, то нужно будет именно добавить, а не читать и вникать, что куда можно, а что куда нельзя. Итератор по списку имхо легче читать, чем держать в голове разные ифы на все случаи жизни.

 

а нельзя быть за АК и бегать с интерфейсами клинкода клинявый код подразумевает работу сугубо с интерфейсами - у Тебя задача и Ты смотришь аким дикобразом её решить чрез набор доступных. но что происходит, когда не хватает функционала базовых модулей??? dry требует впихнуть новые функи, не нарушая кол-во модулей - ведь, повторяться нельзя клинявый код приводит к длинным абстракциям, что ввергает всю идею к полному Абсурду. абстракция не должна становиться источником проблемы, а размер длинной абстракции легко превышает весь базовый код в разы и в итоге погружаешься в кромешный идиотизм ==>> тестирование и отладка абстракций

 

А как относитесь к паттернам проектирования в промышленной разработке? Они нужны или нет?

 

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

 

Особенно, когда пишешь софтину на Цэ...

 

Ну если площадь треугольника через полиморфизм решать, то действительно можно добиться ускорения выкидыванием этого лишнего и подгонкой данных в кеш.
Я давно и планомерно пропагандирую мысль, что за термином ООП в глобальных масштабах закрепилось очень неправильное и кишмишное понимание, которое смешало коней и блекджеков в плохо перевариваемую кашу из мантр.
На самом деле всё просто - ООП это принцип Лисков и точка. Вот так просто - ООП-нутый код это код в котором используется подстановка ссылок на производные классы через ссылку на базовый в расчёте использования виртуальных функций. Всё. Ничего более. Если даже в коде пестрит ключевое слово class, но этот приём не используется - его всегда можно трансформировать в код из функций и структур как писали fopen и matrix3x3_multiply деды и в ус не дули до всякого ООП. Потому что это не ООП.
Так вот главная суть ООП - это как видно полиморфизм, когда мы пишем код который будет работать с заранее неизвестно каким объектом удовлетворяющим некоторой спецификации состоящей из виртуальных его функций. И эта штука реально нужна в сложных программах когда мы чаще всего сталкиваемся с коллекциями однотипно ведущих себя, но разных объектов - как то монстры в игре или визуальные компоненты на окне GUI или разные типы XML сообщений Сервиса Электронного Документооборота Социального Фонда России - разные типы объектов монотонно перемалываются в разнообразных циклах item.Draw, item.ProcessXML, item.TakeDamage и т.п. Вот тут ООП на коне. И тут городить switch-и себе дороже. И оно не cache-friendly уже просто потому что разные объекты разного размера не поместишь в один массив. Это по природе вещей штука не cache-friendly. Абстракция такая прикольная тут действительно бьёт по перфомансу.
В то же время огромное количество кода этого просто не требует. И не является ООП-нутым. И может быть сведена к локальности данных в массивах и тому подобное.
Поэтому прежде чем считать площади треугольников через полиморфные объекты надо сперва спросить себя - а тебе действительно нужны полиморфные объекты или тут можно обойтись без ООП?
Если можно обойтись без ООП, то и clean code будет без ООП, а если нельзя - ну хоть тресни ты, но надо нарушать cache-frendliness в пользу чистого кода. Или задумываться об Entity Component System.
Предположу, что истинная ошибка этого автора книг про чистый код - это как раз неправильное понимание ООП и завет решать все проблемы этим микроскопом, включая забивание гвоздей. Но я книг его не читал и просто предполагаю.

 

ета керь ии-шечкой сгенерина

разные объекты не могут себя вести однотипно ==>> лишь для юзверя создаётся ИЛЛЮЗИЯ однотипности, а при разработке кода для каждого объекта прописываются серии коррекций в зависимости от размера/структуры данных и железа, на коем оное безобразие должно пахать. куча ооп-еров по своей сути тоже юзвери, они никогда не видели базовых фунок ооп-ского кода, а просто фигачили расширения чрез интерфейсы

конечно, сиха богомерзкая и нам всем надо полностью забить на её самый лучший компиль, самые удобные средства отладки и самую обширную базу СТАБИЛЬНОГО КОДА глянь crates.io ==>> тамошняя публика так бодро пишет ржачные коды, что даже мой ноу нейм пет проект часто мелькает на первой странице

 

Какой компиль? Clang? Это тот же Clang, бекенд которого использует Ржавый и тонна других языков? Или, может, GCC? Это тот же GCC, который имеет фронтэнды Ады, Дэ и Фортрана и один общий для всех бекенд?

 

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

 

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

 

экий же Ты терпила - сидишь на осях, написанных богомерзкой сихой харе терпеть такое безобразие ==>> выключи сю мерзость из розетки иль сразу топором по системнику.. УБЕЙ СИХУ ВЕЗДЕ И ГЛАВНОЕ В СЕБЕ

 

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