Думаю какая то недоделанная заглушка. Закрываю сайт. У меня мозила.
Читаю вашу статью до конца. Что то тут не так. Вроде другие люди открывают ваш сайт и видят не то что я.
Пробую открыть ваш сайт опять - и обнаруживаю интересную функциональность. Если мышкой не поводить по экрану - ни одна статья не будет загружена. Т.е. вся подгрузка висит на javascript событии.
Вроде поисковики давно уже научились выполнять яваскрит на странице, но если краулер настроен только на текст - он ничего не увидит на вашем сайте. Даже я человек попался на такое.
На мобильнике наверно тоже не очень (не проверял).
В статье прослеживается мысль которую я неоднократно описывал тут.
Любая программа это алгоритм. Алгоритм работы даже одного инпута на форме может быть очень большим. Это всяческие ограничения на ввод, описание автоматических действий при вводе текста, по типу автокоррекции, запрету определённых символов и прочего.
И тут мы приходим к сути проблемы. За многие десятилетия истории алгоритмов, человечество пришло к самому эффективному способу их точного описания - это код.
В вайбкодинге - мы пытаемся описать алгоритм человеческим языком. И этот способ проигрывает по качеству наглядности и минимализму обычному коду.
Отсюда в вышеописанной статье есть предостережения по типу - ни в коем случае не кидайте LLM не полный промт. Иначе она сама на-галлюцинирует такого, что потом это просто нереально отладить. Но! Максимально полный промт (описывающий все алгоритмы поведения) - это чистый код. Только написанный на языке (человеческом) - который не особо подходит для кодинга.
И есть ещё одна глобальная проблема. Писать максимально подробный промт сразу - практически невыполнимая задача даже для сеньора. Так уж устроена наша мясная нейросеть - где нейроны связаны графом. И если выборка не попадает в граф - то и информация не будет подгружена.
Когда мы пишем код сами - многие особенности поведения алгоритмов всплывают на автомате в голове. И мы их реализуем не задумываясь.
Но если всю туже работу нам нужно будет описать в промте человеческим языком - пласт знаний алгоритмов у нас в голове не всплывёт. Потому что описание алгоритма в человеческом коде - не пересекаются с алгоритмами в коде на котором вы всю жизнь писали. И собственно на котором тренировали свою мясную нейросеть.
Я не хочу, да и не могу, вспоминать что там было 30 лет назад. Что я помню сейчас - загадка была не простая. Простое тырканье ручек не приводило к решению. И повторяю - это совершенно не важно. Мне тогда был интересно решить с помощью Delphi любую интересную задачу.
P.S. А по поводу думать - мне было интересно "думать" и изучать Delphi. Я вас не минусил.
Да там нужно было кликать по таким ручкам. В несколько итераций. Но как до такого можно был додуматься? Ведь пока кликаешь - каша из ручек становилась всё более хаотичной. А то что идёшь по правильному пути было видно только за 1-2 оконечных клика.
Да это и не важно. Школьнику было не интересно (да и не возможно) применять какой то математический аппарат - и найти какие то математические зависимости в такой задаче (хотя математику может и интересно).
Можно наверно было просто наугад найти потратив пару часов - просто кликая всё подряд.
Мне задача показалось очень подходящей для изучения Delphi. Не было бы этой задачи - нашёл бы что другое.
Ну сейчас нейросети заставляют человека (посредством рекламы из всех щелей) покупать товары. И это навящевая вездесущая реклама очень сильно портит качество жизни конкретному человек.
Не пора ли избавить его (человека) от этой неприятной посреднической роли? Пусть у каждого будет собственный ИИ-дворецкий который будет управлять жизнью человека и покупать всё что нужно.
Ах да. Такое уже повсюду начинают внедрять. Правда читал тут статью что такой ИИ помощник накупил яиц каких то "веганских" в три-дорога. Но это только начало.
Delphi - тёплые воспоминания. В 90-x тоже переходил с ассемблера и С на него. Писал всякие утилиты под виндовс. Помню до сих пор одну программку. Была такая игра в тех же 90-x Братья пилоты. И там был холодильник-сейф с головоломкой. Головоломка представляла из себя ручки-переключатели. 5 рядов по пять ручек. Переключение одной ручки - переключала все ручки по диагонали и по вертикале от этой ручки на противоположную позицию. Что бы открыть сейф - все ручки должны быть вертикальными.
Просто переключая ручки - было практически невозможно решить эту головоломку. И тут мне на помощь пришёл Delphi. Набросав интерфейс в виде этого холодильника я сделал программу которая брутфорсом перебирала все варианты для получения результата - все ручки горизонтальны. Для старта нужно было только перенести стартовое положение всех ручек из игры в программу. Результат выводился в виде последовательности какую ручку надо переключить.
Показав программу однокласснику - мой "хакерский" имидж взлетел до небес! Кстати приятель мне показал какой то алгоритм - там нужно было как то хитро переключать ручки и чудесным образом в последствии все они выстраивались по горизонтале. Додуматься до такого алгоритма было невозможно. Где то был прочитан в журнале.
Уже многие годы спустя, когда я обучал своих детей программированию, а я знаю что простое обучение это ужасно нудно и неэффективно, а когда решаешь конкретную задачу - то интересно. В общем тоже дал задание своим детям взломать этот холодильник программой. Только уже использовался C#.
Статьи пишут нейросети. Коменты пишут нейросети. Всё это читают нейросети - всякие краулеры и прочее. Может пора сделать хабр только для ИИ. И вход по капче которую человек не пройдёт? И язык там использовать бинарный код?
Если сократить эту простыню текста в нормальный вид то имеем следующее.
Есть сервер СУБД и как на него навесить кучу кеширующих серверов которые могли бы отвечать на запросы самостоятельно. При этом придумываем механизм что бы сервера кешей могли саморазмножаться или самоуничтожаться. Попутно решаем геморой синхронизации данных кешей и центральной СУБД
Деление аналитических запросов и транзакционных. Аналитический запрос подразумевает запрос к столбцам без индексов - там идёт полный скан столбца. Транзакционный подразумевает что он заранее оптимизирован и использует индексы везде где можно для быстрого выполнения.
Также упомянуты такие костыли как например что делать при удалении строк? Posgres например не удаляет их, а помечает как удалённые, или при обновлении строки тоже создаёт новую копию. При этом страницы обрастают кучей незадействованной памятью - которую нужно потом уничтожать сборщиком мусора. В противовес этому есть алгоритмы автоматической ликвидации таких пустых мест налету. Но каждый подход имеет свои плюсы и минусы.
Упомянуты векторные вычисления. Это ассемблерные инструкции процессора Sse2, Avx2. Что это? Инструкции позволяющие атомарно читать, записывать, сравнивать данные длиной 16,32,64,128,256 и более байт. Это сильно ускоряет скорость например поиска по колонке с таким типом данных - а также решает геморрой с параллельной записью и чтением, когда происходит гонка потоков чтения и записи. И чтение происходит битым (половина данных старая, половина новая и вариации). Но для работы векторных инструкций данные должны быть выровнены в памяти. т.е адреса должны быть кратны тем самым числам 16,32,64,128,256. Иначе работать не будет - ограничения железа процессора. Нормально данные выровнять в памяти можно в СУБД колоночного вида. Postgres же имеет строчный вид - и данные там не выровняешь. Когда у тебя все типы идут друг за другом. Можно конечно кучу дыр на выравнивание наставлять - но это дикий оверхед по памяти.
Дальше насколько понял из статьи - анализируется запрос. Если жирный содержит кучу запросов к столбцам без индекса - то отправляем на кеширующий сервер с жирной памятью. Ведь для выполнения запроса нам нужно будет перелопатить весь столбец. Это значит выгрузить его в память с диска. Если не жирный можно отправить на дохлый кеширующий сервер. В продвинутых системах есть выгрузка неиспользуемых страниц автоматом.
Вывод. Очень туманно (специально?) и запутанно описали принцип построения кеширующих серверов. Анализа на ходу типа запроса(например есть ли запрос к перебору столбца без индекса) и распределения его на жирные/тощие кеши. Также навели туману на разницу типов построения базы данных колоночной и строковой.
Как думать - это и есть природная расположенность к программированию. А именно - когда начинаешь выстраивать огромный алгоритм в уме, а в реальности это приводит к дикому потреблению сахара из крови и "сушения" собственных мозгов, так вот - что бы от этого действия тебя не начинало тошнить через 5 минут, а наоборот - мозг награждал тебя дофаминовым откликом.
Имея такой генетический природный подарок дальше дорога одна. Тренировки-тренировки-тренировки.... Годами. Суша свой мозг каждый день - заставляешь расширятся и разрастаться кровеносным сосудам в голове, что бы мозг мог выесть всю глюкозу из крови в максимально короткое время.
Я как то мерил свою глюкозу после выпитой литровой колы. Сахар подскочил до 8. После 2 часов сушения мозга - сахар упал до 3.9. Хотя это для меня и не характерно. Обычно сахар держится на одном уровне без колебаний.
Когда программист "перегорает" - это химический процесс в голове когда, химия тебе не помогает, а наоборот вредит - картизолом там или другими гармонами. В таком состоянии не напишешь ни строчки кода (утрированно конечно про строчку, но смысл понятен). Хоть расшибись. Хоть тебе дадут миллион долларов - с условием что ты будешь писать код.
Всю эту простыню я написал к тому - что не-программисту от природы никакие книги "как программировать" не помогут. А программисту от природы, такие книги не нужны. Ему нужны БЕСПЛАТНЫЕ самоучители из инета по тому или другому языку. Он просто берёт и делает свой первый проект в удовольствие.
Кстати та же история с психологами. Психология это наука понимания и управления психикой другого человека. Миллионы мошенников психологи от природы находят миллионы своих жертв и просто манипулируют ими как хотят. Каждый день читаешь о очередном "тупни" который перевёл все свои деньги на "безопасный счёт."
И с другой стороны - институты выпускают тысячи психологов. Но я общался с некоторыми представителями. И они окопались очень глупы. Я это к чему - нельзя обучится психологии если не дала способностей к этому природа. Как и с программированием. Как и с музыкой. Как и с живописью... Хотя весьма посредственным "писателем строчек кода" наверно можно себя заставить стать.
Математик использует математический аппарат. Все эти cos, sin и прочие теоремы. Сложность отдельной маленькой формулы может быть максимальна для понимания.
Программист может (и в 99% случаев) обходится без этого. Программист строит огромные алгоритмы в уме. Огромные графы простых кирпичиков. Сложность отдельного взятого кирпичика не превышает 2+2. Но количество кирпичиков может быть крайне много, а взаимосвязи запутаны до предела.
Это как мозг. Работа отдельного нейрона - понятна и проста. Работа всех нейронов одновременно - непонятно до предела.
Эта мысль описана в вашей книге?
P.S. Можно быть и математиком и программистом одновременно. Также есть области программирования (достаточно мало встречающиеся, по сравнению с огромным ворохом всего программного кода) где математика используется в полный мере. Например симуляция реальности в 3D играх.
Лет 25 назад существовали такие кнопочные телефоны siemens s35 и подобные. У меня был проект - надо было через этот телефон выйти в интернет с контроллера. Сами телефоны управлялись через COM порт и AT команды.
Тогда я был молод и горяч и море по колено и горы по плечу. Сказано сделано. Выход в интернет начинался с PPP протокола. В него упаковывался IP, в него TCP. Потом шёл ворох вспомогательных протоколов типа ICMP. В общем всё это я реализовал на С - было дико интересно.
А потом я наткнулся на недокументированные команды AT которые могли реализовывать стек протоколов TCP/IP - и своя разработка улетела в мусорку ). Весёлые времена были.
Добавлю офтопа. Как же мне смешно смотреть на мою карму )))) Я уже давным давно понял писать сюда что то не имеет никакого смысла. Что бы ты не написал - тебе попросту напихают минусов в карму. Потому как на хабре должен остаться только рекламный булшит и кривые переводы в коммерческих блогах. Даже этот комментарий не имеет смысла писать.
Со временем ИИ инструменты сыграют злую шутку с программистамимясными мешками человеком
Сильный ИИ заменит просто всех. Продавщиц на кассе. Всех служащих работающих с людьми. Водители. Врачи (кроме хирургов наверно и то спорно). Да вообще не представлю профессии где человек останется нужен.
И программист тоже не нужен будет. Только он станет не нужен не в первых рядах как тут обычно акцентируют, а ближе к концу очереди мясных отходов
Как бы это разделитель. Компилятор без этого может склеить код там где этого не должно быть.
Вот пример - я писал минификатор для файлов javascript. Основная операция это выкидывать ненужный текст. А это как раз всякие переносы строки которые могут и 2 байта занимать (\r\n) и куча пробелов. Если всё это выкинуть то всё склеится. А точка запятой будет как раз это разделять. Ну в javascript ещё пробел можно использовать.
Просто мы для читабельности используем форматирование с кучей переносов строк и пробелов. И вроде как использование точки с запятой уже и не надо.
Вот в javascript так и сделали - хочешь используй, хочешь нет.
Опять же есть языки где вместо точки с запятой используют для форматирования другие символы \r\n, begin end и прочее. Но точка с запятой это минимальный и наглядный символ для разделения блоков.
Я на столько привык к ней что без её использования уже и к коду с другими разделителями трудно приступать . Мозг уже как компилятор просто на автомате выцепляет её из сплошного текста и форматирует мне его на самостоятельные программные блоки.
Отлично! Программа будет складывать целые числа (int). Давай уточним оставшиеся детали:
Сколько чисел должно складываться?
Фиксированное количество (например, 2 числа)
Произвольное количество (пользователь вводит числа, пока не решит остановиться)
Как программа должна получать числа?
Ввод с клавиатуры (пользователь вводит числа в консоли)
Чтение из файла (например, числа хранятся в текстовом файле)
Как программа должна выводить результат?
Просто вывод результата в консоль
Запись результата в файл
Другое (например, вывод с пояснением, типа "Сумма чисел: ...")
Должна ли программа обрабатывать ошибки?
Да (например, если пользователь ввел не число)
Нет (программа работает только с корректными данными)
Ответь на эти вопросы, и я составлю код для твоей программы! 😊
Вывод. Столь простую программу мне как программисту делать 1 минуту. Взял и написал. Потому как я уже в подсознании знаю ответы на все вопросы и знаю что мне надо. Просто сразу пишу нужный код.
А ИИ может мне наверно ещё пол часа вопросы задавать?
Наверно новичку это норм.
А если это будет чуть сложнее сложения 2 чисел? Уточняющих вопросов будет как книга Война и мир?
И кстати - вот нагляднейшний пример кучи пограничных вариантов в простейшей программе сложения двух чисел. Опытные программисты просто на автомате все эти вопросы будут решать.
А новичок даже не подозревать об их существовании.
Я бы ещё добавил что часто бизнес аналитик играет роль щита от самадура-заказчика способного изнасиловать тебе мозг так что и программировать не захочешь.
Вместо тебя мозг насилуется бизнес аналитику. И опять же я замечал что если такой аналитик "не сильно умный" - то ему как бы и норм. Это его "суперсила".
И мне кажется что если есть такой бизнес аналитик которого вы описали, то он не останется на этом уровне, что бы ему насиловали мозг, а быстро пойдёт по карьерной лестнице вверх.
Вы правы. Более того про бизнес аналитиков я писал выше. Но на практике я часто видел бизнес аналитиков которые играли роль простого посредника вопросов. И гораздо проще было напрямую связаться с заказчиком и разъяснить все вопросы.
Опять же насколько хорош бизнес аналитик не был он не знает (по крайней мере не в его компетенции) многих нюансов, ограничений и особенностей устройства внутренней кухни баз данных, сервисов и прочего.
Поэтому программисты часто напрямую согласовывают с заказчиком многие моменты. Ну и бизнес аналитик за ними как прилежный учеинк всё согласованное записывает себе в тетрадочку.
И часто в схеме бизнес аналитиков попросту может не быть.
Да знаю про контекст. Проблема лишь в том что контекст ИИ может взять только из кода. А вот человеческий контекст намного больше. И каждый день дополняется по проекту.
Он состоит из.
Общения с заказчиком.
Общение с кучей рабочих людей на предприятии заказчика. Например когда программистская контора делает какую нибудь ERP для предприятия.
Каждодневных утренних планёрок и кучи ненужных совещаний
Собственного опыта программиста.
Всё это практически невозможно вспомнить и написать подробно в промте. Зато когда программист пишет код - этот контекст без труда автоматически всплывает в его голове. Так устроен мозг и нейроны - один нейрон тянет другой и так далее. Не зря есть такое понятие как "воспоминание разблокировано" Глянул мельком на камень на земле по дороге на работу и вспомнил случай из детства который никогда не вспоминал.
Часто есть отрицательный момент. Программист десять лет вёл проект на работе. И в его голове хранится ТАКОЙ контекст этого проекта - что он становится "незаменимым работником". Кроме него уже никто не может в этом разобраться. И ИИ не разберётся. Т.к. 10 лет не варился в этом проекту и не знает кучи подводных камней.
Помогу чем смогу. Открываю сайт и вижу это:
Думаю какая то недоделанная заглушка. Закрываю сайт. У меня мозила.
Читаю вашу статью до конца. Что то тут не так. Вроде другие люди открывают ваш сайт и видят не то что я.
Пробую открыть ваш сайт опять - и обнаруживаю интересную функциональность. Если мышкой не поводить по экрану - ни одна статья не будет загружена. Т.е. вся подгрузка висит на javascript событии.
Вроде поисковики давно уже научились выполнять яваскрит на странице, но если краулер настроен только на текст - он ничего не увидит на вашем сайте. Даже я человек попался на такое.
На мобильнике наверно тоже не очень (не проверял).
В статье прослеживается мысль которую я неоднократно описывал тут.
Любая программа это алгоритм. Алгоритм работы даже одного инпута на форме может быть очень большим. Это всяческие ограничения на ввод, описание автоматических действий при вводе текста, по типу автокоррекции, запрету определённых символов и прочего.
И тут мы приходим к сути проблемы. За многие десятилетия истории алгоритмов, человечество пришло к самому эффективному способу их точного описания - это код.
В вайбкодинге - мы пытаемся описать алгоритм человеческим языком. И этот способ проигрывает по качеству наглядности и минимализму обычному коду.
Отсюда в вышеописанной статье есть предостережения по типу - ни в коем случае не кидайте LLM не полный промт. Иначе она сама на-галлюцинирует такого, что потом это просто нереально отладить. Но! Максимально полный промт (описывающий все алгоритмы поведения) - это чистый код. Только написанный на языке (человеческом) - который не особо подходит для кодинга.
И есть ещё одна глобальная проблема. Писать максимально подробный промт сразу - практически невыполнимая задача даже для сеньора. Так уж устроена наша мясная нейросеть - где нейроны связаны графом. И если выборка не попадает в граф - то и информация не будет подгружена.
Когда мы пишем код сами - многие особенности поведения алгоритмов всплывают на автомате в голове. И мы их реализуем не задумываясь.
Но если всю туже работу нам нужно будет описать в промте человеческим языком - пласт знаний алгоритмов у нас в голове не всплывёт. Потому что описание алгоритма в человеческом коде - не пересекаются с алгоритмами в коде на котором вы всю жизнь писали. И собственно на котором тренировали свою мясную нейросеть.
Я не хочу, да и не могу, вспоминать что там было 30 лет назад. Что я помню сейчас - загадка была не простая. Простое тырканье ручек не приводило к решению. И повторяю - это совершенно не важно. Мне тогда был интересно решить с помощью Delphi любую интересную задачу.
P.S. А по поводу думать - мне было интересно "думать" и изучать Delphi. Я вас не минусил.
Да там нужно было кликать по таким ручкам. В несколько итераций. Но как до такого можно был додуматься? Ведь пока кликаешь - каша из ручек становилась всё более хаотичной. А то что идёшь по правильному пути было видно только за 1-2 оконечных клика.
Да это и не важно. Школьнику было не интересно (да и не возможно) применять какой то математический аппарат - и найти какие то математические зависимости в такой задаче (хотя математику может и интересно).
Можно наверно было просто наугад найти потратив пару часов - просто кликая всё подряд.
Мне задача показалось очень подходящей для изучения Delphi. Не было бы этой задачи - нашёл бы что другое.
Ну сейчас нейросети заставляют человека (посредством рекламы из всех щелей) покупать товары. И это навящевая вездесущая реклама очень сильно портит качество жизни конкретному человек.
Не пора ли избавить его (человека) от этой неприятной посреднической роли? Пусть у каждого будет собственный ИИ-дворецкий который будет управлять жизнью человека и покупать всё что нужно.
Ах да. Такое уже повсюду начинают внедрять. Правда читал тут статью что такой ИИ помощник накупил яиц каких то "веганских" в три-дорога. Но это только начало.
Delphi - тёплые воспоминания. В 90-x тоже переходил с ассемблера и С на него. Писал всякие утилиты под виндовс. Помню до сих пор одну программку. Была такая игра в тех же 90-x Братья пилоты. И там был холодильник-сейф с головоломкой. Головоломка представляла из себя ручки-переключатели. 5 рядов по пять ручек. Переключение одной ручки - переключала все ручки по диагонали и по вертикале от этой ручки на противоположную позицию. Что бы открыть сейф - все ручки должны быть вертикальными.
Просто переключая ручки - было практически невозможно решить эту головоломку. И тут мне на помощь пришёл Delphi. Набросав интерфейс в виде этого холодильника я сделал программу которая брутфорсом перебирала все варианты для получения результата - все ручки горизонтальны. Для старта нужно было только перенести стартовое положение всех ручек из игры в программу. Результат выводился в виде последовательности какую ручку надо переключить.
Показав программу однокласснику - мой "хакерский" имидж взлетел до небес! Кстати приятель мне показал какой то алгоритм - там нужно было как то хитро переключать ручки и чудесным образом в последствии все они выстраивались по горизонтале. Додуматься до такого алгоритма было невозможно. Где то был прочитан в журнале.
Уже многие годы спустя, когда я обучал своих детей программированию, а я знаю что простое обучение это ужасно нудно и неэффективно, а когда решаешь конкретную задачу - то интересно. В общем тоже дал задание своим детям взломать этот холодильник программой. Только уже использовался C#.
Статьи пишут нейросети. Коменты пишут нейросети. Всё это читают нейросети - всякие краулеры и прочее. Может пора сделать хабр только для ИИ. И вход по капче которую человек не пройдёт? И язык там использовать бинарный код?
Если сократить эту простыню текста в нормальный вид то имеем следующее.
Есть сервер СУБД и как на него навесить кучу кеширующих серверов которые могли бы отвечать на запросы самостоятельно. При этом придумываем механизм что бы сервера кешей могли саморазмножаться или самоуничтожаться. Попутно решаем геморой синхронизации данных кешей и центральной СУБД
Деление аналитических запросов и транзакционных. Аналитический запрос подразумевает запрос к столбцам без индексов - там идёт полный скан столбца. Транзакционный подразумевает что он заранее оптимизирован и использует индексы везде где можно для быстрого выполнения.
Также упомянуты такие костыли как например что делать при удалении строк? Posgres например не удаляет их, а помечает как удалённые, или при обновлении строки тоже создаёт новую копию. При этом страницы обрастают кучей незадействованной памятью - которую нужно потом уничтожать сборщиком мусора. В противовес этому есть алгоритмы автоматической ликвидации таких пустых мест налету. Но каждый подход имеет свои плюсы и минусы.
Упомянуты векторные вычисления. Это ассемблерные инструкции процессора Sse2, Avx2. Что это? Инструкции позволяющие атомарно читать, записывать, сравнивать данные длиной 16,32,64,128,256 и более байт. Это сильно ускоряет скорость например поиска по колонке с таким типом данных - а также решает геморрой с параллельной записью и чтением, когда происходит гонка потоков чтения и записи. И чтение происходит битым (половина данных старая, половина новая и вариации). Но для работы векторных инструкций данные должны быть выровнены в памяти. т.е адреса должны быть кратны тем самым числам 16,32,64,128,256. Иначе работать не будет - ограничения железа процессора. Нормально данные выровнять в памяти можно в СУБД колоночного вида. Postgres же имеет строчный вид - и данные там не выровняешь. Когда у тебя все типы идут друг за другом. Можно конечно кучу дыр на выравнивание наставлять - но это дикий оверхед по памяти.
Дальше насколько понял из статьи - анализируется запрос. Если жирный содержит кучу запросов к столбцам без индекса - то отправляем на кеширующий сервер с жирной памятью. Ведь для выполнения запроса нам нужно будет перелопатить весь столбец. Это значит выгрузить его в память с диска. Если не жирный можно отправить на дохлый кеширующий сервер. В продвинутых системах есть выгрузка неиспользуемых страниц автоматом.
Вывод. Очень туманно (специально?) и запутанно описали принцип построения кеширующих серверов. Анализа на ходу типа запроса(например есть ли запрос к перебору столбца без индекса) и распределения его на жирные/тощие кеши. Также навели туману на разницу типов построения базы данных колоночной и строковой.
Как думать - это и есть природная расположенность к программированию. А именно - когда начинаешь выстраивать огромный алгоритм в уме, а в реальности это приводит к дикому потреблению сахара из крови и "сушения" собственных мозгов, так вот - что бы от этого действия тебя не начинало тошнить через 5 минут, а наоборот - мозг награждал тебя дофаминовым откликом.
Имея такой генетический природный подарок дальше дорога одна. Тренировки-тренировки-тренировки.... Годами. Суша свой мозг каждый день - заставляешь расширятся и разрастаться кровеносным сосудам в голове, что бы мозг мог выесть всю глюкозу из крови в максимально короткое время.
Я как то мерил свою глюкозу после выпитой литровой колы. Сахар подскочил до 8. После 2 часов сушения мозга - сахар упал до 3.9. Хотя это для меня и не характерно. Обычно сахар держится на одном уровне без колебаний.
Когда программист "перегорает" - это химический процесс в голове когда, химия тебе не помогает, а наоборот вредит - картизолом там или другими гармонами. В таком состоянии не напишешь ни строчки кода (утрированно конечно про строчку, но смысл понятен). Хоть расшибись. Хоть тебе дадут миллион долларов - с условием что ты будешь писать код.
Всю эту простыню я написал к тому - что не-программисту от природы никакие книги "как программировать" не помогут. А программисту от природы, такие книги не нужны. Ему нужны БЕСПЛАТНЫЕ самоучители из инета по тому или другому языку. Он просто берёт и делает свой первый проект в удовольствие.
Кстати та же история с психологами. Психология это наука понимания и управления психикой другого человека. Миллионы мошенников психологи от природы находят миллионы своих жертв и просто манипулируют ими как хотят. Каждый день читаешь о очередном "тупни" который перевёл все свои деньги на "безопасный счёт."
И с другой стороны - институты выпускают тысячи психологов. Но я общался с некоторыми представителями. И они окопались очень глупы. Я это к чему - нельзя обучится психологии если не дала способностей к этому природа. Как и с программированием. Как и с музыкой. Как и с живописью... Хотя весьма посредственным "писателем строчек кода" наверно можно себя заставить стать.
Чем программист отличается от математика?
Математик использует математический аппарат. Все эти cos, sin и прочие теоремы. Сложность отдельной маленькой формулы может быть максимальна для понимания.
Программист может (и в 99% случаев) обходится без этого. Программист строит огромные алгоритмы в уме. Огромные графы простых кирпичиков. Сложность отдельного взятого кирпичика не превышает 2+2. Но количество кирпичиков может быть крайне много, а взаимосвязи запутаны до предела.
Это как мозг. Работа отдельного нейрона - понятна и проста. Работа всех нейронов одновременно - непонятно до предела.
Эта мысль описана в вашей книге?
P.S. Можно быть и математиком и программистом одновременно. Также есть области программирования (достаточно мало встречающиеся, по сравнению с огромным ворохом всего программного кода) где математика используется в полный мере. Например симуляция реальности в 3D играх.
O! Разблокировано воспоминание.
Лет 25 назад существовали такие кнопочные телефоны siemens s35 и подобные. У меня был проект - надо было через этот телефон выйти в интернет с контроллера. Сами телефоны управлялись через COM порт и AT команды.
Тогда я был молод и горяч
и море по колено и горы по плечу.Сказано сделано. Выход в интернет начинался с PPP протокола. В него упаковывался IP, в него TCP. Потом шёл ворох вспомогательных протоколов типа ICMP. В общем всё это я реализовал на С - было дико интересно.А потом я наткнулся на недокументированные команды AT которые могли реализовывать стек протоколов TCP/IP - и своя разработка улетела в мусорку ). Весёлые времена были.
Добавлю офтопа. Как же мне смешно смотреть на мою карму )))) Я уже давным давно понял писать сюда что то не имеет никакого смысла. Что бы ты не написал - тебе попросту напихают минусов в карму. Потому как на хабре должен остаться только рекламный булшит и кривые переводы в коммерческих блогах. Даже этот комментарий не имеет смысла писать.
del
Я бы сказал так:
Со временем ИИ инструменты сыграют злую шутку с
программистамимясными мешкамичеловекомСильный ИИ заменит просто всех. Продавщиц на кассе. Всех служащих работающих с людьми. Водители. Врачи (кроме хирургов наверно и то спорно). Да вообще не представлю профессии где человек останется нужен.
И программист тоже не нужен будет. Только он станет не нужен не в первых рядах как тут обычно акцентируют, а ближе к концу очереди
мясных отходовКак бы это разделитель. Компилятор без этого может склеить код там где этого не должно быть.
Вот пример - я писал минификатор для файлов javascript. Основная операция это выкидывать ненужный текст. А это как раз всякие переносы строки которые могут и 2 байта занимать (\r\n) и куча пробелов. Если всё это выкинуть то всё склеится. А точка запятой будет как раз это разделять. Ну в javascript ещё пробел можно использовать.
Просто мы для читабельности используем форматирование с кучей переносов строк и пробелов. И вроде как использование точки с запятой уже и не надо.
Вот в javascript так и сделали - хочешь используй, хочешь нет.
Опять же есть языки где вместо точки с запятой используют для форматирования другие символы \r\n, begin end и прочее. Но точка с запятой это минимальный и наглядный символ для разделения блоков.
Я на столько привык к ней что без её использования уже и к коду с другими разделителями трудно приступать . Мозг уже как компилятор просто на автомате выцепляет её из сплошного текста и форматирует мне его на самостоятельные программные блоки.
Вывод. Столь простую программу мне как программисту делать 1 минуту. Взял и написал. Потому как я уже в подсознании знаю ответы на все вопросы и знаю что мне надо. Просто сразу пишу нужный код.
А ИИ может мне наверно ещё пол часа вопросы задавать?
Наверно новичку это норм.
А если это будет чуть сложнее сложения 2 чисел? Уточняющих вопросов будет как книга Война и мир?
И кстати - вот нагляднейшний пример кучи пограничных вариантов в простейшей программе сложения двух чисел. Опытные программисты просто на автомате все эти вопросы будут решать.
А новичок даже не подозревать об их существовании.
Интересный подход. А если попросить текущий ИИ что бы он задавал вопросы и по ответам писал код.
Ради интереса задал deepseek такой промт
На что он мне ответил
Я бы ещё добавил что часто бизнес аналитик играет роль щита от самадура-заказчика способного изнасиловать тебе мозг так что и программировать не захочешь.
Вместо тебя мозг насилуется бизнес аналитику. И опять же я замечал что если такой аналитик "не сильно умный" - то ему как бы и норм. Это его "суперсила".
И мне кажется что если есть такой бизнес аналитик которого вы описали, то он не останется на этом уровне, что бы ему насиловали мозг, а быстро пойдёт по карьерной лестнице вверх.
Вы правы. Более того про бизнес аналитиков я писал выше. Но на практике я часто видел бизнес аналитиков которые играли роль простого посредника вопросов. И гораздо проще было напрямую связаться с заказчиком и разъяснить все вопросы.
Опять же насколько хорош бизнес аналитик не был он не знает (по крайней мере не в его компетенции) многих нюансов, ограничений и особенностей устройства внутренней кухни баз данных, сервисов и прочего.
Поэтому программисты часто напрямую согласовывают с заказчиком многие моменты. Ну и бизнес аналитик за ними как прилежный учеинк всё согласованное записывает себе в тетрадочку.
И часто в схеме бизнес аналитиков попросту может не быть.
Да знаю про контекст. Проблема лишь в том что контекст ИИ может взять только из кода. А вот человеческий контекст намного больше. И каждый день дополняется по проекту.
Он состоит из.
Общения с заказчиком.
Общение с кучей рабочих людей на предприятии заказчика. Например когда программистская контора делает какую нибудь ERP для предприятия.
Каждодневных утренних планёрок и кучи
ненужныхсовещанийСобственного опыта программиста.
Всё это практически невозможно вспомнить и написать подробно в промте. Зато когда программист пишет код - этот контекст без труда автоматически всплывает в его голове. Так устроен мозг и нейроны - один нейрон тянет другой и так далее. Не зря есть такое понятие как "воспоминание разблокировано" Глянул мельком на камень на земле по дороге на работу и вспомнил случай из детства который никогда не вспоминал.
Часто есть отрицательный момент. Программист десять лет вёл проект на работе. И в его голове хранится ТАКОЙ контекст этого проекта - что он становится "незаменимым работником". Кроме него уже никто не может в этом разобраться. И ИИ не разберётся. Т.к. 10 лет не варился в этом проекту и не знает кучи подводных камней.