Тут могут предъявить за излишне интенсивное использование динамической памяти - new/delete
Вот это довольно показательный момент. Он суммирует наш разговор. Вместо быстрого решения задач вам приходится думать о быстрой работе компьютера. Про стоимость работы программиста я вам писал, но раз вам "предъявляют" за минимальные попытки ускорить написание программ, то здесь я уже не могу помочь. Выбор в сторону оптимизации скорости исполнения сделан не вами, но вы его полностью приняли и отказываетесь воспринимать альтернативы. 10% по вашему очень много. Ну ладно, я вам писал про в 15 раз дороже в случае сравнения стоимости компьютера и труда. Это тоже вас не заинтересовало. Но чем тогда вас убеждать?
Вот совсем коротко:
Труд дороже железа. Доказать пытался, но не вышло.
Бой за 10% ускорения стоит в разы дороже, чем решение той же задачи без ускорения на 10%. Опять пытался доказать, но не получилось.
Оттуда же, откуда знаю, как решать квадратное уравнение. В математике такие вещи доказывают. В программировании это все по разному называют, я бы назвал - качественное проектирование.
огромное количество собранных статистик у нас показывают что SQL не во всех случаях является оптимальным с точки зрения производительности
Я не говорил, что стандартный инструмент во всех случаях лучше. Я говорил, что он во многих случаях (в большинстве случаев) экономит усилия программиста при достаточно эффективном результате. Достаточно эффективный, это такой, когда нет смысла экономить миллисекунды при времени исполнения минуты.
Это статическая структура, объявленная во время компиляции и куда вы просто читаете с диска блок данных (запись), или класс, у которого в рантайме вызывается конструктор, выполняющий каки-то преобразования?
Эта структура - класс. С накладными расходами в виде конструктора и чего-то ещё. Теперь математика: время чтения с диска, пусть будет SSD, положим 1 миллисекунда, затем преобразование в нужную нам структуру. За миллисекунду пусть прочитали 100 килобайт по сто байт структур (это пиковая, редко в реальности достижимая скорость выборки строго нужных данных). То есть всего 1000 структур. Время выполнения конструктора и прочего для каждой структуры - пусть 100 наносекунд, хотя всё это в кэшах и в цикле, так что процессор много чего может оптимизировать. Итого имеем 100 микросекунд на всё. Всего имеем примерно 10% затрат на конструкторы и 90% на чтение. Далее напишите всю обработку вручную, вместо одной строчки, как я показывал. Сравните свои затраты с моими. Получите в 100 раз больше, чем у меня. Вспомните про стоимость программистов.
для каждой задачи есть наиболее эффективный инструмент
Есть всего лишь эффективные и неэффективные решения. Разница определяется расчётом. Это просто математика. Её вполне способен считать компьютер.
Вот три ситуации:
Всё это шаблон. Шаблон такой: отображение, фильтрация, вычисление, запись данных. План запроса в каждом случае я вам вычислять не буду, это трудоёмко, но единожды написав программу вычисления подобных планов запроса, я автоматизирую все ваши ситуации. Хотя заранее признаю, что план запроса может быть по каким-то критериям неоптимальный. Так что вы, в каких-то случаях, сможете опередить мой планировщик. Но в некоторых случаях даже вы не сможете его победить.
А теперь вспомните, сколько времени вы потратили на решение этих задач. Сравните с программистом, который пользуется оптимизатором, работающим за него. Ну и снова вспомните стоимость труда программиста.
Сэкономили на разработчиках, сэкономили на тестировщиках. Получили плохой код. В результате в период "пиковых нагрузок" все встало колом
Ну вы ожидаете от меня откровенно тупых решений. То есть я увольняю всех умных и оставляю только тупых. Вы действительно думаете, что я умею только вот так работать?
Язык позволяет формулировать новые команды. Таким способом я получаю максимально удобное представление операций. А что там внутри новой команды, в момент использования библиотеки я понимаю, но чаще всего могу просто не думать об этом, потому что знаю, что преобразование в SQL будет достаточно эффективным. Хотя конкретно вам могу объяснить - вы видите, как происходит сбор данных для подготовки SQL, а внутри, уже в момент выполнения запроса, из собранных данных формируется корректный SQL, достаточно эффективный, то есть если нужно получить запись по id, то будет такой результат: select * from table_name where id=?, ну а потом, после получения результата, запись будет скопирована в соответствующую структуру, которая задаётся классом. Итогом будет объект, содержащий данные из запрошенной записи.
И которое не везде применимо. У нас вот не очень
Здесь вы уходите в область вашего представления о разработке. Я вам только замечу - ваше представление не является единственно верным. То есть другие представления могут быть эффективнее. Но что бы доказать это я буду вынужден растягивать эту беседу на очень долгий срок, чего мне не хочется делать. Скажу только коротко, что большая часть задач в теме OLTP (а именно эта часть актуальна и для банка и для кучи других организаций) автоматизируема до уровня "программист вообще не нужен". И без всякого модного ИИ. Другое дело, к счастью для многих программистов, со стороны бизнеса нет достаточного понимания самого себя, что бы эффективно пользоваться такими инструментами. А достигается полезный результат (при условии соответствующего по уровню развития бизнеса) именно переходом на высокие уровни абстракции, которые в RPL вы застрелитесь формулировать.
На самом деле в каждой новой задаче у вас будет свои условия выборки по своим таблицам которая дает свой набор данных
Вот, вот. Условия-то свои, а всё остальное - полностью идентично. Подставляй значения в шаблон и получай радость.
Но вот логика - это основное. Это везде свое. Общих мест не найдете
Найдём. На то и созданы абстракции. Их суть в том, что бы эти общие места находить.
Все структуры формируются в compile time. Дальше туда уже читаются данные
Здесь вы просто не поняли, о чём речь. Классы - это структуры, которые да, формируются при компиляции. И потом наполняются данными во время выполнения программы. Об этом я и говорил.
Идешь и смотришь код - мама дорогая... Какой-то программист-абстракционист писал. Абстракция на абстракции и абстракцией погоняет. Все очень концептуально, но... Работает медленно
Да, можно переусложнить, можно замедлить, можно вообще всё испортить. Но это не значит, что нельзя сделать эффективно. Хотя соглашусь, что эффективно сделать не просто, от того и появляются все перечисленные косяки.
Быстродействие и эффективное использование ресурсов - это то, что тут всех интересует и ценится в первую очередь
Не так. Вы указываете на стандартную ошибку - оптимизацию по простейшему критерию. Вы выбрали критерий - стоимость железа. Допустим ваш сервер стоит миллион долларов. И на него пишут программы суммарно 100 человек (для разных частей АБС). Допустим у них скромная з/п, со всеми накладными (налоги, офис, страховки и т.д.) путь на человека будет 250 т.р. Итого имеем 25 миллионов рублей в месяц, или примерно 3 миллиона долларов в год. Если железо полностью заменяется раз в 5 лет, то расходы на людей в 15 раза больше его стоимости. То есть если сократить затраты труда программистов на 1/15, получим выигрыш в размере стоимости железа. За 5 лет при выделении миллиона долларов на сокращение затрат труда программистов абсолютно реально не то что на 1/15, а весьма вероятно на десятки процентов сократить потребность. Вот вам и пример - вы выбрали ошибочный критерий оптимизации, то есть если бы выбрали критерий "стоимость работы программистов", то получили бы в разы большую экономию.
Одну строчку, примерно как вы её видите. Я немного сократил и переименовал части для большей понятности, а в остальном - именно так и выглядит.
Здесь смысл такой - человечество придумало множество удобств, сокращающих затраты труда программиста. Но пока вы их не прочувствуете на личном опыте, вы не поверите. Надеюсь, что ООП вам знакомо, так вот на его примере мы видим объединение логики со структурами данных, которое даёт нам то самое упрощение. Нам нет необходимости заглядывать внутрь объекта, ведь мы знаем, что всё нужное там уже есть (алгоритмы и данные), поэтому мы просто используем выставленный наружу функционал. Сравните с привычным вам подходом на си - отдельно данные и отдельно функции (алгоритмы). И вам приходится структурировать программу так, что бы ненужные данные не захламляли вашу текущую задачу. А в ООП это структурирование уже выполнено.
И все ваши дальнейшие примеры идут по тому же пути. Вы демонстрируете детали, которые мне просто не нужны в момент решения задачи, поскольку они уже есть и скрыты от меня таким образом, что я могу действительно не задумываться о них. Просто создаю объект, жму точку, IDE показывает список методов, выбираю нужный, и всё - задача решена.
Аналогично, встроенные в RPL средства содержат в себе какую-то логику, которую в них заложили их создатели. Но в тех дополнительных библиотеках, которые вы объявили ненужными, вся эта логика тоже есть, а плюсом к ней идут всяческие дополнения, позволяющие написать запрос, в том числе существенно сложнее показанных ранее, в одну строчку. Вам же приходится бегать по курсору, по сути переходя на уровень обработчика запросов в СУБД. И это всё вы делаете ради экономии на разборе SQL. Но эта экономия ничтожна. В показанном мною первом примере результирующий запрос мог бы выглядеть так: select * from table_name where id=?, или даже так: select id from table_name where id=?, если бы я явно указал список полей. Всё это самые тривиальные запросы, которые планировщик СУБД прекрасно умеет переводить в примерно тот код, который вы написали на RPL. То есть эффективность выполнения запроса будет ровно такая же, как у вас, кроме одного - разбора SQL-выражения. Но такое тривиальное выражение разбирается за микросекунды. Если вы сравните микросекунды со временем загрузки нужной части индекса с диска при поиске, вы поймёте, что экономить эту мелочь просто бессмысленно.
поиск совпадений между адресами клиентов (порядка сотни миллионов адресов) и адресами субъектов списков росфинмониторинга
И это всё тоже эффективно решается на SQL. Если у вас кто-то сумел сделать такое решение неэффективным (выполняется часы), это не значит, что эффективно сделать нельзя. Здесь просто нужно понимать суть алгоритма и то, как работает СУБД. Всё, далее я на SQL дам вам ваши же 15 минут, или даже быстрее. И собственно разбор SQL в СУБД займёт ну пусть даже несколько сот миллисекунд (хотя скорее десятков), но что это в сравнении с 15-ю минутами? И что важно - я это сделаю хоть на IBM i, хоть на любой другой платформе, где есть SQL.
На этом примере очень наглядно становится понятно, почему узкая заточенность на низкоуровневых подходах может вас тормозить. Вы привыкли выжимать всё возможное, но это влечёт за собой переход на низкоуровневые языки, со всей их сложностью, а я же, представляя, как данные обрабатываются на низком уровне, просто укладываю эту обработку в SQL, который и пишется быстрее и ошибок в котором бывает намного меньше.
Хотя стоит признать, что без понимания того, что происходит на низком уровне, действительно можно писать очень неэффективные запросы. Но я всё же ожидаю, что мы обсуждаем тему работы квалифицированного программиста, а не чучела с парой классов образования, но взявшегося писать программы.
Один момент. Здесь нет "подключения к БД". БД - это часть системы. Мы уже "внутри БД"
Вот, вот. Вы опять уходите на уровень деталей реализации, которые в данный момент совсем несущественны. Хотя в реальности, разумеется, существует набор изолированных от вас процессов, выполняющих роль СУБД, и к этим процессам происходит подключение средствами ОС, но вы этого не видите, поскольку подключение скрыто в недрах RPL. Но не суть, главное - вы привыкли видеть низкоуровневые вещи и не можете от них абстрагироваться. Поэтому пишете на RPL там, где вполне можно писать на SQL и быстрее и с меньшим количеством ошибок.
Вот сколько таблиц там у вас? У нас - десятки тысяч объектов (таблиц и индексов). И на все прописывать классы? Извините, но зачем, когда можно работать без этого? Если можно просто прочитать запись как статически описанную структуру и дальше просто работать с ее полями как с обычными переменными?
Ну опять же вы не понимаете, как работают современные средства отображения данных на структуры. Классы - это и есть статическое описание структур данных. То есть те статические структуры, которые вы далее и предлагаете использовать. Единожды описав структуру каждой таблицы, мы получаем, пусть по сотне-двум байт на таблицу, мегабайт-два структур. Сравните это с террабайтами памяти на вашей системе. И посчитайте - какую часть памяти вы сэкономите, если откажетесь от пары мегабайт структур. Мне кажется вывод очевиден.
А теперь представьте, что у вас в распоряжении язык, где все эти типы уже есть
Мне не надо это представлять, сегодня практически в любом языке все типы есть. Другое дело, что они объектные, то есть оборачивают ту же дату в форме long внутрь класса, который уже умеет выдавать вам месяц, год, число и т.д. Да, за счёт расхода памяти на оборачивание мы получаем некоторые издержки, но это же копейки в сравнении с наличными ресурсами. Плюс встроенные средства RPL точно так же обязаны содержать какие-то обёртки над структурой данных, которая в DB2 содержит данные о дате. Так что опять получается никакой существенной выгоды вы от использования RPL не получаете.
То же относится и к формам, упомянутым вами. Вы показали некий формат, который RPL умеет преобразовывать в поля на экране. Но я вам напомню, что в мире есть тысячи подобных форматов. Самый известный - html. И сравните гибкость, предоставляемую разработчику пользовательского интерфейса в современных браузерах с псевдографическими экранами, которые получаются в вашем случае. Пример про модальность именно в сторону этой гибкости и отсылал.
И затраты на написание кода (в части работы с БД и бизнес-логики) на RPG, который специально для этого предназначен, ничуть не выше чем на другом языке с кучей зависимостей, компенсирующих то, чего там нет. Но результат лучше
А здесь я могу сказать одно - вы не пробовали писать по другому. Попробуйте. Вам понравится.
Уже поздно. Мир перейдёт на новую спираль развития с гораздо более мощным интеллектом. Менее мощные интеллекты обречены на роль динозавров.
Возможно ... мы сможем найти решение
Никаких "возможно". Что нам говорил известный китаец про дорогу длинной 1000 китайских единиц измерения длины? Она начинается с одного шага.
Все это знают. И никто ведь не делает этот шаг. Все ждут, что шаг сделают за них. Либо тупо обсуждают очередной детский аттракцион, мол водил детей, но мне тоже понравилось. Вот так и доживут до роли динозавров, играючи. А что, смерть, о которой не подозреваешь, ни разу не напрягает. Правильной дорогой идёте, товарищи дети.
Несколько однобоко. То есть по сути один язык - си, плюс работа с БД от уровня условно нативных функций и в сторону SQL. Ожидаю сильный перекос в сторону преждевременной оптимизации. Это стандартное качество пишущих низкоуровневые программы, не воспринимайте как оскорбление.
Как вы на (любой язык по вкусу) быстро проверите наличие записи в БД для заданного значений ключа
Псевдокод:
If (select.one.from(table).where("id=",xxx)==null) ...
Но вы, разумеется, ожидаете очень быстрое решение (по скорости выполнения). Такова привычка, выработанная десятилетиями низкоуровневого программирования. В данном же случае представлен вариант работы библиотеки, которая в общем случае классифицируется как ORM (object to relational mapping). Смысл существования такой библиотеки - сокращение затрат на написание кода, а не на сокращение потребления ресурсов (включая время). Если код краток и понятен, то его не только можно написать быстро, но в нём так же будет минимум ошибок. Суммарно это даёт повышение скорости разработки, хотя и с ущербом для использования ресурсов.
Но должен заметить, что ресурсы перерасходуются вполне умеренно. В примере выше имеем перерасход памяти сотню-две байт непосредственно в момент исполнения, но после исполнения эти байты освобождаются. По скорости, в сравнении со временем обработки запроса БД (а это обращение к диску), перерасход составляет тысячные доли общих затрат, а то и даже тысячные процента.
Нужно найти записи с минимальным и максимальным значением DTA для заданного ID
Например, на чистом С++, без дополнительных библиотек?
Неправильная постановка задачи. Или вы собрались сами реализовать протокол сетевого взаимодействия вашей СУБД?
Именно библиотеки на порядки ускоряют разработку, ведь не нужно каждый раз писать свою библиотеку, реализующую то, что другие разработчики давно реализовали и вынесли в отдельный компонент, а теперь миллионы других разработчиков просто используют, не думая о запросах, ответах, структурах, буферах и прочей низкоуровневой мелочи.
Хотя ibm i, возможно, предоставляет API для си-разработчиков, выполняющий именно то, что вы просите. Но вы забыли один момент - API кто-то за вас разработал. И включил его в состав вашего ПО. Но включить что-то состав вы можете самостоятельно, без оглядки на кого-то, кто это сделает за вас. Собственно, так поступает сегодня весь мир.
Теперь выгоды встроенного ПО - оно быстрее. Но всё остальное - минусы. У вас нет выбора. Функционал беден в сравнении с массой доступных для других платформ библиотек. Вы полностью зависите от поставщика техники, включая программную составляющую. У вас из-за санкций ещё не отключили что-нибудь важное в сердце вашей системы - в IBM i?
Сколько строк кода вам придется написать чтобы у вас была структура (в которую вы будете читать запись из этой таблицы), соответствующая структуре записи?
Спектр решений здесь примерно такой:
Одна строка - данные подключения к БД - и вы получаете сгенерированные классы со всем необходимым. Вторая строка - select.one.from(table).where("id=",xxx);
Нижняя часть спектра - вы сами пишете низкоуровневые команды и отправляете их через драйвер БД.
Нижняя часть спектра - очень затратное удовольствие ради экономии долей процентов от общих затрат. Хотя в современной массовой разработке, надо признать, многие просто плюют на любые затраты (кроме затрат собственного труда), а потому используют весьма затратные способы работы с БД. Но не от отсутствия эффективных способов, а от лени и непонимания.
с полями БД типа date, time, numeric, decimal - какой язык позволит работать с ними, не создавая в рантайме дополнительных объектов?
Любой язык, в котором есть так называемые "примитивные" типы данных. Правда придётся объявлять даты в БД как long, например. Но это если уж мы настолько зажаты в тиски, что даже на объект, оборачивающий long, у нас нет памяти. Мне жаль программистов, которым для решения бизнес-задач выдают что-то вроде IBM PC AT 286.
Зачем?
IBM, на самом-то деле, создала много интересных решений. И в случае с AS 400 я вижу хорошо масштабируемый подход, объединяющий вертикальное и горизонтальное масштабирование. Но не было возможности почувствовать его мощь.
Например?
ORM, Web, ESB. Это минимум, но есть много частных случаев с различными удобными библиотеками.
Вот возьмём web. Как вы обеспечиваете модальность в своих клиентских терминалах? Модальность, это запрет на переход ко всем UI элементам, кроме заданного набора. Вы вынуждены перерисовывать окно терминала и располагать в нём только доступное. Но, например, когда вам нужно просто сказать, что пользователь ошибся, вам придётся закрыть те поля, где он ввёл ерунду. Я уж не говорю про подсвечивание этих полей без всякого отвлечения пользователя на всплывающие диалоги. То есть это вообще проблема псевдографических интерфейсов, хотя вы, скорее всего, ответите, что вашим пользователям ни к чему удобства, может другими словами, мол они привыкли и т.д., но суть именно такая - нет удобств и не будет.
Откуда такое утверждение?
Из вашего списка.
Какие рекомендации? О каких "технологиях" идет речь?
Я же говорю - IBM много чего полезного придумали. Но в вашем случае низкоуровневый подход, похоже, закрывает от вам общую картину.
А вы имели опыт разработки (хотя бы более года) на чём-то другом что бы корректно делать выводы про "все необходимое уже есть в самом языке"?
Мне интересно сравнить концепт от IBM с остальным миром. Внутренняя интеграция, конечно, хорошо, но кому нужна производительность, если за неё нужно платить разработкой на ассемблере? Это востребовано в очень узких нишах.
Вы пишете, что отказались от Java, то есть отказались от кучи продуктов, выполняющих за вас кучу задач. И даже какой-нибудь Message Broker не используете, хотя есть MQ. Поэтому интересно - насколько далеко вы находитесь от рекомендаций IBM по выбору используемых технологий? Сами всё выбирали?
По самой i подскажите. Там DB2 всё ещё есть? А Java? Оно у вас не используется? На какой технологии у вас работают клиентские места? Telnet? Если веб, то что запросы обрабатывает? В каком виде получаются запросы (байтовый буфер?)?
Как вообще там с отсталостью программных технологий? Если вы пишете на си, тем более на такой редкой платформе, то у вас просто не должно быть в наличии полезных для бизнеса вещей вроде кучи фреймворков для других языков. Вы всё с нуля ваяете сами?
К сожалению, тема архитектуры в ИТ отдана на откуп дизайнеров, которые художники, литераторы, но никак не инженеры.
Каков смысл статьи? Это просто перечисление. Вот такой вот список содержит истину. Всё, если не выучил - досвидания. Если вызубрил - станешь архитектором. Но где здесь инженерный подход?
Инженеры гарантируют что-то в своих конструкциях доказуемо, то расчётами и ссылками на данные об известных экспериментах. Как гарантируют что-то "архитекторы" (которые художники)? Вот так:
Конструируя системы с учетом высокой доступности, разработчики способны гарантировать длительную стабильность и доступность сервисов
То есть они гарантируют, что они способны. Очень надёжная гарантия!
Или вот ещё:
Для оценки надежности часто используются такие показатели, как среднее время между отказами
Ну ведь прекрасно! Дом стоит сто лет - он надёжен! А вот самолёт непрерывно летает всего несколько часов, а потом его надо обслуживать. Он ненадёжен (по мнению архитекторов), ведь среднее время между отказами в сложной системе на порядки меньше, чем в простой. Значит архитектор всегда выберет надёжное решение - дом, который не то что летать, двигаться не сможет. Да, это решение с высокой надёжностью (в сравнении с самолётом), но решает ли оно проблемы заказчика? По критерию, выбранному архитекторами - оно прекрасно решает все возможные проблемы.
Или вот так они голосуют за безопасность:
применение лучших практик для предотвращения неавторизованного доступа, утечек данных, вредоносных воздействий и прочих рисков
В списке для презентации заказчику указаны "лучшие практики"? Указаны, аж две или три штуки! Всё, мы в безопасности!
И так же во всём остальном:
Паттерны проектирования в области системных разработок представляют собой проверенные и широко применяемые решения
Слизал стандартное решение у соседа - молодец! Оно проверено и широко применяется. Ну и что, если другие давно в кроссовках ходят вместо лаптей, зато лапти проверены тысячами лет эксплуатации!
Вы скажете ,что в лаптях неудобно бегать? Не проблема. Архитектор вам ответит вот так:
Производительность в контексте системного проектирования обозначает способность программной системы быстро и эффективно обрабатывать данные
То есть в лаптях тоже можно быстро и эффективно что-то обрабатывать. А насколько быстро? Это уже вопрос не к архитектору, он за свою работу (в основном языком) деньги уже честно получил.
Как-то так и получается в итоге, что в стране 900 000 (почти миллион, да) программистов, а автоматизацией пока лишь пугают, поскольку до завершения этого прибыльного процесса ещё очень и очень далеко. Зато сколько на такую орду нужно архитекторов!
Рецензия, очевидно, дана лишь для отписки. Для нашей реальности это ожидаемо. Но тем не менее - вопрос об отказе от данной схемы наверняка рассматривался не только ленивыми рецензентами. И скорее всего были обнаружены какие-то существенные недостатки схемы. Какие? На этот вопрос следует доказательно ответить. Либо доказать, что недостатки можно обойти, либо признать своё поражение.
Вызывает подозрение КПД установки. Первый же ответ на тему КПД показывает нам ничтожное соотношение потраченной химической энергии и полученной кинетической.
Для внесения ясности необходимо кратко описать этапы преобразования энергии в системе и сравнить суммарные потери энергии с обычной турбиной. Вы в статье попытались сделать что-то подобное, но собственно энергетический баланс вами показан не был. Возможно, это и послужило поводом для отрицательной рецензии в проблемах энергетики.
Сделайте же главное - покажите, откуда возьмётся экономия энергии в сравнении с ГТУ. Сделать это нужно именно коротко - энергия на входе равна, этап I - энергия понизилась на столько, этап II - энергия понизилась на столько, завершающий этап - энергия равна тому-то. Это простейшую схему поймёт любой школьник, но её-то у вас и нет. Пока её не будет - рецензии будут отрицательными. Ну а при наличии, возможно, вы сами убедитесь в бесперспективности идеи.
КПД модифицированной турбины Герона стремится к величине 60%, что сопоставимо со значением для установок, работающих по комбинированному циклу
Почему авторский вариант нельзя использовать по комбинированному циклу? И если можно, то зачем некорректно сравнивать разные КПД?
Ну и с другой стороны - почему выбранная схема была отвергнута вот уже в течении 2000 лет? Наверно что-то мешало? Как минимум, последние 100 лет. Что же мешало?
Профсоюз нельзя понимать узко. Обособленная банда, выбивающая выгоду за счёт окружающих - разве это хорошо? Ну ладно, лично для главаря много денег - это хорошо. Но кто сказал, что для остальных бандитов будет повышение зарплаты? Только надежда.
Другой случай - союз наёмных работников вообще, то есть всех. Сил у такой банды будет побольше. Зарплаты реально поднимутся. Но запашок по прежнему останется.
И третий случай - реальная защита прав большинства. В чём отличия от банды? В том, что банда живёт ради эгоизма. Эгоизм, в первую очередь, поднимает наверх самых отъявленных эгоистов. И они себе делают много денег. Что останется - бандитам. Ну а большинству предложат пососать лапу.
Реальная защита большинства вместо сосания лапы предложит реальное улучшение жизни именно большинства. Именно поэтому акцент делается на слове реальная. В условиях профсоюзов, государств современного вида, прочих эгоистических организаций, защита большинства исключительно декларативная. Поскольку главенствующим принципом жизни общества является возвеличивание эгоизма во всех проявлениях, именно самые эгоистичные и пролезают на самый верх. И разумеется, только они и снимают сливки.
Поэтому для реальной защиты большинства следует, в первую очередь, изменить определяющий ценность человека во властной вертикали принцип.
Но, с другой стороны, каждый конкретный член большинства точно так же является эгоистом (эволюционно выработанное качество). Хотя чем человек ниже в социальной иерархии, тем ему проще отказаться от эгоизма волевым усилием. Просто потому, что чем ниже, тем меньше будет потеря при таком отказе. Плюс чем ниже, тем сильнее влияние окружения на человека, тем глубже доходит смыл понятия совесть.
Но, опять же, чем ниже, тем менее готов человек к сложным действиям по качественному управлению в требуемой общественной организации. Плюс чаще всего он не понимает последствий такого массового явления, как популизм.
В результате имеем эгоистов наверху и пассивную неграмотную массу внизу (почти в прямом смысле "быдло", к сожалению).
Вот здесь и нужен профсоюз в качестве воспитателя пассивного большинства. Способов много, но только при условии отсутствия эгоизма у стоящих близко к власти в профсоюзе. Хотя им, опять же, будут мешать пассивность и безграмотность. Поэтому большинство профсоюзов заканчивают в отстойной яме истории - лидеры продаются (эгоизм побеждает), тупят (безграмотность), ну и просто ничего не делают (пассивность).
То есть у затопленной струи нет никакого снижения давления в поперечном направление.
В домах вентиляцию делают так - крышка над трубой, которая экранирует подсасывающий эффект воздушной струи сверху. Поэтому подсасывающий эффект снизу при наличии ветра создаёт тягу в вентиляционном канале. Это факт, независимый от идеальной жидкости. Рассмотрите внимательнее конусы и сопла в вами же рассматриваемой конструкции, где там крышка над трубой? Она там есть, поэтому и эффект есть.
Расширение струи воды за счёт давления пара при "кавитации" конечно можно учитывать, только при аккуратном расчёте вам не удастся расшвырять струю в стороны
Обратите внимание на ваши собственные иллюстрации за номерами 18 и 22. Всё там почему-то "расшвыривается" в стороны.
Ну, а лично меня эти теории ниразу не устраивают, так как они мне ничего не объясняют, а лишь пудрят мне мозги заумью
Вам выше подсказали - укажите на подтверждаемые экспериментом противоречия фактов и общепринятых теорий. И ещё лучше - дайте свои формулы, которые указанное противоречие снимают. Но как-то ваш спор выше не показал наличия конструктива в вашем подходе.
Заказ такси не могут одновременно делать миллионы человек, потому что населения на земле для таких масштабов не хватит.
Значит система явно перегружена внутренними коммуникациями. Но что это за коммуникации? Ответ прост - микросервисы. Вместо пусть миллиона в секунду (и то много) имеем на пару порядков больше.
Но как происходит отсос воздуха в этой конструкции?
Вообще-то при движении жидкости/газа вдоль поверхности, параллельной потоку, давление на поверхность уменьшается в сравнении с давлением на плоскость, перпендикулярную потоку, чем пользуются при измерении скорости воздушных/водных судов относительно среды.
Вот это уменьшение давления и "подсасывает" воздух в конструкции. А если добавить кавитацию, то струя будет расширяться за счёт давления пара, после чего соприкоснётся со стенками и превратится в банальный поршень, всасывающий всё, что находится за ним.
То есть объяснить явление можно без проблем для существующих теорий.
Первое устраняется принятием в команду грамотного специалиста. Второе устраняется принуждением написать два варианта - SQL и ORM, с полным пониманием, как оно внутри работает. Второй вариант обычно показывает, что понимания примерно столько же, сколько в варианте №1.
Вывод - вся критика ORM исходит от непонимания. И от нежелания понимать (это про фанатов чистого SQL в первую очередь).
Да, необходимость напрячься и изучить ORM, действительно идёт вразрез с общепринятой парадигмой ничегонеделанья за большие деньги, но всё же надо когда-то начинать. И учесть, что ORM - это лишь один из множества требуемых шагов. Дальше придётся учить ещё много чего.
В эпоху засилья микросервисного подхода, когда для получения данных из БД пихается сообщение в кафку, которая находит один из тысячи микросервисов, ответственный за выполнение select * from table1, затем отдаёт сообщение микросервису, который уже через сотню фасадов и прочего нагромождения (включая ORM) наконец где-то глубоко в недоступных потрохах передаёт SQL в одну из сотен баз данных (ага, по БД на микросервис), действительно оказывается, что добавление ORM к этому монстроидальному зоопарку ничего не меняет, кроме одного важного момента - без ORM нельзя копипастить готовые шаблоны простейших действий из интернета. Что возвращает нас опять к началу - мы имеем засилье самых примитивных погромистов вместо действительно необходимых специалистов.
Взглянув на такую схему получения данных из БД, пишущие на SQL действительно хватаются за голову и начинают ломать вокруг себя все 4-5 мониторов, которыми окружены как модница приблудами для покраски ногтей. Но граждане, вы не туда смотрите! Точнее - вы видите собачий бред, позволяющий за приложения уровня Hello World получать миллиарды денег. Но ORM здесь не при делах! Неуиноатый он, вот так.
ORM действительно ускоряет разработку. Но не модную, а эффективную. И если вам по жизни не повезло и вы не встречали на трудовом пути эффективные решения с ORM, то хотя бы не вставайте сразу в позу отрицания и вспомните, что в мире есть решения без микросервисов, кафки и прочего лютого треша. И это значит, что вы прошли мимо этих эффективных решений. Что в свою очередь означает - вам ещё учиться, учиться и учиться, много лет. Но ORM в этом не виноват. Это просто вам не повезло. Хотя знайте - так же как и вам не повезло ещё 95% погромистов, потому что когда на каждый приличный банк приходится по 1000 разработчиков, это означает, что 50 из них реально нужны, а 950 - всего лишь перекладывают json-ы из кафки в микросервисы, не создавая при этом ничего полезного с точки зрения логики бизнес-процесса. Так что сломайте свои мониторы не злобы ради, но понимания для. Поймите - инструмент ORM не виноват, а виноваты... ну вот такие у нас социальные условия, таков метод производства общественного продукта.
Вы, опять же, можете лично спросить ChatGPT. Мне он заявил, что знает больше десятка форматов, я выбрал ARIS, он нарисовал. Смысл нарисованного вполне понятен. Возможно, поскольку чат русскоязычный, он перевёл все xml-тэги на русский. Но всё это вы сами можете узнать у него.
Вы подключаете к вашему мессенджеру плагин, проверяющий степень доверия собеседнику через сеть доверия
На этом пункте всё ломается.
Кто напишет плагин? Кто будет хостить сеть доверия? Кто будет перехватывать трафик сети? Кто будет подменять в своих интересах все необходимые ему данные?
В существующей ситуации, когда есть власть, обладающая всеми необходимыми ресурсами для контроля всех узлов сети, начиная с контроля компьютеров/смартфонов большинства пользователей, любая хитрая сеть не стоит ничего.
Кроме того, привычки населения таковы, что в предложенной сети будут участвовать лишь единицы. Но чем меньше участников - тем меньше усилий требуется от власти для обретения полного контроля.
Реальное решение затронутой проблемы одно - организация общества на существенно других принципах. Пока во всех существующих странах главными являются заинтересованные в удовлетворении исключительно личных потребностей люди - никакие сети доверия им не страшны, поскольку за ваши деньги (в виде налогов) они купят все необходимые средства контроля.
Вам самому лень попробовать? Это доступно в РФ, причём бесплатно, нужно всего лишь научиться пользоваться гуглом.
Вот маленький пример генерации:
scss
eEPC
Function Покупка на кассе
Start (Круг)
-> Подойти к кассе (Функция)
-> Провер��ть наличие штрих-кода (Функция) [Да/Нет]
-> Да (Переход) ->Считать штрих-код (Функция)
-> Нет (Переход) -> Найти товар в списке (Функция)
-> Наполнить списокк ��п��ате (Функция)
-> Нап��ч��тать чек (Функция)
-> Получить деньги (Функция)
End (Круг)
Здесь редактор решил, что язык называется scss, но я просил у чата язык ARIS.
Вот это довольно показательный момент. Он суммирует наш разговор. Вместо быстрого решения задач вам приходится думать о быстрой работе компьютера. Про стоимость работы программиста я вам писал, но раз вам "предъявляют" за минимальные попытки ускорить написание программ, то здесь я уже не могу помочь. Выбор в сторону оптимизации скорости исполнения сделан не вами, но вы его полностью приняли и отказываетесь воспринимать альтернативы. 10% по вашему очень много. Ну ладно, я вам писал про в 15 раз дороже в случае сравнения стоимости компьютера и труда. Это тоже вас не заинтересовало. Но чем тогда вас убеждать?
Вот совсем коротко:
Труд дороже железа. Доказать пытался, но не вышло.
Бой за 10% ускорения стоит в разы дороже, чем решение той же задачи без ускорения на 10%. Опять пытался доказать, но не получилось.
Что ещё сказать? Я не знаю.
Оттуда же, откуда знаю, как решать квадратное уравнение. В математике такие вещи доказывают. В программировании это все по разному называют, я бы назвал - качественное проектирование.
Я не говорил, что стандартный инструмент во всех случаях лучше. Я говорил, что он во многих случаях (в большинстве случаев) экономит усилия программиста при достаточно эффективном результате. Достаточно эффективный, это такой, когда нет смысла экономить миллисекунды при времени исполнения минуты.
Эта структура - класс. С накладными расходами в виде конструктора и чего-то ещё. Теперь математика: время чтения с диска, пусть будет SSD, положим 1 миллисекунда, затем преобразование в нужную нам структуру. За миллисекунду пусть прочитали 100 килобайт по сто байт структур (это пиковая, редко в реальности достижимая скорость выборки строго нужных данных). То есть всего 1000 структур. Время выполнения конструктора и прочего для каждой структуры - пусть 100 наносекунд, хотя всё это в кэшах и в цикле, так что процессор много чего может оптимизировать. Итого имеем 100 микросекунд на всё. Всего имеем примерно 10% затрат на конструкторы и 90% на чтение. Далее напишите всю обработку вручную, вместо одной строчки, как я показывал. Сравните свои затраты с моими. Получите в 100 раз больше, чем у меня. Вспомните про стоимость программистов.
Есть всего лишь эффективные и неэффективные решения. Разница определяется расчётом. Это просто математика. Её вполне способен считать компьютер.
Всё это шаблон. Шаблон такой: отображение, фильтрация, вычисление, запись данных. План запроса в каждом случае я вам вычислять не буду, это трудоёмко, но единожды написав программу вычисления подобных планов запроса, я автоматизирую все ваши ситуации. Хотя заранее признаю, что план запроса может быть по каким-то критериям неоптимальный. Так что вы, в каких-то случаях, сможете опередить мой планировщик. Но в некоторых случаях даже вы не сможете его победить.
А теперь вспомните, сколько времени вы потратили на решение этих задач. Сравните с программистом, который пользуется оптимизатором, работающим за него. Ну и снова вспомните стоимость труда программиста.
Ну вы ожидаете от меня откровенно тупых решений. То есть я увольняю всех умных и оставляю только тупых. Вы действительно думаете, что я умею только вот так работать?
Язык позволяет формулировать новые команды. Таким способом я получаю максимально удобное представление операций. А что там внутри новой команды, в момент использования библиотеки я понимаю, но чаще всего могу просто не думать об этом, потому что знаю, что преобразование в SQL будет достаточно эффективным. Хотя конкретно вам могу объяснить - вы видите, как происходит сбор данных для подготовки SQL, а внутри, уже в момент выполнения запроса, из собранных данных формируется корректный SQL, достаточно эффективный, то есть если нужно получить запись по id, то будет такой результат: select * from table_name where id=?, ну а потом, после получения результата, запись будет скопирована в соответствующую структуру, которая задаётся классом. Итогом будет объект, содержащий данные из запрошенной записи.
Здесь вы уходите в область вашего представления о разработке. Я вам только замечу - ваше представление не является единственно верным. То есть другие представления могут быть эффективнее. Но что бы доказать это я буду вынужден растягивать эту беседу на очень долгий срок, чего мне не хочется делать. Скажу только коротко, что большая часть задач в теме OLTP (а именно эта часть актуальна и для банка и для кучи других организаций) автоматизируема до уровня "программист вообще не нужен". И без всякого модного ИИ. Другое дело, к счастью для многих программистов, со стороны бизнеса нет достаточного понимания самого себя, что бы эффективно пользоваться такими инструментами. А достигается полезный результат (при условии соответствующего по уровню развития бизнеса) именно переходом на высокие уровни абстракции, которые в RPL вы застрелитесь формулировать.
Вот, вот. Условия-то свои, а всё остальное - полностью идентично. Подставляй значения в шаблон и получай радость.
Найдём. На то и созданы абстракции. Их суть в том, что бы эти общие места находить.
Здесь вы просто не поняли, о чём речь. Классы - это структуры, которые да, формируются при компиляции. И потом наполняются данными во время выполнения программы. Об этом я и говорил.
Да, можно переусложнить, можно замедлить, можно вообще всё испортить. Но это не значит, что нельзя сделать эффективно. Хотя соглашусь, что эффективно сделать не просто, от того и появляются все перечисленные косяки.
Не так. Вы указываете на стандартную ошибку - оптимизацию по простейшему критерию. Вы выбрали критерий - стоимость железа. Допустим ваш сервер стоит миллион долларов. И на него пишут программы суммарно 100 человек (для разных частей АБС). Допустим у них скромная з/п, со всеми накладными (налоги, офис, страховки и т.д.) путь на человека будет 250 т.р. Итого имеем 25 миллионов рублей в месяц, или примерно 3 миллиона долларов в год. Если железо полностью заменяется раз в 5 лет, то расходы на людей в 15 раза больше его стоимости. То есть если сократить затраты труда программистов на 1/15, получим выигрыш в размере стоимости железа. За 5 лет при выделении миллиона долларов на сокращение затрат труда программистов абсолютно реально не то что на 1/15, а весьма вероятно на десятки процентов сократить потребность. Вот вам и пример - вы выбрали ошибочный критерий оптимизации, то есть если бы выбрали критерий "стоимость работы программистов", то получили бы в разы большую экономию.
Одну строчку, примерно как вы её видите. Я немного сократил и переименовал части для большей понятности, а в остальном - именно так и выглядит.
Здесь смысл такой - человечество придумало множество удобств, сокращающих затраты труда программиста. Но пока вы их не прочувствуете на личном опыте, вы не поверите. Надеюсь, что ООП вам знакомо, так вот на его примере мы видим объединение логики со структурами данных, которое даёт нам то самое упрощение. Нам нет необходимости заглядывать внутрь объекта, ведь мы знаем, что всё нужное там уже есть (алгоритмы и данные), поэтому мы просто используем выставленный наружу функционал. Сравните с привычным вам подходом на си - отдельно данные и отдельно функции (алгоритмы). И вам приходится структурировать программу так, что бы ненужные данные не захламляли вашу текущую задачу. А в ООП это структурирование уже выполнено.
И все ваши дальнейшие примеры идут по тому же пути. Вы демонстрируете детали, которые мне просто не нужны в момент решения задачи, поскольку они уже есть и скрыты от меня таким образом, что я могу действительно не задумываться о них. Просто создаю объект, жму точку, IDE показывает список методов, выбираю нужный, и всё - задача решена.
Аналогично, встроенные в RPL средства содержат в себе какую-то логику, которую в них заложили их создатели. Но в тех дополнительных библиотеках, которые вы объявили ненужными, вся эта логика тоже есть, а плюсом к ней идут всяческие дополнения, позволяющие написать запрос, в том числе существенно сложнее показанных ранее, в одну строчку. Вам же приходится бегать по курсору, по сути переходя на уровень обработчика запросов в СУБД. И это всё вы делаете ради экономии на разборе SQL. Но эта экономия ничтожна. В показанном мною первом примере результирующий запрос мог бы выглядеть так: select * from table_name where id=?, или даже так: select id from table_name where id=?, если бы я явно указал список полей. Всё это самые тривиальные запросы, которые планировщик СУБД прекрасно умеет переводить в примерно тот код, который вы написали на RPL. То есть эффективность выполнения запроса будет ровно такая же, как у вас, кроме одного - разбора SQL-выражения. Но такое тривиальное выражение разбирается за микросекунды. Если вы сравните микросекунды со временем загрузки нужной части индекса с диска при поиске, вы поймёте, что экономить эту мелочь просто бессмысленно.
И это всё тоже эффективно решается на SQL. Если у вас кто-то сумел сделать такое решение неэффективным (выполняется часы), это не значит, что эффективно сделать нельзя. Здесь просто нужно понимать суть алгоритма и то, как работает СУБД. Всё, далее я на SQL дам вам ваши же 15 минут, или даже быстрее. И собственно разбор SQL в СУБД займёт ну пусть даже несколько сот миллисекунд (хотя скорее десятков), но что это в сравнении с 15-ю минутами? И что важно - я это сделаю хоть на IBM i, хоть на любой другой платформе, где есть SQL.
На этом примере очень наглядно становится понятно, почему узкая заточенность на низкоуровневых подходах может вас тормозить. Вы привыкли выжимать всё возможное, но это влечёт за собой переход на низкоуровневые языки, со всей их сложностью, а я же, представляя, как данные обрабатываются на низком уровне, просто укладываю эту обработку в SQL, который и пишется быстрее и ошибок в котором бывает намного меньше.
Хотя стоит признать, что без понимания того, что происходит на низком уровне, действительно можно писать очень неэффективные запросы. Но я всё же ожидаю, что мы обсуждаем тему работы квалифицированного программиста, а не чучела с парой классов образования, но взявшегося писать программы.
Вот, вот. Вы опять уходите на уровень деталей реализации, которые в данный момент совсем несущественны. Хотя в реальности, разумеется, существует набор изолированных от вас процессов, выполняющих роль СУБД, и к этим процессам происходит подключение средствами ОС, но вы этого не видите, поскольку подключение скрыто в недрах RPL. Но не суть, главное - вы привыкли видеть низкоуровневые вещи и не можете от них абстрагироваться. Поэтому пишете на RPL там, где вполне можно писать на SQL и быстрее и с меньшим количеством ошибок.
Ну опять же вы не понимаете, как работают современные средства отображения данных на структуры. Классы - это и есть статическое описание структур данных. То есть те статические структуры, которые вы далее и предлагаете использовать. Единожды описав структуру каждой таблицы, мы получаем, пусть по сотне-двум байт на таблицу, мегабайт-два структур. Сравните это с террабайтами памяти на вашей системе. И посчитайте - какую часть памяти вы сэкономите, если откажетесь от пары мегабайт структур. Мне кажется вывод очевиден.
Мне не надо это представлять, сегодня практически в любом языке все типы есть. Другое дело, что они объектные, то есть оборачивают ту же дату в форме long внутрь класса, который уже умеет выдавать вам месяц, год, число и т.д. Да, за счёт расхода памяти на оборачивание мы получаем некоторые издержки, но это же копейки в сравнении с наличными ресурсами. Плюс встроенные средства RPL точно так же обязаны содержать какие-то обёртки над структурой данных, которая в DB2 содержит данные о дате. Так что опять получается никакой существенной выгоды вы от использования RPL не получаете.
То же относится и к формам, упомянутым вами. Вы показали некий формат, который RPL умеет преобразовывать в поля на экране. Но я вам напомню, что в мире есть тысячи подобных форматов. Самый известный - html. И сравните гибкость, предоставляемую разработчику пользовательского интерфейса в современных браузерах с псевдографическими экранами, которые получаются в вашем случае. Пример про модальность именно в сторону этой гибкости и отсылал.
А здесь я могу сказать одно - вы не пробовали писать по другому. Попробуйте. Вам понравится.
Уже поздно. Мир перейдёт на новую спираль развития с гораздо более мощным интеллектом. Менее мощные интеллекты обречены на роль динозавров.
Никаких "возможно". Что нам говорил известный китаец про дорогу длинной 1000 китайских единиц измерения длины? Она начинается с одного шага.
Все это знают. И никто ведь не делает этот шаг. Все ждут, что шаг сделают за них. Либо тупо обсуждают очередной детский аттракцион, мол водил детей, но мне тоже понравилось. Вот так и доживут до роли динозавров, играючи. А что, смерть, о которой не подозреваешь, ни разу не напрягает. Правильной дорогой идёте, товарищи дети.
Несколько однобоко. То есть по сути один язык - си, плюс работа с БД от уровня условно нативных функций и в сторону SQL. Ожидаю сильный перекос в сторону преждевременной оптимизации. Это стандартное качество пишущих низкоуровневые программы, не воспринимайте как оскорбление.
Псевдокод:
If (select.one.from(table).where("id=",xxx)==null) ...
Но вы, разумеется, ожидаете очень быстрое решение (по скорости выполнения). Такова привычка, выработанная десятилетиями низкоуровневого программирования. В данном же случае представлен вариант работы библиотеки, которая в общем случае классифицируется как ORM (object to relational mapping). Смысл существования такой библиотеки - сокращение затрат на написание кода, а не на сокращение потребления ресурсов (включая время). Если код краток и понятен, то его не только можно написать быстро, но в нём так же будет минимум ошибок. Суммарно это даёт повышение скорости разработки, хотя и с ущербом для использования ресурсов.
Но должен заметить, что ресурсы перерасходуются вполне умеренно. В примере выше имеем перерасход памяти сотню-две байт непосредственно в момент исполнения, но после исполнения эти байты освобождаются. По скорости, в сравнении со временем обработки запроса БД (а это обращение к диску), перерасход составляет тысячные доли общих затрат, а то и даже тысячные процента.
Object dates[] = select.one.fields("min(dta),max(dta)").from(table).where("id=",xxx).groupBy("id");
Неправильная постановка задачи. Или вы собрались сами реализовать протокол сетевого взаимодействия вашей СУБД?
Именно библиотеки на порядки ускоряют разработку, ведь не нужно каждый раз писать свою библиотеку, реализующую то, что другие разработчики давно реализовали и вынесли в отдельный компонент, а теперь миллионы других разработчиков просто используют, не думая о запросах, ответах, структурах, буферах и прочей низкоуровневой мелочи.
Хотя ibm i, возможно, предоставляет API для си-разработчиков, выполняющий именно то, что вы просите. Но вы забыли один момент - API кто-то за вас разработал. И включил его в состав вашего ПО. Но включить что-то состав вы можете самостоятельно, без оглядки на кого-то, кто это сделает за вас. Собственно, так поступает сегодня весь мир.
Теперь выгоды встроенного ПО - оно быстрее. Но всё остальное - минусы. У вас нет выбора. Функционал беден в сравнении с массой доступных для других платформ библиотек. Вы полностью зависите от поставщика техники, включая программную составляющую. У вас из-за санкций ещё не отключили что-нибудь важное в сердце вашей системы - в IBM i?
Спектр решений здесь примерно такой:
Одна строка - данные подключения к БД - и вы получаете сгенерированные классы со всем необходимым. Вторая строка - select.one.from(table).where("id=",xxx);
Нижняя часть спектра - вы сами пишете низкоуровневые команды и отправляете их через драйвер БД.
Нижняя часть спектра - очень затратное удовольствие ради экономии долей процентов от общих затрат. Хотя в современной массовой разработке, надо признать, многие просто плюют на любые затраты (кроме затрат собственного труда), а потому используют весьма затратные способы работы с БД. Но не от отсутствия эффективных способов, а от лени и непонимания.
Любой язык, в котором есть так называемые "примитивные" типы данных. Правда придётся объявлять даты в БД как long, например. Но это если уж мы настолько зажаты в тиски, что даже на объект, оборачивающий long, у нас нет памяти. Мне жаль программистов, которым для решения бизнес-задач выдают что-то вроде IBM PC AT 286.
IBM, на самом-то деле, создала много интересных решений. И в случае с AS 400 я вижу хорошо масштабируемый подход, объединяющий вертикальное и горизонтальное масштабирование. Но не было возможности почувствовать его мощь.
ORM, Web, ESB. Это минимум, но есть много частных случаев с различными удобными библиотеками.
Вот возьмём web. Как вы обеспечиваете модальность в своих клиентских терминалах? Модальность, это запрет на переход ко всем UI элементам, кроме заданного набора. Вы вынуждены перерисовывать окно терминала и располагать в нём только доступное. Но, например, когда вам нужно просто сказать, что пользователь ошибся, вам придётся закрыть те поля, где он ввёл ерунду. Я уж не говорю про подсвечивание этих полей без всякого отвлечения пользователя на всплывающие диалоги. То есть это вообще проблема псевдографических интерфейсов, хотя вы, скорее всего, ответите, что вашим пользователям ни к чему удобства, может другими словами, мол они привыкли и т.д., но суть именно такая - нет удобств и не будет.
Из вашего списка.
Я же говорю - IBM много чего полезного придумали. Но в вашем случае низкоуровневый подход, похоже, закрывает от вам общую картину.
Спасибо, понятно.
А вы имели опыт разработки (хотя бы более года) на чём-то другом что бы корректно делать выводы про "все необходимое уже есть в самом языке"?
Мне интересно сравнить концепт от IBM с остальным миром. Внутренняя интеграция, конечно, хорошо, но кому нужна производительность, если за неё нужно платить разработкой на ассемблере? Это востребовано в очень узких нишах.
Вы пишете, что отказались от Java, то есть отказались от кучи продуктов, выполняющих за вас кучу задач. И даже какой-нибудь Message Broker не используете, хотя есть MQ. Поэтому интересно - насколько далеко вы находитесь от рекомендаций IBM по выбору используемых технологий? Сами всё выбирали?
По самой i подскажите. Там DB2 всё ещё есть? А Java? Оно у вас не используется? На какой технологии у вас работают клиентские места? Telnet? Если веб, то что запросы обрабатывает? В каком виде получаются запросы (байтовый буфер?)?
Как вообще там с отсталостью программных технологий? Если вы пишете на си, тем более на такой редкой платформе, то у вас просто не должно быть в наличии полезных для бизнеса вещей вроде кучи фреймворков для других языков. Вы всё с нуля ваяете сами?
К сожалению, тема архитектуры в ИТ отдана на откуп дизайнеров, которые художники, литераторы, но никак не инженеры.
Каков смысл статьи? Это просто перечисление. Вот такой вот список содержит истину. Всё, если не выучил - досвидания. Если вызубрил - станешь архитектором. Но где здесь инженерный подход?
Инженеры гарантируют что-то в своих конструкциях доказуемо, то расчётами и ссылками на данные об известных экспериментах. Как гарантируют что-то "архитекторы" (которые художники)? Вот так:
То есть они гарантируют, что они способны. Очень надёжная гарантия!
Или вот ещё:
Ну ведь прекрасно! Дом стоит сто лет - он надёжен! А вот самолёт непрерывно летает всего несколько часов, а потом его надо обслуживать. Он ненадёжен (по мнению архитекторов), ведь среднее время между отказами в сложной системе на порядки меньше, чем в простой. Значит архитектор всегда выберет надёжное решение - дом, который не то что летать, двигаться не сможет. Да, это решение с высокой надёжностью (в сравнении с самолётом), но решает ли оно проблемы заказчика? По критерию, выбранному архитекторами - оно прекрасно решает все возможные проблемы.
Или вот так они голосуют за безопасность:
В списке для презентации заказчику указаны "лучшие практики"? Указаны, аж две или три штуки! Всё, мы в безопасности!
И так же во всём остальном:
Слизал стандартное решение у соседа - молодец! Оно проверено и широко применяется. Ну и что, если другие давно в кроссовках ходят вместо лаптей, зато лапти проверены тысячами лет эксплуатации!
Вы скажете ,что в лаптях неудобно бегать? Не проблема. Архитектор вам ответит вот так:
То есть в лаптях тоже можно быстро и эффективно что-то обрабатывать. А насколько быстро? Это уже вопрос не к архитектору, он за свою работу (в основном языком) деньги уже честно получил.
Как-то так и получается в итоге, что в стране 900 000 (почти миллион, да) программистов, а автоматизацией пока лишь пугают, поскольку до завершения этого прибыльного процесса ещё очень и очень далеко. Зато сколько на такую орду нужно архитекторов!
Рецензия, очевидно, дана лишь для отписки. Для нашей реальности это ожидаемо. Но тем не менее - вопрос об отказе от данной схемы наверняка рассматривался не только ленивыми рецензентами. И скорее всего были обнаружены какие-то существенные недостатки схемы. Какие? На этот вопрос следует доказательно ответить. Либо доказать, что недостатки можно обойти, либо признать своё поражение.
Вызывает подозрение КПД установки. Первый же ответ на тему КПД показывает нам ничтожное соотношение потраченной химической энергии и полученной кинетической.
Для внесения ясности необходимо кратко описать этапы преобразования энергии в системе и сравнить суммарные потери энергии с обычной турбиной. Вы в статье попытались сделать что-то подобное, но собственно энергетический баланс вами показан не был. Возможно, это и послужило поводом для отрицательной рецензии в проблемах энергетики.
Сделайте же главное - покажите, откуда возьмётся экономия энергии в сравнении с ГТУ. Сделать это нужно именно коротко - энергия на входе равна, этап I - энергия понизилась на столько, этап II - энергия понизилась на столько, завершающий этап - энергия равна тому-то. Это простейшую схему поймёт любой школьник, но её-то у вас и нет. Пока её не будет - рецензии будут отрицательными. Ну а при наличии, возможно, вы сами убедитесь в бесперспективности идеи.
Почему авторский вариант нельзя использовать по комбинированному циклу? И если можно, то зачем некорректно сравнивать разные КПД?
Ну и с другой стороны - почему выбранная схема была отвергнута вот уже в течении 2000 лет? Наверно что-то мешало? Как минимум, последние 100 лет. Что же мешало?
Профсоюз нельзя понимать узко. Обособленная банда, выбивающая выгоду за счёт окружающих - разве это хорошо? Ну ладно, лично для главаря много денег - это хорошо. Но кто сказал, что для остальных бандитов будет повышение зарплаты? Только надежда.
Другой случай - союз наёмных работников вообще, то есть всех. Сил у такой банды будет побольше. Зарплаты реально поднимутся. Но запашок по прежнему останется.
И третий случай - реальная защита прав большинства. В чём отличия от банды? В том, что банда живёт ради эгоизма. Эгоизм, в первую очередь, поднимает наверх самых отъявленных эгоистов. И они себе делают много денег. Что останется - бандитам. Ну а большинству предложат пососать лапу.
Реальная защита большинства вместо сосания лапы предложит реальное улучшение жизни именно большинства. Именно поэтому акцент делается на слове реальная. В условиях профсоюзов, государств современного вида, прочих эгоистических организаций, защита большинства исключительно декларативная. Поскольку главенствующим принципом жизни общества является возвеличивание эгоизма во всех проявлениях, именно самые эгоистичные и пролезают на самый верх. И разумеется, только они и снимают сливки.
Поэтому для реальной защиты большинства следует, в первую очередь, изменить определяющий ценность человека во властной вертикали принцип.
Но, с другой стороны, каждый конкретный член большинства точно так же является эгоистом (эволюционно выработанное качество). Хотя чем человек ниже в социальной иерархии, тем ему проще отказаться от эгоизма волевым усилием. Просто потому, что чем ниже, тем меньше будет потеря при таком отказе. Плюс чем ниже, тем сильнее влияние окружения на человека, тем глубже доходит смыл понятия совесть.
Но, опять же, чем ниже, тем менее готов человек к сложным действиям по качественному управлению в требуемой общественной организации. Плюс чаще всего он не понимает последствий такого массового явления, как популизм.
В результате имеем эгоистов наверху и пассивную неграмотную массу внизу (почти в прямом смысле "быдло", к сожалению).
Вот здесь и нужен профсоюз в качестве воспитателя пассивного большинства. Способов много, но только при условии отсутствия эгоизма у стоящих близко к власти в профсоюзе. Хотя им, опять же, будут мешать пассивность и безграмотность. Поэтому большинство профсоюзов заканчивают в отстойной яме истории - лидеры продаются (эгоизм побеждает), тупят (безграмотность), ну и просто ничего не делают (пассивность).
Каков ваш профсоюз, товарищ автор?
В домах вентиляцию делают так - крышка над трубой, которая экранирует подсасывающий эффект воздушной струи сверху. Поэтому подсасывающий эффект снизу при наличии ветра создаёт тягу в вентиляционном канале. Это факт, независимый от идеальной жидкости. Рассмотрите внимательнее конусы и сопла в вами же рассматриваемой конструкции, где там крышка над трубой? Она там есть, поэтому и эффект есть.
Обратите внимание на ваши собственные иллюстрации за номерами 18 и 22. Всё там почему-то "расшвыривается" в стороны.
Вам выше подсказали - укажите на подтверждаемые экспериментом противоречия фактов и общепринятых теорий. И ещё лучше - дайте свои формулы, которые указанное противоречие снимают. Но как-то ваш спор выше не показал наличия конструктива в вашем подходе.
Зачем им 40 миллионов запросов в секунду?
Заказ такси не могут одновременно делать миллионы человек, потому что населения на земле для таких масштабов не хватит.
Значит система явно перегружена внутренними коммуникациями. Но что это за коммуникации? Ответ прост - микросервисы. Вместо пусть миллиона в секунду (и то много) имеем на пару порядков больше.
Вообще-то при движении жидкости/газа вдоль поверхности, параллельной потоку, давление на поверхность уменьшается в сравнении с давлением на плоскость, перпендикулярную потоку, чем пользуются при измерении скорости воздушных/водных судов относительно среды.
Вот это уменьшение давления и "подсасывает" воздух в конструкции. А если добавить кавитацию, то струя будет расширяться за счёт давления пара, после чего соприкоснётся со стенками и превратится в банальный поршень, всасывающий всё, что находится за ним.
То есть объяснить явление можно без проблем для существующих теорий.
Против ORM массово есть два возражения:
Не знающий SQL всё испортит.
Знающий SQL привык писать только SQL.
Первое устраняется принятием в команду грамотного специалиста. Второе устраняется принуждением написать два варианта - SQL и ORM, с полным пониманием, как оно внутри работает. Второй вариант обычно показывает, что понимания примерно столько же, сколько в варианте №1.
Вывод - вся критика ORM исходит от непонимания. И от нежелания понимать (это про фанатов чистого SQL в первую очередь).
Да, необходимость напрячься и изучить ORM, действительно идёт вразрез с общепринятой парадигмой ничегонеделанья за большие деньги, но всё же надо когда-то начинать. И учесть, что ORM - это лишь один из множества требуемых шагов. Дальше придётся учить ещё много чего.
В эпоху засилья микросервисного подхода, когда для получения данных из БД пихается сообщение в кафку, которая находит один из тысячи микросервисов, ответственный за выполнение select * from table1, затем отдаёт сообщение микросервису, который уже через сотню фасадов и прочего нагромождения (включая ORM) наконец где-то глубоко в недоступных потрохах передаёт SQL в одну из сотен баз данных (ага, по БД на микросервис), действительно оказывается, что добавление ORM к этому монстроидальному зоопарку ничего не меняет, кроме одного важного момента - без ORM нельзя копипастить готовые шаблоны простейших действий из интернета. Что возвращает нас опять к началу - мы имеем засилье самых примитивных погромистов вместо действительно необходимых специалистов.
Взглянув на такую схему получения данных из БД, пишущие на SQL действительно хватаются за голову и начинают ломать вокруг себя все 4-5 мониторов, которыми окружены как модница приблудами для покраски ногтей. Но граждане, вы не туда смотрите! Точнее - вы видите собачий бред, позволяющий за приложения уровня Hello World получать миллиарды денег. Но ORM здесь не при делах! Неуиноатый он, вот так.
ORM действительно ускоряет разработку. Но не модную, а эффективную. И если вам по жизни не повезло и вы не встречали на трудовом пути эффективные решения с ORM, то хотя бы не вставайте сразу в позу отрицания и вспомните, что в мире есть решения без микросервисов, кафки и прочего лютого треша. И это значит, что вы прошли мимо этих эффективных решений. Что в свою очередь означает - вам ещё учиться, учиться и учиться, много лет. Но ORM в этом не виноват. Это просто вам не повезло. Хотя знайте - так же как и вам не повезло ещё 95% погромистов, потому что когда на каждый приличный банк приходится по 1000 разработчиков, это означает, что 50 из них реально нужны, а 950 - всего лишь перекладывают json-ы из кафки в микросервисы, не создавая при этом ничего полезного с точки зрения логики бизнес-процесса. Так что сломайте свои мониторы не злобы ради, но понимания для. Поймите - инструмент ORM не виноват, а виноваты... ну вот такие у нас социальные условия, таков метод производства общественного продукта.
Вы, опять же, можете лично спросить ChatGPT. Мне он заявил, что знает больше десятка форматов, я выбрал ARIS, он нарисовал. Смысл нарисованного вполне понятен. Возможно, поскольку чат русскоязычный, он перевёл все xml-тэги на русский. Но всё это вы сами можете узнать у него.
Я понимаю ваше желание избавиться от критики, но помочь в его удовлетворении не могу.
На этом пункте всё ломается.
Кто напишет плагин? Кто будет хостить сеть доверия? Кто будет перехватывать трафик сети? Кто будет подменять в своих интересах все необходимые ему данные?
В существующей ситуации, когда есть власть, обладающая всеми необходимыми ресурсами для контроля всех узлов сети, начиная с контроля компьютеров/смартфонов большинства пользователей, любая хитрая сеть не стоит ничего.
Кроме того, привычки населения таковы, что в предложенной сети будут участвовать лишь единицы. Но чем меньше участников - тем меньше усилий требуется от власти для обретения полного контроля.
Реальное решение затронутой проблемы одно - организация общества на существенно других принципах. Пока во всех существующих странах главными являются заинтересованные в удовлетворении исключительно личных потребностей люди - никакие сети доверия им не страшны, поскольку за ваши деньги (в виде налогов) они купят все необходимые средства контроля.
Вам самому лень попробовать? Это доступно в РФ, причём бесплатно, нужно всего лишь научиться пользоваться гуглом.
Вот маленький пример генерации:
Здесь редактор решил, что язык называется scss, но я просил у чата язык ARIS.