Pull to refresh
-23

User

0,1
Rating
Send message

Угу. Поэтому AI - агенту надо формулировать задачи на специально разработанном языке, не допускающем двойного толкования. Раньше такие называли языками программирования, "промпты" - программами, а людей, которые их формируют - "программистами"...

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

В результате человечество сжигает своё будущее в виде:

  • невосполнимых ресурсов, превращаемых в мусор и тепло

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

  • биосферы планеты, постоянно деградирующей

  • войны, ведущиеся чисто ради выгода корпораций, торгующих оружием

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

Есть слабая надежда на Китай и КПК, но они могут и не вытянуть.

А что вы делали, когда кто-то выключал питание на чём-то в промежутке? На свитче или датчике, например?

Про проведение платежа в банке - погуглите, что такое транзакция в SQL и как она реализуется технически. Там всё сделано именно так, чтобы даже выключение питание на всех серверах разом не оставила систему в неопределённом состоянии. И полагаться при этом на то, что "программа подчистит за собой" никто и никогда не будет, потому что завершение программы путём аварийного выключения питания - это наиболее вероятный способ завершения работы для программ, которые рассчитаны на работу 24/7.

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

Ну вот представьте себе, у вас - редактор для файла сложного формата. Пользователь наредактировал всякого, данные у вас в памяти и тут возникла ошибка. Если вы просто "упадёте" - файл останется без этого наредактированного, но хоть корректный. А вот если попытаетесь сохраниться...

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

А если, например, функции передали nullptr вместо имени файла, и в документации этой функции не описано поведение в такой ситуации - я немедленно паникую. Или если передали структуру, в которой должны быть инварианты, а они не выполняются - паникую.

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

Называется это "защитное программирование", и нет никогда никаких причин его не использовать.

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

С++ стандартов где-то позже 11 или 17 существенно переусложнён и идёт по пути языка Ада - т.е. нормальный программист может держать в голове и постоянно пользоваться ограниченным объемом возможностей языка.

Но каждый использует при этом разный набор возможностей.

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

Язык должен быть относительно прост, так чтобы в голову очень среднего программиста помещался целиком.

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

--------------

По поводу исключений и обработки ошибок:

  1. Исключения имеют практический смысл в двух случаях: а) в модульных тестах для выхода по панике без падения процесса б) для использования вместо longjump.

  2. Если у вас в коде есть ошибка, которую вы не знаете как обработать - кидать исключение - самая глупая идея, которая только может придти вам в голову. Самое разумное в этом случае: немедленно завершить процесс. Попытка продолжения скорее всего приведёт к худшим последствиям, чем немедленное завершение - например, будет не просто потеря, но искажение данных. Если в какой-то ситуации вы провели анализ и выяснили, что "в данном месте, деление на ноль может случиться при вот таких условия, и в этом случае мы должны сделать вот это" - вам не надо кидать исключение. А если вы не можете понять, "как вот здесь оказалось деление на ноль" - немедленно паникуйте с дампом памяти.

А что вы делаете, когда на очередной вопрос вам отвечают: "rm -rf /" ?

Пусть для начала винду 11 перепишут так, чтобы не глючила.

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

Прибыль? А зачем? У них бесконечный источник бабла. Можно творить что угодно.

И да, личное будущее всего топ-менеджмента этих компаний уже обеспечено навсегда - ну, если доллар не гикнется в принципе.

Да понятно всё.

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

Тут главное вовремя резюме обновить и съ***ться в другую компанию.

Ну а то, что в Микрософт - жопа, я уже понял. Windows 11 как бы намекает...

Так госплан же. Нормально. Про ЭРП когда-нибудь слышали?

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

-----------------------------------------------------

Вот почему кто-то считает стоимость, определённую "торговлей" кучи ублюдков на бирже "справедливой", а? Чем и кем она "справедлива"?

А давайте определять цену на картошку по результату боксёрского поединка, например?

Или футбольного матча?

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

А какой из этого следует вывод?

А вывод следует очень, очень простой.

Тех, кто придумал, разрешил, и оправдывает биржи, на которых возможна вот такая "высокочастотная торговля" надо вывести на улицу и расстрелять. Можно колосажание или четвертование, по местным обычаям.

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

За саму такую идею надо убивать.

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

К сожалению, 90-95% программистов сейчас занимаются абсолютно бессмысленной работой.

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

В США до сих пор есть идиоты, которые считают, что "биржа" создаёт деньги или что "игра на бирже" без инсайдерской информации это что-то кроме обычной азартной игры в любом казино?

В том-то и дело, что именно для черновой работы его использовать-то и нельзя.

Нет возможности сказать "а найди-ка косяки в этом документе" - доверять результатам просто опасно.

Ну а о "чистовой" работе вообще без шансов.

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

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

А не идиотизм ли это, извините? Как по классикам: "Внутре у ней нейронка", ага.

Какое вообще отношение нейросеть может иметь к численному решению дифуров?

Ну то есть нейросеть - да, сама работает через численное решение дифуров, но с помощью совершенно не-ИИ алгоритмов.

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

Это всё равно как сказать: "а давайте мы будем модель с миллионами ячеек не компьютером обсчитывать, а посадим человека поумнее - чтобы он вручную считал методом Рунге-Кутты.

Т.е. "натренированная" нейросеть должна заменить кого?

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

Единственный вопрос, который встаёт: а нахрена это делать?

Идентификация по серийному номеру (или, например, MAC-адресу) имеет один существенный недостаток - надо настраивать для каждого экземпляра устройства.

Т.е. если вы делаете девайс с тремя сетевыми платами, серийно делаете, хотя бы по 100 штук в месяц - вас задолбает привязка по МАС-адресу каждой платы в каждом девайсе.

А ещё при ремонте - плату заменил, меняй правила в udev. А меняет - местный персонал, который открутить-прикрутить может, а вот прописать правило в udev - нет.

Это как минимум чрезвычайно неудобно.

--------------------

Можно конечно скрипт написать, типа "вставьте кабель/нажмите/где лампочка зажглась скажите" - который бы позволял более-менее автоматизировать привязку по серийнику. Но всё равно неудобно.

Information

Rating
3,747-th
Registered
Activity