Вот что заметил. Вроде GPT появился, а работы особо меньше не стало и скорость разработки не особо повысилась. Не, ну может процентов на 20 повысилась, но не в десятки раз, как то ожидалось.
И вроде что не спроси — все же этот GPT знает. Но чего то в нем нет и толком не могу понять чего именно, что мешает делать проекты. И здается что оно и не появится, по этому нужно понять что это такое, назвать его и развиваться в этом направлении.
И вот в чем фишка же. В основном сборка проекта — это архитектура, сборка из готовых блоков. Редко когда приходится опускаться на уровень создания блока, как то написание своего парсера markdown
И возможно что я понял что же это — оно выражается одним емким словом — онтология.
Причем, что интересно, даже если вы опустились на уровень ниже и делаете свой парсер markdown — все-равно нужно понимать глубинную суть вещей, варианты форматов, видеть коллизии и т.д.
Здравствуйте, Shmj, Вы писали:
S>Причем, что интересно, даже если вы опустились на уровень ниже и делаете свой парсер markdown — все-равно нужно понимать глубинную суть вещей, варианты форматов, видеть коллизии и т.д. S>Кто что скажет по этому вопросу?
Ну я обычно занимаюсь эсхатологией и герменевтикой парапрограммных объектов.
Чтобы дойти до онтологии — это редчайший яркий момент, ради которых вообще имеет смысл заниматься обычной нудятиной.
The God is real, unless declared integer.
Re[2]: В чем непреходящая суть профессии разработчика ПО?
Здравствуйте, netch80, Вы писали:
N>Ну я обычно занимаюсь эсхатологией и герменевтикой парапрограммных объектов. N>Чтобы дойти до онтологии — это редчайший яркий момент, ради которых вообще имеет смысл заниматься обычной нудятиной.
Многие вещи нам кажется очевидными, но они не есть таковые.
К примеру — адрес. Адрес это строка или объект? Бывает и так и так. Если объект — то какая структура, какие поля? Далее — если вам нужно некой гео-позиции сопоставить адрес — это должен быть список объектов, один объект или строка? Может быть и так и так и эдак — все зависит от назначения.
Вот это назначение, смысл — это и есть онтология.
Начинается все с понимания реальности и понимания что вообще имеет смысл делать а что будет пустой тратой времени. Сделать абы что — не проблема. Важно чтобы оно обрело нужность — а вот это уже большая большая проблема. Можно потратить много лет, вложить много сил и ресурсов — а оно нужным не будет Нужность — это первичный онтологический вопрос, на который нет простого ответа.
И уже эта нужность идет тонкой ниточкой на всех этапах. Разработчик как бы воплощается в шкуру пользователя, пытается понять его глазами — как он хочет видеть адрес и как ему будет удобно — списком, объектом или строкой. Больше — не значит лучше.
=сначала спроси у GPT=
Re[2]: В чем непреходящая суть профессии разработчика ПО?
Здравствуйте, Pzz, Вы писали:
Pzz>Кто умеет работать, работает. Кто не умеет работать, учит. Кто не умеет учить, командует.
Сам использовал эту поговорку. Но здесь нужно понимать, что это насмешка. Хорошо учить и хорошо руководить ещё сложнее, чем просто работать.
Тот кто действительно умеет учить развит гораздо выше обычного работающего, так как может не только работать, но и передавать знания в особой форме и содержании.
А руководитель, который может заменить любого работающего явно эффективнее в руководстве, чем просто работающие и в особенности тех, кто ничего не понимает.
Re[3]: В чем непреходящая суть профессии разработчика ПО?
Здравствуйте, velkin, Вы писали:
V>Сам использовал эту поговорку. Но здесь нужно понимать, что это насмешка. Хорошо учить и хорошо руководить ещё сложнее, чем просто работать.
Это одна из тех насмешек, которые крайне близки к реальности.
V>Тот кто действительно умеет учить развит гораздо выше обычного работающего, так как может не только работать, но и передавать знания в особой форме и содержании.
Только вот лично я видел крайне мало тех, кто учит, и кто мог бы делать реальный проект. И Лаптева я не считаю, я хз, как он учит, и какие реальные проекты он делает. Он тот ещё профессор.
V>А руководитель, который может заменить любого работающего явно эффективнее в руководстве, чем просто работающие и в особенности тех, кто ничего не понимает.
Видел одного электронщика, который основал свою контору (совместно с ещё одним электронщиком и несколькими конструкторами), а сейчас там гендирит и неплохо ищет заказы, и, в принципе, он электронщиком был не плохим, и сейчас думаю в случае проблем легко сможет найти проблему на плате, и даже немного представляет, как работает микроконтроллер со стороны программиста. Но это исключение из правила, я один раз такое видел. Подавляющее большинство руководства ни бельмеса не понимает в разработке вообще и в разработке ПО в частности — они мыслят тупо погонными метрами и килограммами продукции; те, кто когда-то был разработчиком, но быстро выплыл в руководители — они тоже заменить никого из разработчиков не могут, но такие хотя бы немного ближе к пониманию проблематики.
А вот тебе пример из моей недавней практики. Делаем устройство. Пока есть один опытный образец, в нем четыре идентичных блока, соответственно — четыре платы. Развели первую ревизию, дали мне её немного потрогать, потом забрали: "надо вставлять в изделие". А ничего, что изделие без моей прошивки — это груда металлолома? А мне для работы нужна плата на стенде у меня рядом, а не в цеху, где стойка с блоками. Окей. Доперло, что плата сырая получилась, кое-что добавили, сделали вторую ревизию. Соответственно, мне старые платы отдали. Алилуйя, блин. Правда, на старой ревизии пришлось радикально обколхоживать её, и всё равно она далеко не идентична тому, что стоит на железе, и из-за этого периодически вылезают косяки. Я же просил что первую ревизию сделать мне доп плату, что вторую. Хрен. Ипись как хочешь с тем что есть. Каждый раз была одна и та же отговорка: "ну мы вот по результатам эксплуатации сделаем выводы и запилим новую ревизию, зачем нам тратить деньги на доп платы, если они пойдут потом на выброс?". Причем, если один из руководства гуманитарий какой-то — просто ген дир направления, то второй — ген конструктор изделия, и вроде как электронщик, сам даже одну плату для устройства разводил (впрочем, там ничего сложного, разве только то, что она силовая на много ампер, в остальном тупая железка с ключами и радиатором). Моя плата — ничего особенного, ей полтос трублей — очень красная цена, со всеми компонентами. Можно было сделать, и сэкономить пару-тройку месяцев моего труда (если что, я стою гораздо больше полтоса в месяц). Вот такое вот руководство. И это ещё у нас контора весьма успешная и бурно развивающаяся.
Здравствуйте, Marty, Вы писали:
M>Только вот лично я видел крайне мало тех, кто учит, и кто мог бы делать реальный проект.
В этом и суть моего выссказывания. Есть разница между плохо работать и хорошо работать. Так же есть разница между плохо учить и хорошо учить. Тоже самое касается руководства.
Может ли человек не умеющий работать научить работать? Как по мне научить работать может мало кто даже из тех, кто умеет работать.
И с руководством по сути тоже самое. Вопрос в том кого считать руководителем. А что если заменить руководителя на случайного человека с улицы?
Потому насмешка насмешкой, но эффективности такой сценарий, про не умеешь работать учи или даже руководи, не добавляет.
Это лишь говорит, что к обучению и руководству относятся ещё более безответственно чем к работе.
А потом остаётся статистика, где лишь 6% заканчивают обучение на програмистов, это 94% брака. Или 90% стартапов проваливаются.
Re: В чем непреходящая суть профессии разработчика ПО?
Здравствуйте, Shmj, Вы писали:
S>И вроде что не спроси — все же этот GPT знает.
Я тут на днях тоже решил прикоснуться к достижениям научной мысли и задал вопрос чатгпт.
Документацию было лень читать, вон роботы все уже и так прочитали, пусть отвечает, думаю.
Ну и хреново оказывается они ее читают, пришлось самому.
Вопрос был про минимальный размер изображения для указателя мыши в винде.
Чатгпт на него ответа не знает.
Сгенерить вызов CreateCursor() хоть как-то внятно оно тоже не смогло. Про xor- и and-маски для монохромного курсора тоже представления не имеет. Ну и как ему тут что-то более серьезное доверять?
Re[2]: В чем непреходящая суть профессии разработчика ПО?
Здравствуйте, Shmj, Вы писали:
N>>Ну я обычно занимаюсь эсхатологией и герменевтикой парапрограммных объектов. N>>Чтобы дойти до онтологии — это редчайший яркий момент, ради которых вообще имеет смысл заниматься обычной нудятиной.
S>Многие вещи нам кажется очевидными, но они не есть таковые.
S>К примеру — адрес. Адрес это строка или объект? Бывает и так и так. Если объект — то какая структура, какие поля? Далее — если вам нужно некой гео-позиции сопоставить адрес — это должен быть список объектов, один объект или строка? Может быть и так и так и эдак — все зависит от назначения.
S>Вот это назначение, смысл — это и есть онтология.
Да я-то полностью согласен. Но я говорю о том, что до этой "непреходящей сути" ещё терриконы, горы и просто кучи всякого хлама и шлама, который достаёт, но без которого не получится.
S>Начинается все с понимания реальности и понимания что вообще имеет смысл делать а что будет пустой тратой времени. Сделать абы что — не проблема. Важно чтобы оно обрело нужность — а вот это уже большая большая проблема. Можно потратить много лет, вложить много сил и ресурсов — а оно нужным не будет Нужность — это первичный онтологический вопрос, на который нет простого ответа.
И тут согласен. Но это уже скатываемся в кэпство ни о чём. Скрывать под наклейкой "онтология" сильно разные вещи — как минимум, что нужно и как это сделать — это неполезно.
The God is real, unless declared integer.
Re: В чем непреходящая суть профессии разработчика ПО?
Здравствуйте, Shmj, Вы писали:
S>Кто что скажет по этому вопросу?
Послушай Альтмана, он же давал совет — сократи ожидания в 100 раз.
Нафантазировали тут нешарящие ребятки, думаете выдавать текстовую статистику — уже интеллект.
Первое. Проблема "ИИ" — статистическая достоверность.
Ты, кожаный мешок, можешь разделить свои знания "вот это 100% достоверно", а "тут есть варианты". И ты можешь строить сколь угодно сложную логическую конструкцию — алгоритм, раздел математики, и будешь уверен — тут 100% достоверность.
"ИИ" современный, просто выдает результат с достоверностью, ну пусть 90%. В реальности LLM — хорошо если 70%. Когда ты с помощью "ИИ" проектируешь на 10 ходов в перед, в результате ты получаешь белый шум.
Второе. Почему "ИИ" не используется? Используется. Только первые результаты такие — использование LLM повышает трудозатраты людей. Проверять за ИИ то еще удовольствие, ты не знаешь в каком конкретно моменте он нафантазировал. А фантазирует он очень правдоподобно и врет очень уверенно. Это тоже кстати косяк, врет и не краснеет.
И, забыл добавить. Около половины сотрудников, которые в течение года использовали ИИ произошло профессиональное и эмоциональное выгорание. Люди просто охренивают разбирать этот ИИ бредоконтент. Генерирует он быстро, а перерабатывать это очень не просто. Люди чувствует себя чернорабочими.
PS Я не говорю, что это бесперспективно. Конечно эта технология уже пошла в массы — даже я делаю пару интересных проектов.
Но быстрых фантастических результатов не ждите.
PPS Проблему достоверности решают, и здесь будут результаты. Во-первых достоверность будет оцениваться ансамблем нейросетей, обучаемых с подкреплением. При этом нейросети, дающие недостоверный результат должны будут терять право голоса и удаляться/заменяться. Первый AGI подобный продукт будет работать как хор из тысяч нейросетей. Я думаю, до этого еще лет 20 нам.
Через 20 лет я ожидаю уже полноценного "ИИ математика", "ИИ инженера конструктора", "ИИ проектировщика производств".
Нужность — это первичный онтологический вопрос, на который нет простого ответа.
