Форум 'Философия программирования' на RSDN

Самый успешный проект в истории человечества

Sun, 22 Mar 2026 12:11:32 GMT

Вначале был LLM. Точнее статья 2017 года, attention all you need. Хрень которая умеет распареллеливать вычисления и обрабатывать текст как массив знаний. Затем идея что если мы обучим сеть продолжать предложения, то на текст он будет отвечать текстом. Внезапно оказалось, что на вопрос — LLM создает наиболее вероятный ответ. Так называемый — zero shot. Немного химии и дообучения и появился ChatGPT. Первый ChatGPT появился ноябрь 2022. Фактически 4 с половиной года назад. В него стали пихать больше знаний и процессоров, он становился умнее и умнее. Потом оказалось что если давать несколько примеров (few shot) то LLM отвечает вернее. Потом придумали технологию Function Calling чтобы LLM могла получать дополнительную информацию.
Где-то в 2024 году началась эра агентов. Это когда программист программирует процесс, создает промпт LLM, дает инструменты, и LLM сама решает как выполнить эту задачу.

«Это крупнейший, самый популярный и самый успешный проект с открытым исходным кодом в истории человечества. Это определенно следующий ChatGPT»

(с) Генеральный директор NVideо
https://expert.ru/news/glava-nvidia-nazval-ii-startap-openclaw-novym-chatgpt/

В ноябре 2025 года — первый проект
В январе 2026 года — появилось название
В марте 2026 — самое скачиваемое приложение из github

Ребята сделали классную вещь. Они дали возможность выполнять команда bash, использовать браузер, интеграция с телеграммами, whatsup, discord и другими экстремисткими программами запрещенными российским гражданам. И есть один обязательный инструмент — create_skill. Технические подробности — опущу. По сути это запрограммируй себя. OpenClaw может сам себя программировать, настраивать свою идентификацию редактируя файл с говорящим названием SOUL.md. Может настраивать новые уникальные задачи, можно попросить зайти на страницу и заказать билеты, отследить публикации, посмотреть текущие pull request. Безусловно есть отлаженные skill в частности https://www.skillhub.club/ но сама концепция самопрограммирования. И главное — она успешная.

Время жизни OpenClaw несколько месяцев. Время прогресса сжимается. Что будет в конце года?

update: Вот фирмы разработчиков берут деньги за предложение и автоматизацию сценариев. А тут сценарии придумывает пользователь. С чего деньги брать?

Зачем ИИ домысливает ?

Tue, 10 Mar 2026 15:22:18 GMT

Решил я поискать, что есть в сети обо мне на раннем этапе моей карьеры — студента — химика и аспиранта — химика. Вывели меня на ИИ (от Гугла), ну я его и попытал.

Сначала хотел просто процитировать, что он на мои вопросы ответил, но это было бы длинно и неинтересно. Поэтому лишь краткое резюме.

Начал я с того. что спросил о своем участии во всесоюзной олимпиаде студентов по химии 1976 года. Думал, что ничего не ответит. К удивлению, ответил, и почти правильно — лишь сказал, что занял я второе место, а в действительности было третье. Это-то ладно, но вот почему-то меня произвел в студенты ФЕН НГУ и потом долго рассказывал о моей дальнейшей карьере в НГУ в качестве преподавателя и научного сотрудника. В действительности я был студентом Томского ГУ, а к НГУ никогда отношения не имел. Ну ладно, ошибиться по вопросу, в каком вузе я учился и какое место занял — грех небольшой, но зачем же было расписывать мою дальнейшую карьеру в НГУ, если я вообще к нему не имел отношения ?

Потом спросил о том, чем я занимался во времена аспирантуры. И тут он ответил. И годы аспирантуры правильно привел, и тематику. И названия моих статей правильно привел. Правда, ошибся в названиях журналов — якобы они опубликованы в "Известиях вузов". Между тем диссертацию я делал в институте АН СССР и статьи были в Известиях АН СССР, серия химическая. Дал даже название моей диссертации и автореферата, но тут уже вообще чистая фантазия — их нет в сети и ссылок на них нет. ИИ сам это название придумал.

Потом сообщил, что я работал в Омском ГУ. Верно, работал. Вот только почему-то заявил, что преподавал я на химическом факультете и занимался научной работой в области физической и аналитической химии. Между тем работал я на математическом факультете, вел программирование, а к своей химической тематике с момента прихода в ОмГУ никогда не возвращался. А уж к аналитической химии после 2 курса вообще отношения не имел.

Причем живо все это описал. Чуть ли не в классика меня превратил — в тех областях, где я или вообще не работал, или где моя роль весьма умеренная. Договорился до того, что мои результаты попали в какие-то справочники по химии, где и пребывают. Между тем мои работы времен аспирантуры ни для какого справочника не годятся — в них нет данных, которые можно поместить в справочники.

Общий вывод — сочетание вполне достоверных данных с домысливанием (чтобы не сказать больше). Там где можно найти достоверные данные — он их приводит, иногда с простительными искажениями. Хотя и непонятно, зачем искажать. Привести правильно год журнала, номер тома и страницы, название статьи и дать название другого журнала — зачем ?

В остальном же буйный полет фантазии — домысливает по принципу "если мы о нем вот это знаем, то что бы еще могло быть ? Вот такое могло бы. Могло. Ну значит, оно и было".

Был он студентом НГУ ? Был (по его мнению. в действительности не был). Ну значит, мог быть потом там же научным сотрудником. Чем занимался там ? Сейчас придумаем.
Делал он диссертацию ? Делал. Значит, должен был быть автореферат. Названия его найти не удалось, не беда. Сейчас придумаем это название по аналогии с названиями его статей.
Был он аспирантом вуза ? Да. Ну значит, и публиковался в Известиях вузов.
Работал он потом преподавателем в ОмГУ ? Да. Он же химик ? Да. Ну , значит, и преподавал на химическом факультете в той же области химии, которой занимался в аспирантуре.

В итоге получилась вольная фантазия, где правда так перемешана с домыслами, что кому-то, ничего не знающему обо мне, отличить одно от другого практически невозможно. Поэтому общая ценность всего этого равна 0. Тут не ложка дегтя, которая портит бочку меда, тут в бочке половина меда и половина дегтя, хорошо перемешанные.

Что это — его родимое пятно ? Надеяться на то, что со временем станет лучше, в этом случае не приходится. Новых данных о ранних годах моей карьеры не появится, скорее всего. Так что дообучиться он не сможет, не на чем. Поэтому вопрос не в том, что он какие-то данные не учел, а в том, что он вольно нафантазировал там, где всего лишь нужно было сказать "не знаю".

Он когда-нибудь так фантазировать перестанет ?

И еще рассуждения об ИИ

Sat, 31 Jan 2026 07:44:55 GMT

Во-первых, ограничимся достаточно узкой областью. Какой-нибудь open source фреймворк.

Что тут вообще может делать интеллект, неважно какой.

1. Освоить имеющийся материал по этому фреймворку
2. Применить эти знания на практике, то есть сделать код с использованием его для конкретной задачи
3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
4. Разработать свой код в качестве contibutor и предложить pull request
5. Принять этот pull request (или отвергнуть его)
6. Внести изменения в release и сделать следующую версию.

ЕИ все это может. Разумеется, разные представители ЕИ

Ну ладно, (6) мы пока ИИ не поручим

(1) — (2) ИИ вроде как может.

Может ли он (3) — (5) ? Если сейчас не может — сможет ли ?

Иными словами, сможет он стать разработчиком нового или останется только компилятором существующего ?

Multithreading: как очередь, но вручную и красиво?

Thu, 15 Jan 2026 09:56:40 GMT

Периодически возникает при многонитевом построении примерно следующий "паттерн": есть элемент состояния/управления (как очередь заданий), который требует контролируемого взаимодействия с помощью лока и "условной переменной". Но чтобы на время выполнения задания не блокировать тех, кто хочет установить следующее задание, лок снимается на это время. Получается следующая схема:

## Псевдокод в стиле Python
with self.lock: ## для C++ аналог -- захват лока в конструкторе
    while True:
        if not self.task: ## можно было и с предикатом, если кому удобнее читать
            self.cv.sleep()
            continue
        task = self.task
        self.task = None
        self.lock.release() ## начинается длительная операция
        try:
            self.execute(task)
        except Exception:
            ... пожаловались ...
        self.lock.acquire()

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

Можно было бы просто перевести на очередь. Но бывает, что при этом ещё и какие-то элементы статуса отдаются обратно, или воздействие от управляющего метода более сложное. И если может быть поставлено не более одного задания, то делать это в виде очереди, ограниченной одним элементом, тоже как-то странно. Ещё бывают собственные idle операции, а ждать чтения из очереди с таймаутом не всегда возможно.

Какие есть варианты сделать это красиво без подобных ручных плясок?

Некоторые размышления об ИИ

Sat, 13 Dec 2025 13:45:06 GMT

Почему не в форум об ИИ — там в основном специальные вопросы, а это обсуждение общего плана.

Интеллект это или не интеллект — вопрос скорее философский. В общем, можно сказать, что это нечто, отчасти похожее на человеческий интеллект, но и существенно от него отличающееся. Тут можно многое сказать, но не буду.

Если считать его все же интеллектом, то вполне логично сравнить его с естественным интеллектом (ЕИ). И вот тут обнаруживаются существенные различия организационного характера.

Носители ЕИ, как правило, являются специалистами в одной, реже нескольких областях. Их знания в других областях поверхностны, и, как правило, не годятся для того, чтобы сделать серьезные экспертные заключения. За примерами ходить далеко не надо. Тут все более или менее являются специалистами в ИТ и могут дать компетентное заключение по какому-то вопросу, но послушаешь, что они высказывают в непрофильных форумах, например, по экономике — порой волосы становятся дыбом и уши вянут. И уж никакой серьезный экономист в здравом уме и твердой памяти не станет руководствоваться их высказываниями по экономике.

Более того. ЕИ (если конечно, речь не идет о личностях вроде Ноздрева) по большинству вопросов вне своей сферы компетенции даст ответ — не знаю. Ну действительно, что Вы можете ответить на узкоспециальный вопрос, скажем, по гетерогенному катализу ? Только одно — не знаю. Я как химик по образованию когда-то что-то знал, но давно забыл, так что и мой ответ, скорее всего, будет таким же.

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

С ИИ все обстоит иначе. Он универсален и готов ответить на любой вопрос. А поскольку нельзя объять необъятное, то он начинает фантазировать, скрещивая данные из самых разных источников, и как результат, часто попадая впросак. Универсальный же ЕИ существует только в произведениях фантастов (вроде Лемовского Соляриса), реально его нет.

Может быть, в этом и (отчасти) кроются некоторые проблемы , связанные с ИИ ? Может быть, будь он организован иначе, эти проблемы бы ушли ?

Представьте себе, что ИИ организован по-другому. Вместо универсального ChatGPT или DeepSeek имеется большое количество узкоспециализированных ИИ, но таких, которые очень хорошо ориентируются в своей области, так что на вопрос, относящийся к ней они дают всегда или почти всегда правильный ответ, а если вопрос выходит за пределы их компетенции — пытаются определить, к компетенции какого другого ИИ он относится и передаю вопрос ему. Иными словами, ведут себя как люди в этом плане. "Я в этой области плохо разбираюсь, но знаю Ивана Петрова, который вроде в этом разбирается, спрошу его". Возможно, что Иван Петров тоже окажется не специалистом и передаст вопрос Петру Сидорову, а возможно, что в итоге будет собрано совещание с участием всех троих, и совместными усилиями они найдут ответ. Вот и для ИИ могло бы быть аналогично.

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

Это существенно изменит и саму модель ИИ как явления. Вместо одного универсального ИИ в огромном датацентре можно будет иметь сотни и тысячи (а может, сотни тысяч) специализированных ИИ, взаимодействующих между собой и расположенных на относительно некрупных серверах относительно небольших организаций.

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

Что думаете ?

Unix-way универсален для нейрочипов?

Tue, 25 Nov 2025 08:46:37 GMT

Насколько универсальна Unix-философия и Unix-инструментарий (Unix-утилиты)?
Когда появятся нейрочипы и сознание пост-человека перетечёт в компьютеры, будет ли чиповая ОС в своих недрах содержать Unix-ядро, монолит или микроядро, не важно, важно для моего вопроса то, что будет или нет там набор Unix-утилит. Если да, то получается, изучая Unix-утилиты, можно будет уметь ковыряться в своих мозгах? Типа, смотреть tail мыслей. Или редачить воспоминания с помощью sed, что как-бы нельзя делать, но разработчики чипа забыли убрать sed из дистрибутива чип-ОС.

Список переходов в ДКА

Tue, 30 Sep 2025 19:40:28 GMT

Здравствуйте!

Наверное, в "Философию", хотя, вопрос всё же вполне практический.

Ковыряю генератор ДКА. Думаю, как описывать переходы между состояниями. Пока надумал примерно так:

Синтаксис описания переходов:

СписокИсхСостояний : СписокСобытий [? ДопУсловие] -> ЦелевоеСостояние [? ДопУсловие] [: СписокДействий] [- Описание];
где
  СписокИсхСостояний - Состояние1 [, Состояние2 [, Состояние3... ] ]
  СостояниеN         - * / Состояние / !Состояние
  СписокСобытий      - Событие1 [, Событие2 [, Событие3... ] ]
  СобытиеN           - * / Событие / !Событие
  СписокДействий     - Действие1 [, Действие2 [, Действие3... ] ]

'*' - означает любое состояние, для которого не задано перехода.
'!' (отрицание) - используется совместно с состоянием '*', и явно исключает
    генерацию перехода из этого состояния.

Аналогичная семантика используется при описании списка событий.

ДопУсловие - логическое выражение, состоящее из предикатов, операций '&', '|', '!'
и группроующих скобок.
ДопУсловие может располагаться либо после списка событий, либо после целевого состояния,
но только в одном из этих мест.

Ничего не забыл?

Вопрос — как сравнивать такие записи? И надо ли сравнивать? По идее, переходы могут пересекаться по условиям, и это нельзя. И хочется сразу отсечь проблемы. Или оставить на потом?

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

Сначала идут все переходы, у которых нет "звездочек" в исходных состояниях и в событиях перехода.
Потом — те переходы, у которых есть "звездочка", но есть исключения из звездочки, состояния/события с отрицанием (тут вопрос, что идёт раньше, "звездочка" в исх состояниях или "звездочка" в событиях?)
Потом — те переходы, у которых только одна звездочка.

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

Предложения, пожелания, критика?

Два несуществующих файла

Fri, 26 Sep 2025 17:11:48 GMT

Вот если мы сравниваем два нулевых указателя, то получаем true.
А вот если мы сравниваем два несуществующих файла, то функция их сравнения должна возвращать true или false?

Программа как договор :)

Sun, 22 Jun 2025 11:43:10 GMT

Наткнулся в канале одного умного человека на уподобление программы договору. Интересная точка зрения, мне раньше не попадалась.

Игорь Ашманов об влиянии ИИ на ИТ, общество, бизнес...

Thu, 12 Jun 2025 05:15:32 GMT

https://www.youtube.com/watch?v=kb9qKsiTfTw&ab_channel=%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D0%B9%D0%A1%D0%B0%D0%B2%D0%B2%D0%B0%D1%82%D0%B5%D0%B5%D0%B2%D0%B8%D0%A0%D0%BE%D0%B4%D0%BD%D0%B0%D1%8F%D0%A8%D0%BA%D0%BE%D0%BB%D0%B0
Довольно любопытно.

«Искусственный интеллект понижает качество везде, где он дотягивается. Это я вам говорю, как профессиональный разработчик искусственного интеллекта»

«Есть проблема – об этом надо сказать. Люди с удовольствием становятся рабами роботов. Они с удовольствием отдают ответственность.
Как от этого, от этой проблемы защищаться – склонности людей передавать ответственность роботам?»

«У нас есть категория оголтелых цифровизаторов, которые рассказывают всем, в том числе самому главному начальнику, что цифровизация нас спасёт, что всё будет круто.
Пока мы знаем, что цифровизация привела к тому, что были совершены миллиарды звонков мошенников, которые украли сотни миллиардов рублей у наших граждан. Почему? Потому что утекли гигантские объёмы записей персональных данных»

«Человек очень склонен экономить энергию, особенно – мыслительную энергию. Все будут её экономить – значит, должны отупеть. Ну как – все уже отупели от смартфонов, от Гугла, от Википедии и так далее. Дальше будет сильно хуже»
...

Зуев, Недоря, Богатырев о ЯП

Tue, 20 May 2025 05:20:04 GMT

Очень интересный видос
https://rutube.ru/video/539091c054d11587b5e21fc3fe3b5f56/?r=wd
С Недорей и Богатыревым знаком лично — пересекались на конференциях.
Из книжки Зуева по ТурбоПаскалю в свою переложил на С++ пример о побочном эффекте.
Еще в 2003 году.

Практический смысл (польза) от разработки ПО

Tue, 13 May 2025 07:52:10 GMT

Вот сейчас кричат из каждой кофеварки — мидлов заменят мидлов заменяет. Т.е. если ты не эксперт и не элита — сиди дрожи.

И я так задумался — а в чем вообще смысл разработки ПО и зачем она человечеству, нельзя ли без нее?

И скорее прихожу к выводу что конечный смысл — занять людей хоть чем-то. Т.е. просто чтобы они были заняты и не буянили. А основной смысл криков об ИИ и замене — это вызвать эмоции страха, как-то сыграть на этих эмоциях.

Поясню. Вот есть ручной труд:

	Скрытый текст
	https://www.youtube.com/watch?v=N5mGcYwMWKc

Чел. увлечен, радуется что у него получается, что его ценят в обществе, есть что передать детям. И тут вы приходите со своей "Ардуникой" и сервоприводами и автоматизируете все что он делает. Ну пусть не все, часть работы. И что? Чел. теряет смысл жизни, заняться ему нечем. И дальше возникает новая проблема — нужно спасать его от безделья и делать комп. игрушки. А ведь раньше он не страдал и в реале.

Ну ладно, когда автоматизация производства (еда, одежда, машины, дома) — это можно еще понять.

Но ведь большинство софта — и того не делают, даже труд не автоматизируют. Вот есть https://alternativeto.net/ — 131,855 приложений. Чтобы по минутке каждому уделить — нужно 270 дней потратить. И это не все что наваяло человечество — на самом деле намного больше.

И какой в этом великий смысл? По сути критических софтин не так много и они уже давно написаны не единожды.

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

Как создается нужность. Вот одни гомы напали на других — догадались убивать друг-друга "вентиляторами". Теперь уже появилась нужность — нужно писать софт для вентиляторов, чтобы делать абсолютно бессмысленную идеи — убивать других гомов.

Или другое. Сидит штаны протирает орда бездельников — чиновников. И придумывают новые обязательные отчеты для бизнеса в неймоверном количестве. И вот тебе уже — нужность налоговых консултантов, нужность писателей книг по этим налогам, бухгалтерских еженедельников, кучи софта для отчета и подсчетов. И нафига? Думаете в этом всем есть смысл? Да нет же никакого смысла — он надуман.

Так вот — фишка в том что оно и так уже давно 90% ничего не нужно, просто чтобы гомов чем-то занять, чтобы не было стенка на стенку — как бы создается иллюзия нужности. Ну и иллюзия страха, чтобы ты крепче держался за свою нужность.

Дублирование логики?

Tue, 06 May 2025 07:43:32 GMT

Есть такой термин номер недели. В базе есть таблица со всеми днями на год и у каждого дня есть номер недели. Это много где используется на уровне логики базы.
Тут зашел разговор, что для ускорения работы на бэке хорошо бы не лазить в базу, а в бэке иметь высчитывание.
Как считаете нормально ли иметь по сути дублированную логику в бэке или лучше из базы брать и хранить в том же кэше?

Бизнес ничего личного

Sat, 22 Feb 2025 21:38:04 GMT

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

как пример:
https://www.reddit.com/r/KafkaFPS/comments/1it0dp4/%D0%B0%D0%BD%D0%B5%D0%BA%D0%B4%D0%BE%D1%82_rtx_5090_%D0%B2_10_%D1%80%D0%B0%D0%B7_%D1%85%D1%83%D0%B6%D0%B5_rtx_4090_%D0%B0_%D1%82%D0%B5%D0%BF%D0%B5%D1%80%D1%8C/

https://www.youtube.com/watch?v=CDgh9QDcgsc

Сможет ли deepseek разобрать винду, чтобы сделать исходники?

Wed, 05 Feb 2025 12:53:27 GMT

А в чем сложности разобрать ядро винды или ios?

Верстка UI - обзор подходов

Sun, 29 Dec 2024 10:06:41 GMT

Вот что интересное заметил.

Ранее старались разделить — мухи отдельно, котлеты отдельно. Т.е. желали декларативное описание UI и отдельно уже код. Вот примеры

Дедовский MFC .rc (resource script)

Канонически правильный, не мешаем котлеты с мухами:

IDD_MYDIALOG DIALOGEX 0, 0, 200, 150
STYLE WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "My Dialog"
FONT 8, "MS Sans Serif"
BEGIN
    CONTROL "OK", IDOK, "Button", WS_TABSTOP, 50, 120, 50, 14
    CONTROL "Cancel", IDCANCEL, "Button", WS_TABSTOP, 110, 120, 50, 14
END

Qt Designer UI Language (XML)

XML

<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
 <class>MainWindow</class>
 <widget class="QMainWindow" name="MainWindow">
  <property name="geometry">
   <rect>
    <x>0</x>
    <y>0</y>
    <width>400</width>
    <height>300</height>
   </rect>
  </property>
  <property name="windowTitle">
   <string>Пример окна</string>
  </property>
  <widget class="QWidget" name="centralWidget">
   <layout class="QVBoxLayout" name="verticalLayout">
    <item>
     <widget class="QLineEdit" name="lineEdit"/>
    </item>
    <item>
     <widget class="QPushButton" name="pushButton">
      <property name="text">
       <string>Нажми меня</string>
      </property>
     </widget>
    </item>
   </layout>
  </widget>
  <action name="actionExit">
   <property name="text">
    <string>Выход</string>
   </property>
  </action>
 </widget>
 <resources/>
 <connections/>
</ui>

QT QML (Qt Modeling Language)

QML

import QtQuick 2.15
import QtQuick.Controls 2.15

ApplicationWindow {
    visible: true
    width: 400
    height: 300
    title: "Пример на QML"

    Column {
        anchors.centerIn: parent
        spacing: 10

        TextField {
            id: inputField
            placeholderText: "Введите текст"
        }

        Button {
            text: "Нажми меня"
            onClicked: console.log("Текст: " + inputField.text)
        }
    }
}

— это уже переходной этап, т.к. кроме декларации — был JavaScript. Но все-же не смешивалось с основным ЯП — как то C++.

WinForms и Xaml

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

Xaml же уже полностью вернулись к концепции полного разделения — был специальный XML-файл:

XAML

<Window x:Class="ExampleApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Пример XAML UI" Height="300" Width="400">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*"/>
            <ColumnDefinition Width="Auto"/>
        </Grid.ColumnDefinitions>

        <!-- Метка для ввода текста -->
        <TextBlock Grid.Row="0" Grid.Column="0" Margin="10" Text="Введите текст:" VerticalAlignment="Center"/>

        <!-- Текстовое поле для ввода -->
        <TextBox x:Name="InputTextBox" Grid.Row="0" Grid.Column="1" Margin="10" Width="200"/>

        <!-- Кнопка для подтверждения -->
        <Button x:Name="SubmitButton" Grid.Row="1" Grid.ColumnSpan="2" Margin="10" Content="Отправить" Click="SubmitButton_Click"/>

        <!-- Поле для отображения результата -->
        <TextBlock x:Name="ResultTextBlock" Grid.Row="2" Grid.ColumnSpan="2" Margin="10" Text="Здесь будет результат" TextWrapping="Wrap"/>
    </Grid>
</Window>

Что с Web-технологиями

Интересно что ASP.Net WebForms — был смесью HTML и серверных тегов — все-таки позиционировался как декларативный — код на C# размещался отдельно, что поднимало на уровень выше по сравнению с тогдашним PHP:

ASP.NET Classic WebForms

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ContactForm.aspx.cs" Inherits="MyApp.ContactForm" %>

<!DOCTYPE html>
<html lang="en">
<head runat="server">
    <meta charset="utf-8" />
    <title>Contact Form</title>
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@4.5.2/dist/css/bootstrap.min.css" rel="stylesheet" />
</head>
<body>
    <div class="container">
        <h2>Contact Form</h2>

        <form id="form1" runat="server">
            <div class="form-group">
                <label for="Name">Name</label>
                <asp:TextBox ID="NameTextBox" runat="server" CssClass="form-control" />
            </div>

            <div class="form-group">
                <label for="Email">Email</label>
                <asp:TextBox ID="EmailTextBox" runat="server" CssClass="form-control" />
            </div>

            <div class="form-group">
                <label for="Message">Message</label>
                <asp:TextBox ID="MessageTextBox" runat="server" TextMode="MultiLine" CssClass="form-control" />
            </div>

            <asp:Button ID="SubmitButton" runat="server" Text="Submit" CssClass="btn btn-primary" OnClick="SubmitButton_Click" />
        </form>
    </div>
</body>
</html>

Потом как-то стал популярен MVC везде, в т.ч. в том же PHP он начал активно использоваться, и уже все стало намного проще:

ASP.NET MVC (Razor)

@model MyApp.Models.ContactForm

@{
    ViewBag.Title = "Contact Form";
}

<h2>@ViewBag.Title</h2>

@using (Html.BeginForm("Submit", "Home", FormMethod.Post))
{
    <div class="form-group">
        @Html.LabelFor(m => m.Name)
        @Html.TextBoxFor(m => m.Name, new { @class = "form-control" })
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Email)
        @Html.TextBoxFor(m => m.Email, new { @class = "form-control" })
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Message)
        @Html.TextAreaFor(m => m.Message, new { @class = "form-control" })
    </div>

    <button type="submit" class="btn btn-primary">Submit</button>
}

ASP.NET Blazor

@page "/contact"
@using MyApp.Models

<h3>Contact Form</h3>

<EditForm Model="@contactForm" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <div class="form-group">
        <label for="Name">Name</label>
        <InputText id="Name" class="form-control" @bind-Value="contactForm.Name" />
    </div>

    <div class="form-group">
        <label for="Email">Email</label>
        <InputText id="Email" class="form-control" @bind-Value="contactForm.Email" />
    </div>

    <div class="form-group">
        <label for="Message">Message</label>
        <InputTextArea id="Message" class="form-control" @bind-Value="contactForm.Message" />
    </div>

    <button type="submit" class="btn btn-primary">Submit</button>
</EditForm>

Андроид

Используются XML-файлы с описанием элементов формы:

XML-layout

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:padding="16dp">

    <EditText
        android:id="@+id/usernameEditText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="Enter your username" />

    <Button
        android:id="@+id/submitButton"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Submit" />
</LinearLayout>

iOS

Аналогично, использовался XML для описания:

Storyboard

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
  <dict>
    <key>UIApplicationSceneManifest</key>
    <dict>
      <key>UIWindowScene</key>
      <dict>
        <key>UIWindowSceneRoleApplication</key>
        <dict>
          <key>UIViewController</key>
          <dict>
            <key>view</key>
            <dict>
              <key>subviews</key>
              <array>
                <dict>
                  <key>UILabel</key>
                  <dict>
                    <key>text</key>
                    <string>Hello, world!</string>
                    <key>frame</key>
                    <string>{{50, 50}, {200, 40}}</string>
                  </dict>
                </dict>
                <dict>
                  <key>UIButton</key>
                  <dict>
                    <key>title</key>
                    <string>Press me</string>
                    <key>frame</key>
                    <string>{{50, 120}, {200, 50}}</string>
                    <key>action</key>
                    <string>buttonPressed:</string>
                  </dict>
                </dict>
              </array>
            </dict>
          </dict>
        </dict>
      </dict>
    </dict>
  </dict>
</plist>

Новые нравы

А теперь смотрите к чему мы опять вернулись.

Flutter

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: Text('Форма регистрации')),
        body: Padding(
          padding: const EdgeInsets.all(16.0),
          child: RegistrationForm(),
        ),
      ),
    );
  }
}

class RegistrationForm extends StatefulWidget {
  @override
  _RegistrationFormState createState() => _RegistrationFormState();
}

class _RegistrationFormState extends State<RegistrationForm> {
  final _formKey = GlobalKey<FormState>();
  final _nameController = TextEditingController();
  final _emailController = TextEditingController();
  final _passwordController = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        children: <Widget>[
          TextFormField(
            controller: _nameController,
            decoration: InputDecoration(labelText: 'Имя'),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Пожалуйста, введите имя';
              }
              return null;
            },
          ),
          TextFormField(
            controller: _emailController,
            decoration: InputDecoration(labelText: 'Электронная почта'),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Пожалуйста, введите email';
              } else if (!RegExp(r'\S+@\S+\.\S+').hasMatch(value)) {
                return 'Введите корректный email';
              }
              return null;
            },
          ),
          TextFormField(
            controller: _passwordController,
            decoration: InputDecoration(labelText: 'Пароль'),
            obscureText: true,
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Пожалуйста, введите пароль';
              } else if (value.length < 6) {
                return 'Пароль должен содержать хотя бы 6 символов';
              }
              return null;
            },
          ),
          SizedBox(height: 20),
          ElevatedButton(
            onPressed: () {
              if (_formKey.currentState?.validate() ?? false) {
                // Если форма валидна, отправить данные
                ScaffoldMessenger.of(context).showSnackBar(
                  SnackBar(content: Text('Форма отправлена')),
                );
              }
            },
            child: Text('Отправить'),
          ),
        ],
      ),
    );
  }
}

Kotlin Multiplatform (KMP)

Вариант Compose Multiplatform:

Compose Multiplatform

@Composable
fun LoginForm() {
    Column {
        TextField(value = username, onValueChange = { username = it }, label = { Text("Username") })
        TextField(value = password, onValueChange = { password = it }, label = { Text("Password") }, visualTransformation = PasswordVisualTransformation())
        Button(onClick = { /* handle login */ }) {
            Text("Login")
        }
    }
}

SwiftUI

И даже новомодный SwiftUI

SwiftUI

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Hello, world!")
                .font(.title)
                .padding()
            
            Button(action: {
                print("Button pressed")
            }) {
                Text("Press me")
                    .font(.title)
                    .padding()
                    .background(Color.blue)
                    .foregroundColor(.white)
                    .cornerRadius(10)
            }
        }
        .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

— это декларативно-императивный подход какой-то, когда вроде и все в декларации, но так же можно в любом месте и функцию дернуть. Причем сразу многие популярные платформы поддались этой тенденции. Т.е. все-таки отказались от концепции полного разделения мух и котлет — немножко мух теперь поддобавить можно

Изменение массива данных

Tue, 17 Dec 2024 06:52:48 GMT

Есть массив объектов типа Card {amount : decimal, currency : string} полученных из базы.
Надо на фронт отправить пользователю всё в одной валюте и для этого есть метод ApplyCurrencyRate в репозитории который к уже полученному из базы массиву применяет курс валюты выбранной пользователем.

какой вариант лучше:

List<ApplyCurrencyRate> ApplyCurrencyRate(List<ApplyCurrencyRate> list, Dictionary<string, decimal> rates)
{
  var result = list;
  Array.Foreach(result, ....);
  return result;
}

void ApplyCurrencyRate(List<ApplyCurrencyRate> list, Dictionary<string, decimal> rates)
{   
  Array.Foreach(list, ....);
}

Программисты-попаданцы :)

Sat, 14 Dec 2024 19:04:14 GMT

Внезапно подумалось, есть ли книги о программистах-попаданцах. Погуглил — действительно есть, но какое-то мутное фэнтези, замешанное на магии. А вот чтоб какой-нибудь питонист/жабаскриптер, да попал в реальные 60-70-е прошлого века, с миссией нести идеи "эффективного и безопасного" программирования в массы унылых тружеников фортрана и кобола?

Динамические vs статические классы

Sat, 07 Dec 2024 10:36:58 GMT

Я как обычно излагаю Delphi понятия, но вроде на C++ должно быть всё очень похоже. Если не ошибаюсь, в C++ есть динамические классы, которые корректно называть собственно классами, и статические классы, аналогом которых в Delphi являются рекорды?
Часто возникает выбор — оборачивать ли какую-то сущность а класс или рекорд. Я обычно делаю рекорд из всего, что не требует никакого динамического выделения памяти. Например у меня есть рекорд tvector, включающий в себя три числа x, y, z. Для разных операций с векторами вроде вычисления длины вектора, сложения, умножения и т.д. я пишу функции (какие-то в виде собственных функций рекорда, какие в виде просто функций). Делать из векторов класс было бы весьма неудобно, т.к. надо их будет каждый раз инициализировать и финализировать, а с рекордом я могу написать vector2:=vector1.
Но везде, где появляются динамические массивы и строки, обычно мне кажется удобнее создавать класс. У класса есть три базовых функции, которые надо проверять и править каждый раз, когда я что-то в него добавляю: конструктор, деструктор и ассигн. В Delphi нет и видимо в принципе не может быть полностью безглючного присвоения data2:=data1 с такими рекордами, поэтому надо делать data2.assign(data1).
Собственно к рекорду тоже можно прикрутить ассигн, но мне интуитивно кажется что это всё не есть удачные решения. Тут главный момент — передача данных в произвольных функциях. С классами всё понятно и удобно, потому что я всегда знаю что переменная класса — это указатель, соответственно если например класс передаётся как параметр какой-то функции, я точно знаю что перед её вызовом был вызван конструктор класса, а после будет вызван деструктор. С рекордами, если они содержат что-то динамическое, приходится передавать данные в функциях через var, и я плохо осознаю, например, не будет ли лишних проблем, если переменную с var передать как var ещё одной подпрограмме, может быть рекурсивной.
С классами меня естественно раздражает их медленность по сравнению с рекордами, плюс то что классы хранят какую-то дополнительную информацию вроде названия класса или таблицы виртуальных методов, а это ещё тормоза. В Delphi нет быстрых классов без этого? Если нет, может я когда-то дозрею до того, что начну активно использовать указатели к рекордам. Но может быть я слышал что использование указателей в современном программировании считается моветоном, вроде безусловных переходов?
Сишники, вам понятны эти дельфистские заморочки, или у вас как-то по-другому?

Связи в разметке (на примере HTML)

Thu, 05 Dec 2024 07:46:10 GMT

Как бы вы организовали связи между узлами разметки, если бы проектировали язык разметки с нуля?

Возможные варианты.

0. Нынешний. У элементов есть id. Элементы ссылаются друг на друга указанием id таргета (на уровне стандарта: for, aria-controls и т.д.). id уникален в скоупе документа.

Проблема в том, что это синглтон со всеми вытекающими. Например, нам нужно временно (или даже постоянно) склонировать узел для технических нужд, и мы приплыли. Другая проблема — шаблонизация. Представим себе, что у нас есть пара элементов. Тот же input и label к нему. Их нельзя просто объединить в шаблон и инстанцировать, заменяя чисто текст, нужно ещё каждый раз генерировать бессмысленный идентификатор, только для того, чтобы создать связь. Эта связь никому не интересна за пределами шаблона, но о ней приходится думать снаружи (лично я добавил к шаблонизатору специальную переменную "автоидентификатор").

1. Понизить скоуп id. Наверно, тогда что-то сломается? Вам для чего-нибудь нужна уникальность id на уровне документа? Другой вопрос: понижать до какого уровня? До парента? Или ломать ветки как с position: relative, т.е. до первого помеченного (например, абсолютным позиционированием) элемента выше по дереву?

2. Ссылаться не при помощи id, а при помощи селекторов. Но как тогда быть с конфликтами? Брать первый попавшийся? Брать ближайший в иерархии? И хотя это даёт бОльшую гибкость, увы, селекторы не решают проблему скоупа.

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

3. Оформлять связи специальными элементами-скобками: <group><input><label></group>. Если элементы разнесены, ничего не получится. Т.е. сгодится для for, но не для aria-controls.

4. Вынести описание связей из разметки куда-нибудь ещё (в специальные элементы, в заголовок документа, в DSL). Непонятно, правда, как при описании связи ссылаться на сами элементы... Похоже, это тупиковая идея

5. Ваши варианты.