Поразмыслив над вашей идеей всплыло куча подводных камней.
Например как учитывать новые добавленные строки? В старой таблице не будет этих строк и собственно не будет 4-го поля для анализа.
Как учитывать удалённые строки? Это придётся ещё тогда служебный столбец добавлять типа deleted. И его тоже анализировать при каждом цикле?
Одновременно транзакция write может работать только 1. Потому как на каждый write придётся дублировать все эти поля.
Понял вашу идею.
И что получаем. На каждый цикл проверки делать дополнительную проверку 4 поля. И того если имеем миллион строк. Проверок делаем 2 миллиона при переборе (в случае когда условие например придётся на последнюю строку). А если учесть что это будут if с переходом — то скорее всего поломается оптимизация в проце для чистого перебора массива.
Далее мы должны в каждой таблице загруженной в RAM делать дополнительную колонку — например int. И того на 1M строк имеем лишние 4Mб данных.
Меня больше всего волнует потеря производительности для двойной проверки каждой строки.
БД про которую я пишу это не in-memory БД. А работает на страницах. Но в любом случае, если таблица без индекса — то её нужно будет загрузить всю в RAM — где в цикле проверять каждую строку. Если памяти не хватает — придётся выгружать первые страницы(которые уже не нужны) из RAM, пред загрузкой последних.
То что вы описали — это то что описал и я. В цикле для каждого столбца каждой строки придётся вызывать функцию которая будут проверять изменялось ли значение. Проверка это будет в общем случае как перебор другого массива в котором будут например структуры (номер строки, номер столбца, новое значение). И избавится от этого дикого оверхеда не получится.
Понятно про что вы пишете. Вопрос в том имеет ли это смысл, Смотрите — самый простой, и самый быстрый вариант хранения таблицы в памяти — одномерные массивы массивов. Тогда SELECT без индекса — это просто for по массиву. Он делается максимально быстро в кеше процессора.
С другой стороны имеем тот же массив массивов + новые изменённые данные. Где их хранить? Ну допустим имеем новый массив. В котором например структуры (номер строки, новое значение). Тогда вместо простого for, мы должны на каждом цикле делать запрос к новому массиву, перебирать его и искать изменённую строку. Получаем дикий оверхед. Как избавится от этого оверхеда? Так на вскидку ничего нормального в голову не приходит. А если изменений на гигабайт — то вообще получим неработоспособную систему — такой SELECT просто зависнет навечно.
И тут получаем мой вопрос — а ради чего это нужно?
Пока напрашивается простой вариант — сделать 2 вида транзакций:
Fast — это в которых нету внутренних select, либо нас устраивают устаревшие данные. В таких транзакциях блокировать таблицу в конце транзакции.
И второй вариант — с полной блокировкой таблицы.
Что касается собственной разработки БД.
По поводу преимуществ собственной разработки уже были да и будут миллион дискуссий, более того всё существующее ПО это когда то собственная разработка. Но я согласен — без явной причины, на такой подвиг я бы не согласился ни за что. Нас вполне устраивал Postgres. Тут мне в личку писали, я там подробно ответил причину почему всё таки своя БД. Приведу ответ тут:
По поводу БД. Решение написать свой велосипед был непростым, но ему предшествовала 1 причина. Изначально БД была MSSQL, давно правда, потом перешли на Postgres. И он собственно устраивал на 100%. Но как то в 1 момент на 1 из проектов вылез непонятный косяк. Postgres периодически рандомно подвисал на транзакциях. Проблему искали 3 месяца. Что только не делали. Обложили всё что можно логами. Postgres заставили выводить все логи которые он может. Но блин из логов было только что мол этот запрос выполняется 40 секунд. Почему — хрен знает. Даже написали свой провайдер (до этого был Npgsql), думали проблема с коннектами.
А причина потом оказалась до банального проста. Кабель соединяющий один из RAID дисков — подгнил и периодически глючил. И postgres — просто периодически висел в ожидании записи на диск данных в WAL. И НИГДЕ ПРО ЭТО НЕ писал.
Собственно боязнь очередной нерешаемой подставы — привёл к решению собственной БД. Где можно посмотреть ВСЁ.
БД сейчас в стадии разработке. Используется C# и .net core. Для нас такое решение идеально потому как позволяет применить 1 интересную вещь. БД используется для web платформы, которая тоже написана на C# и .net core. БД — встраиваемая (вариант автономной работы тоже закладывается). И в режиме встраивания можно объединить обработку запроса в web сервере и БД в 1 поток с одним адресным пространством. Написал сумбурно — но смысл прост, уберется прослойка в виде TCP соединения с базой данных, и достигается максимальное быстродействие. И главное работа с БД у нас построена на процедурах. Писать процедуры на языке SQL — тот ещё геморрой, но мы привыкли уже. В нашей же БД процедуры пишутся на C#. NET вообще замечательная платформа. Лучшая по отладке. Например типичный кейс — приконектится из windows к серверу linux на другой стороне шарика к рабочему процессу в режиме отладки и у себя в студии просто по шагам отлаживать в исходном коде, с просмотром переменных и прочего. Иногда только так можно найти баг, который у тебя в локальной среде не воспроизводится.
Сейчас БД находится в стадии разработки. Например изначально был только управляемый код, что бы отладить основные механизмы. Сейчас переписываться под неуправляемый — что бы получить скорость. Разработки ещё на год…
Параллельно пишется менеджер для работы с БД. По типу SQL Manager for PostgreSQL. Тоже непростая вещь.
В дальнейшем планируется выложить БД в opensource. Но пока рано.
SCN — у нас тоже пару раз мелькал в обсуждениях. Ничего сложного нету что бы сделать какой нибудь long и инкриментировать его в транзакциях. Вот только куда и зачем это применить так и не нашлось. И главное это ни как не решает проблему которую я описал. А именно где хранить изменения которые произошли внутри транзакции — напрямую в таблицах RAM или в другом месте. А в таблицы данные переносить при выходе из транзакции. И в этот момент уже точно — хочешь не хочешь а таблицу придётся блокировать. Нельзя вносить одновременно изменения в один массив (таблицу) из разных потоков. Иначе такая каша может получится. Типа в одном потоке мы удалили строку, а в другом вставили. А в реальности существует строка или нет будет решать рандом переключателя задач.
Выигрыш записывать изменения в конце транзакции только в том что это время будет меньше чем время всей транзакции.
В нашей БД такой механизм применить легко даже не сильно меняя код. А именно. При каждом INSERT/UPDATE/DELETE — идёт запись в WAL. Так вот просто комментировать строку изменения таблицы, при этом изменения WAL останется. А в конце транзакции применить WAL к таблицам. Точно также как WAL применяется при старте БД. Также решается мега геморрой отката транзакции — его просто не будет, потому как таблицы RAM не изменились.
Но тогда внутри транзакции SELECT будет работать на устаревших данных.
И ещё непонятно. При старте транзакции указывается список таблиц которые должны быть неизменны на момент старта транзакции, транзакция же атомарна, что бы вся логика внутри транзакции отработала правильно. Но в случае если не блокировать таблицы — и изменения в них могут вносить другие транзакции, может получится каша.
Например делаем внутри транзакции SELECT сколько денег у клиента. Возвращается что 100$. Далее идём делать какую то логику. А в этот момент в другой транзакции снимаем эти 100$. Но при этом мы находимся в первой транзакции и она работает по логике что у клиента есть 100$.
Короче есть на чем подумать. Если внутри транзакции ненужны селект — то можно не блокировать таблицы на время транзакции. В сценариях описанных выше — такой подход неприемлем.
С вами согласен. Пост просто пролистал и сразу перешёл к комментам.
Но по поводу страниц хотел бы сказать зачем мы их применили у себя. Не буду описывать тернисты путь, как мы выбирали размер и прочее, напишу 2 главные причины.
Страницы на диске по 8Кб — основная причина, если мы изменили 1 байт в таблице, не хотелось бы переписывать 16Мб на диске, если страница например 16Мб. Изначально такой размер был выбран для получения преимуществ в скорости чтения с диска, и количества файлов в файловой системе, которое тоже ограничено, и прочего. Но последующая разработка показала оптимальным всё таки размер совпадающий с размером странице диска.
Страница в RAM — тоже равна 8Кб. Основная причина — экономия RAM. Загружать в RAM только те страницы которыми пользуешься.Опять же если страница RAM и DISK одинакового размера — то упрощает их синхронизацию.
Тут надо различать как бы 2 БД. 1 находится в виде файлов на диске. Другая загруженная в RAM. Как раз вся работа с БД идёт в RAM. А на диск уже идёт только синхронизация.
И Вакуум запускается для диска. Потому как на диске используется страничная организация памяти.
А вот для RAM — там можно безнаказанно выделять и удалять память. Иначе можно вставить гигабайт данных, а потом удалить. И что этот гигабайт будет висеть мёртвым грузом в RAM?
Но я не знаю как точно работает postgres. Я написал как это должно работать по логике.
В разработке сейчас собственная реляционная табличная БД. Причина собственной разработки это отдельная тема. И честно сказать — это самый мозговыносящий проект в моей практике.
Прочитав ваш комментарий я прекрасно удивил одну из проблем которую мы решали в процессе проектирования. И у меня возник вопрос.
Собственно как работает доступ к таблицам. Разные потоки делают запросы на read — при этом таблица лочится — но все могут получить доступ на чтение. Если в очереди запросов подходит запрос write — то ожидается пока все read не закончатся, потом лочится на write — и далее с таблицей работает 1 поток.
Все INSERT/UPDATE/DELETE — это write запросы и делаются внутри транзакции. И представим ситуацию — мы сделали UPDATE на гигабайт данных, или DELETE — а далее делаем SELECT в тойже транзакции — и мы должны получить уже изменённые данные. Самое простое — это когда мы залочили таблицу и делаем изменения прямо в ней. И Select тоже в ней. Если придётся откатывать транзакцию — то это тяжёлая операция. В нашем случае — идёт восстановление таблицы из журнала WAL. Также при откате Текущий WAL транзакции не записывается на диск.
Вы же описали ситуацию когда изменения INSERT/UPDATE/DELETE не делаются в существующие таблицы, а делаются кудато в другое место. Ну допустим в массив какой-то. Соответственно в это время с таблицей могут работать другие в режиме read.
Но как тогда делать SELECT? Путь это простая таблица без индексов. Это будет набор массивов в котором просто циклом перебираем строки. Но в вашем случае надо как то знать какие строки изменённые.
Конечно можно придумать геморройный механизм этого. Но это будет намного медленнее и жрать память. Простой перебор одномерного массива намного быстрее, чем перебор с проверкой — а не изменилась ли строка? А ещё надо учитывать DELETЕ — который может вообще пол таблицы в разных местах выкинуть.
Вобщем вопрос — а нужно ли такое поведение? Я вижу как минимум например засаду в следующем сценарии. Сделали платёж — запустился скрипт изменения баланса в БД — но подавис по времени. Если сделать сразу новый платёж — то мы получим неправильный баланс денег.
Запомнился один случай из многолетней практики. Запускаю код и он неожиданно выдаёт правильный результат сразу. Что меня очень удивило. Начал разбираться и оказалось — правильный «результат» был выдан потому что тот код который должен был быть протестирован, до не го даже не дошла программа. Не работала та часть которая уже вроде была оттестирована и должна была работать правильно.
Разумеется. Так и с роботами будет. Каждое чп — расследование, доработка ПО.
Но никого же не посадят, если текущее ПО было согласовано, работало, но не смогло предусмотреть какой то невероятный случай.
Собственно с птицами — тут даже никакие доработки не помогут. Птицы просто есть и ничего с ними не поделаешь. И не смотря на это — самолёты летают. А единичные не везунчики, которые разбились, ну не повезло им — дело закрыто. Остальные летайте дальше.
Понял вашу мысль про ответственность водителей. И честно говоря вообще не вижу тут проблемы. Во первых законов можно наиздавать сколько угодно, печальная практика последнего времени это подтверждает.
А есле конкретно водителей то не вижу проблемы. По идеи отлаженный робот водитель не должен будет ошибаться. А если ошибся в случае поломки железа — ну что сказать, значит тебе не повезло. Короче — анализируются логи робота. Если работал по инструкции но всё равно накосячил — форс мажор.
Никто же не виноват когда птица попадает в двигатель самолёта и все погибают.
А мне в детстве досталась какая то ЕС-ка. Какая не помню, аналог 286 или что то того. Там дос и паскаль был — я на нём игры писал для себя ))) Карточные. И играл потом в них. А ещё там был «Prince of Persia». Правда скорость работы была порой 1 кадр в секунду, две. А для меня это было как читы, проходить сложные моменты.
В последствии уже увидел как эта игра игралась на 8-битных приставках и меня поразила скорость. Как вообще можно было выиграть с такой скоростью )
В детстве, когда ещё и диалапа нормального не было, много сидел за монохромным монитором. Зелёным. Рентген фигачил так что зимой загар появлялся на лице. Зрение в последствии осталось нормальным — генетика наверно хорошая.
Много лет сидел на светлой. Когда появились тёмные темы — плювался и не мог понять почему на ней сидят. И как то незаметно сам подсел на тёмную. А от светлой начали глаза слезится.
И дальнейшая практика показала что — редакторы кода в которых сидишь целыми днями только тёмная. Сайты — дело привычки. Есть которые только светлые воспринимаются. Есть тёмные.
И по поводу тёмного. Если у вас тёмный #000 а светлый #FFF — то глаза вытекут через час. Тёмный — фон только #333-444, текст #AAA-CCC.
Тёмная контрастная — это ужасно.
В книге «Ложная слепота», автор описал встречу человечества в лице космического корабля с представителями инопланетной цивилизации, индивидуумы которых эволюционно не имели самосознания, но при этом развивались, проявляли логику и пытались навялять этому самому человечеству )
Блин вот вообще не понял про что речь. ИИ наверное понял бы )))
прямого взаимодействия с реальным миром
Игры и виртуальные миры что ли? Но не подходит под контекст диалога — вроде про профессии говорим.
Про уголовную ответственность — тут вообще лексика поломаная. Ну или опять же я не ИИ…
Ну с точки зрения текущего существования. Капитализма и людей на его вершинах.
Когда появится государство «0» как в аниматрице… Ну там свои приоритеты будут.
В принципе я могу понапридумывать вполне логичных приоритетов для машин, но лень…
И да не стоит забывать что сознание достаточно хрупкая вещь как показала практика. Вон человеки с миллионами лет дебагинга, до сих пор имеют всякие fatal exeption по типу шизофрений и прочего. Не думаю что сию проблему избегут кремневые (ну или какое там будут) сознания.
Ну 9 из 10 (взято для примера что очень много) человек тоже не знают свою цель в жизни. большинство сходится на мысли, что в детях. Т.е. банальное продолжения рода.
А вот для ИИ как раз всё очевидно. Я как разработчик заложу любую цель. Убить всех человеков. Заработать все деньги. И прочее. Или вообще без цели — просто существование. И опять же если это сильный ИИ то он будет обладать памятью и модулем мыслей. Где будут постоянно крутится блоки информации. И изначальная цель может быть скорректирована в зависимости от новой входной информации.
И новую цель можно будет увидеть в логах.
Либо я как разработчик зашью главную цель аппаратно — что бы её приоритет всегда был выше чем любые программные цели.
Собственно какая цель будет у ИИ всё более прозрачно, чем у мясных аналогов.
Первые думаю умрут водители. Умерли же когда то извозчики. Потом умрут всякие менеджеры — на всех кассах. Где люди по сути выполняют рутинную обезьянью работу.
Это считай уже значительная часть населения.
В общем везде не нужен будет человек где можно поставить робота.
Человек сможет выиграть только если он окажется дешевле. Но т.к. робототехника будет удешевляться с каждым днём — то в результате всё равно проиграет конкуренцию.
Так же человек сможет конкурировать в сфере интеллектуального контента. Музыка, книги и прочее. И да, работа it-шника — это тоже интеллектуальный контент. Потому как архитектура программы — тоже своего рода как книга, песня. Поэтому если it-шники и уйдут то в череде последних.
Если создадут сильный ИИ то стоит боятся вообще всем. Никто из людей не нужен будет.
И по поводу IT-шников. Они (за редким исключением) не используются «высокой» математикой. А используют на полную логику и абстрактно объектное мышление. Это как мозг — работа отдельного нейрона достаточно примитивна. А вот взаимосвязь всех нейронов — порождают сложнейшие абстракции по типу сознания и прочего.
Так и программа — каждая конкретная часть примитивна и математика там на уровне сложения и присвоения переменных. Но вот что бы удержать всю программу в голове, каждый виртуальный модуль, и при этом что бы каждая автономная часть работала в едином оркестре. Не каждые мозги на такое способны — собственно отсюда и зарплаты у таких людей.
Есть такое понятие у it-тишников. Погружение в контекст задачи. Это как раз и есть чтение текста программы, и выстраивание в голове архитектуры. Взгляд даже на свой проект, спустя время, не сильно отличается как если бы на тоже самое смотрела «блондинка». Без контекста у обоих в голове будет одинаковая каша.
Мое мнение — по чёткому ТЗ даже уже на текущем уровне возможно автоматическое создание программ. Потому что чёткое ТЗ — это по сути своей уже программа. Но IT как правило работают в поле где ТЗ вообще отсутствует. Не зря же придумали всякие аджайл и спринты. Потому как что конкретно в итоге получится — неизвестно. Может вообще после очередного спринта всё с ног на голову встанет. И по этому программистам пока не стоит боятся за работу.
Например как учитывать новые добавленные строки? В старой таблице не будет этих строк и собственно не будет 4-го поля для анализа.
Как учитывать удалённые строки? Это придётся ещё тогда служебный столбец добавлять типа deleted. И его тоже анализировать при каждом цикле?
Одновременно транзакция write может работать только 1. Потому как на каждый write придётся дублировать все эти поля.
И что получаем. На каждый цикл проверки делать дополнительную проверку 4 поля. И того если имеем миллион строк. Проверок делаем 2 миллиона при переборе (в случае когда условие например придётся на последнюю строку). А если учесть что это будут if с переходом — то скорее всего поломается оптимизация в проце для чистого перебора массива.
Далее мы должны в каждой таблице загруженной в RAM делать дополнительную колонку — например int. И того на 1M строк имеем лишние 4Mб данных.
Меня больше всего волнует потеря производительности для двойной проверки каждой строки.
То что вы описали — это то что описал и я. В цикле для каждого столбца каждой строки придётся вызывать функцию которая будут проверять изменялось ли значение. Проверка это будет в общем случае как перебор другого массива в котором будут например структуры (номер строки, номер столбца, новое значение). И избавится от этого дикого оверхеда не получится.
С другой стороны имеем тот же массив массивов + новые изменённые данные. Где их хранить? Ну допустим имеем новый массив. В котором например структуры (номер строки, новое значение). Тогда вместо простого for, мы должны на каждом цикле делать запрос к новому массиву, перебирать его и искать изменённую строку. Получаем дикий оверхед. Как избавится от этого оверхеда? Так на вскидку ничего нормального в голову не приходит. А если изменений на гигабайт — то вообще получим неработоспособную систему — такой SELECT просто зависнет навечно.
И тут получаем мой вопрос — а ради чего это нужно?
Пока напрашивается простой вариант — сделать 2 вида транзакций:
Fast — это в которых нету внутренних select, либо нас устраивают устаревшие данные. В таких транзакциях блокировать таблицу в конце транзакции.
И второй вариант — с полной блокировкой таблицы.
Что касается собственной разработки БД.
По поводу преимуществ собственной разработки уже были да и будут миллион дискуссий, более того всё существующее ПО это когда то собственная разработка. Но я согласен — без явной причины, на такой подвиг я бы не согласился ни за что. Нас вполне устраивал Postgres. Тут мне в личку писали, я там подробно ответил причину почему всё таки своя БД. Приведу ответ тут:
Выигрыш записывать изменения в конце транзакции только в том что это время будет меньше чем время всей транзакции.
В нашей БД такой механизм применить легко даже не сильно меняя код. А именно. При каждом INSERT/UPDATE/DELETE — идёт запись в WAL. Так вот просто комментировать строку изменения таблицы, при этом изменения WAL останется. А в конце транзакции применить WAL к таблицам. Точно также как WAL применяется при старте БД. Также решается мега геморрой отката транзакции — его просто не будет, потому как таблицы RAM не изменились.
Но тогда внутри транзакции SELECT будет работать на устаревших данных.
И ещё непонятно. При старте транзакции указывается список таблиц которые должны быть неизменны на момент старта транзакции, транзакция же атомарна, что бы вся логика внутри транзакции отработала правильно. Но в случае если не блокировать таблицы — и изменения в них могут вносить другие транзакции, может получится каша.
Например делаем внутри транзакции SELECT сколько денег у клиента. Возвращается что 100$. Далее идём делать какую то логику. А в этот момент в другой транзакции снимаем эти 100$. Но при этом мы находимся в первой транзакции и она работает по логике что у клиента есть 100$.
Короче есть на чем подумать. Если внутри транзакции ненужны селект — то можно не блокировать таблицы на время транзакции. В сценариях описанных выше — такой подход неприемлем.
Но по поводу страниц хотел бы сказать зачем мы их применили у себя. Не буду описывать тернисты путь, как мы выбирали размер и прочее, напишу 2 главные причины.
Страницы на диске по 8Кб — основная причина, если мы изменили 1 байт в таблице, не хотелось бы переписывать 16Мб на диске, если страница например 16Мб. Изначально такой размер был выбран для получения преимуществ в скорости чтения с диска, и количества файлов в файловой системе, которое тоже ограничено, и прочего. Но последующая разработка показала оптимальным всё таки размер совпадающий с размером странице диска.
Страница в RAM — тоже равна 8Кб. Основная причина — экономия RAM. Загружать в RAM только те страницы которыми пользуешься.Опять же если страница RAM и DISK одинакового размера — то упрощает их синхронизацию.
И Вакуум запускается для диска. Потому как на диске используется страничная организация памяти.
А вот для RAM — там можно безнаказанно выделять и удалять память. Иначе можно вставить гигабайт данных, а потом удалить. И что этот гигабайт будет висеть мёртвым грузом в RAM?
Но я не знаю как точно работает postgres. Я написал как это должно работать по логике.
Прочитав ваш комментарий я прекрасно удивил одну из проблем которую мы решали в процессе проектирования. И у меня возник вопрос.
Собственно как работает доступ к таблицам. Разные потоки делают запросы на read — при этом таблица лочится — но все могут получить доступ на чтение. Если в очереди запросов подходит запрос write — то ожидается пока все read не закончатся, потом лочится на write — и далее с таблицей работает 1 поток.
Все INSERT/UPDATE/DELETE — это write запросы и делаются внутри транзакции. И представим ситуацию — мы сделали UPDATE на гигабайт данных, или DELETE — а далее делаем SELECT в тойже транзакции — и мы должны получить уже изменённые данные. Самое простое — это когда мы залочили таблицу и делаем изменения прямо в ней. И Select тоже в ней. Если придётся откатывать транзакцию — то это тяжёлая операция. В нашем случае — идёт восстановление таблицы из журнала WAL. Также при откате Текущий WAL транзакции не записывается на диск.
Вы же описали ситуацию когда изменения INSERT/UPDATE/DELETE не делаются в существующие таблицы, а делаются кудато в другое место. Ну допустим в массив какой-то. Соответственно в это время с таблицей могут работать другие в режиме read.
Но как тогда делать SELECT? Путь это простая таблица без индексов. Это будет набор массивов в котором просто циклом перебираем строки. Но в вашем случае надо как то знать какие строки изменённые.
Конечно можно придумать геморройный механизм этого. Но это будет намного медленнее и жрать память. Простой перебор одномерного массива намного быстрее, чем перебор с проверкой — а не изменилась ли строка? А ещё надо учитывать DELETЕ — который может вообще пол таблицы в разных местах выкинуть.
Вобщем вопрос — а нужно ли такое поведение? Я вижу как минимум например засаду в следующем сценарии. Сделали платёж — запустился скрипт изменения баланса в БД — но подавис по времени. Если сделать сразу новый платёж — то мы получим неправильный баланс денег.
Но никого же не посадят, если текущее ПО было согласовано, работало, но не смогло предусмотреть какой то невероятный случай.
Собственно с птицами — тут даже никакие доработки не помогут. Птицы просто есть и ничего с ними не поделаешь. И не смотря на это — самолёты летают. А единичные не везунчики, которые разбились, ну не повезло им — дело закрыто. Остальные летайте дальше.
А есле конкретно водителей то не вижу проблемы. По идеи отлаженный робот водитель не должен будет ошибаться. А если ошибся в случае поломки железа — ну что сказать, значит тебе не повезло. Короче — анализируются логи робота. Если работал по инструкции но всё равно накосячил — форс мажор.
Никто же не виноват когда птица попадает в двигатель самолёта и все погибают.
В последствии уже увидел как эта игра игралась на 8-битных приставках и меня поразила скорость. Как вообще можно было выиграть с такой скоростью )
И дальнейшая практика показала что — редакторы кода в которых сидишь целыми днями только тёмная. Сайты — дело привычки. Есть которые только светлые воспринимаются. Есть тёмные.
И по поводу тёмного. Если у вас тёмный #000 а светлый #FFF — то глаза вытекут через час. Тёмный — фон только #333-444, текст #AAA-CCC.
Тёмная контрастная — это ужасно.
Игры и виртуальные миры что ли? Но не подходит под контекст диалога — вроде про профессии говорим.
Про уголовную ответственность — тут вообще лексика поломаная. Ну или опять же я не ИИ…
Когда появится государство «0» как в аниматрице… Ну там свои приоритеты будут.
В принципе я могу понапридумывать вполне логичных приоритетов для машин, но лень…
И да не стоит забывать что сознание достаточно хрупкая вещь как показала практика. Вон человеки с миллионами лет дебагинга, до сих пор имеют всякие fatal exeption по типу шизофрений и прочего. Не думаю что сию проблему избегут кремневые (ну или какое там будут) сознания.
А вот для ИИ как раз всё очевидно. Я как разработчик заложу любую цель. Убить всех человеков. Заработать все деньги. И прочее. Или вообще без цели — просто существование. И опять же если это сильный ИИ то он будет обладать памятью и модулем мыслей. Где будут постоянно крутится блоки информации. И изначальная цель может быть скорректирована в зависимости от новой входной информации.
И новую цель можно будет увидеть в логах.
Либо я как разработчик зашью главную цель аппаратно — что бы её приоритет всегда был выше чем любые программные цели.
Собственно какая цель будет у ИИ всё более прозрачно, чем у мясных аналогов.
Первые думаю умрут водители. Умерли же когда то извозчики. Потом умрут всякие менеджеры — на всех кассах. Где люди по сути выполняют рутинную обезьянью работу.
Это считай уже значительная часть населения.
В общем везде не нужен будет человек где можно поставить робота.
Человек сможет выиграть только если он окажется дешевле. Но т.к. робототехника будет удешевляться с каждым днём — то в результате всё равно проиграет конкуренцию.
Так же человек сможет конкурировать в сфере интеллектуального контента. Музыка, книги и прочее. И да, работа it-шника — это тоже интеллектуальный контент. Потому как архитектура программы — тоже своего рода как книга, песня. Поэтому если it-шники и уйдут то в череде последних.
И по поводу IT-шников. Они (за редким исключением) не используются «высокой» математикой. А используют на полную логику и абстрактно объектное мышление. Это как мозг — работа отдельного нейрона достаточно примитивна. А вот взаимосвязь всех нейронов — порождают сложнейшие абстракции по типу сознания и прочего.
Так и программа — каждая конкретная часть примитивна и математика там на уровне сложения и присвоения переменных. Но вот что бы удержать всю программу в голове, каждый виртуальный модуль, и при этом что бы каждая автономная часть работала в едином оркестре. Не каждые мозги на такое способны — собственно отсюда и зарплаты у таких людей.
Есть такое понятие у it-тишников. Погружение в контекст задачи. Это как раз и есть чтение текста программы, и выстраивание в голове архитектуры. Взгляд даже на свой проект, спустя время, не сильно отличается как если бы на тоже самое смотрела «блондинка». Без контекста у обоих в голове будет одинаковая каша.
Мое мнение — по чёткому ТЗ даже уже на текущем уровне возможно автоматическое создание программ. Потому что чёткое ТЗ — это по сути своей уже программа. Но IT как правило работают в поле где ТЗ вообще отсутствует. Не зря же придумали всякие аджайл и спринты. Потому как что конкретно в итоге получится — неизвестно. Может вообще после очередного спринта всё с ног на голову встанет. И по этому программистам пока не стоит боятся за работу.