Comments 322
Подсказки при писании скриптов на баше. Хотя оно делает в скриптах ошибки, но пробовать его перед гуглением быстрее чем просто гуглить. Я не специалист по скриптам на баше, но писать мне их приходится. Так как скрипт на баше - это последовательный рецепт, ChatGPT делает это OK.
Так как скрипт на баше - это последовательный рецепт, ChatGPT делает это OK.
Кмк, тут важно, что база данных для обучения bash, включая похожие языки, сильно больше базы для обучения SystemVerilog. Причём зачастую скрипт, который вам нужен, уже кто-то дословно написал.
Жуткий сценарий: в соседнем кубикле страдает администратор, которому эти скрипты поддерживать. Он на них смотрит и приходит в ужас: ошибки не обрабатываются, имена файлов с пробелами удаляют половину данных. Он стонет что все надо переписывать с нуля, а эти верификаторы считают что сделали всю работу.
Ну я был раньше верификатором, сейчас я rtl-дизайнер (в основном, хотя бывает и верификаторам помогаю). Но в любом случае, для обработки ошибок я в начале каждого скрипта пишу такие опции, чтобы оно сразу вылетало когда возникает ошибка, а я ее не обрабатываю. А именно:
set -e - Exit immediately if a command exits with a non-zero status. Note that failing commands in a conditional statement will not cause an immediate exit.
set -o pipefail - Sets the pipeline exit code to zero only if all commands of the pipeline exit successfully.
set -u - Causes the bash shell to treat unset variables as an error and exit immediately.
set -x - Causes bash to print each command before executing it.
set -E - Improves handling ERR signals
Насчет имен файлов с пробелами - ChatGPT везде ставит кавычки "$abc", даже изнишне с моей точки зрения (если я знаю, что в $abc внутри пробелов нет, то я пишу например ../$abc)
Кстати если вы спец по башу, мне было бы интересно ваше мнение о моих башевских скриптах, например из open-source проекта (там в нескольких строках я использовал подсказки от ChatGPT, но в принципе писал сам) https://gitflic.ru/project/yuri-panchul/valid-ready-etc/file?file=scripts
Качественная работа! Прослеживается структура мышления. Я бы добавил больше функций. Это с одной стороны удобнее, можно дать хорошее название части кода, чтобы сразу понять что он делает не вникая в сам код. С другой стороны удобно включать и отключать куски кода во время разработки, вместо комментирования многих строчек.
Увы, это всё не до конца помогает, если писать сложные скрипты. Например, вот такой код выведет should not print вместо failed:
#!/bin/bash
set -eEuo pipefail
{ set -e; false; echo "should not print"; } || echo failedИнтересно!
А почему должно ожидаться, что скрипт выдаст "failed"?
Потому что в фигурных скобках команда завершилась с ошибкой — false. Из этого напрашивается вывод, что выполнение фигурных скобок прерывается из-за `set -e`, фигурные скобки целиком тоже завершились с ошибкой, дальше идёт обработчик ошибки справа от фигурных скобок.
Другими словами, ожидается прерывание выполнения не только на самом верхнем уровне, но и внутри скобок.
Так задумано, и в man bash это описано.
Не надо писать сложные скрипты. Я был тем админом из соседнего кубикла. Пишите тестируемый код, если он больше 10 строчек.
я не специалист в bash скритпах, но практически универсальная рекомендация первой строчкой писать
#!/bin/bash
Потому что если пользователь использует zsh, как например я, эти скрипты упадут тут же, хотя бы потому что zsh не понимает pipefail. В статье на которую вы ссылаетесь, что рекомендует остальные флаги, все примеры начинаются с этого.
У меня по ссылке не полный скрипт, а просто текстовые файлы которые скрипт сорсит. Обратите внимание на расширение source.bash
Например 02_simulate_rtl.source.bash
Он запускается из другой директории скриптом, у которого в первой строчке все в порядке:
собственно скрипт который запускается выглядит так:
#!/usr/bin/env bash
set -Eeuo pipefail # See the meaning in scripts/README.md
script=$(basename "$0")
source_script=${script/\.bash/.source.bash}
dir_source_script=../scripts/$source_script
for i in {1..3}
do
[ -f $dir_source_script ] && break
dir_source_script=../$dir_source_script
done
if ! [ -f $dir_source_script ]; then
printf "$script: cannot find \"$source_script\"\n" 1>&2
exit 1
fi
dir_source_script="$(readlink -f $dir_source_script)"
. "$dir_source_script"Я использую рекомендацию в качестве первой строчки использовать "#!/usr/bin/env bash" что считается лучше чем "#!/bin/bash" в разных статьях
а зачем в просто текстовых файлах повторять set?
если они вызываются точкой, достаточно в главном файле, там же где #!
Неплохо знать, что расширение в линуксе не значит ровным счетом ничего.
А для шелл скриптов, все что начинается с решетки - это комментарий.
Поэтому ваш #!/user/bin/env bash в сорс скриптах - это просто комментарий.
ln -s /bin/zsh /bin/bash
По сути, вы вручную пишите на древнем языке то, что можно автоматизировать через систему конфигураций, например через тот же Ansible.
На крайний случай, учитывая что Bash со всеми его закидонами не предназначен для вменяемого программирования, можно было бы написать скрипты на Python, или на худой конец на PHP, Ruby или что там есть адекватного. Код бы получился более сопровождаемый чем вот это месиво из консольных команд и подстановок.
Имхо учить дополнительный тул для писания скриптов в open-source проектах имеет смысл если 1) этих скриптов нужно писать минимум несколько тысяч строк и 2) если это же тул готовы учить другие люди в проекте.
PHP в автоматизации синтеза и симуляции я никогда не видел, Ruby иногда вижу но вроде его популярность угасает, а Python имхо более многословный.
Я имел в виду что без разницы какой язык, хоть Lua, главное чтобы он хоть как-то соответствовал современным понятиям а не костылям из 70-х.
В Bash один только синтаксис условий чего стоит:
Синтаксис условий в BASH скриптах - главные особенности
Когда три условия дают разный результат:
if [ "$a" = "$b" ]; then
if [ "$a"="$b" ]; then
if ["$a"="$b"]; then
То, знаете ли, по сегодняшним меркам, не объяснишь сотруднику ради чего сделано именно ТАК.
То, знаете ли, по сегодняшним меркам, не объяснишь сотруднику ради чего сделано именно ТАК.
Большинство объяснений начинается словами "Знаешь, сынок, так исторически сложилось..."
Например, если помнить, что [ — это таки программа (а точнее — алиас программы test, а у программы бывают параметры, которые разделяются пробелами, то сразу становится понятно, что первое — это вызов внешней программы с четырьмями параметрами, второе — с двумя, а третье — ни то и ни другое, а, похоже, внутренний синтаксис баша.
А какая отсюда мораль? Курите маны, ибо они рулезь!
Курите маны, ибо они рулезь!
Ну да, да. Даже эту фразу уже лет двадцать никто не использует. А 90 перцентов айтишников понятия не имеет откуда она есть пошла.
То же самое и с bash, который всеми своими закидонами демонстрирует, что вменяемости в нем не было раньше, нет и сейчас.
Никто не хочет иметь дело с маразматиком, хотя методики как с ним обращаться есть и даже работают.
Когда три условия дают разный результат:
У вас нет трех условий. У вас есть одно условие и две записи с некорректным синтаксисом.
Так бывает, когда программисты на других языках программирования, недооценивая баш, считают что способны ОТЛИЧНО писать на нем, вообще без чтения документации.
две записи с некорректным синтаксисом.
if [ "$a" = "$b" ]; then
Это условие "если программа [, вызванная с четырьмя параметрами: "<содержимое переменной a>", =, <содержимое переменной b>, "]" вернула нулевой код возврата (т.е. условие истинно), то..."
if [ "$a"="$b" ]; then
Это условие "если программа [, вызванная с двумя параметрами: "<содержимое переменной a>=<содержимое переменной b>", "]" вернула нулевой код возврата (т.е строка "<содержимое переменной a>=<содержимое переменной b>"не пустая — а она не может быть пустой, потому что в ней даже в самом худшем случае будет симол равенства), то..."
if ["$a"="$b"]; then
А это уже внутренние заморочки bash, поэтому не хочу ошибиться.
это не три варианта условия, это вы неправильно пользуетесь синтаксисом команды test. То, что на некоторые некорректные записи вы не получаете syntax error это не значит, что тут нет вашей ошибки.
Я не понимаю зачем вы умышленно делаете ошибки и сваливаете их на баш. Может просто пользоваться редактором с подсветкой синтаксиса?
Тем более, что оператор test изначально относится к GNU tools, и синтаксис взят оттуда, а его реализация внутри шелл уже произошла пост-фактум, с необходимой обратной совместимостью синтаксиса.
... когда программисты на других языках программирования, недооценивая INTERCAL, считают что способны ОТЛИЧНО писать на нем, вообще без чтения документации...
Проблема в том, что бывают языки, чтение документации к которым не позволяют ОТЛИЧНО на нем писать, и bash - одно из таких поделий. True - это 0, False - это 1. Давайте сравнивать числа текстовыми аббревиатурами! А строки? Строки будем сравнивать математическими символами, это же логично. Давайте сделаем зависимость от результата от того, как вызывается функция! Да, параметры будут те же! А результат пусть будет разный если мы присваиваем значение переменной или используем функцию inplace! Давайте возврат из функций мешать с поточным выводом! Чтобы в функции ничего нельзя было выводить в поток, не повлияв на возвращаемый результат! Ооо, прекрасно, атлично получилось!
(с грустью потупившись) Так исторически сложилось...
шелл был создан для того, чтобы запускать другие программы.
Функции в шелл - это тоже "другая программа", поэтому вполне логично, что и вызов внешних программ и функций возвращает "код возврата", а не что-то другое.
Никто не мешает функции выводить что-то в поток а потом вернуть нужный результат через return.
Никто не мешает функции выводить что-то в поток а потом вернуть нужный результат через return.
В точно знаете как писать скрипты в Bash? Потому что через return вы не можете просто взять и "вернуть нужный результат". Директива return возвращает код возврата, каковой является только числом и только в диапазоне 0-255. А программистам зачастую нужно возвращать и побольше значения, и надо же такому случиться, возвращать строку!
более чем
Я об этом и говорю, что баш - это язык программирования, который создан в первую очередь как интерфейс для запуска других программ, поэтому все команды - возвращают код возврата. Ведь предполагается, что любая из команд может быть вызовом внешнего файла, другим процессом, и кидать, например, массивы между двумя процессами, кто будет контракт между ними настраивать?
А False, это кстати не 1, а не ноль.
Древний, но не устаревший. В какой-то степени фундаментальный. Написанное потом используется без переписывания много лет. А тот же Python, что было написано на 2.7, на 3.10 (или что там новое) может уже работать не так (и наоборот).
Обычно шелл-скрипты на Python гораздо хуже поддерживать. А sh/bash более менее понятен всем.
Bash хорош тем, что на нём можно написать действительно мультиплатформенную программу, без возни с компиляторами.
И много таких мультиплатформенных программ написано?
Из больших (как для скрипта) активно пользуюсь MiceWeb.
Не густо :)
Есть ещё Piu-Piu.
Почему так мало, это другой вопрос. Может, потому что синтаксически Bash не интуитивный, приходится часто гуглить. Может, потому что суперсовместимость только если вынести за скобки Windows (на которой нужен или WSL, или стороннее ПО вроде Git Bash).
На баш можно писать отличный сопровождаемый код. И тянуть ансибл для установки приложения - тоже самое, что тянуть кубер для запуска одного процесса в докере
Это будет происходить ровно до того момента, пока не понадобится, например, сделать настройку удаленно, или в настройке будет нуждаться больше чем один хост. Тогда непременно встанет вопрос: о чем мы раньше думали?
больше чем один хост?
А в чем проблема с scp/remsh/ssh ?
Начинается.. ;)
Допустим, не все хосты доступны одновременно. Допустим, на некоторых что-то пошло не так.. Допустим, эти задачи захотелось распараллелить.. В какой-то момент этих костылей станет слишком много.
В ансибл если хосты не доступны, тоже не будет ждать. Либо надо юзать дополнительные средства.
В баш нет проблем с тем, чтобы распараллелить. Просто не путайте "больше чем один хост" и сотни хостов с регулярными задачами.
Если у меня микросеть на десяток машин и несколько разовых задач, не особо вижу смысл в каких-то оркестраторах - баш легко справляется.
В целом неплохо. Я бы вместо `[ foo ] || [ bar ]` писал `[ foo -o bar ]`.
На самом деле, рекомендуют, все-таки, [ foo ] || [ bar ] вместо [ foo -o bar ].
Например, http://www.oilshell.org/blog/2017/08/31.html
set -e - Exit immediately if a command exits with a non-zero status. Note that failing commands in a conditional statement will not cause an immediate exit.
Это вообще полный бред. Такое может пригодиться в коротеньких скриптах, но в подавляющем большинстве это нормально.
if ping -c 1 google.com; then
echo success;
else
echo execute some procedure;
fiА у вас что? сразу выход из скрипта на первой строчке?
set -o pipefail - Sets the pipeline exit code to zero only if all commands of the pipeline exit successfully.
Ну это же неправильно. Мало ли как может быть сработать логика в пайплайне, там может быть и нормально если одни из команд вернет ошибку. Та же претензия что и к -e
set -u - Causes the bash shell to treat unset variables as an error and exit immediately.
Многие скрипты не требуют обязательной инициализации переменных..
Я так тоже думал, но выяснилось, что "set -e" - это "умная" опция, она не прерывается если ошибка обрабатывается в "if":
https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_pipefail/
The
-eoption will cause a bash script to exit immediately
when a command fails. This is generally a vast improvement upon the
default behavior where the script just ignores the failing command and
continues with the next line. This option is also smart enough to not
react on failing commands that are part of conditional statements.
Moreover, you can append a command with|| truefor those rare cases where you don’t want a failing command to trigger an immediate exit.
Мало ли как может быть сработать логика в пайплайне, там может быть и нормально если одни из команд вернет ошибку
А для конкретно таких случаев я устанавливаю "set +o pipefail" локально, например:
CABLE_NAME_1=$(set +o pipefail; grep "1) " cable_list | sed 's/.*1) //')
Многие скрипты не требуют обязательной инициализации переменных..
Опция "set -u" мне не сильно мешает, и если даже редко помогает словить ошибку - уже хорошо
Думаю что начинать бояться чатгпт всяким инженерам и программистам нужно будет тогда и только тогда, когда чатгпт сможет по невнятному мычанию манагера внести правки в СУЩЕСТВУЮЩИЙ проект. А до этого как до Сириуса ползком.
До невнятного мычания ещё далеко, тут согласен. Но вот человеческие комментарии коллег в code review уже обучили понимать, иногда неплохо понимает и делает нужный рефакторинг.
:крик_мунка: сингулярность, скайнет, мы все умрем!
нужно следующим этапом сделать кнопку "Сделать лучше" - тогда и менеджер будет не нужен, владелец бизнеса просто будет нажимать эту кнопку (каждое нажатие разумеется стоит $$$) когда понадобится. Тогда в бизнесе преуспеет тот кто быстрее и чаще будет нажимать кнопку "Сделать лучше".
Останутся жить только собственники средств производства, а все остальные голожопики - не вписались в рынок.
Видел ваши посты в ЖЖ, приятно, что вы еще и на Хабре есть. В ЖЖ у многих от ваших постов что называется "попки подгорают" только так.
Ещё в предыдущей версии Visual Studio была интеллектуальная система подсказок, которая увидев, что у меня есть итерируемая локальная переменная и я начинаю писать for предлагала автозаполнение пройтись циклом по этой переменной. ChatGPT после того как модель похудеет и специализируется будет делать то же самое, только угадывать не в одном случае из трёх, как сейчас, а сильно чаще. Думаю это будет вполне применением.
Мне, правда, не сильно поможет. :( Потому что есля я сел за клавиатуру плотно, скорее всего это означает, что в моем алгоритме поплывет не только ChatGPT, но и другие синьеры. :((((((
Гляньте в сторону github copilot
Нет смысла вкладываться в привыкание к технологии, которая в любой момент может объявить вне закона любого понимающего русский язык только за то, что им разговаривал путин..
Вы преувеличиваете, бьют преимущественно по местонахождению и, реже, по фактической резидентуре. Сам недавно проходил довольно дотошное KYC в нескольких финансовых организациях с моим единственным российским паспортом и ничего, прошел.
Тут скорее про концепции, у copilot уже есть и еще будут конкуренты, в т.ч. опенсурсные (но у вас не хватит железа чтобы их запустить самостоятельно).
Запустить не сложно. Когда вы в среде разработки ваше GPU простаивает и даже распоследние трансформеры в свежие nVidia карточки вполне помещаются. Большая часть железа нужна чтобы обучить, и дистанционный доступ нужен только для того чтобы контролировать тех, кто хочет этим воспользоваться и не допустить попадания уже обученных сетей в руки других людей. Вам же сказали, что это OpenAI, тоесть открытый, понимать надо, что это означает.
Юра, хватит отлынивать. Поправь уже этот код и в продакшн
Я не специалист по скриптам на баше
И это то самое ключевое.
Вместо этого можно было сразу сказать: Я использую ChatGPT так же как описанный в статье манагер.
Тяп-ляп-в продакшн. Вроде похоже.
Ну, во-первых, в баше стоимость ошибки ниже. Ошибка в коде на SystemVerilog может привезти к респину чипа на фабрике и ущербу в 20 миллионов долларов.
Во-вторых, я подсказки от баша перепроверяю и довожу до ума сам лично, а не даю другим.
Во-третьих я пишу скрипты на баше в основном для своих open-source проектов. На основной работе это за меня пишет специализированный инженер по инфраструктуре.
В-четвертых, как я уже написал, баш хотя и неортогонален, но это язык последовательных рецептов, и его может быть проще автоматизировать (в SV микроархиректура, создание которой (high-level synthesis) до сих пор очень плохо поддавалось автоматизации.
ChatGPT даёт не знающим иллюзию знаний. Это видно на примере того же манагера из статьи.
Ведь он же уверен, что программа дала ему ценный результат.
Аналогично и в вашем вашем принижении bash просматривается иллюзия понимания и даже оценки "стоимость ошибки ниже".
В чём отличие от того манагера? Тот же самый подход. Та же уверенность в верности иллюзий.
Вот и выходит что дело не в технлогиях, а в людях.
А пренебрежительно к bash зря вы. :(){ echo -n " * ";:;};: сгладил углы =)
Прежде чем судить мое понимание баша, я прошу вас почитать мои скрипты и их покритиковать. Примеры моих скриптов https://gitflic.ru/project/yuri-panchul/valid-ready-etc/file?file=scripts - они вызываются с помощью ". " из скриптов например вот отсюда https://gitflic.ru/project/yuri-panchul/valid-ready-etc/file?file=boards%2Fomdazz%2F02_flip_flop_fifo_day_2%2F09_fifo_with_better_debug_2
Мне всегда интересно мнение о моих скриптах от людей, которые специализируются в скриптинге
Я посмотрел скрипты, и я не понимаю зачем вы так все усложняете количеством файлов
У вас скрипты размером в 10-20 строк, но при этом идут постоянные source других скриптов, что не есть гуд.
Кроме того в clean скрипте у вас идет
cd ..
rm file
почему бы не "rm ../file", ведь теперь после вызова этого скрипта нужно потом опять cd делать в исходную папку?
Я бы посоветовал большинство ваших "отдельных скриптов" оформить функциями и вызывать функции вместо выполнения постоянных source
при этом можно все эти функции выложить в отдельный скрипт, который в начале соурсить.
Прежде всего реально скриптов всего 7:
00_setup.source.bash
01_clean.source.bash
02_simulate_rtl.source.bash
03_synthesize_for_fpga.source.bash
04_configure_fpga.source.bash
local_redirect.bash.template
prepare_public_package.bash
Все остальные скрипты во всем дереве - это копии скрипта local_redirect.bash.template. Де-факто это символические ссылки на скрипты 00-04 из локальных директорий. Я не хочу держать их символическими ссылками, так как git плохо работает с символическими ссылками на разным платформах (а пакет должен работать под Linux и Windows + часть про симуляцию должна работать под MacOS, где есть Icarus Verilog).
Далее, clean скрипт такой потому что в момент cd он работает внутри временной директории, которую он собственно и удаляет.
Исходная причина этого: программа IntelFPGA Quartus, которая используется в скриптах, имеет специфические особенности:
Она создает много мусорных временных файлов в той же директории, в которой находится файл проекта.
Она также портит таймстемпами и информацией о себе файл установок .qsf, который тоже должен находиться в той же директории, что и проект.
Из-за (1) и (2), а также из-за того, что я не хочу пользователя менять path, моя методология такова: я создаю кучу скриптов в десятках или сотнях местах дерева примеров (де-факто символических ссылок) которые ищут реальный скрипт в директории scripts, а также копируют во временную поддиректорию run всякую информацию и потом работают в ней.
Скрипты 01-04 короткие, но превращать их в функции я не хочу, по той причине, что я планирую существенно увеличить размер скриптов simulate и synthesize. Сейчас они работают только с програмой IntelFPGA Quartus и Icarus Verilog, но я хочу чтобы эти скрипты распознавали и поддерживали Xilinx Vivado, GoWin synthesizer, QuestaSim, Synopsys VCS, Cadence Xcelium, возможно и OpenLane.
Далее, clean скрипт такой потому что в момент cd он работает внутри временной директории, которую он собственно и удаляет.
Так а зачем? rm вполне может удалить директорию и без cd
Все остальные скрипты во всем дереве - это копии скрипта
Еще больше причин все скрипты оформить функциями и вызывать просто функции. В результате останется всего два файла.
я планирую существенно увеличить размер скриптов simulate и synthesize
Функции могут быть существенно большими, никаких проблем тут не будет. Гляньте https://github.com/sfkulyk/jks-manager
Пусть собеседования проводит, код ревью делает, за стайлгайдами следит.
Копилот за меня пишет б0льшую часть кода, чатгпт за меня сочиняет сопроводительное письмо к резюме,… Будущее уже тут, даже если еще не все это поняли.
Копилот за меня пишет б0льшую часть кода, чатгпт за меня сочиняет сопроводительное письмо к резюме,
Становится интересно — а кто тогда за Вас зарплату получать будет?
Очевидно, я, ведь инструменты не являются субьектами. Причем скорее всего больше чем раньше, учитывая что продуктивность растет разительно.
В чем их прелесть и заключается.
инструменты не являются субьектами
Зато владелец инструмента — является.
Именно, поэтому он и получит всю зарплату.
Именно, поэтому он и получит всю зарплату.
Вот и я про то же: он-то получит, а Вы тут каким боком?
"Скрипач - не нужен" (с)
В смысле? Я инструмент купил, он мой, я им пользуюсь.
Я инструмент купил, он мой, я им пользуюсь.
А что, Вам его кто-то продал?
Добро пожаловать в XXI век, программы никто больше не продаёт, продают право пользования ими — это во-первых.
Во-вторых, Билл Гейц, гугель и прочие Безосы не настолько дураки, чтобы делиться с Вами прибылью. Они скупят оптом все лицензии и сами будут получать всю прибыль от пользования инструментом. Делиться с Вами? Ещё чего! "Это капитализм, детка", прав тот, у кого больше прав бабок.
Инструмент без мастера, его использующего, не стоит ничего. И ничего не делает.
Инструмент без мастера, его использующего, не стоит ничего. И ничего не делает.
Ну Билл Гейц наймёт за два цента десяток индусов.
Или не наймет. Инструмент обычно как раз заменяет низкоквалифицированных людей, а не наоборот. То есть если раньше мне нужен был в команду человек который будет километры бойлера писать (и скорее всего это был бы именно тот товарищ за два цента), то теперь мне невпадлу нажать 3 кнопки и сделать это самостоятельно. При этом мою часть работы (головой) машина сделать не скажу что не может совсем, но без подсказок с моей стороны — без шансов, а чтобы знать как подсказать, нужно представлять половину ответа уже.
Ну так Вы определитесь уже, какой вариант Вы видите — "я нажал кнопку "сделать мне хорошо", и оно всё-всё сделало, а я только бабки получил", или "раньше я копал лопатой, а теперь буду экскаватором, но за рычагами всё равно я". А то Вы начали с первого, а закончили вторым.
Но только во втором варианте [будущая] проблема (не для Вас, а для индустрии): если джуны больше не нужны — то из кого будут вырастать [новые] сеньоры?
Ну так Вы определитесь уже, какой вариант Вы видите — "я нажал кнопку "сделать мне хорошо", и оно всё-всё сделало, а я только бабки получил", или "раньше я копал лопатой, а теперь буду экскаватором, но за рычагами всё равно я". А то Вы начали с первого, а закончили вторым.
Это примерно одно и то же. Нажимать на рычаги — это по сути 0 работы по сравнению с тем чтобы лопатой с утра до вечера неделю махать. Я позволил себе вольность округлить до нуля при сравнении двух величин, где вторая непропорционально больше.
Но только во втором варианте [будущая] проблема (не для Вас, а для индустрии): если джуны больше не нужны — то из кого будут вырастать [новые] сеньоры?
Кажется, есть профессии, где на самом старте уже нужно много уметь, врачи например. Возможно айти больше на это станет похоже, где после универа ещё 5 лет ординатуры. В любом случае человечество в целом в выигрыше от такого, как и от любой автоматизации. Меньше людей занятых на работе — больше людей смотрящих нетфликс на велфейре — мы ближе к wall-e утопии.
Нажимать на рычаги — это по сути 0 работы по сравнению с тем чтобы лопатой с утра до вечера неделю махать.
"лопатой с утра до вечера неделю махать" было давно и неправда до появления визуальных редакторов — когда стало больше не нужно подавать команды вида "компьютер, подвинуть курсор на 3 строки вниз и 18 символов вправо, а там вставь символ "=".
Меньше людей занятых на работе — больше людей смотрящих нетфликс на велфейр
А с чего такая уверенность, что государство должно и будет платить всем щедрый велфер?
Ну, надо же будет чем-то население занять.. Можно конечно в крествый поход куда-то отправить, но это тоже не бесплатно.
надо же будет чем-то население занять..
Не обязательно, в Канаде просто предлагают бесплатную... эвтаназию как альтернативу тому чтобы стать бомжом. https://www.dailymail.co.uk/news/article-11516989/Canadian-man-doctors-approval-euthanasia-despite-admitting-POVERTY-main-factor.html
С того, что я не верю в то что люди добровольно пойдут на кладбище, ущерба от миллионных бунтов будут куда больше чем от велфейра.
Его придумали как и многие другие вещи не от великого человеколюбия, а по прагматическим причинам.
я хочу скормить chatgpt неоконченную книгу и посмотреть чем она закончится.
Но попытайтесь объяснить это менеджеру, который это не понимает.
Вы, Юрий, подняли проблему значительно более серьёзную, чем ChatGPT и даже SystemVerilog. Сейчас считается, что управление людьми может быть абстрактным, без понимания предметной области. Причём это так везде.
И предстоят годы жесточайших разочарований, прежде чем эта дурь не будет выбита из головы всех и каждого. Посмотрите скажем, скажем статью https://habr.com/ru/post/713462/ — лирический герой пришёл из условного «конвейера» в творческую область, нихрена не прочитал об особенностях, и считает, что «может управлять».
Если зачерпнуть стаканом воды из болотца, то пропорция флоры в стакане будет практически идентична таковой в самом болотце. Значит, проблема не на производстве/НИИ/IT-компании или в банке. Проблема в корневых свойствах популяции, идущих ещё от обезьян - лучшую самку берет самый успешный. В 60-х годах это был физик, в 70-х - гитарист, сейчас - нагловатый и пробивной менеджер.
Как от этого защититься, если не хочется самому становиться таким же, жертвуя своим призванием? Общего ответа нет, но если «три этажа сверху» решили пожертвовать собой «техническими», чтобы инженерам под их прикрытием было возможно работать - то это большая удача. У вас есть полупроницаемая мембрана, и состав флоры в вашем конкретном стакане отличается в лучшую сторону от общего болота. Но это состояние неустойчиво - невежество и наглость могут порвать мембраны (M&A компании, новые инвесторы, смена совета директоров, инъекция родственников владельцев в вертикали итд) - и все, прощай защита. Как только к власти хотя бы в одном узле придёт самоуверенный дурак, у которого «все просто» - вся функциональная ткань организма начнёт замещаться соединительной, а вместо полезной информации по синапсам компании начнут циркулировать директивы и KPI. С этого момента структура начнёт подавать признаки Альцгеймера, потом оттуда уйдут способные производить истинную информацию (а это в нашей Вселенной умеют только мылящие существа), и дальше кривая резко уйдёт в землю, и структура превратится в зомби и затем в мумию.
Заметьте, это применимо к организациям любого масштаба - например, к несчастью, подобный закат наблюдаем сейчас мы все на 1/6 части суши (.
Проблема в корневых свойствах популяции, идущих ещё от обезьян - лучшую самку берет самый успешный.
Это сведение мотиваций людей к переупрощённым поведенческим паттернам приматов мягко говоря бессмысленно, если не вредно.
Люди в рассматриваемом контексте — это не животные. Даже скорее антиживотные — люди ставят себе все, интересные в данном контексте цели, сами.
Вопрос лучшей самки: вы намекаете на то, что женщины-менеджеры — это скрытые лесбиянки? Не соответствует наблюдениям.
Ну и окончательно: вы же абсолютно никак не раскрыли вопрос, почему «самый успешный» — это «менеджер-универсал, незаинтересованный в ознакомлении с предметом управления». Только его чутка переформулировали.
Это сведение мотиваций людей к переупрощённым поведенческим паттернам приматов мягко говоря бессмысленно, если не вредно.
Там чуть сложнее, но в целом так и есть, мотивация не изменилась с первобытных времен.
женщины-менеджеры — это скрытые лесбиянки?
Мотивация женщин вообще в корне отличается от мужской.
https://humans-ethology.com/files/zhenschina._uchebnik_dlya_muzhchin._1ya_redakt.pdf
Приведённая книжка просто ужасна. Сборник неразрешённых комплексов и проблем.
Книжка реально стоит того, чтобы стереть её из памяти. К сожалению, имел несчастье её прочитать и повестись. Позже, по мере знакомства с научпопом начал осознавать, что с ней не всё хорошо. В общем, автор -- дилетант, а возможно и активный шарлатан. Как следствие, книга совершенно не коррелирует с современными научными данными, чаще им прямо противоречит. Типичная ситуация -- автор нахватался отрывков знаний, включая устаревшие и непроверенные, построил в своей голове как бы непротиворечивую (для него) модель и сразу нашёл ответ на вопрос жизни, вселенной и всего. И давай книжки писать.
не коррелирует с современными научными данными
Какие научные данные в такой недетерминированной сфере?
Только эмпирические данные.
Наука давно работает отнюдь не только с "детерминированными" данными. Не знаю уж, что вы под "эмпирическими" данными подразумеваете, но эмпирические (то есть полученные опытным путём или из наблюдений) -- это и есть научные данные, если они запротоколированы. Так вот, книги Новосёлова противоречат тем самым эмпирическим данным наблюдений, а также не сочетаются с признанными теориями, что является необходимым условием. Его книги это чистая графомания его имхо.
Давайте разберем что там не так?
Не считая его некоторых антизападных заносов (оставим это на его совести).
С чем именно в женском поведении и отношении противоречат научные данные? По моему там оно описано довольно близко к истине.
не сочетаются с признанными теориями
Надеюсь это не те современные фем-, гомо- и прочие критические расовые теории.
Про то что мотивация не изменилась, вы, вероятно, правы. Но приведённая вами книга - это какая-то кладезь стереотипных штампов, присыпанная шовинизмом и бодрой ненавистью к западному обществу:
Прекратив рожать детей, западная эмансипированная женщина, по сути, перестала быть полноценной самкой
Практически во всех развитых странах возник демографический кризис. Попросту, женщины вместо того, чтобы рожать детей, предпочитают бороться за отъем материальных благ у ослабленных мужчин
Этнических европейцев просто вырежут под крики «Аллах Акбар»
и тому подобное. Вы же не всерьёз свои убеждения строите на книгах, подобных этой?
Даже скорее антиживотные — люди ставят себе все, интересные в данном контексте цели, сами.
Это что за цели? Возможно это какие-то промежуточные цели, а конечные цели почти всегда одинаковые и заданы генетикой - добыча ресурсов, статус, опыт, друзья или партнеры для размножения. Часто эти цели взаимопересекаются, например много ресурсов и определенный статус увеличивают шансы на выживание и получение более качественного партнера для копирования ДНК.
Вопрос лучшей самки: вы намекаете на то, что женщины-менеджеры — это скрытые лесбиянки?
С самками он немного упростил. Чуть правильнее будет: половые партнеры и ресурсы. А если совсем правильно и упрощенно - больше удовольствия и меньше страданий. Женщины-менеджеры и мужики-менеджеры по сути там именно за этим. Чтобы чаще лучше себя чувствовать и меньше чувствовать себя плохо. Кому-то для этого сейчас хочется быть лезбиянкой, а кому-то купить мерседес.
Забыл уточнение: мозг устроен таким образом, что в большинстве случаев он получает удовольствие именно от тех действий, который увеличивают вероятность размножения или добычи ресурсов. Хотя при желании систему конечно можно хакнуть, например героином.
женщины нифига таких не бракуют.
Там часто качество женщин соответствующее.
> мужчин откровенно не хватает.
Это только при взгляде на абсолютные цифры. Во всех возрастных группах до 40-50 лет - мужчин больше женщин.
в России, где мужчин откровенно не хватает
Это вы, товарищ майор из военкомата?
Я если честно вообще не понял почему самый успешный самец в вашем понимании именно самоуверенный менеджер , а не просто хороший спец в своей отрасли, ведь девушки очень любят когда парень разбирается в чем-то хорошо
В 60-х годах это был физик
Мне кажется, это слегка приукрашено.
Весьма глупое представление о "лучших". Ещё можно омегаверс сюда воткнуть, на том же уровне. Всё намного сложнее, чем это примитивное представление. Есть только одна черта дающая достаточное превосходство - видимая уверенность.
Так же весьма примитивное представление отношений в рабочем коллективе. Аналогия с фильтром подходит для небольших в большем - когда возможность влиять на ситуацию ограничена, а фильтр может пропустить достаточно для функционирования. Но бывает, что этого не достаточно и тогда используется ассимиляция. Кроме того, компании используют инструменты для избавления от тех кто не должен был пройти через фильтр или "испортился" в процессе.
Наблюдаемый сейчас процесс - это последствия того же начавшегося уже почти век назад. И последние десятилетия "фильтр" этой компании работает весьма хорошо, постоянно избавляется от того, что не отвечает внутреннему кодексу.
Вы слишком оптимистичны. Если структуре легче производить имитацию, чем саму работу - она будет производить имитацию. Для компаний с большой инерцией при поднятии вверх до уровня некомпетентности (типичное явление, описанное в литературе, кстати), внешне ничего заметного не происходит. Это как раковая опухоль - видимые симптомы появляются уже тогда, когда по всему организму уже рассеяны метастазы.
Чтобы этого не было, нужно создать полицию полиции и проверять саму структуру - но в этой полиции полиции тоже вырастет замещающая вертикаль.
Так что саморегулирования не видать - только перезагрузка.
Про США - если вы о политике - принципиальной разницы нет. Есть определённые процедуры, препятствующие превращению flip-flop геронтократии в тиранию - но не более того. Посмотрите, например, глубину риторики кандидатов от вечных партий ;). А что касается теорий жизненного цикла компаний итд - все как раз оттуда - так что эта проблема глобальная. В РФ плюс ко всему ещё и пещерная модель управления - весь большой «бизнес» нанизан на один кингболт, и это вносит свою атмосферу в структуру и стиль управления.
Честно говоря, не очень понятно, зачем в первом абзаце вы упоминали свойства животных популяций, связанные с доминированием, и общее состояние дел в какой-либо области деятельности. Не вижу связи между этими двумя явлениями. Если поясните, в чём между ними связь, буду благодарен.
И надеюсь, что это не покажется обидным или странным, но образный стиль вашего комментария показался мне переусложнённым, излишне искусственным. Я ценю, когда люди включают в устную и письменную речь метафоры, метонимии, сравнения, перифразы, но конкретно это сообщение мне было тяжело читать, пришлось дважды или трижды обращаться к нему. Прошу прощения, если задел или грубо написал.
Вот-вот. Тут ChatGPT и SystemVerilog не при чём. Менеджер приходит и говорит, вот тут у меня идея простенькая, сделай за недельку. И попробуй объясни, что "за недельку" это не сделать.
Да, найти доступную базу всех национальных парков мира с их координатами в 2023 году сложнее чем определить птичку на фото. Комикс не очень хорошо состарился.
найти доступную базу всех национальных парков мира с их координатами в 2023 году сложнее
В Google WolframAlpha забанили? https://www.wolframalpha.com/input?i=coordinates+of+all+united+states+national+parks+
Приведённый Вами запрос выдаёт географические координаты просто точек, видимо, центров парков. Для решения задачи из комикса нужно описание границ каждого парка. В виде последовательности вершин замкнутого контура, например.
Попросить, цитата, "базу всех национальных парков мира с их координатами"
Получить ровно то что просили
Пожаловаться "да я совсем не то имел в виду".
Месье, я так понимаю, менеджер?
А что же вы перешли к выполнению задания, не уточнив детали?
базу всех национальных парков мира с их координатами
Тут не указано, с какими именно координатами этих парков. Может, точками центров, а, может, таки и границ.
Тут не указано, с какими именно координатами этих парков. Может, точками центров, а, может, таки и границ.
"Все детали, явно не оговорённые в задании, кандидат имеет право принять по своему усмотрению". Иначе интервьюер может и не выдержать!
Месье способен держать в голове немножко контекста.
Вы нашли национальные парки США, задача не решена. Ну и общаетесь вы с позиции д`Артаньяна.
Иронично для этого комикса, что после десяти лет исследований с момента этого комикса теперь задача по определению птиц тоже становится лёгкой
А какого года картинка? :). Просто сейчас для check whether the photo is of a bird на самый первый взгляд:
- известно что задача — решается и есть прикладные приложения и может быть и статьи на хабре как это делать
- в принципе понятно что стоит гуглить либо в районе сервиса который image classification сделает но каждый запрос будет стоить копеечку либо на тему как сделать
- можно поискать людей кто на kaggle такие задачки писал на всяких pytorch...
Вы тут две разные проблемы смешиваете.
Менеджер без понимания предметной области с абстрактным управлением людьми и менеджер которому невозможно объяснить (или даже скорее менеджер который не слушает) это две разные вещи.
Хороший управленец (вне зависимости от предметной области и степени погружения в нее) будет слушать специалистов, найдет себе специалистов которые смогут дать альтернативное мнение если нужно ну и так далее. Заменеджит проблему в общем.
А плохой управленец может в общем и целом игнорировать объяснения и при полном понимании предметной области.
Проблема только в том, что для того, чтобы найти спец-тов, а не имитацию таковых, нужно самому быть спец-том. ) Или придётся доверять каким-то косвенным методам оценки, которые являются весьма слабой гарантией по факту. Отсюда и возникают поиски эксперта, который 10+ лет вытирал задницу туалетной бумагой фирмы N «потому что наша фирма использует именно такое оборудование». Сюда же прилетает и игнорирование собственных ошибок, потому что сделав неправильный выбор, после гадания на псевдо-не-кофейной гуще, «хорошему управленцу» будет совсем не вариант расписаться в собственной некомпетентности, и по таким законам жанра уровень абсурда будет только нарастать. Бывает, конечно и такое, что «баг на баг» дает искомый рез-т, но это редкость. Так что Хороший Управленец должен быть и Хорошим Спец-том. Иначе фиаска™.
спец-тов
рез-т
Скажите, пожалуйста, на что Вы тратите сэкономленные Вами две с половиной секунды жизни?
Экономия больше, так как не надо лезть в словарь и смотреть как оно правильно пиш-ся
Ну как же — все эти секунды уходят на жалость к подобным инвалидам, которые испытывают невообразимые интеллектуальные муки, пытаясь сначала разобраться в общеупотребительных сокращениях, а потом применяют изрядно заезженный «пассивно-агрессивный» шаблончик про «экономию секунд», в попытках мщения за столь увесистый вред их головному мозгу. Не знаю, что вас удержало от обращения в суд. Пожалуйста, не держите зла.
«пассивно-агрессивный»
в попытках мщения
Пожалуйста, не держите зла.
Интересно откуда у современной молодёжи такое ощущение собственной значимости, что они посюду к себе агрессию чувствуют? Страшно подумать, что когда-нибудь именно они будут сидеть за ядрёными кнопками...
Не знаю, что вас удержало от обращения в суд.
Наверное, тот факт, что меня в детстве учили, что на отдельные категории людей совершенно не стоит обижаться? /s
Вы просто не понимаете, что экономите свое время за счет других. Вам быстрее написать, другим дольше читать.
Как обочечник, которому больше всех надо. Да, в итоге он проезжает быстрее, но другие из-за него едут дольше.
Даже не так, а вот так: серийный программист Джон
Проблема только в том, что для того, чтобы найти спец-тов, а не имитацию таковых, нужно самому быть спец-том
ответил ниже - варианты есть
Хороший управленец (вне зависимости от предметной области и степени погружения в нее) будет слушать специалистов, найдет себе специалистов которые смогут дать альтернативное мнение если нужно ну и так далее.
Откуда «хороший управленец» определит, кто спец, а кто — нет, без малейших сведений о предметной области? Первейшее дело, которое управленец должен сделать при переходе в новую для себя область — самообразование. Вспомните того же Сталина, читавшего книги по металлургии.
В случае лирического героя статьи по ссылке, он должен был сразу же копать литературу в области «как управлять разработкой программного продукта» и читать, читать, читать. Искать опытных управленцев, пытать их. А не случайно узнавать у ¡секретарши!, что совершает дикие ошибки, задав жёсткий срок окончания работ, а не промежуточные плавающие сроки с промежуточными целями. Блин, если бы он там в припадке ярости уволил хотя бы четверть персонала, про срыв сроков не говорим, он бы просто весь проект сорвал бы.
Откуда «хороший управленец» определит, кто спец, а кто — нет, без малейших сведений о предметной области?
Тут ничего нового - рекомендации, нетворкинг, референсы. Видел пару раз как люди довольно далекие от предметной области собирали хорошие команды спецов и потом не мешали им работать.
самообразование
Это тоже часть про заменеджит, однако требует время, а управлять надо вот уже. Один из вариантов выхода кстати - поиск управленца из предметной области и управление управленцем, чем не выход?
Вспомните того же Сталина, читавшего книги по металлургии.
Звучит как анекдот, что периодическая таблица элементов приснилась сначала Пушкину, только он ничего не понял. Так и Сталин. Непонятно, что он понял, прочитав книгу по металлургии, но мог расстрелять всех, причастных к изданию этой книги. На всякий случай.
Искать опытных управленцев, пытать их.
Да, Сталин в этом деле был мастер. И главное ведь у него это как-то само получилось? Неужели без чтения специальной литературы? Какой самообразованый человек был! Вы бы ещё мсье Гитлера в пример привели, как художник смог поднять Германию и поставить на уши весь мир. Но зато в отличии от Сталина, прочитавшего книгу, Гитлер написал книгу.
Но среди всяких императоров лично мне нравится Наполеон. Потому что у него есть теорема Наполеона. Раньше было лучше. Потом императоры совсем никудышные пошли.
что совершает дикие ошибки, задав жёсткий срок окончания работ, а не промежуточные плавающие сроки с промежуточными целями.
Прям как в анекдоте «вы либо трусы наденьте, либо крестик снимите». В одном предложении приводить в пример Сталина, а в следующем критиковать методы его работы. Уверен, что и Чикатило тоже книжки читал, но вы почему-то не его привели в пример. Интересно, на чём основана ваша избирательность?
Также напомню, что Сталин был ярым противником кибернетики, которой вы как раз и занимаетесь. Стоит ли упоминать известное выражение Сталина, что «Кибернетика — чуждая марксизму ж...овская наука».
И вы приводите этого человека здесь как пример!? Вы серьёзно?
Хватит вешать лапшу что Сталин преследовал кибернетику. Даже сли вы делаете это от незнания, вам не добавит чести. Первый институт в СССР по проектированию компьютеры был построен в 1948 году ИТМВТ, Институт точной механики и вычислительной техники имени С.А. Лебедева. Он создан в 1948 году для разработки электронных вычислительных машин – основного технического средства кибернетики. Но вы как ”продвинутый интелекуал" конечно же об этом не скажете и будете цитировать Хрушева, вернее те правки которые кукурузный приказал внести в речи Сталина.
а что вы скажете на цитату из Философского словаря 1954 года издания:
По существу своему кибернетика направлена против материалистической диалектики, современной научной физиологии, обоснованной И.П. Павловым (см.), и марксистского, научного понимания законов общественной жизни. Эта механистическая метафизическая лженаука отлично уживается с идеализмом в философии, психологии, социологии.
цитата по http://vivovoco.astronet.ru/VV/PAPERS/BIO/CYBER.HTM
Такие политические книги вряд ли могли пропустить без тщательной проверки на соответствие партийной линии. а Сталин уже умер к 1954-му году
… форма современного механицизма. Приверженцы кибернетики определяют её как универсальную науку о связях и коммуникациях в технике, в живых существах и общественной жизни, о «всеобщей организации» и управлении всеми процессами в природе и обществе. Тем самым кибернетика отождествляет механические, биологические и социальные взаимосвязи и закономерности. Как всякая механистическая теория, кибернетика отрицает качественное своеобразие закономерностей различных форм существования и развития материи, сводя их к механическим закономерностям.
Мы сейчас под словом «кибернетика» понимаем несколько иное.
не так вот это
Хватит вешать лапшу что Сталин преследовал кибернетику
Кибернетика, как лженаука об управлении, в том числе и человеками - коммунистам не нужна. У них для этого есть Линия Партии.
А компьютеры коммунистам нужны - траектории баллистических ракет расчитывать, например..
Вот такая вот коммунистическая диалектика.
Это ваша диалектика. Никак не Сталинская. Идиотов везде конечно хватало. Но наличие идиотов в популяции никак не связана с идиологией или политсистемой, они есть всегда. Наивно думать что Сталин не интересовались новейшими иследованиями .
>>Наивно думать что Сталин не интересовались новейшими иследованиями
Ну так и Гитлер тоже читал книги и интересовался новейшими достижениями и преуспел даже лучше Джугашвилли.
Мне вот интересно, где проходит та черта или что является тем признаком, когда вы начинаете считать что вот этот людоед вам родной, а другой - это ваш враг? Вы сами сможете назвать или вам нужна посторонняя помощь, чтобы разобраться в этом тонком моменте?
Интересовался, конечно. И делал выводы. Например, что наука, которая, в теории, позволяет заменить руководящую роль Партии несложным скриптом - является буржуазной лженаукой.
Немного не в тему, но управление компьютерами имеет один фатальный минус - их легко обходит как человек, так и общество в целом. Другое дело, что можно дополнять и защищать там, где не справляется алгоритм и наоборот, закрывать слабые стороны человеческого фактора.
Вырвано из контекста. Речь шла о попытках применения К. в общественных науках. О чём уже написали ниже.
Вспомните того же Сталина, читавшего книги по металлургии
"Хороший политик" использует науку для достижения своих целей. Если наука не подходит, создаётся своя: маркститко-ленинская философия, Ahnenerbe...
Прекрасная формулировка. Я вижу то же самое сегодня в университетах когда администрация указывает специалистам как работать.
Как серпом по колокольчикам. Был у нас тут "эффективный менеджер". У вендора было сырое ПО. И "эффективный менеджер" говорит, типа "хера тут делать то, допрограммируйте то-то и то-то и всё". Учитывая, что мы не программисты, возникает очень много вопросов. Человек даже не понимает сути, распределения времени, обязанностей и т.д. Но тем не менее менеджер и получает приличную котлету от проекта.
Человек даже не понимает сути
Возможно, наоборот, всё он понимает. Если ${vendor} не сделал ${feature} в своём ${product} - значит, есть в этом какие-то особенности. Не нужно быть великим программистом, чтобы сообразить. Возможно, ему наоборот интересно чтобы ${feature} не появилась. Может, у него в планах протолкнуть переход на ${newvendor}.
И предстоят годы жесточайших разочарований, прежде чем эта дурь не будет выбита из головы всех и каждого
Из головы всех и каждого? Вы серьезно так думаете? Тогда вам предстоят "годы жесточайших разочарований".
Да ничего страшного, мне около 15 лет назад тоже на основе того, что выдаёт декомпилер байткода сказали что там делов то, вот перед скобочкой надо if добавить и дописать пару условий, в автоматическом режиме на произвольном бинарнике. Я попытался объяснить что править байткод без внятного инструментария такая себе идея. В попытке доказать что это невозможно я задачу таки решил, и вынес для себя очень важный урок, на тему глаза боятся, а руки делают. И менеджеры которые не понимают сложность реализации были всегда.
Находить паттерны в байткоде и править - это вещь стремная, но если понимать риски, возможная. Тут другое. Тут есть два описания схемы, одна связана с архитектурной спецификацией (что блок должен делать), а вторая с микроархитектурной спецификацией (как он это делает). Все это объединено в рамках одного языка, но первое описание похоже на софтверные программы (блоки, которые отвечают на транзакции, в нем например нет тактового сигнала), а второе описывает аппаратные структуры (в нем есть тактовый сигнал, конвейер итд). Первое не будет превращаться в железо, а второе будет. Мучать первый тип кода чтобы он превратился во второй - это мечта менеджмента с начала 1990х (я это знаю, так как у меня был стартап на эту тему). Так вот ChatGPT спросили дать код, он дал код первого типа, а на запрос выдать код второго типа (синтезируемый) просто добавил к коду первого типа "always_comb" и сказал (сверкая честными глазенками) "готово".
В моём случае начальник тотально ничего не понимал про байткод. Он запускал декомпилер на бинарник и видел код, думая что он там как в архиве лежит и говорил ну подправь вот тут код. Никакие объясения что того кода там в помине нет не помогали.
Они абсолютно одинаковы, если посмотреть с точки зрения того, что в обоих случаях начальник некомпетентен. И почему-то ещё находится на своём месте.
Потому что тот, кто начальника нанимает и увольняет, некомпетентен ещё более, и не может отличить, кто ему больше пурги гонит — начальник или разработчик.
В моём случае всё было просто, этот начальник вдаделец бизнеса и основной работник с поверхностными знаниями в it но успешный в другом, я был единственным айтишником, так что некому было его увольнять.
А вы видели хоть один кусок кода, «написанный» ChatGPT, который был бы не таким? Я вот пока нет. Все что тут в статьях расхваливали, что вот оно, будущее настало, все что сам пробовал — оно на, мой взгляд, все примерно такое, как у вас получилось. То есть — на практике неприменимое. Несопровождаемое. И так далее. Без исключений.
Я на днях получил от него нужную мне функцию на VBScript для Excel, которая потребовала лишь косметических правок и заработала. И это был первый раз, когда я вообще что-то сделал на VBScript. Простенько, но и затрат ноль.
Причем, все это валидно не только для результата работы ИИ, обычный живой программист тоже может принести вам результат, про который вы всего этого не знаете достоверно. Вот тут несколько раз приводили примеры типа: «Смотрите, оно задачку и литкода решило, и тесты прошли». Ну так это означает, что оно удовлетворяет требования литкода к решению. А когда это будет ваша задача — это будет вашей функцией решать, правильное ли решение ChatGPT вам подсунул. И если вы не разбираетесь в предмете — эта задача (тестирования, в широком смысле) ничуть не проще самой задачи создания решения. И ChatGPT не может вам объяснить, как он решение получил, и почему оно верное.
Я не отличаю VBA от VBScript, но результат получил, о чём и речь. Для моей функции на 50-60 строк этого хватило, ТЗ соответствует) Сложнее - пока не выйдет, но ведь и нейросети сейчас стремительно становятся сложнее. Качественный сдвиг уже произошёл, а количественный подтянется. В том числе и возможность попросить раскомментировать код, объяснить логику его работы. Это уже даже сейчас можно просить и получать.
И ведь мы даже не заостряем внимание на том, что ChatGPT, вообще-то, не предназначен для программирования. Никто его этому специально не учил. Это побочная, неожиданно развившаяся, так называемая emergent ability, самозародившаяся просто в результате объёма его знаний. Что будет когда его отдельно и прицельно потренируют на конкретном языке, и привяжут к нему соответствующие инструменты? Например, сейчас у него большая проблема с точными вычислениями, но есть модификация GPT-3, связанная с движком WolframAlpha, которая выдаст ответы с точностью до N-го знака после запятой.
Ну, знаете.. Программа уже написана, осталось ее тупо закодировать. Причем в виде описания на естественном языке она занимает больше места, чем на С++. И самое интересное тут не цикл for, а формула цвета, которую думал человек.
Первый запрос был такой: "Напиши скетч для ардуино, который будет управлять гирляндой. Три режима моргания, шесть NeoPixel, одна кнопка". Дальше он всё сам.
Значит, итераций больше чем 2?
Нужны ли в процессе от человека знания про архитектуру ардуины? Функция loop, pull-up резисторі и все такое?
С первого раза он выдал длинный, красиво отформатированный код, как по учебнику. Три режима мигания были отдельными функциями. Потом я попросил его максимально сократить количество строк (я ведь всё это затеял ради одного скриншота), типа убрать #define, устранить функции в пользу спагетти-кода, и он это сделал. От меня никаких знаний не нужно, да и более того - я могу спрашивать зачем нужно то или иное, и он всё подробно расскажет. Зачем setup() и loop(), как использовать либы adafruit, всё такое. Если мне не нравится паттерн моргания, я могу его описать русским языком, и он изменит код соответственно. Если компилятор выдаст ошибку - передам её боту и он предложит багфикс.
Но, повторю, это работает с маленькими программами, пока они помещаются у него в кратковременной памяти.
повторю, это работает с маленькими программами, пока они помещаются у него в кратковременной памяти.
Вообще не проблема!
Делаем декомпозицию и пишем процедуры и функции, которые умещаются в его памяти, и уже используя их пишем модули, которые умещаются в его памяти, и уже их объединяем в программу, которая умещается в его памяти.
Декомпозицию и архитектуру, тоже можно делать не самостоятельно, а при помощи нейросетки.
А когда условный ChatGPT v2 сгенерирует синтезируемый код, в котором не будет никакой понятной структуры что мы будем с ним делать? (К обычным программам это тоже относится). Ну прогоним тесты, они пройдут. Но это даст меньше уверенности, чем при тестировании вручную написанного кода, потому что модели ошибок у реализации, которая писалась как условный конечный автомат (или еще какую-то структуру) и у огромного спагетти-кода - разные! Отдельный вопрос, как это хозяйство развивать, кроме как перегенерировать заново с новыми требованиями.
Сейчас похожая проблема возникает с нишевыми тулами для высокоуровневого синтеза, например Catapult C, которые превращают подмножество Си в зашифрованный модуль на верилоге. Но про сравнению с адом имени ChatGPT это цветочки. Собственно особой проблемы тут нет до того момента, когда в той или иной компании менеджмент или начнет продавливать это использовать, или уверовавший в ChatGPT инженер вставит сгенеренный блок куда-то.
Мне кажется, что это два принципиально разных примера.
В случае с Catapult C - вы можете обычными методами тестирования проверить правильность С-программы. И дальше - специфические тесты на транслятор Catapult C. То есть специфические тесты на ошибки в двух моделях.
В случае же с ChatGPT у вас нет ни одной модели, верность которой вам проверять.
Отдельный вопрос, как это хозяйство развивать, кроме как перегенерировать заново с новыми требованиями.
Ну с компиляторами ЯВУ как-то сжились. Да, придётся перегенерировать.
Проблемы нейросетей в том, что они принципиально не дают модели своего поведения. То есть, как исправить код на С, чтобы он после компиляции выдавал 146% то, что нужно, понять легко.
А вот если будет компилировать нейросеть, это будет по условиям задачи невозможно.
Видимо, нужна принципиально другая постановка задачи. Компилятор - это не черный ящик, в него можно залезть и попробовать повысить его надежность. То есть, для зрелых проектов имеем, грубо говоря 99% с перспективой улучшения. Предположим, что ChatGPT дает на 95% работающий код. И получаем мы его с гораздо меньшей трудоемкостью. Но перспективы улучшения очень туманны. А получить халявный результат всё равно хочется :) Может быть придется идти по известному пути получения надежной системы из ненадежных компонентов? Резервирование и вот это всё? Три нейросети код генерируют, еще одна тестирует?
Ну да, концепция «чёрного ящика» полностью исключает направленное развитие. Только случайное. Мне кажется, что это как раз прикрывает это направление. Либо, можно делать попытки вытаскивания каких-то структур из «чёрного ящика».
То есть, имея две фазы: получение какого-то результата с помощью нейросетки, а потом выяснение того, почему же именно эта нейросетка добилась такого результата. Потом построение модели, и следующей версии нейросети на основе этой модели.
Резервирование и вот это всё? Три нейросети код генерируют, еще одна тестирует?
Скорее компилятор тестирует. Вопрос — сколько времени эта генерация будет занимать?
А зачем эти тесты, если они нагенерированы тем же методом из той же самой спецификации?
Вся суть верификации - это сравнение интерпретации спецификации четырьмя людьми:
человеком, который реализует X;
человеком, который реализует модель X;
человеком, который пишет тесты для X и модели X, а потом сравнивает ответы X и модели X;
и человеком, который проверяет полноту покрытия тестами плана верификации.
Если эти люди совпадают (или если это делает одна и та же нейросеть) то имеется проблема
А у 3 и 4 разве есть конфликт интересов? Их-то, вроде, можно совместить.
Если 3 - лентяй, то он может сначала написать в плане тестирования слишком расплывчатые формулировки для тестирования определенных фич скажем "проверить работу команды сложения с константой", а потом, если он еще и 4, написать covergroups (это штука в SystemVerilog которое проверяет функциональное покрытие) которые ждут появления только сложения с константами 0, 1 и 101, и забыть про проверку покрытия сложения с отрицательными чистами.
Было же уже сильно похожее, когда в начале, емнип, 2000х сильно баловались с fpga и "генетическими алгоритмами".
Конечный результат - насколько я помню - был примерно такой. На выходе получалась "нех", которая непонятно как "то работает, то не работает". Порой получались даже варианты, которые "работали" без гтч. Анализу "нех" поддавались, мягко говоря, плохо (на то оно и "нех"). Типа, убирание "бессмысленных" ячеек, убивало схему. Или "нех" могла норм работать, в одном участке матрицы, и "вообще не работать" в другом. Могла сильно зависеть от температуры, например. А могла и не сильно.
Поигрались, посмотрели... сказали: " потрачено" и, насколько я понимаю, на этом все и закончилось :-)
На выходе получалась "нех", которая непонятно как "то работает, то не работает". Порой получались даже варианты, которые "работали" без гтч. Анализу "нех" поддавались, мягко говоря, плохо (на то оно и "нех"). Типа, убирание "бессмысленных" ячеек, убивало схему.
Самая мякотка
...конструкция найденного решения оказалась в высшей степени интригующей. Из выделенных изначально 100 ячеек в итоге для функционирования схемы оказалось задействовано лишь 32. Остальные можно было убирать, что никак не меняло работу конфигурации.
При этом 5 ячеек из оставшихся 32 вообще не выполняли никаких логических функций, способных влиять на выход. Тем не менее, при их отключении тут же прекращалась и работа схемы, т.е. различение сигналов разной частоты. Очень похоже на то, что эволюцией были задействованы какие-то физические свойства этих ячеек — возможно, емкостный эффект или электромагнитная индукция — чтобы влиять на сигнал, проходящий поблизости. Неким неведомым образом этот тонкий эффект от “посторонних” ячеек сыграл свою роль и был интегрирован в окончательное решение.
ну вот вам и эффект https://ru.wikipedia.org/wiki/Эффект_бабочки
Что самое смешное, это уже один раз произошло в микроэлектронике.
Вместо лаконичной, компактной и красивой, любовно нарисованной руками топологии чипов теперь везде адская синтезированная мешанина :)
Научить генерировать на формально верифицируемых языках (agda, idris). Тогда другая машина сможет убедиться, что сгенерированная программа корректная, а человек просто проверит, что соотношения выраженные на типах соответствуют ТЗ
Вспомнилась история c башорга, цитирую по памяти: разбирал код системы, которую должен был поддерживать, нашел участок, представляющий собой две страницы сплошного ассемблерного кода без пробелов и форматирования, перед ним комментарий предшественника: "что это - не знаю, как работает - не понимаю, трогать боюсь". ЧСХ задолго до каких-либо ChatGPT.
А его самого спросить не судьба?
Да спросить-то можно. Но откуда доверие к ответу взять?
НЕдоверие к ответу можно взять прямо из интернета, пройдя по предложенной им самим ссылке.
Luxoft/EPAM/Auriga, типичный аутсорсный проект - сроки сдачи вчера, но код уже весь есть, правда не компилируется, там просто поправить немного, ведь Индусы на аутсорсе уже всё сделали. Внимание вопрос, чем это отличается от того, что предложил тебе Менеджер+ChatGPT связка? ;-)
Будет страшнее, когда ChatGPT сгенерирует рабочий код, вы построите по нему железку, а затем
Был замечательный фантастический рассказ, где роботы поймали человека, исследовали его, и выяснили, что его жизнь можно продлить путём уменьшения подачи кислорода для дыхания. Ткани же окисляются..
Такая тема реально была популярна одно время
Восьминулевые. Там ещё был десятинулевик, местный робот генерал, один в один как синтезированный алгоритм комментариев для яндекс маркета, предложил давать снотворное и будить раз сутки на одну минуту и параллельно давать интересные задачи каждый день до смерти, чтобы он не хотел спать. ИИ который мы заслужили. Но кончилось все хорошо: "Дважды два - около четырёх".
Ну, это выглядит проблемой обучающей выборки (не учил никто сетку на примерах именно синтезируемого кода, вот она и решает не ту задачу). Плюс непонимание этого факта менеджером.
Я предполагаю (если chatGPT взлетит) другую проблему: она будет периодически генерить неверный код без видимых невооружённым глазом ошибок. И чтобы его исправить – понадобится очень квалифицированный программист.
Ну так оно так и делает сейчас. Код чуть посложнее простейших примеров как правило выглядит рабочим, компилируется-запускается (хотя это полагаю, зависит от языка) но не работает. Но часто если его немного поправить там и тут - заработает. При этом чтоб понять где проблема нужно как минимум мочь тоже самое написать самостоятельно. Пример же скопированный со стэковерфлоу вероятно заработает сразу.
Это, примерно, аналогично тому, когда ты приходишь на легаси проект.
Знаете, я развлекался копипастой в Юнити со Стековерфлоу. В 4 случаях из 5 мне нужно было 3-4 примера, из которых я делал кадавра. В последнем пятом я понимал сам метод и писал тоже сам, уже по мануалам функций и процедур (за название не отвечу, терминологию не учил совсем). Всё равно приходится знать самому на уровне выполняемой задачи, будь то алгоритм движения или парсинг строк (простейшее).
Это не сильно отличается от достаточно регулярно возникающей ситуации вида "вот смотри, уже есть готовый алгоритм на С, надо только синтаксис под Verilog поправить и готово". Просто при появлении новых инструментов человеческая глупость умножается на их возросшую производительность.
IMHO намного большая проблема всех этих GPT - это то что в массовом сознании достоверность обесценивается в пользу правдоподобности. Хорошо когда условный код можно относительно быстро и автоматизированно проверить хотя бы по критерию работоспособности, а вот проверить фактическую достоверность нагенерённых "статей"...
В общем ждём весёлых историй вроде "ChatGPT посоветовал выпить метилового спирта для дезинфекции желудка".
P.S. Юрий, я думаю что вам не стоит беспокоиться по крайней мере до тех пор пока ChatGPT не научится применять кредитные счётчики. :)
ждём весёлых историй вроде "ChatGPT посоветовал выпить метилового спирта для дезинфекции желудка".
Уже были весёлые истории вида "в Интернете посоветовали пить ивермектин от ковида", так что здесь ничего нового.
намного большая проблема всех этих GPT - это то что в массовом сознании достоверность обесценивается в пользу правдоподобности. Хорошо когда условный код можно относительно быстро и автоматизированно проверить хотя бы по критерию работоспособности, а вот проверить фактическую достоверность нагенерённых "статей"...
Ну да.
Давеча, мне прилетел комментарий к статье:
Статейка ни о чём, буквально, дай нейросети затравку - она напишет лучше
Удивительно, на youtube говорят другое - и асинхронные очереди, и машины состояний, и параметризируемые модули - все выходит вместе с testbench и комментариями.
Я глянул очень кратко на youtube. Там три тривиальных дизайна, которые гуглятся в интернете.
16-битный сумматор - ну это грех не написать.
FIFO - оно там написано неоптимально, не так как принято писать FIFO в электронных компаниях, но как проще писать студентам. Я это разбирал вот здесь - https://habr.com/ru/post/713122/#comment_25162646
Простейший конечный автомат.
Да, я согласен, что если ChatGPT сказать "напиши сумматор", он его напишет, но уже арбитры он писать не умеет - вместо round robin пишет приоритетный арбитр, а на возражение "это не round robin, а приоритетный арбитр" пишет "извините, ошибся" - и снова пишет приоритетный арбитр.
То есть оно может писать простейшие компоненты, которые можно нагуглить, но вот строить из них вычисляющие что-то структуры не умеет - пишет несинтезируемый код. Я по крайней мере пока не видел.
То есть оно может писать простейшие компоненты, которые можно нагуглить
Получается, ChatGPT это дополнение к Google Search.
То есть оно может писать простейшие компоненты, которые можно нагуглить, но вот строить из них вычисляющие что-то структуры не умеет - пишет несинтезируемый код. Я по крайней мере пока не видел.
Как уже упоминали в комментах выше, выборка SystemVerilog кода очень мала: на github порядка 3К репозиториев содержат SystemVerilog код, 18К Verilog и 16К VHDL. Сравните с 5М+ для Java и с 3М+ для Python. Хардверный дизайн очень закрытая область.
По SystemVerilog была ещё и проблема с поддержкой тулзами. Насколько мне известно в той же Vivado (EDA для ПЛИС Xilinx) более-менее полную поддержку синтезируемого подмножества SystemVerilog подвезли года с 2019, до этого там постоянно надо было держать ухо востро и сверяться с мануалом, поддерживает ли ту или иную конструкцию эта версия синтезатора. Несинтезируемое подмножество и того позже. Отсюда вопрос: на чём вообще электронный мозг мог бы научиться, если большая часть SystemVerilog кода -- это закрытые наработки фирм?
Вы, как мне кажется, пытаетесь лишить «эффективного» менеджера обратной связи от системы, которой он управляет. Если сгенерированный менеджером код приведёт к тому, что чип «будет размером с чемодан, а задержка на котором будет не пикосекунды, а секунды» — значит это не является критериями оптимизации. Просто, ввязываясь в борьбу с менеджером, Вы мешаете ещё одному менеджеру практически доказать, что управление инженерами не делает из него самого инженера.
Просто через пару чемоданов владельцы бизнеса отправят менеджера на мороз. Если менеджер сам является владельцем бизнеса, то он либо откажется от этой затеи, либо пожертвует бизнесом.
Может, лучше посредника между бизнесом и кодером заменить на нейросеть? Требования вроде поменьше.
Это еще что за хрень, со ссылкой на 127.0.0.1:43110 ?
То же через прокси.
Я правильно понимаю что вот это извращение с ZeroNet ради ссылки на washingtonpost и одного! ОДНОГО КАРЛ! комментария к ней?
p.s.
https://www.washingtonpost.com/business/energy/google-faces-a-serious-threat-from-chatgpt/2022/12/07/363d2440-75f5-11ed-a199-927b334b939f_story.html
defder ━ on Jan 24, 2023 (modified on Jan 24, 2023)
So, humans should develop efficient anti-spam system.
Now, each user can post something to people.
In the future, each new user/identity will have to prove his worth first.
Представь так она анализирует людей, находит нелегальных иммигрантов по камерам или оплатам, мыслит аналитически и понимает, что 15 дней назад призывник бегал трусцой, а теперь почему-то у него появилась астма, и дает выводы военным, которые переотправляют этого человека на доп анализы и выходит, что у него нету астмы.
К таким вещам ее подключат, а вот к нахождению лекарства от спида не захотят наверное.
Но блин, это уже не кино, а реальность, нейросеть изменит весь современный мир.
Статья попахивает набросом. Менеджер, даже не самый лучший, всегда услышит какие проблемы есть и чего будет стоить работа. То, что описано в статье - это не менеджер, а совсем какое-то нереальное фуфло. Таких не встречал даже в крупных корпорациях
Подскажите, в какой уровень зарплат у проектировщиков плат, cpu, gpu ? Просто любопытно. Со стороны кажется , что область довольно наукоемкая и сложная , а вот адекватность ЗП вызывает сомнения;)
Вы про зарплаты в России или в Silicon Valley? В Silicon Valley зарплаты примерно на том же уровне что и у продвинутых писателей на C++ (типа для инфораструктуры облака или компиляторов). Про Россию у меня слишком отрывочные знания про зарплаты.
А сколько это в тысячах долларов в год до налогов? +-.
Честно говоря кажется что это потяжелее программирования и есть завязка на всего несколько компаний, где нужны такие знания, а это риск.
В чем мотивация инженеров этим заниматься, вместо программирования, где можно получать столько же и больше выбор компаний?
Широкая вилка от $150K (юный инженер) до $350K (супергуру аркитект).Старшие инженеры - $200K-270K. Отдельная тема - бонусы (порядок 20%) и опционы.
Мотивация может быть очень разная. Например, всё что связано с производственными технологиями, более объективно. Приблизительно как писал Маяковский:
Нецензурное
Силу в кулак, волю в узду, в работу впрягайся с маху.
Выполнил план - посылай всех в п...у, не выполнил - сам иди на х..!
Мне, например, куда легче живется от того, никто не может сказать мне, что результат моего труда - искомый, но путь достижения результата - "какой-то не такой". Хотя моя область - еще более "приземленная", чем разработка железа - автоматизированная металлообработка.
Сильно :-)
Приблизительно как писал Маяковский:
Мне вот интересно, хоть кто-нибудь из тех, кто приписывает это Маяковскому, имеет на руках пруф, что это действительно он, а не позднее подражание?
.Не понял насчёт объективности.
Как раз таки математика и как следствие программирование самые что ни на есть объективные - программа выполняет ровно то, что написано, а не то, что хочется;).
Можно даже формально доказывать корректность программ.
Пощупать результаты труда, тут да, согласен .
Но уровень ЗП все же играет роль, капитализм никто не отменял)
Честно говоря кажется что это потяжелее программирования
Микроэлектроника и программирование по разному дают нагрузку на мозг.
Микроэлектроника меньше нагружает мозг чем программирование Senior С#(полный стэк) в какой нибудь фирме.
В отрасли программирования надо чаще переучиваться чем в микроэлектронике.
Программирование вход легкий но работать в долгую тяжелее.
Микроэлектроника вход тяжелый но работать в долгую легче.
и есть завязка на всего несколько компаний, где нужны такие знания, а это риск.
Проектировщики микроэлектроники много где нужны. Без работы не остануться.
В чем мотивация инженеров этим заниматься,
Интересно.+ видишь результат своей работы + меньше сидишь за монитором.
Я кстати не слышал тут на хабре, чтобы микроэлектроники психологически выгорали.
А вот фулстэкеры(стильно модно молодежно) бывало тут на хабре писали как они выгорели.
Возможно, да
меньше сидишь за монитором.
А за чем сидишь?
Фен, паяльник, осциллограф, логический анализатор. За компом тоже сидишь: Altium, KiCAD, Cadece allegro, симуляторы, пакеты для конечно-элементного моделирования.
Прозвучало так, как будто это преподносится как плюс в плане сохранения здоровья. Мол, сидеть за монитором вредно или утомительно, а на этой работе работе вместо вредного сидения за компьютером получаешь что-то более полезное и менее утомительное.
На самом же деле сидение за паяльником я нахожу куда более травматичным, чем сидение за монитором.
И дело совсем не в испарениях флюса и микрочастицах свинца. Дело в шее и голове. Когда ты сидишь и смотришь вперёд в монитор, это естественная и нетравматичная позиция голове.
При пайке же голова наклонена вниз и ты смотришь не вперёд, а под углом около 70—80 градусов вниз.
Шея согнута.
Лично мне пришлось по этой причине сократить до минимума количество паяльных дел — после нескольких часов сидячки лицом вниз, головная боль на последующие сутки была обеспечена.
Осциллограф это тоже очень утомляющая вещь. При работе за компьютером руки лежат на столе или на клавиатурной полочке под столешницей и практически отдыхают.
При работе с осциллографом рука часто находится в вытянутом вперед положении, чтобы что-то подкрутить/нажать на нём. Другая рука при этом может минутами находиться в перенапряженном положении, потому что держит и упирает щупы в нужные точки на плате.
А самая мякотка это когда на манер китайских палочек для еды левой рукой упираешь сразу два щупа в разные точки на плате, а правой рукой двигаешь курсоры на осциллографе чтобы сделать замер (или хотя бы нажать Stop), при этом глаза направлены на осциллограф, и только стальная хватка гарантирует, что кончик щупа не соскочит с ножки TQFP-микросхемы и не устроит мгновенный апокалипсис в схеме.
Так что работа, когда ты 100% времени только в монитор и смотришь, она конечно более скучная, но уж точно менее изматывающая физически.
Ну а что касается пайки, то разве что безокулярный микроскоп типа Mantis решил бы проблему с шеей.
Вы затронули правильную тему. И понимающие люди видят в этом проблему. Но на это будут всё равно миллиарды выданы. Чтобы потом всё это забыть. Точно также как с "убийцами" программистов - case программами. Которые в конце 90-х ну из каждого утюга нам обещали, что вскоре не надо будет вообще программировать, только стрелочки соеденить визуально.
А если боту эту статью скормить он сможет исправить и сделать как надо? :)
Юрий, вы не правильно поставили задачу. Маловероятно, что бот соберёт рабочий код, если это всего навсего последовательные операции, то даже и лучше. А вот несколько парлелельных FSM, там становится слишком сложно и вариативно, хотя и это можно формализовать.
Странно, что никто не подумал о другом, о тестировании кода, это же следующая итерация линта (AFL) или Formal для Jasper-а или даже отдельный продукт. Неважно, что за код это будет, но SVA будет соответствовать описанию на проект. Так что это скорее конец верификации, а не дизайну.
Эту задачу ставил не я. В некоторой дискуссии в фейсбуке человек мне доказывал, что ChatGPT может выдавать SystemVerilog и показал в качестве примера код выданный на запрос реализовать некий алгоритм работы со строками. Несинтезируемым кодом.
На мое возражение, что этот код не определяет микроархитектуру и его для создания схемы использовать нельзя (разве как часть высокоуровневой модели для тестирования) был ответ "это небольшие недочеты, которые скоро будут исправлены". Я спроецировал эту ситуацию и вот.
Насчет SVA - ну ChatGPT возможно и можно надрессировать на писание простых SVA, типа "напиши concurrent assertion что valid после перехода от 0 к 1 должен стоять 1 пока не случится valid=1 & ready=1 на положительном фронте тактового сигнала". Но это небольшая часть верифиации вообще-то, да и я сомневаюсь, что тренирующие студенты в Южной Америке и Восточной Европе надрессируют на нетривиальные concurrent assertions (я интервьирую кучу студентов, то бишь я знаю)
Не нужен нетривиальный concurent assertion, когда тул позволит сделать 100 immediate assertion. Мне видится в этом куча возможностей, в принципе, AFL сейчас так и работает.
То есть тул на основе текста микроархитектурной спецификации будет анализировать код и расставлять assertions? Это звучит как хотелка, а не нечто что реально доступно в текущих технологиях. То есть что-то расставлять он будет, но во многих местах будет тупо и бесить. Хотя это может быть деятельность для убивания энтузиазма интернов - дать им подчищать assertions, расставленные ChatGPT.
Именно так, пусть тупо, но лучше чем ничего.
Как дизайнеру, это вполне достаточно. Иногда невозможно полностью покрыть тестами, и если будет "нечто", что позволит увеличить покрытие, ещё и при этом автоматически, то профессия тестировщика видится уже совсем по другому.
Менеджер, который "пишет код" с помощью ChatGPT - это уже не менеджер. Скорее это разработчик, который пишет код с помщью stack overflow или google. Куда веселее было, если бы код так и синтезировался, ушел в чип, и через год аукнулся критической ошибкой и полным редизайном.
А ведь заголовок не подвел. Ожидаемо неожиданно
Ещё более жуткий сценарий. Менеджер, сам являющийся нейросетью ChatGPT, присылает вам сгенерированную им же программу, чтоб вы её отладили.
Департамент, сам являющийся учредителем и состоящий из ста человек, присылает вам сгенерированное им же задание, чтобы вы его исполнили в будущем году. В начале года департамент задаёт исходные условия для выполнения. (Условия = сроки, штатное расписание, оплата.) В конце года департамент меняет эти условия, то есть задачи, выполненные в прошлом году, надо было исполнять при других условиях.
_pyramid_(structure)_on_January,_1st,_2022.png){kind=link}
Глубоко не всматривался, но сразу бросилось в газа - красивые, строго структурированные строки.
Можно заменить строки вида
if [ -z "${var-}" ]
then
export var="..."
else
export var="$var:..."
fiна следующую
export var="${var+$var:}..."А не выругается в комбинации с таким?
set -u # Causes the bash shell to treat unset variables as an error and exit immediately.Нет. Не выругается и не завершится с ошибкой. Единственное, что я поправил бы в своем предыдущем ответе - переписать в виде ${var:+$var:} - выполнить подстановку, если переменная существует и не пустая строка (в отличие от первого варианта, который подразумевает только проверку на существование переменной).
Вы придумали ситуацию, от которой Вас "бомбануло"? Странная ситуация..
Да ну и черт с ним, уволит такой менеджер несколько сотрудников и начальство задаст ему вопросы и самого переведет на программу улучшения производительности.
Зачем решать административные проблемы техническим методом? ТЗ инженеру должен писать инженер
Читая срач о менеджерах в очередной раз убеждаюсь, что современное ИТ свернуло не туда. Концепция менеджера не разбирающегося в предметной области призвана защитить технарей от давления со стороны менеджмента. РМ, по определению, не имеет права вносить свои субъективные правки в оценку экспертов. И именно у "разбирающегося" РМ возникает этот соблазн.
Проблема в ИТ остро стала когда РМ превратился из отдельной специальности в часть карьерной лестницы, и РМами начали становится те кто именно "разбирается". Еще и на плечи РМа взвалили обязанности консультанта/аналитика.
Я успел еще поработать в нормальных условиях, где РМы действительно профессионалы своего дела. Где мою оценку задачи может оспорить только техлид но никак не РМ, и если РМ озвучил казачику оценку ниже чем дал я, то это будут его проблемы но никак не мои.
Побочная тема: как поживают автотрассировщики печатных плат и авторасстановщики компонентов (не установщики на этапе монтажа, а "размещатели" на плате перед трассировкой)?
Раньше надо было или вручную расстановку / разводку делать или после автомата переделывать, что по трудоёмкости сравнимо с ручной работой.
Максимум что застал, пока не ушёл из отрасли - интерактивная трассировка: контроль зазоров, длин трасс.
Может тут AI помочь?
Нужна специализированная нейросеть.
А так, помню, что писали про эволюционный алгоритм создающий непонятным образом работающие схемы, которые перестают работать, если человек пытается убрать из схемы, на его взгляд, "лишнее". (судя по всему, эти схемы используют на первый взгляд неочевидные человеку наводки)
Берешь этот код, c коментами и пишешь чатгпт:
"Этот код не синтезируемый, напиши пожалуйста такой, же но синтезируемый <>"
Если начинает опять инструкции не те слать , так ей и написать - код несинтезируем, потому что
да нечто подобное происходит и без ChatGPT. Приходит CTO и говорит - я тут новую суперфичу налабал на выходных, оформи, интегрируй в мастер, погоняй и в продакшн запустим. И вот вылизывание поделки выходного дня до уровня продакшена, решение неочевидных проблем, совместимость между браузерами (фича-то новая экспериментальная и везде работает по-разному) заняло почти год.
Разное было, это не один раз случалось. Ну например совместный браузинг - когда ты видишь что на том конце делает в браузере другой человек. Можешь помочь ему - что-то подсветить, что-то заполнить за него или только наблюдать за тем что он делает, причем только за тем что разрешено (номер кредитки не подсмотришь). Можно записывать а ля видео, сохранить, проиграть действия.
Вот жуткий сценарий.
Пока еще не случилось, но очень вероятно что будет (по аналогии
нахождения взаимодействия между писателям вирусов и спамерами)
Используя ИИ генерировать скрипты для выманивания данных сберкарт.
Использовать ИИ для обработки профилей из соцсетей + слитые базы для определения целевой аудитории, на кого воздействовать этими скриптами.
Генерация алгоритмов мошенничества (запросы:как заработать миллион. Вроде уже сообщения об этом попадались).
Очень вероятно, что мы на пороге этих событий, если они уже не свершились, на мой взгляд.
После обсмотрения всякой «чешуи» (в прямом и переносном смыле), которую генерят нейронки для художественных целей, я стал спокоен за UI-дизайнерскую работу. Между тем, что получается в качестве картинки даже с простынёй уточняющих параметров и тем, что делают дизайнеры интерфейсов, например, макеты и прототипы, есть принципиальная разница. Такая же, как между словами «красиво» и «работает».
На рендер.ру 5 лет отмерили, тут 3 года :)
А есть и 3 месяца.
(ссылка может вызвать чувства, и на первый взгляд она вообще не по теме)
Жуткий сценарий - это когда менеджер вообще лезет в написание кода.
Имхо, страшнее будет тогда, когда он напишет синтезируемый код, который будет работать и делать то, что указано в задании, но так, что человек не сможет в этом разобраться (за разумное время). Машины, которые создают машины. Практически зонд фон Неймана.
Но это же суть человека -- разбираться.
В скобках - уточнение условий. А ведь ещё может быть так, что объясняющих гипотез - десять в какой-нибудь там ..нцатой степени, и проверить их все нереально даже на квантовом компьютере (если бы у нас такой был). А-ля проблема теории струн.
В итоге: есть нечто, что вроде бы работает, но никто не знает - как оно это делает. А "автор" не может объяснить, потому что он машина.
К вопросу: должен ли менеджер быть спецом в прикладной (по теме проекта) области? Тут говорят, что «да», но PMBOK говорит, что нет. Пояснения:
Слишком общие языки - зло. Нужен отдельный синтезируемый язык и отдельный язык для тестирования или api для встраивания его в обычные языки. Надеюсь ИИ это поймет, и реализует такой подход, когда избавится от людей.
По моему проблема не в ChatGPT, а в менеджменте.
Здесь ключевая проблема, в общем-то, менеджеры, и она стара как мир, вокруг нее вертится все. Вечное желание сэкономить и получить премию при зачастую полном отсутствии знаний в области, куда лезут с правками. Сначала делают, а проблемы разгребают совсем другие люди, причем ручками, ручками. А проблем эти олени уже не раз таким о.разом доставляли. И описываемый пример - цветочки. Более яркие - авария на ЧАЭС, Бхопал... Но пример действительно жуткий, прям страшно стало, что будет, когда эти олени во многих отраслях массово возьмутся внедрять подобную инновацию. И ведь могут. Дураков полно.
А Вам не страшно, что олени рано или поздно внедрят это дело и в чьи-нибудь РВСН, и не будет на них Дэвида Лайтмена? Там уже не цветочки, а грибочки...
Жуткий сценарий использования ChatGPT