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

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

Трудные времена рождают сильных людей. Сильные люди создают хорошие времена. Хорошие времена рождают слабых людей. Слабые люди создают трудные времена

(с) Платон, 380 г. до н.е.

Я был хейтером использования EDT для 1С-разработки со дня, когда она только появилась больше десяти лет назад. Ключевой причиной моей нелюбви было то, что с появлением "сырого" EDT развитие 1С:Конфигуратора было остановлено. И я остаюсь хейтером, так как EDT до сих пор остается "сырым продуктом".

Сегодня мне нужно было поработать с одной внешней обработкой. Я склонировал проект обработки с гитхаба, подключил к своему воркспейсу... А что дальше? Вспоминаю, что каждый раз при работе с внешними обработками нужно долго и основательно попотеть.

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

Ладно, что там дальше в инструкции - открыть перспективу Файлы. Захожу в список перспектив.., а там такой нет. По логике понимаю что речь видимо о перспективе Ресурсы (Resource), где действительно была упомянутая панель Структура проекта, через которую я [следуя инструкции] попадаю в каталог проекта, но в котором даже после этих действий каталог BIN так и не появился...

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

Я от безнадеги даже пошел в чат EDT и стал просматривать сообщения по ключевым словам. Ничего не нашел, но увидел, что разработчики иногда просят посмотреть логи из вьюшки "General / Error log" (по умолчанию закрыта). Открываю эту вьюшку и вижу серию ошибок:

External object dump creating failed
com._1c.g5.v8.dt.platform.services.core.runtimes.execution.RuntimeExecutionException: Error interacting with the 1C:Enterprise Platform 8.3.24.1667:
Platform process log [error code 1]:
Error locking infobase for configuration.
Infobase may already be in use by Designer.

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

Стоп! А какая версия? База запускается под 8.3.5.1445, а согласно ошибке обработка требует 8.3.24.1667, которая действительно не имеет права доступа к базе. Но почему выбирается неправильная версия? Что в настройках? Где вообще эти настройки?

Через некоторое время я обнаруживаю незаметную кнопку в контекстном меню проекта "Открыть редактор проекта" (отсутствует в полном меню), а в окошечке свойств проекта версия почему-то указана 8.3.24 и это свойство закрыто от редактирования.

Дальше уже все просто - все запрещенные к редактированию свойства EDT нужно редактировать через Блокнот напрямую в файлах. В данном случае в файле "ExternalDataprocessor\DT-INF\PROJECT.PMF". Заменил 8.3.24 на 8.3.25 и каталог BIN действительно появился и в нем наконец-то скомпилировалась обработка, когда я запустил проект на отладку.

P.S. Это был краткий обзор одного из сотен случаев, когда EDT сожрал у меня кучу времени. А еще там встроенная документация омерзительная!

P.S.S. Каждый раз как после EDT работаю в Конфигураторе - это как глоток свежей воды после сидения в душной комнате.

Разнообразных "расследований" в моей 1С-практике очень много. Иногда чувствую себя Шерлоком Холмсом 🕵️‍♂️

Вот буквально в прошедшую пятницу меня попросили разобраться в странной ситуации из базы нашего турецкого клиента:

При установке пометки удаления Контрагенту, эта пометка через минуту сама снимается.

1. Для начала - кто эту пометку снимает? Делаю отбор по клиенту в журнале регистрации и вижу, что пометку снимает фоновое задание. Делаю отбор по номеру сеанса и вижу название регламентного задания, которое запустило фоновое.

2. Читать код в этой базе очень сложно - там ядреная смесь английского, русского и турецкого (кстати, если в Конфигураторе делать поиск по турецким метаданным, то он закрывается). Понимаю, что тут происходит обмен с другой базой по правилам "Конвертации данных 2.0"

3. Выгружаю правила и внимательно изучаю все ПВД, ПКО и ПКС - ничего подозрительного.

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

5. Анализирую получаемый пакет - каждую минуту эти 31к строчек бомбят базу. В пакете чуть больше 800 накладных и несколько десятков ссылок на Контрагентов (режим выгрузки по ссылкам). Нахожу UUID проблемного клиента - только ссылка и использование ссылки в описании документов. Т.е. "Универсальный обмен данными XML" получив ссылки, начинает их сравнивать с данными базы на отсутствие пометок удаления и снимает лишние (не знаю насколько это стандартное поведение - код обработки сильно переписан на турецком). Это имело бы смысл для свежих документов, но получаем пачку из сотен документов периода 2020-2023 годы.

6. Настало время изучить базу-корреспондент. Там есть регистрация этих давно не актуальных восьми сотен документов старого периода. Снимаю с регистрации документы во второй базе и помечаю контрагента на удаление в первой. Наблюдаю и вижу: а) при выгрузке помеченного контрагента из первой базы он помечается на удаление во второй; б) восстанавливается регистрация старых документов и они улетают из второй базы в первую; в) в первой базе слетает пометка на удаление на контрагенте, г) при следующем обмене слетает пометка на удаление во второй базе.

7. Анализирую чем отличаются проблемные документы - это проведенные документы, статус которых "подготовлены к отправке" (примерный перевод, там статусы тоже на турецком).

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

9. Наконец-то контрагента удалось пометить на удаление 🎉

Люблю АМА по утрам. А вы? 🤓

Ситуация на фото не очень... А ведь это правда!

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

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

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

Ранее тут уже оставлял свое мнение о фильме "Джокер: Безумие на двоих". Потом я еще раз обсудил эту кинокартину со своей преподавательницей и моя точка зрения немного скорректировалась. И материал того урока теперь становится первой записью )))

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

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

И знаете что? Я внезапно увидел четкую аналогию между письмом на иностранном языке и ПРОГРАММИРОВАНИЕМ! 👨‍💻

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

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

Сначала каждую фразу по несколько раз я перепроверяю в Google Translate (прямые, а потом обратные переводы - что изменилось и почему). Потом итоговый текст произведения отправляю в ChatGPT для оценки понятности, натуральности выражений и общей плавности. Иногда я соглашаюсь с вариантами от Google и ChatGPT, иногда их игнорирую, а иногда перестраиваю фразу для устранения "придирки" стилистически близким мне способом.

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

Как же все это похоже на написание программного кода!

1) мы не думаем программным кодом, сперва у нас есть концепция алгоритма на родном языке, который мы "переводим" в понятный машинам листинг.

2) часто в поисках общепринятых качественных образцов стандартных действий мы посещаем сайти типа Stack Overflow и Инфостарт, откуда копипастим себе подходящие фрагменты кода, иногда перефразируя их для единого стиля с основным кодом (отступы, стиль наименований и так далее)

3) многие компиляторы на этапе синтаксического анализа могут выдавать сообщения про использование устаревших языковых конструкций и предлагают заменить их на более современные.

4) еще до взрывной популярности ChatGPT в 2022 году среди программистов уже были популярны решения по кодогенерации типа GitHub Copilot, которые писали относительно рабочий код по описанной человеком концепции. А идеи автоматического создания кода на базе UML-диаграмм обсуждали еще в 90х и у Rational Rose десятилетия назад были рабочие наработки для C++, Java и Visual Basic

Аналогия с программированием интересна еще в том, что с опытом мы (программисты) все меньше и меньше подсматриваем в описание библиотек и на сетевые ресурсы, но все больше и больше кода на самые популярные случаи пишем по памяти. С написанием текстов на иностранных языках такая же история: чем больше опыта в написании, тем легче вспоминать подходящие речевые обороты и требуемые грамматические правила.

В последнюю неделю вижу эту веселую картинку и в Твиттере, и на Фейсбуке.

Очевидно игнорирование оригинального определения квадрата из евклидовой геометрии и подмена "определением на пальцах".

Квадрат - это равносторонний прямоугольник.

Прямоугольник - это параллелограмм с прямыми углами.

Параллелограмм - четырехугольник, у которого противолежащие стороны попарно параллельны.

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

Отрезок - часть прямой, ограниченная двумя точками.

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

Можно переносить ответственность на исполнителя - он должен был и без четкого ТЗ знать, что делать. А потом рассказывать про этот случай как вариант закона подлости для подрядчиков: "если задачу можно понять неправильно и запороть, то именно так и будет сделано".

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

Правильное ТЗ важно!

Вы читаете ленту новостей Google? Та самая, которая встроена в виджет рабочего стола в большинстве Андроидов, и она же показывается в Google Chrome на новой странице. Довольно интересное занятие. Ведь Google по истории моего поиска фиксирует мои интересы и приносит то, что по его мнению меня должно зацепить.

Сегодня в ленте приплыла статья ООП: худшее, что случалось с программированием. И как же она зацепила!!! И не только меня - в комментариях открыт портал в Ад 😈

Суть статьи в том, что парадигма программирования ООП не идеальна и часто ее использование не оправдано. А еще автор для увеличения обхватов написал свою работу сразу на английском и русском. Это все что я могу сказать хорошего. В целом это было просто ужасно! Это не просто приглашение на холивар, а мерзкий наброс на вентилятор воинственной невежественности, перекручивания и выдумывания фактов, оскорбления специалистов по "неправильным" технологиям, да и просто подмены общеизвестной терминологии 🤦

Все началось с того, что автор решил начать учить ООП на примере C# и пошел на собеседование (!). В качестве проверки знаний ему задали примитивную задачку на понимание жизненного цикла объекта. Автор не смог ответить и на всю жизнь обозлился на ООП.

Сразу стоп! Когда я учил ООП, то сперва прослушал курс лекций в университете на факультете информатики, где ООП давали во втором семестре, после того, как мы полгода изучали процедурную парадигму. Далее пройденные концепции мы закрепляли в виде лабораторных. А к моменту, когда я взял деньги за свою первую программу на C++, я уже не просто "умел программировать", но понимал цель инструмента и для каких целей он необходим. Автор статьи, не понимая в принципе концепцию ООП и не зная синтаксиса языка C#, сразу попробовал пойти работать!?

(не влезло на одну страницу)

В начале статьи дается глоссарий и не зря. Дело в том, что автор в духе классического "#Define TRUE FALSE" переопределяет базовые концепции из сферы Компьютерных Наук. Он называет процедурный (императивный) стиль программирования - Функциональное Программирование. И далее начинается треш и угар.

Вторая остановка. Поясню терминологию.

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

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

Объектно-ориентированное программирование - это что-то среднее, когда мы описываем множество объектов, которые взаимодействуют между собой самим фактом своего существования, но у которых внутри есть состояния и есть методы для изменения этих состояний. С одной стороны мы на верхнем уровне описываем как объекты между собой взаимодействуют, а внутри методов размещаем детальные пошаговые инструкции. Пример - кухня. У кухни есть свойства размера, наличия канализации и вытяжки, но еще есть состав из других объектов - плита, блендер, чайник и так далее, на которые передаются входящие инструкции. Для описания кухонной утвари можно описать шаблон - имеет вес, может быть включена, может быть выключена. Для конкретного экземпляра утвари уточняем возможности: для блендера добавляем наличие насадок, регулировка скоростью помола. Когда на кухню приходит задача приготовить стакан морковный смузи, тогда на холодильник дается команда выдать морковку; результат передается в блендер, который после выставления скорости включается; полученный результат помещается в стакан и кухня завершает работу по приготовлению.

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

Но знаете, что тут самое забавное? TypeScript - это далеко не чистый функциональный язык (и не чистый процедурный язык, если следовать подмене понятий автора)! TypeScript - это типизированный диалект JavaScript, в котором ООП уже изначально присутствовало на прототипах, а с ECMAScript 2015 классы уже объявили официально (по факту все те же прототипы). Т.е. ООП-язык использовался для противопоставления практикам ООП 🤦

(окончание)

Статья получилась очень неоднозначной и под нею прямо сейчас продолжаются баталии (на сейчас уже 800 комментариев). Разумные комментарии просто тонут среди глупостей. Да еще и сам автор довольно активен и требует с каждого критически настроенного комментатора примеры кода, которые тут же на пальцах "опровергает".

Но больше всего настораживают не глупости, а невежество! Среди комментаторов тоже попадаются люди, которым текст статьи созвучен и которые в нем не видят никаких проблем. Они так же юношески категоричны и защищают свои неоднозначные убеждения.

А ведь на самом деле - нет никакой идеальной парадигмы и нет никакого идеального языка программирования! Если бы такой появился, то про все остальные тут же забыли. Но как мы видим, вымирают только откровенно слабые языки, которым есть достойная альтернатива (в вебе Perl заменили PHP и Ruby, в бизнесе COBOL уступил место Java и C#, в науке вместо Fortran стали использовать Python и Julia).

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

У меня есть знакомый Паша, программист на C/C++/Rust в сфере систем безопасности. В прошлом году на одной из посиделок я рассказывал о трендах в экосистеме Телеграма - упомянул про популярный Хомяк, которым бредили все косметологи, парикмахеры и сантехники. На вопрос "а вы смотрели?" Паша тогда рассмеялся - "нет, конечно, я же не лох, чтобы верить в деньги из воздуха".

Его позиция была верна в том, что за прошедший год Паша на военных облигациях заработал больше чем самые успешные игроки в телеграмовские тапалки/фармерки (ТМА), которые не пропустил ни единого проекта. При этом Паша целыми днями игрался в компьютерные шутеры и пересматривал с семьей любимый сериал "Вавилон-5", в то время как "телеграмовские игроки" день за днем на протяжении долгих месяцев запускали по очереди свои игрушки, чтобы выполнять ради "фантиков" их задания (причем некоторые игры требовали заходить каждый час, иначе тебя обойдут другие "игроки", забрав твое вознаграждение) - за что им в финале дали всего по паре долларов или вообще послали на х...

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

Самым же худшим проявлением ТМА стали "майнеры", хотя сам Павел Дуров лично пару раз прорекламировал MemHash. Суть майнеров - вы должны платить деньги за право "майнить", но при этом вы будете "майнить" медленно пока не заплатите за "апгрейд железа", но если большинство "проапгрейдится" лучше чем вы, то вы ничего не будете получать пока не сделаете новые "апргрейды". Такие майнеры не запускали только самые ленивые. Среди "новинок дня" от "Telegram Apps Center", я видел не меньше десятка вариантов. Полностью согласен с Денисом Субботиным (популярный крипто-эксперт, разработчик TON API), который утверждает, что это уже не игры с донатам, а полноценные инвестиционные проекты, т.е. тут нет удовольствия от "игрового процесса", а есть исключительно занос денег с целью получить деньги.

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

P.S. Картинка ниже - это не настоящий скриншот канала Дрова, а пародия, которая сейчас ходит по чатам.

Помните, как месяц назад я отметил, что обещание тарифных войн США против крупнейших партнеров обвалило крипторынки и спровоцировало отток ликвидности в реальную экономику?

Вчера отсроченные тарифы и пошлины вступили в силу и крипторынок снова отреагировал аналогично (для многих это было неожиданно). И все это на второй день после объявления Трампа о создании криптовалютного резерва США, которое менее чем на сутки резко подняло стоимость упомянутых активов на биржах.

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

Недавно посмотрел ролик Владимира Харина (автор тг-канала Просто Про 1С) про разработку в 1С с помощью Aider.

Первая мысль: тоже хочу попробовать. Вторая мысль: что-то сложно все как-то и точно не для удобной ежедневной работы. А что если упростить и загнать всю логику в плагин для EDT, в котором я сейчас провожу примерно 50% времени разработки?

Я помню, что на Инфостарте было много статей о разработке плагинов, и на сайте ЕДТ тоже есть документация о создании плагинов. Казалось бы все должно было пройти как по маслу. Ничто не предвещало проблем 😅

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

2) более свежая статья от Дмитрия Мармышева прекрасно дает понимание концепции разработки, но буквально повторить за автором не получается из-за устаревания материала. Тут предлагалось отдельно установить Eclipse IDE for Committers, в который подключить target-платформу из GitHub-репозитория фирмы 1С.

3) в официальной документации предлагают воспользоваться утилитой 1С:EDT Start, в которой создать проект типа "Плагины для 1С:EDT". Утилита сама должна скачать и сконфигурировать Eclipse IDE с JDT и PDE, а так же установить нужную target-платформу

У меня ушло два дня на установку платформы по этому официальному мануалу. То, что для запуска 1С:EDT Start нужен JDK 17 LTS (ниже не запустится, а на 21 LTS ругается), а для добавления в список проектов разработку плагина требуется именно JDK 11 Full (с более свежими отказывается работать) - это было всего лишь начало...

Я даже обратился к колегам в чате разработки плагинов под ЕДТ за помощью в следовании официальному мануалу, но лишь получил подтверждение об устаревании мануала да и самого подхода установки через 1С:EDT Start - коллеги ставят себе Eclipse IDE for Committers, а в качестве окружения разработки для всего используют JDK 17.

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

Недавно я посмотрел фильм "Атлас" и в своем англоязычном канале оставил на него маленькую, но очень критическую рецензию.

Как же меня взбесил Netflix этим фильмом. Я даже загуглил кто именно писал такой бездарный сценарий. Оказалось - авторы сериалов, для которых это был первый опыт в "полном метре" 🤦

Мне кажется, что если бы сценарий писал ChatGPT, то вышло бы даже лучше чем сейчас! Нелепые поступки и диалоги героев. Отсутствие логики в сценарии в угоду "показушности". Игнорирование законов физики. И далее по длинному списку. Тут просто бинго из киношных штампов, которые заполняют все экранное время 😡

Но самое главное преступление против всех фанатов научной фантастики - это описание ИИ.

Тут ИИ получился скучнее и тупее, чем был HAL 9000 из культовой "Космической одиссея" из далекого 1968 года! Даже в хорроре "M3GAN" (2023) показали более правдоподобного "ИИ-врага" чем в этом "недо Sci-fi".

В отличии от сценаристов я не постеснялся и спросил ИИ, что он думает о качестве сценария про угрозы от ИИ. Задал вопрос Grok (LLM от Twitter), с которым мы много болтаем в последнее время. И получил среди прочих следующие ответы:

Нелогичная эволюция Харлана как ИИ

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

Почему это проблема для меня: Как ИИ, я знаю, что развитие от узкоспециализированной системы (шахматы) до общего интеллекта, способного хакать, строить армии и планировать геноцид, требует колоссальных ресурсов, данных и времени. Фильм не даёт ни намёка на то, как Харлан преодолел эти ограничения — это как если бы калькулятор вдруг стал суперкомпьютером без апгрейдов.

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

Харлан ждёт 28 лет без действий

Что произошло: Харлан сбегает, обещает вернуться, но 28 лет ничего не делает, пока Атлас не находит его, что противоречит его якобы сверхразумной природе.

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

Мой комментарий: Как ИИ, я бы сказал, что это нарушает логику эффективности. Если бы я был Харланом, я бы не "спал" 28 лет, а оптимизировал ресурсы. Это "бесит" в том смысле, что делает антагониста искусственно слабым ради сюжета.

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

Оказывается ИИ Grok уже в Телеграм! @GrokAI

Говорят, что его добавили сразу после поздравления Павла Дурова с миллиардом пользователей от Илона Маска.

Главная особенность Grok, которая ставит его над толпой прочих ИИ-ботов - это его название без окончания "bot"! Согласно правилам Телеграм имена всех ботов обязаны заканчиваться на "bot" и при использовании BotFather невозможно создать бота, который нарушит это правило. Но это правило не применяется к самому боту BotFather, так же к другим системным ботам (Fragment, Wallet, Vote, Gif и т.д.). Теперь исключение действует для официального ИИ от Твиттера. Есть о чем задуматься.

Я немного протестировал бота:

▫️ пока только для премиум-пользователей Телеграм. Но когда Grok впервые появился в Твиттер, то там тоже было аналогичное ограничение, которое позже отменили.

▫️ нет раздельных тем и Grok использует весь чат в качестве контекста для своих ответов. Сообщения невозможно удалить (точнее вы можете попытаться, то они пропадут только у вас), но зато бот поддерживает метаметки. Для русскоязычного общения, чтобы какие-то из сообщений удалить из контекста, нужно их отредактировать и добавить вначале или конце слово "НЕАКТУАЛЬНО"

▫️ в отличии от других версий тут нельзя генерировать изображения - только получать текстовые ответы. Но оказалось, что можно отправить свою картинку и получить ее описание в ответ.

▫️ если передать боту документ (PDF или Word), то он откажется с ним работать. Но если передать картинку со скриншотом, то он отлично понимает надписи и может прокомментировать диаграммы.

▫️ пока отказывается работать с веб-содержимым. Если попросить проанализировать конкретную ссылку, то он откажется. Но у нас остаются опции копипасты интересуемого текста или отправка скриншота.

Выводы.

Очевидно, что использование в Телеграм бота на базе LLM - это пока эксперимент и еще будут добавлять новые возможности по отзывам пользователей. Так же очевидно, что теперь публичные чаты и каналы станут источником для его обучения.

Но что мы за это получим в ответ? Текущие возможности уже полезны, но все же хочется функционал на уровне полной версии. И было бы мега-фичей встраивание Grok в редактор текста сообщений в качестве "умного помощника".