Коллеги! Предлагаю обсудить плохую, на мой взгляд, тенденцию, которую сейчас изложу. А вся негативная тенденция заключается в том, что в какой-то момент программирование превратилось в нечто сродное магии. Во времена, когда я начинал программировать, такое понятие, как фреймворки, не было распространено, и реализовывать ту или иную функциональность в программе приходилось либо самостоятельно (при этом не особо боясь быть помеченным клеймом "изобрёл очередной велосипед"), либо пользоваться готовыми библиотеками и сопутствующей к ним документацией. При этом, принимать решение о том, что нужно выбрать ту или иную библиотеку, либо реализовать тот или иной алгоритм самостоятельно, принимал сам разработчик. Это позволяло оптимизировать такие важные показатели, как загрузка ядер процессора, использование оперативной памяти, общая пропускная способность системы и обеспечение целостности хранимых данных. Сейчас же мы имеем тенденцию к разрастанию фреймворков разного пошиба, которые полностью переворачивают представление о разработке. Эти фреймворки берут на себя ответственность за управление перечисленными ранее ресурсами, и зачастую делают это катастрофически отвратительно. При этом, применение этих фреймворков уже не выглядит как подключение библиотеки и использование необходимой функциональности, а представляет собой нечто вывернутое наизнанку. Иными словами - неочевидная магия, заклинания к которой нужно тщательно подбирать. И проблема не в том, что нужно перелопачивать кучу документов, а в том, что порой заклинаний просто нет, либо они выглядят настолько ублюдочно, что хочется набить морду всем тем, кто эти фреймворки сделал. Если смотреть применительно к Java, то это, прежде всего, программирование через аннотации и XML. Чем дальше, тем ублюдочнее, особенно когда вы чуть ли не весь алгоритм сериализации объекта описываете, проставляя аннотации над каждым полем/методом класса. Ну или отвратительные запросы, которыми Hibernate кладёт БД. Ну или вообще Spring, где нормальное программирование превращается в программирование через коллбэки и во вписывание очередных костылей в штатные классы через наследование/инъекции зависимостей. Ну а самая вишенка на торте - это когда конфигурация, описывающая связи между объектами, "вшита" внутрь и размазана по куче jar-файлов. Может, я что-то не понимаю? Это же адски как неконтролируемые решения по множеству параметров. Почему сейчас, если ты пишешь какую-то легковесную/минималистичную библиотеку или систему, на тебя ржут и тычут пальцем: "Хииии, изобрёл очередной лисапед! Во %framework name% это уже есть искаробки!" При этом забывают, что этот %framework name% косвенным образом за собой тащит кучу совершенно ненужных зависимостей, а об, например, асинхронной работе с сетью там можно только мечтать? Лично для меня маркером хренового фреймворка всегда является то, что первая глава в документации всегда посвящена не тому, из каких частей он состоит, как и какая часть для чего нужна, и сколько ресурсов и каких на неё потребуется, а то, как этот фреймворк поскорее впилить в ваш проект. Да и вообще, почему современные книги и электронные ресурсы всё больше и больше стремятся не рассказать, "как оно работает под капотом", а "что нужно делать, чтобы оно заработало". То есть, от понимания сути проблемы мы переходим просто к набору рецептов, которые в будущем нам предлагают применять на все случаи жизни. Извините, наболело. Возможно, я в чём-то неправ. Но мне одному видится, что всё современное программирование сводится в какое-то унылое гуано?
Наоборот, современная тенденция - отказ от фрейморков в пользу библиотек, фокусирующихся на конкретных вещах. Даже в Java. Про документацию - любая хорошая документация библиотеки для managed языка должна начинаться с того, как за 15 минут эту библиотеку впилить в проект и получить результат. Про капот - понимание нужно сеньорным программистам. Огромный спрос на программистов неизбежно приводит к росту кол-ва джунов и миддлов, которые пошли в профессию за деньгами и не созрели лезть под капот, но уже могут приносить пользу.
Это должно было произойти. На разработку некоторых вещей могут уйти годы. Если каждый будет изобретать велосипеды, всё так и остановится на точке, до которой самым упрямым задротам хватит терпения. Это цивилизация, когда потомки стоят на плечах предков.
Я этого не отрицаю. Но хорошая и лаконичная библиотека в тысячи раз лучше самого расфуфыренного фреймворка. Я не оправдываю лисапедостроительство. Однако некоторые вещи лучше сделать самому, чем полагаться на решения сомнительного качества, вы так не считаете?
А я вынужден многие вещи делать сам, потому что фасм со сквозной компиляцией использую. .lib подключить не могу, кучу длл таскать рука не поднимается. Поэтому как-то уже прохладно к этому сделайсамству отношусь. Но мне бы не пришло в голову компрессию-декомпрессию делать самому, лучше рипнуть чужую, может быть не самую удачную библиотеку, чем полгода писать. Если что-то можно использовать из состава винды, обязательно использую, вплоть до словарей из vbs, хотя динамически выделяемые буферы и без этого уже давно реализованы.
Больше всего меня поражает то факт, что фремворки не умеют освобождать ресурсы. Карл, ну как же так? Вся область тестирования посвящена этому: RAII, нагрузочное тестирование. Переходите на Delphi. А лучше на vhdl. Асинхронность делается просто. Нужен функциональный стиль программирования с Thread-safety компилятором. Который будет дублировать входные/выходные переменные, которые должны автоматически очищаться. Достаточно двух-связного списка. И ещё блоки выделение памяти должны помечаться номером потока. И метод toTherad для передачи объекта(блока памяти) между потоками. А ещё нужен нормальный синглтон со свойством Thread-safety. А то небезопасные мьютексы это бич Qt.
Вот как раз на Spring и всех этих XML построен один большой проект http://payneteasy.com и все дочерние структуры типа http://sbctech.ru Плотно общался с разработчиками, когда ты программерам расказываешь про низкоуровневые вещи, они смотрят на это как на магию, это вне их понимания, их уровень это конструирование логики. Фреймворки созданы для низкоквалифицированного персонала. По сути как конструктор лего для детей. Это выгодно бизнесу, можно набрать гастарбайтеров недорого и стать "крутой компанией как все". Самое удивительное, что разрабы вот этого Spring + XML яростно ненавидят C\C++, испытывал эту ненависть на себе много раз и лично меня это ROFLило, потому как их аргументация "а вот на C++ можно так сделать?" смотрелась всегда смешно, ибо на C\C++ можно сделать как угодно, а Java жестко залимитирован. Про возможности архитектурного проектированияна шаблонах C++ (ака Александреску туториалы) разрабы Java даже не имеют представления, за гранью их мыслительных способностей. У Java есть большой плюс в виде изоляции от физического мира, рантайм позволяет по честному работать с объектами. В принципе инструмент очень хороший, а комьюнити там сплошь фреймворкнутое, я только и слышал постоянно про фреймворки в офисе. Гастарбайтеры же. Крутые вещи в цене всегда. На самом деле полно офигенных проектов, таких как zlib, libpng, проект asio отделившийся от boost, mbedtls и пр. проекты которые имеют минимум зависимостей и решают конкретные задачи. Такие всегда нужны. Фреймворки создают люди с раздутым эго для людей с раздутым эго, у них много общего. Явно прослеживается желание изменить мир и создать некий "швейцарский нож". Самое удобное использование это WEB, строить гавносайты на гавнофреймворках, и заказчик доволен и разрабы не парились. Свою нишу удовлетворяет.
SadKo, да, ты прав. Я работаю именно на джаве и с блокчейнами за деньги. Если бы мне не платили, я бы лучше посидел дома. Цель работы - накопить денег, купить недвижку и постараться стать как можно более независимым, чтобы заниматься действительно интересными, приятными и вечными вещами. В чем проблема? Сиди на своем кресле в офисе и зашибай деньги. >Плотно общался с разработчиками, когда ты программерам расказываешь про низкоуровневые вещи, они смотрят на это как на магию, это вне их понимания, их уровень это конструирование логики. Фреймворки созданы для низкоквалифицированного персонала. То есть ты бы хотел, чтобы информационную систему для макдональдса или страховой компании писали на ассемблере, изобретя перед этим свою RTOS под свое железо, предварительно разработанное на верилоге. И начать с выкапывания кремния для степперов. Если вы такие фанатики программирования, вы бы работали, если бы вам за это не платили? А именно на спринге зарплаты выше, чем зарплаты разработчиков на низкоуровневых языках, для которых 3.5 вакансии в городах-недомиллионников и совершенно нет вакансий в мухосранях. Людям хочется путешествовать, купить свою квартиру и трахать в ней подружку, а в свободное фремя не думать о проблемах бизнеса, понимаешь? Коммерческое программирование говно, но за него платят. Для любителей лоу-лвла советую обратить внимание на FPGA. На них начинают писать ускорители для нейронных сетей. В гугле разрабатывают протокол QUIC. Не хочешь присоединитсья к ним? --- Сообщение объединено, 7 май 2019 --- На то, что вы здесь пишите, в продакшене насрать. Многие системы никогда не будут нагружены настолько сильно, чтобы их пришлось оптимизировать. Желание тянуть в такие системы низкоуровневые оптимизации больше похоже на психическое расстройство байтоеба с экзистенциальным кризисов. Бизнесу проще докупить сервера и память, если чего-то вдруг станет не хватать. Заказчик все равно заплатит богато, если система ему будет крайне полезна. Вы столько лет занимаетесь кодингом, но так и не поняли, на чем держатся компании и группы разработки, и когда оптимизация нужна, а когда она не понадобится вообще. Ищите работу по себе. Компаний со сложными задачами много. Но им требуется нечно большее, чем годы реверсинга.
>>Но мне одному видится, что всё современное программирование сводится в какое-то унылое гуано? Не одному. Это все от бизнес требований. Мало кому нужны специалисты по тому что под капотом. Фреймворк хорошо потому что программист как винтик тогда. Поменял и дальше работает. Быстро и дешево.
Проблема ясна. Люди живут в мухосранях и либо не знают, где можно применить свои навыки, либо не конкурентноспособны и не могут попасть в передовые компании, которые создают технологии будущего.
Я знаю как работает асио, причем подробно, плюс я реализовал много протоколов читая rfc, есть socks клиент, который работает на Win10 32/64 без проблем, на асинхронных сокетах, показывает себя лучше проксифаера. Почему знание устройства используемой либы выглядит столь нереальным? Это же простые вещи. --- Сообщение объединено, 7 май 2019 --- Вот поэтому я тут продвигал Java, ибо действительно денежное направление. Бизнес не зря выбирает этот язык, ибо там меньше проблем в самом языке, поэтому больше времени на решение задач. --- Сообщение объединено, 7 май 2019 --- как раз вот это и происходит сейчас, действительно дешевле железо, чем цена за труд профи и время на ожидание, плюс никаких гарантий
сейчас всё заточено на скорость поделки. поэтому и фреймворки. и либы. что одно что другое - ладно, тут вроде обкатывается и относительно объезжено. и вроде без косяков(хотя не факт что их нет, стоит копнуть порой), но не факт что тот кто эти классы/либы использует - имеет целостное представление о том как правильно с ними работать. ну и далее - слоёный пирог
лол, ну покажи рабочий сокс клиент под вин10, чтобы держало хайлоад. Видимо ты не особо разбираешься в этом, так вот сокс сервер это простое относительно решение по сравнению с сокс клиентом. Да и то сокс сервера никто на 100% по rfc толком не воплощает ибо зачем да, эти все udp associate, потом еще копать upnp под роутеры, сложно же. Ты 100% даже не знаешь о upnp стандарте для открытия внешнего порта судя по изречениям. А вот чекалки некоторые открывают ftp адреса для проверки айпи, а если сокс кривой(99% это так), то udp пойдет в облом и вуаля айпи в блеке. Пр malloc и new я ржу, что тут может быть сложного? До какой глубины? До PDT таблиц устроит? )))) Что касается инди, он веселый шоумен, он нужен для атмосферы и потехи, но знания у него такие себе, зачем-то ковыряется в вещах не поедставляющих ни интереса, ни пользы. Почитать все того же gl00my полезнее в сотни раз, ибо там все по делу. P.S. Либы пишу и трачу много времени, денег это не даст, зато позволит делать труъ вещи не ради бабла, а ради технического прогресса и эгоистичное удовлетворения. P.P.S. Потратил месяц на большие числа под CUDA, отдача 0 денег, зато как приятно получить нужный результат. Увы приходится писать лажу, чтобы зарабатывать в офисе для оплаты всего этого.
Раньше библиотеки делались годами по 10 лет и более в одно лицо может в коллектив. В большинстве случаев это делалось в институтах а там первый года 10-30% от реализации требуют, а при по следующих не менее 20-35% переписывания кода. От них всегда требовали улучшать код. Они проводили исследования над своим кодом. А сейчас всё направленно на скорость разработки. Разработка 1 месяц! Спринт 1 неделя. Успел за неделю сделать молодец не успел код идёт в мусорную корзину. Пишется только тот код который даёт прибыль - т.е делаются новые фичи и никто не занимается рефакторингом и поддержкой старого кода. Это не проблема открываем исходники и смотрим. Для краткости не буду описывать как делается выравнивание под внутренние структуры. Куча представляет собой - корзинки для мелких объектов для средних 2-х связный список. Список располагаемый на месте свободных блоков. Быстрая проверка по размеру с последним освободившимся блоком если совпал используем его не совпали ищем перебором по списку свободных блоков. Нашли откусываем нужный кусок. Если это самый верхний кусок, то вызывается VirtualAlloc он помечает страницы нужным битом. Делается это с использованием mmMapIOSpace который построен на специально зарезервированных скользящих страницах. Вызывается обновления кэша процессора invalidatepage для этого есть специальная команда в процессоре и не очень специализированная MOV CR3. Плюс перемещение страниц из списка свободных в список занятых.
Сразу то не разглядел джентельмена в одеяниях оборвайки. Ваши познания на словах вызывают уважения, милорд! P.S. Хайлоад это высоконагруженные системы, можно было погуглить так-то.
Что-то вспомнил чувака с программерсфорума, который рассказывал о том, как он спивается и пьет хлорпротиксен от алкогольной зависимости. Чувак был горд тем, что изучал велосипеды типа менеджеров кучи и реализовывал их. Говорил о том, сколько всего он знает, а его не берут на работу, потому что у него нет опыта. Мол, как же так, я могу написать свой аллокатор, а вы тут требуете свои бусты и Qt. Странные люди, которые не могут адаптироваться к рынку и упорствуют в том, что не приносит им денег и счастья.
ну ладно, давай последний шанс тебе, вот я подробно строил ось хеллоуворлд по манам интел, поэтому со страницами памяти я знаком. Ты сказал, что там много всего. Давай удиви и поведай, что там ты знаешь глубже доков интел, я пока чаю налью, напиши подробно, это ведь теье по зубам, про кодеру ))