Комментарии 272
За последние 60 лет разработка сделала огромный шаг вперед: усложнялось ПО, ускорялись темпы разработки, возникали новые потребности, но людей в ИТ индустрии становилось только больше. Нет оснований полагать, что новая революция в разработке ПО пройдет по другому сценарию.
Полностью согласен с выводом автора. В этом я убедился на собственном опыте, занимаясь разработкой программного обеспечения более чем 55 лет.
Когда появился SQL (1974), все думали, что программисты скоро будут не нужны, т.к. запросы сможет писать любая секретарша. Как много человек, кроме программистов, пишет на SQL в наше время?
Сдается мне, что-то подобное будет и с ИИ в области разработки. Задачи, которые ИИ решает, станут более сложными, и для того, чтобы их женить с реальностью, надо будет вникать в кучу деталей (уже каких-то новых, не обязательно похожих на те, что важны сейчас). И вот этим и будут заниматься разработчики. Просто разработка еще раз изменится, и все
Для современных программистов SQL - это слишком сложно, они так и норовят вместо того, чтобы его писать, воткнуть какой-нибудь ORM. :-)
ORM - это про удобство написания, отладки и т.д., а не про снижение сложности
Также ORM очень сильно снижает время на разработку, когда могут быть разные СУБД (я как-то участвовал в проекте, где у одних клиентов был MSSQL, у других Oracle).
Ну а ваш комментарий выглядит как "нахер тракторы, деды коней в плуг запрягали".
ORM - это про удобство написания, отладки и т.д.,
На одном ЯП, где в целом не принято пользоваться ОРМками, есть в экосистеме одна ОРМка которая позиционирует себя как супер легковесная и вообще идиоматичная со всех сторон.
Решил я ею начать пользоваться в одном проекте. У этой ОРМ заявлен список полезных фич, начал их постепенно внедрять.
Внедрил фичу 1: увидел что как-то она хреново работает. Ну ладно, буду пользоваться остальными фичами, а этой не буду.
Внедрил фичу 2: увидел что она под капотом неявно может творить лютую дичь, и это может навернуть всю СУБД на проде если данных в таблице много. Ну ладно, от фичи 2 отказался, буду пользовать в этой ОРМ все кроме фич 1 и 2.
...
Внедрил фичу N. Ой, ну ее нах. - подумал я, и в итоге от ОРМ остался только query builder.
---
И такой путь мне довелось пройти в экосистеме более чем одного ЯП. Выбирал самые топовые ORM и спотыкался немножко.
Понятное дело, ОРМ - не серебряная пуля.
Но если БД изначально спроектирована хорошо, то скорей всего не придется писать 7этажных замысловатых запросов и тут ОРМ справится. Не идеально но хорошо.
Зато она даст возможность купить обезьянку-программиста подешевле, и легче его заменить на другого. А еще, если ею правильно пользоваться, то позволит относительно просто перескочить на другую СУБД, потому что настало импортозамещение...
Ну а если вам нужно выжать максимальную производительность из кривой косой легаси БД, где на протяжении десятилетий десятки команд городили кто во что горазд, то да скорей всего придется писать запросы вручную.
Эх, я бы с вами даже согласился, если б своими глазами не насмотрелся того что вытворяет ОРМ )
Прикол как раз в том, что как задумка ORM просто прекрасная вещь. Но вот, вероятно, ввиду чрезмерной универсальности, а также самонадеянности разработчиков таких систем, конкретные реализации на текущий момент оставляют желать лучшего. В любой момент, когда наступает ситуация, отличная от простого ненагруженного круда, или когда в таблице больше 5 строчек, ты уже не можешь быть уверен в том, что ОРМ все сделает правильно и оптимально.
А что касается перескакивания с одной СУБД на другую - тут при адекватном проектировании (ну или систем-дизайн, ну или архитектура, как хотите) и без ОРМ все хорошо получается.
Мне довелось заниматься проектом, где не просто однажды понадобилось импортозаместиться, а нужна была одновременная поддержка двух разных способов хранения одних и тех же данных в течение всей жизни продукта (потому что сам продукт выпускался в двух разных форматах/способах запуска). Ничего, и без ORM при должном проектировании системы, все проходило отлично.
Прикол как раз в том, что как задумка ORM просто прекрасная вещь
Нет, ORM это (само)обман:
https://en.wikipedia.org/wiki/Object–relational_impedance_mismatch
Фактически, полноценный движок ORM вынуждает вас на одном языке описать другой язык (SQL, например). Но зачем вам это, если это можно запросы писать прямо на SQL?
Тоже верно
Нет. ORM ценен для производителей ПО тем, что снижает требования к квалификации программиста для работы с БД, что позволяет на программистах сэкономить.
SQL - это не просто другой язык. SQL воплощает в себе совсем другую парадигму - декларативное программирование: программист описывает не то, как он хочет достичь результата, а сам результат. А массово используемые для других частей приложения языки - от Java до JavaScript - в основном, работают в прадигме императивного программирования: они описывают последовательность шагов для достижения результата. Парадигмы эти - существенно разные, и специалист, умеющий хорошо работать в обеих, стоит дороже.
А потому бизнес любит ORM как абстракцию над декларативным SQL, годную для работы чисто на императивных языках программистов с чисто императивным мышлнием. Другое дело, что любая абстракция имеет дыры, то есть, не полна (и это, если чо - одна из возможных формулировок Первого закона диалектики), и в эти дыры начинает проглядывать нижележащий слой. А потому, начиная с некоторого уровня сложности, приходится на практике временами работать и на уровне СУБД и писать запросы к ней на SQL. Но вот большая часть большинства приложений до этого уровня сложности счастливо не доходит, а потому с ORM эта часть оказывается проще и писать ее можно посадить макак, что нравится бизнесу.
Нет. ORM ценен для производителей ПО тем, что снижает требования к квалификации программиста для работы с БД, что позволяет на программистах сэкономить.
Мой камент был как раз о том что это иллюзия, самообман. Выражать на одном языке парадигмы другого языка это не проще чем писать свой компилятор/интерпретатор
Но вот большая часть большинства приложений до этого уровня сложности счастливо не доходит, а потому с ORM эта часть оказывается проще
В этом случае достаточно "генератора SQL-кода" (чтобы с типами не путаться и так далее)
Мой камент был как раз о том что это иллюзия, самообман.
Наличие спроса на продукты класса ORM показывает, что это - не иллюзия.
В этом случае достаточно "генератора SQL-кода" (чтобы с типами не путаться и так далее)
А что вы будете делать, если схему данных, обрабатываемых приложением, надо поправить? Будете заново генерить SQL-код своим генератором? И что собираетесь делать с имеющейся БД? Ведь по меняется, скорее всего, не только DML, но и DDL. Значит, чтобы данные не пропали - заодно придется делать и генератор процедуры переноса данных. Вам не кажется, что вы реально хотите изобрести свой ORM?
Наличие спроса на продукты класса ORM показывает, что это - не иллюзия.
Спрос в данном случае это не аргумент
ИТ-индустрия регулярно болеет заблуждениями типа: "всё - это объект" или "SQL позволит секретаршам и бухгалтерам пользоваться компьютером"
Второй аргумент я вообще не понял - живу в каком-то совсем другом мире
ИТ-индустрия регулярно болеет заблуждениями
Для заблужений она как-то слишком долго болеет. Наверное, причина не в одних заблуждениях, а в том, что это деньги приносиn?
Второй аргумент я вообще не понял - живу в каком-то совсем другом мире
А что непонятного-то? В вашем мире однажды написанные программы не меняются, что ли, И схемы БД (DDL) - тоже?
А если меняются, то нельзя просто один раз взять и сгенерить SQL каким-то простым генератором. Потребуется полноценный ORM.
Вы с 1С знакомы? Конструктор запросов их ОРМ или нет? с одной стороны - там конечно не скуль и есть привязка к типам объектов. С другой - озвученной вашим оппонентом проблемы "Выражать на одном языке парадигмы другого языка это не проще чем писать свой компилятор/интерпретатор" - нет. Так как парадигма там как раз SQLная, только с учетом типов 1С.
С 1С знаком почти никак. Но, насколько я знаю, это - не язык общего назначения, а весьма предметно-ориентированная платформа со своим предметно-ориентированным языком. Тогда как ORM делается как раз для языков общего назначения, сконструированных в парадигме ООП.
Вы с 1С знакомы? Конструктор запросов их ОРМ или нет?
Сама 1С это гипертрофированная ОРМ..язык запросов это уже инструмент написания запросов именно к ОРМ...(ну типа как HQL для Hibernate)
Язык запросов 1с транслируется напрямую в sql. И ь схож по конструкциям (виртуальные таблицы - превращаются в подзапросы, rls - тоже)
Язык запросов 1с транслируется напрямую в sql
ну так HQL и вообще работа с ORM транслируется напрямую в SQL
он схож по конструкции да, но не является им напрямую
сама 1С это ОРМ-ка, там же виртуальные объекты под капотом которых десятки таблиц, связей, индексов и т.п.
вы не можете напрямую оттранслировать условный "выбрать справочник.персонал.табличная часть.фио .... " в select name from employees.. тем десяток джойнов под капотом прицепится...и это делает ОРМка..коей и является 1С так то..
Кажется, вы не понимаете, что такое ORM. Язык запросов 1с ORM не является.
Да и всякие СправочникОбъект с натяжкой.
вы не можете напрямую оттранслировать условный "выбрать справочник.персонал.табличная часть.фио .... " в select name from employees.. тем десяток джойнов под капотом прицепится...
Вообще смогу. правила тех самых джоинов и подзапросов жестко определены.
. Язык запросов 1с ORM не является.
ОРМ это сама 1С... конечно это очень громко, 1С это скорее СУБД но очень сильно отделенная от непосредственно самой БД
если взять какуюнить Oracle DB ... там есть и Oracle Forms - для написания UI, и язык PL/SQL - диалект SQL-я ...но там БД - это основа
А у 1С основа - это виртуальная псевдо объектная сущность из справочников-документов-регистров... т.е. это и есть ORM .. и язык запросов - это язык запросов к этой ORM, а не к БД на которой 1С работает
Я задал вопрос собственно из утверждения
ORM ценен для производителей ПО тем, что снижает требования к квалификации программиста для работы с БД, что позволяет на программистах сэкономить.
и потому мол ОРМ безальтернативен. Насколько я понимаю ОРМ в 1С - это объектная модель. Которая обязательна для половины объектов для записи и считается устаревшей для чтения.
А вот язык запросов формально конечно не ОРМ, но как раз снижает требования к квалификации, да и вообще к построению запросов. То есть как раз возможный альтернативный путь получения профита.
и потому мол ОРМ безальтернативен.
Я такого не писал, так что, комментировать дальше вы, конечно, можете, но я в этом не участвую.
А 1С, по моему пониманию, это платформа для разработки определенной предметной области, соответственно, ее язык - это язык предметной области (DSL). Я вообще про эти специфичекие вещи не говорил и не собирался.
"SQL позволит секретаршам и бухгалтерам пользоваться компьютером"
вы удивитесь, но SQL используют менеджеры, экономисты и люди которые работают с анализом большого количеством разнокалиберных данных...и при этом очень далекие от ИТ
так что ДА SQL позволяет бухгалтерам и "секретарям" пользоваться компьютером.
Аналитики у нас писали SQL, которые не знают ни одного ЯП. А когда работал в банке, у нас даже некоторые бухгалтера просили доступ к консоли SQL и писали запросы. Сейчас на работе продакты иногда пользуются
Для современных программистов SQL - это слишком сложно
Оно не то чтобы сложно, оно просто избыточно и вообще является не тем, что в большинстве случаев нужно программисту. SQL это язык программирования, пусть и специализированный. Но программист и так уже пишет программу на языке программирования и само собой, не на SQL, потому что помимо запросов к БД в программе должно быть ещё куча всего. Ну и зачем ему язык программирования внутри языка программирования (yo_dawg.jpg)? Для программы на условном JavaScript, код на SQL - это просто строка. Зачем это программисту? Ну давайте в код на JavaScript ещё воткнём код на Python в виде строки и будем его каким-нибудь eval'ом выполнять. Или, зачем далеко ходить, можно часть кода на том же JavaScript хранить в строке и выполнять eval'ом. Это прям вообще "best practice", за такой код сразу сеньёра дают. Ну а если серьёзно, то чем вот эти вот строчки SQL в программе лучше любого другого кода, хранимого в строке и выполняемого eval'ом? Да ничем не лучше. Потому и используется либо ORM, либо хотя бы построитель запросов. Но на практике, разница только в объёме дополнительного функционала, а основная идея одинаковая - с самим SQL мы не работаем, а работаем с сущностями на нашем основном языке программирования. SQL предназначен либо для тех, кто напрямую базе запросы шлёт, например из консоли, либо тем кто пишет хранимые процедуры, т.к. они хоть и пишутся не на чистом SQL, но SQL является подмножеством того языка, на котором написана процедура, и там запрос это не просто строка, а полноценная часть кода.
Оно не то чтобы сложно, оно просто избыточно и вообще является не тем, что в большинстве случаев нужно программисту.
Программисту нужно делать так чтоб не навернуть БД на проде, когда ОРМ любезно начинает творить дичь.
либо хотя бы построитель запросов
кхм, чтобы использовать построитель запросов, надо как минимум знать язык этих самых запросов. То есть надо знать SQL
Зачем это программисту?
затем, чтобы контролировать что происходит ваще
У Вас в логике целая кучка ошибок:
Для абсолютного большинства приложений сложнее hello world является нормой использование нескольких языков программирования: парочка основных (для фронта/мобайла/бэка), шелл для скриптов, плюс разные DSL (к которым относится и SQL, кстати) вроде форматов Makefile, Dockerfile, yaml-конфигов сервиса оркестрации деплоя и т.п. SQL тут ничем особенным не выделяется, он рядовой элемент в этом списке используемых языков. Откуда вообще взялась концепция, что для разработки приложений (т.е. работы программистом) достаточно выучить/использовать только один ЯП - я не знаю, возможно с курсов "войтивайти", но она точно ложная.
Код на любом ЯП - просто строка. Но этот факт не имеет вообще никакого отношения к eval.
Нет, разница при использовании ORM/QueryBuilder по сравнению с SQL не только в "в объёме дополнительного функционала":
ORM вообще полностью изменяет концепцию того, что из себя представляет хранилище данных и занимается преобразованием из реальной в собственную, с соответствующей потерей производительности как минимум, а как максимум иногда творя лютую дичь в реальном хранилище (уже упомянутую комментаторами выше).
QueryBuilder это по сути просто альтернативный способ сформировать ту самую строку SQL. Ключевой момент тут в том, что, в отличие от ORM, концепцию хранилища он никак не меняет, и при его использовании нужно всё-равно знать SQL чтобы понимать что ты делаешь. Те "программисты", которые API QueryBuilder-а воспринимают как полноценный альтернативный способ выполнения запросов в БД не требующий понимания SQL (ну т.е. как аналог ORM) - просто капитально заблуждаются. Более адекватная аналогия для QueryBuilder это оператор конкатенации строк, который позволяет собрать строку SQL из нескольких подстрок, и использование этого подхода очевидно требует ровно такого же понимания SQL, как и для записи всего SQL-запроса ручками в одной строке.
Как много человек, кроме программистов, пишет на SQL в наше время?
как ни странно, но довольно много менеджеров, есть даже софт у которых основной интерфейс - это SQL консоль, встречается в банковской сфере и вообще где большие объемы данных...например отчеты о продажах, анализы всяких рынков, акций и т.п.
Как много человек, кроме программистов, пишет на SQL в наше время?
В банках, скажем, почти все в бэк-офисе. Курс по SQL есть во всех уважающих себя экономических университетах. Он очень односторонний обычно, могут просто не давать никакой инфы про создание и администрирование БД, только запросы select.
опенсорс семимильными шагами пожирает пропиетарщину
Чёт в голос. Это тот самый опенсорс у которого разработчики практически всех проектов с более чем 10к пользователей сидят на зарплате в очередном редхате или МС?
Через 10-15 лет LLM вполне сможет...
А, ну всё понятно, P(token|context) похоронит нас всех, так же как нас похоронили экспертные системы. Ваше любимое хобби - экстраполяция?
если всё больше и больше библиотек уже написаны и под горизонтальное масштабирование допилены
Пишу на PHP, про другие языки не знаю и, поэтому, говорить не буду.
В контексте используемого мной языка абсолютно согласен с озвученной позицией - на github есть просто всё, что нам нужно для работы. Очень за редким исключением приходится форкать и допиливать, но 99% работы за нас уже сделали люди с разных концов планеты. Бери и собирай это всё через composer и пиши тривиальную клиентскую логику, оперируя лишь интерфейсами. Ну вот просто не было ещё такого, что бы что-то не найти.
В итоге то, что программист лет 15 назад писал бы минимум полгода, сегодня внедряется за 1 минуту и исправно работает из коробки. Есть решения, которые уже работают так же надежно, как автомат калашникова - там приложили усилия сотни контрибьютеров.
Уже доходит до того, что ты берешь код двух разных библиотек и понимаешь, что они очень похожи, ибо общая грамотность по технологии достигла того предела, что люди пишут почти идентичные решения.
"либы писать" с прочим матаном будет задачей для избранных
С матаном - может быть, а вот либы с рядовыми задачами пишут вполне обычные люди, а не профессора. И этих либ с каждым днём всё больше.
Другими словами, если оптимистично:
Будут разработчики ИИ и no code систем. Программисты.
Будут внедренцы. Кто с помощью ИИ будет создавать и обслуживать бизнес процессы. Тоже типа программисты.
И все это даст прирост в эффективности ИТ отрасли.
Вот так ИИ будет вполне полезен человечеству.
Про "опенсорс, пожирающий проприетарщину" - очень смешно. Почему-то в итоге компании покупают этот самый "опенсорс" с поддержкой за кучу денег у какого-нибудь Редхата за бугром или Астры в РФ, потому что держать толпу своих спецов, собирающих очередной билд "бесплатного" чего-нибудь в разы дороже.
Как думаете, многие ли программисты сейчас знают такие понятия, как поиск пузырьком?
Сортировка. Сортировка пузырьком.
Конечно! Видите, так давно не пользовалась этим термином, что допустила ошибку))
Раньше ее в школе изучали на информатике, в 9 классе, наряду со схемой Горнера. Разве сейчас не так? Любой программист школьник-старшеклассник должен знать такую базу историческую. Странные в тексте примеры.
Да так и есть, просто автор невывез
Но мы же знаем, что и такая дичь бывает:
Разбираясь в появившемся год назад проприетарном коде Qualcomm Technologies для Android, он обнаружил, что неизвестный программист решил в production-коде использовать сортировку пузырьком для того, чтобы найти максимум в массиве.
https://habr.com/ru/articles/333782/
Надеюсь, что в Гринатоме, конечно же, таких специалистов нет.
Раньше не во всех школах была информатика, к сожалению.
еще лет 15 назад, в различных системах сортировку приходилось реализовывать самостоятельно
Это в каких таких системах? Программирую с 2004, что-то ни разу не приходилось сортировку реализовывать. Может не 15, а 30 или больше.
Когда с округлением разобрались, то надо было разобраться с механизмом сортировки списка членов кассы. Ничего другого кроме сортировки методом слияния, имея в своем распоряжении 4К ОЗУ (оперативное запоминающее устройство), перфокарты и магнитные ленты, придумать было нельзя.
Это было в 1977 году!
Может помните ещё такие языки программирования как Pascal или ранние версии Delphi. Вот там точно приходилось самой реализовывать))
Паскаль помню и Дельфи тоже. Но реальное программирование у меня начиналось с python и php. Неужели в Дельфи не было сортировки?
Была, конечно. Но - для объектов (наследников TObject), а они размещались в динамической памяти (куче, по нынешнему). А если хотелось осортировать массив записей (record, аналог struct) свежеиспеченного типа, то надо было это делать самому.
У меня в те далекие годы где-то раз полгода возникала потребность один раз сделать отсортированный список из десятка-другого каких-нибудь записей, чтобы потом много раз искать по нему бинарным поиском. И каждый очередной раз я писал (точнее - копировал и правил) этот код (правда там были простые вставки, а не пузырек). И очень завидовал тем, кому было разрешено использовать C++: там под это дело уже тогда были template и STL, и я про это знал (но не не знал, что многим из плюсовиков суждено было быть покусанными Александреску, если бы знал - меня бы это утешило).
Да у всех на дискетке лежал какой-нибудь MyUtils.pas, где сортировка уже была написана.
Справедливости ради, с самого начала сортировка сразу была в Делфи в базовом классе TList - метод Sort, который использовал быструю сортировку элементов списка, вызывая функцию сравнения в этом же классе (или переопределенную в его потомках, например TStringList). Стандартных библиотечных сортировок обычного массива не было, потому что изначально в синтаксисе Делфи не было дженериков и пришлось бы авторам этой среды разработки делать функции для всех вариантов типов элементов массива. И, по моему мнению, они и не требовались, потому что Делфи изначально задумывалась и проектировалась как среда ускоренной разработки пользовательских приложений, а не для написания драйверов, микросервисов бэкэнда, движков баз данных и т.п. И упомянутый TList.Sort() решал задачу сортировки во всех списках элементов в компонентах библиотеки VCL, и любой свой список, созданный на основе TList, разработчик также мог отсортировать.
Приходилось в продуктовом коде потому что нет библиотечной функции или потому что писали лабу по теме "сортировка данных" и за вызов qsort() зачет не ставили?)
Потому что популярные алгоритмы сортировок известны, реализованы, отлажены и положены в библиотеки вот уже лет 50 как.
Я помню на плюсах собеседовался, меня попросили напсать стэк.
Ну я и написал #include <stack>
Но конечно же они хотели, чтобы я реализовал это руками. И я даже что-то там написал. Возмжоно оно не компилилось, но наборосок был в нужном направлении.
В итоге меня взяли. Я открыл их код и увидел, что они нигде не используют библиотечные функции, а все пишут руками. Код не выносится в функции, а просто копипастится. Я спросил, почему они не используют std, они сказал, что там якобы баги. А в их говнокоде конечно багов не было. В итоге я сказал, что не собираюсь с этим работать и ушел.
Это был мой препод, судя по всему. У него прямо лицо скашивало, когда я вместо того, что три часа рисовать модельку и посадочное микрухи брал готовые библиотеки, и когда вместо убогого ручного управления юартом на слипах просто взял готовую библиотеку. Он каждый раз говорил, что так делать нельзя, а вдруг там баги, как их чинить - и ведь правда думал, что он напишет менее забагованный код и понятный код, чем стандартная библиотека, которой уже больше 10 лет, которая покрыта тестами и имеет кучу звезд на гитхабе. А дальше так же как у вас - код копипастился, переменные односимвольные, комментариев нет, куча магических констант.
Не-не-не. В обучении - надо все самому сделать один раз. Чтобы понимать. Потом уже библиотеки не только можно, но и нужно использовать. Но в первый раз - самому.
Разумеется первые разы самому. Если сам не понимаешь - тут библиотеки не очень помогут. Это было уже сильно после того, как я это все делал сам - и такое было почти везде. Автотрассировщики, библиотеки компонентов и моделей, STD и еще куча всего - была под запретом, потому что сам препод, будучи практикующим разработчиком, их никогда не использовал.
Очевидно, что Ваш препод перегибал. Избегать вообще всех библиотек по абстрактным причинам - безумие. Тем не менее, одна из Go-шных "поговорок" от Роба Пайка: A little copying is better than a little dependency. Затаскивать в проект библиотеку на каждую мелочь просто потому, что её уже кто-то где-то реализовал - тоже идея очень так себе.
ух, какие воспоминания вы всколыхнули! ну кстати в университете 10-13 лет назад меня обучали именно этим двум языкам, специалистов по ООП и более сложным вещам не везде хватало.
Только что сказал дистриб Pascal7 и там в примерах есть файл QSORT.PAS где реализована сортировка QuckSort . Так что все там было.
Буд-то это невероятно сложный алгоритм в десятки строк кода.
for var i := High(Arr) downto Low(Arr) do
for var j := Low(Arr) to High(Arr) - 1 do
if Arr[j] > Arr[j + 1] then
begin
var Tmp := Arr[j];
Arr[j] := Arr[j + 1];
Arr[j + 1] := Tmp;
end;Но важнее, просто понимать принцип. Потому как уже давно сортировка есть и для массивов и для обобщенных списков.
Может помните ещё такие языки программирования как Pascal
Первый релиз Pascal вышел 54 года назад.
Если мы посмотрим чуть ближе, то во всех стандартных библиотеках sort есть с первого релиза. Например, .NET 1.1(2002, 22 года назад), JavaScript в виде стандарта ECMA-262 первой версии(1997, 27 лет назад), Java 1.2(1998, 26 лет назад). На самом деле, можно заглянуть и на пятьдесят лет назад. Так, qsort доступен в стандартной библиотеке C аж 1972-го года, т.е. более полувека назад.
Время писать сортировки руками давно прошло.
Но для собеседований знать как реализовать все равно обязаны. Может через 10000 лет понадобится, кто знает... /s
А мне приходилось и не раз, когда сортировка из либы работает не так как хочется на именно твоих данных.
Вы не поверите, но многие все еще программируют для систем с низкой производительностью и многое должны делать руками, а не готовыми библиотеками с миллионом зависимостей!
Я полагаю, что ИИ заменит программистов. Возможно программисты остануться, но работа их будет совершенно другой. Грубо говоря раньше в перфокартах дырки делали, а сейчас программируют на языках высокого уровня. Возможно программисты будут делать, то что сейчас делают аналитики - подготавливать текстовое описание для ИИ. А сгенеренный код мало кто сможет читать, примерно как сейчас мало кто понимает ассемблер.
Я сейчас склоняюсь в версии, что из современных профессий ничего не останется. Будут ли какие-то другие профессии не известно. На какую профессию не взгляни, есть потенциал вытеснения ее ИИ и роботизацией.
Сейчас мало кто понимает ассемблер потому что его понимать не надо, но он тем не менее очень лёгкий для освоения.
Сгенерированный LLM код понимать надо, потому что гарантий того что он правильно транслирует бизнес требования в код нет, в отличии от гарантий того что компилятор правильно транслирует условный С++ в ассемблер, которые есть.
Из этого следует фатальный недостаток современной кодогенерации - в проектах которые должны работать правильно она не уменьшает, а увеличивает когнитивную нагрузку на разработчика.
Не факт. Лет через 5 код понимать уже будет не нужно. Ты просто тестируешь сгенерированную программу и если она не соответствует требованиям или проявляются баги, то не лезешь в сам код, а просто говоришь LLM что у неё не так и она генерирует новый код. В который ты опять не лезешь, а просто проверяешь работу.
Мне кажется, вы просто не работали с критическими, высоконагруженными системами, при работе над которыми за такие итерации, и без гарантированного результата с вас голову снимут и обратно уже не прикрутят. Реальные системы не могут быть покрыты тестами на 100%, иначе вам для тестов потребуется ещё одна параллельная вселенная, где квантовый ИИ будет бесконечно гонять свои итерации.
Во многих областях требуется детерминизм и конечная ответственность, упёртая в юридический субъект, и если LLM таковым не станет, то лично моей работе ничего не угрожает. Болванчики-операторы же, который смогут только кивать на ИИ с невнятным бормотанием "не виноватая я, оно как-то само там унутре, где у ней неонка" не нужны уже сейчас.
Это то понятно и само собой будут критические и особые области, где итерационный подход неприемлем. Но много ли таких систем? Как бы сейчас тоже нужны разработчики на COBOL-е, но в мизерном количестве.
Критических систем может и не так уж много, но строгий детерминизм решений требуется как раз очень много где.
Я считаю, что LLM и прочая "мягкие" модели принятия решений будут формировать новые области, а не тотально замещать прежние. В прежних областях, требующих строгого детерминизма алгоритмов - они будут использоваться как ассистенты.
вы просто не работали с критическими, высоконагруженными системами, при работе над которыми за такие итерации, и без гарантированного результата с вас голову снимут и обратно уже не прикрутят.
"Если ты не работаешь над системой, то система работает над тобой!"
Болванчики-операторы же, который смогут только кивать на ИИ с невнятным бормотанием "не виноватая я, оно как-то само там унутре, где у ней неонка" не нужны уже сейчас.
Что собственно характерно, такая ситуация уже имела место быть: когда 12 лет назад (и ранее) я разрабатывал ERP и т.п. в энтерпрайзе, в том числе понимал внутренности бух.учета, то большая часть бухгалтерского состава предприятий вот именно так и говорила: чё вы меня спрашиваете, вона смотрите, так 1С посчитала - и это были ответы на наше многострочное логическое обоснование, почему именно суммы должны быть не такими, а другими. И вот тем не менее бованчики-операторы работали, назывались бухгалтерами по профессии... Тогда я понимал, ну что с них требовать - ответственности очень немного... и что все-таки есть пара адекватных специалистов у них, с которыми можно выйти к чистой воде, но вот позже, когда стал заниматься предпринимательской деятельностью и нанимал бухучет ООО на аутсорсе, то оказалось, что такие "операторы" и на фрилансе есть, называют себя "главными бухгалтерами", а ответы у них такие же. Только вот ответственности они не хотят никакой нести - это уж ваше, вы ж дирехтор...
кажется это стимулирует LLMку просто писать новый if на новые тестовые данные )))
Написание исчерпывающего набора тестов проверяющих все крайние случаи плюс быстродействие сложнее чем написание самого кода.
Есть довольно много областей где пофигу как работает код и если он время от времени падает, то ничего страшного. Всякие одноразовые скрипты, парсеры и т.п.
Обычная кодогенерация мне тоже не нравиться. Но тут дело другое, ИИ может не только генерировать код но и менять его по запросу.
Вы для начала машинистов в поездах замените хотя бы, там ровно две опции всего - ехать на указанной скорости и тормозить, один входной канал управления - зеленый/красный семафор. Но что-то пока не выходит.
один входной канал управления - зеленый/красный семафор.
Семафор и светофор вещи все-таки разные. Железнодорожного светофоры бывают разные, в т.ч. желтые, синие, белые, а еще бывают комбинации огней. Система сильно сложнее автомобильных светофоров. Это не считая всего прочего. Вот метро без машинистов уже много где и довольно давно существует.
Три цвета - это сильно сложнее двух?
Ну вообще не три, а больше. Но суть в том, что "один входной канал управления - зеленый/красный семафор" сильно не так.
Посмотрел на систему сигналов для железнодорожного транспорта Германии - и близко нет ни белых, ни синих, так что на 100% уверен, что можно обойтись и без них.
А в Норвегии пять цветов, и сигналы не только светофором передаются. Вам в который раз указывают, что дело устроено сильно сложнее "зеленый/красный". А там, где дело проще (метро) автоматические поезда уже ездят который год. Но вы упорствуете - все просто! Если все просто, почему не сделали, вот как вы сами думаете?
Посмотрел на систему сигналов для железнодорожного транспорта Германии - и близко нет ни белых, ни синих
Где вы смотрели? Вот даже банально в википедии есть желтый свет "A distant signal (Vorsignal) shows Vr 0 by a yellow disc or two yellow lights (the right light is above the left light)." И белый есть "Ersatzsignal = Subsidiary signal
Three white lights aligned as a triangle (pointing upwards), or one flashing white light."
В вики глянул в UK, в Японии есть желтый и везде плюс минус одинаково - двойные, мигающие, всякие сочетания. И куча еще всякой другой разметки.
Не сделали явно не потому, что эти сигналы сложно распознать, а потому, что есть определенные процедуры сертификации, и обойти их, ссылаясь на какие-то "суперпроверенные" алгоритмы ИИ не выйдет, никто такое не пропустит в тираж, потому что на миллионе ситуаций система сработает, а на одной даст петуха. ИИ - это лотерея, и никто в нее играть в таких вещах не собирается.
В метро наоборот сложнее - в рельсовую цепь подаётся частота, кодирующая разрешённую скорость. Плюс ещё стоят стационарные устройства (конкретно в Питере, где используется система автоведения ПАКСД-М, это расположенные на станции и у въезда на неё рейки, при обнаружении которых датчиками на составе запускается соответствующая программа торможения). На ЖД же используются только сигналы светофора и записанная в память прибора безопасности электронная карта.
В метро наоборот сложнее
Я имел в виду все в целом, не просто езду по рельсам. В метро все-таки движение более предсказуемо, нет переездов, нет осадков (хотя где-то может быть наземная часть), человек на путях может оказаться только на станции, составы одинаковые. Расстояние между станциями маленькое, если даже что-то сломается, то дойти пешком до поезда дело пяти минут. Опять же железка это не только поезда которые ездят из пункта А в пункт Б, это еще сортировка, погрузка/разгрузка и еще всякое. Но тут я думаю вы знаете это лучше меня)
Еще остается экономический аспект - сколько зарплата машиниста/помощника составляет от затрат на перевозку грузов. Повысится ли безопасность. Есть ли смысл внедрять полностью автономный ИИ (которого пока нет)? А всякие помогайки и автоматика существуют давно и все это не стоит на месте.
Вы не так поняли.
Метро проще, поскольку протяженность путей меньше и шанс появления на них препятствий тоже меньше. Поэтому есть возможность оборудовать всю путевую сеть и поезда комплексом технических средств. Собственно поэтому автоматическое метро и существует.
В случае с ЖД масштабы иные. Не то чтобы это невозможно, но на несколько порядков больше и дороже в реализации. Ну и как вишенка на торте - случись какой сбой, встанет состав в тайге посреди перегона в 300 км и заблокирует фактически транссиб.... в случае с метро всё сильно проще
проще некуда..я когда ЖД симуляторами увлекался..ох орал с такого, капец там лампочек и сочетаний
наши красный-желтый-зеленый-белый-зеленаяполоса и мигающие сочетания выглядят горааздо проще
===
вообще на всех ЖД мира довольно заумные сочетания светофоров...просто так там без поллитры неразобраться точно, в РФ далеко не самая сложная вариация этой штуки
желтые, синие, белые, а еще бывают комбинации огней.
только они нужны машинистам-человекам
если все 100% локомотивов на ЖД станут автоматическими, потребность в таких заумных системах пропадет
Ну когда-нибудь может быть и будет. Надо еще остальной транспорт полностью автоматическим сделать, чтобы дурачки всякие на переезды не лезли когда там поезд едет)
в данном случае переезды и т.п. практически никак не влияют на то кто там за контроллером поезда сидит
машинист никаких особых действий не может предпринять сверх тех что может предпринять ИИ, это не авто рулить нельзя...
там регламент тупой - видишь препятствие - тормозишь, всё. это может делать и автомат.
Надо еще остальной транспорт полностью автоматическим сделать
И оленей, и лосей.
один входной канал управления - зеленый/красный семафор
А как же грузовик поперёк путей?
Неа. Управление поездом сильно сложнее, чем просто "газовать/тормозить".
Была у нас такая штука как УСАВПП, в общем-то, позволявшая делать многое без участия машиниста. Можно было задать ей программу, а она бы довела поезд до станции с соблюдением ограничений скорости и профиля торможения.
Вот только машинист (на пару с помощником) - он не только кнопки жмякает и контроллером щёлкает. Выход из нештатных ситуаций (в отличие от метро, где при правильном обслуживании условия ну почти идеальные), иногда исправление неполадок и ещё много чего - это всё тоже его обязанности. И никакой ИИ в ближайшие годы туда не поставят - если вдруг модель, пусть даже и сто раз проверенная, заглючит, то поезд взбесится.
ИИ научился играть лучше в шахматы, но от этого люди в шахматы не перестали играть.
Я наблюдаю столько проблем и нехватки кадров во всех сферах. Половина интернет-приложений работает с тормозами или серьезными ошибками в моем телефоне. Почитаете отзывы про мегамаркет от сбера. В офлайн магазинах нет продавцов. В днс в моем районе давно работает один(!) человек на кассе. А это магазин витрина размером с пятерочку.
Что я хочу этим сказать? Мы думаем о 2035 и пока корабли бороздят просторы вселенной... Что ии скоро все порешает... о люди-руководители... тут земных проблем выше крыши. Наймите хоть кого-нибудь для их решения!
ИИ научился играть лучше в шахматы, но от этого люди в шахматы не перестали играть.
Вообще, определенный спад интереса к шахматам после создания ИИ был. Сейчас всякие онлайн соревнования не очень имеют смысл, если любой может жульничать, получая подсказки со смартфона, который играет не хуже гроссмейстера. Да и переодически возникают скандалы, что кто-то жульничает с компьютером на соревнованиях.
Да причём здесь ИИ? Дип Блю с трудом (и со скандалами) выиграл матч у Каспарова ещё в 1997-м.
Спад интереса к шахматам совпал по времени с появлением программ, способных обыграть чемпиона мира, но вызван был не только этим. В 60-80-е годы шахматы были одной из площадок политического противостояния. Фишер! Отщепенец и перебежчик Корчной против Карпова! Шахматисты - самый умные люди, а самый умный человек должен жить где? В самом передовом обществе (СССР) или в самом демократическом (США). А потом шахматы превратились просто в игру.
Так классика же - играть друг с другом и с компом во втором окне, повторяя ходы
Машины появились, но люди не перестали возить грузы на лошадях... Хотя постойте... Люди не перестали играть в шахматы потому что хотят. Бессмысленно обсуждать игру в контексте автоматизации.
ИИ научился играть лучше в шахматы
там вроде не ИИ, а алгоритм написали, он же на простом десктопе работает, играет как гросмейстер.
Алгоритм давно известен - это элементарный перебор позиций на несколько ходов вперёд. Быстродействие процессоров подтянулось, что позволило полностью просчитывать партии. Современный Стокфиш (популярный шахматный движок) на смартфоне порвёт Магнуса Карлсена в десяти играх из десяти без каких либо шансов на победу для последнего))
Это всё довольно удручающе повлияло, разумеется, на шахматы как на вид спорта. Теперь, когда проходит матч за шахматную корону, складывается ощущение что в шахматы не умеют играть лишь те двое за доской - весь остальной мир смотрит обсуждение партии с анализом и оценкой каждого хода от шахматных движков))
Уже очень трудно становится оценить красоту того или иного хода - движок же сразу даёт весь расклад. Ход необычный, но бесперспективный и т.п.
Алгоритм давно известен - это элементарный перебор позиций на несколько ходов вперёд.
Это не элементарный перебор, потому что дерево растёт экспоненциально - нужно быстро и хорошо выбирать нужные ходы на каждом шаге. Особенно это актуально для таких игр как Го, в которых ИИ значительно продвинулся именно благодаря нейросетями. И стокфиш после этого тоже продвинулся.
Быстродействие процессоров подтянулось, что позволило полностью просчитывать партии.
Партии до конца не просчитаны в шахматах и скорей всего не будут - количество комбинаций слишком огромное. Подтянулись не только количественные изменения, но и качественные.
Вот ведь зануды)) Пытаешься на пальцах объяснить - сразу с уточняющими ремарками налетают))
Партии до конца не просчитаны в шахматах и скорей всего не будут - количество комбинаций слишком огромное.
Ну серьёзно?)) Вангую - в ближайшие 50 лет шахматы "посчитают". Уже некоторые дебюты забраковали. Таблицы Налимова уже четверть века юзают. Надо как раз вот оптимизацией алгоритма просто плотно заняться. Сдаётся мне, например, это условное деление партии на три фазы - уже устарело...
Алгоритм давно известен - это элементарный перебор позиций на несколько ходов вперёд.
Элементарный перебор называется минимакс. Из‑за экспоненциальной сложности он вчистую проигрывает разным эвристическим алгоритмам отсечения, использующимся в шахматных движках аж с 1956 года.
Быстродействие процессоров подтянулось, что позволило полностью просчитывать партии.
Полный перебор невозможен — опять же из‑за экспоненциальной сложности. Все движки оценивают благоприятность позиции, которая появится через несколько ходов. Классические движки (типа Stockfish до 11 версии) оценивали позицию по определённому алгоритму, но в районе 2019–2020 годов движки с нейронной оценкой начали выносить классические движки вперёд ногами.
Главный фактор, повлиявший на профессиональные шахматы — это то, что в оценке партий и позиций гораздо меньшую роль стал играть авторитет топов. Раньше Каспаров мог пойти конём и сказать «я чемпион, я так вижу», а десятки мастеров потом тратили дни и недели, чтобы понять, насколько глубок был его замысел. А сейчас — «Kasparov is almost as good at playing chess as my iPhone».
«Kasparov is almost as good at playing chess as my iPhone»
вот-вот. Потому что, как минимум, у любого к-аспарова (с маленькой как обобщение) есть шанс зевнуть, а машина зевать не умеет. Машина также не может встать не с той ноги, поругаться с супругом, ... и по этому быть не в форме.
Дело вовсе не в форме. У Карлсена на пике формы десять лет назад был рейтинг 2882; у Stockfish сейчас (на стареньком железе) — 3642. Значит, нынешний Stockfish победил бы тогдашнего Карлсона с вероятностью 99% (по этой формуле). Обыграл бы вчистую, на классе.
Спорный вопрос.
Если Карлсен белыми и с установкой сделать ничью любыми силами (хотя как еще можно играть против Стокфиша) и выбрать дебют с явными ничейными тенденциями - уверен что шансов на ничью намного больше чем 1%. Понятно, что за ничью человеку надо будет бороться, но шансы устоять существенно больше.
Есть в шахматы Фишера да еще и черными, вот тут конечно человеку совсем тяжело будет устоять
Раз уравнивать шансы — так уравнивать! Ограничить массу вычислительного устройства, на котором ИИ работает, двумя килограммами, а энергопотребление — пятью печеньками в час!
Рейтинг Эло — это статистика. Все факторы (сушка игры противником, чёрные лебеди типа зависшего сервера и т. п.) уже учтены в ней.
Хотя с другой стороны, в рейтинговых играх обычно участвуют игроки примерно одного уровня. Если разница в уровне большая, то сторонние факторы начинают иметь больший вес. В любом случае, разница рейтинга в 760 — это как разница между перворазрядником и Анатолием Карповым.
В предсказании результата игры по Эло не учитывается
1. Цвет фигур
2. Желание соперника засушить
Сейчас есть примеры когда даже средние мастера ФИДЕ ловят гроссмейстеров в дебютную ловушку и либо быстро делают ничью, либо даже выигрывают в тонких компьютерных вариантах, заученных дома.
Такого еще 20 лет назад представить было не реально.
Из описания вакансии с какого-то работного сайта: "...наличие импланта будет предпочтительным". Ну как у Андрея Ливадного в его фантастике.
Будут востребованы айтишники за МРОТ.
С текущей тенденцией нужны будут люди которые из палки и камня могут копья делать
Мне нравится пример из мира шахмат: компьютерные программы постепенно побеждали лучших шахматистов мира. Но если взять в одну команду лучшего шахматиста и компьютер, то с таким тандемом справится или играть на равных практически не реально.
А мне не нравится этот пример. Современные программы и так побеждают любых шахматистов и без помощи ассистента. Т.е. человек тут скорей мешает, чем помогает. С натяжкой подходит игра Го (Бадук), потому что там намного больше комбинаций, и она более абстрактная.
Нет оснований полагать, что новая революция в разработке ПО пройдет по другому сценарию.
Не соглашусь, потому что до сих пор не было в истории аналогов появления сильного ИИ, или хотя бы сильного в области разработки программ - т.е. эффективной автоматизации мыслительной деятельности (а потенциально и мыслительной, и физической).
До сих пор лишь человек мог заниматься разработкой ПО. Сложность задач и, соответственно, самого ПО, росла, но, поскольку программируют люди, то их требовалось всё больше.
Когда же ИИ окажется способен сам разрабатывать ПО, по самым общим выданным ему техзаданиям, или даже вербальному описанию проблемы (и ожидаемо дешевле людей), то увеличения числа задействованных человеческих работников не будет необходимым, т.к. ИИ можно множить, сколько потребуется (и сколько хватит мощности, но вряд ли это будет ограничением надолго), а небольшое "количество" людей будут формулировать ему проблемы для решения.
Разумеется, это тоже предположение, но оно кажется более вероятным.
Такую ставку мало смысла рассматривать, потому что если появится достаточно сильный ИИ чтобы по высокоуровневым требованиям выстраивать системы в миллионы строк, и тысяч взаимодействующих модулей - у человечества будут проблемы намного больше, чем ненужность разработчиков. А с тем что есть сейчас, даже с учетом масштабирования - просто получим снижение стоимости ПО и по тому же маршруту пойдём как уже проходили не раз - по крайней мере еще лет на 25.
Что-то разрабатывать по самому общему описанию? Ну да, конечно. Но только всё, что может быть понято неправильно, будет понято неправильно. А чтобы не допускать никакого недопонимания, надо все максимально подробно расписать на специальном языке, не допускающем неоднозначных толкований.
Правильное понимание вероятно можно обеспечить контекстом, заранее заложенным в ИИ (fine tune или более какой там будет продвинутый будущий аналог) направлением работы компании, примеры предыдущих заказов и т.д., чтобы снизить число возможных вариантов при недосказанности. В конце концов, человек-работник же тоже может понимать якобы с полуслова, а на самом деле опираясь на уже отработанные в компании хорошие решения для реализации деталей большой задачи.
Речь про то, что нет причин, что нельзя научить ИИ делать всё, что может в разработке делать человек. Даже встречаться с заказчиками (пусть и не физически пока) для формирования задач на разработку. Разве что фуршет ИИ ниасилит )
А чтобы не допускать никакого недопонимания, надо все максимально подробно расписать на специальном языке, не допускающем неоднозначных толкований.
И вот мы получили определение термина "программирование" xD
Так нет пока никакого ИИ. А если он когда-нибудь и появится, то он уже точно не будет разрабатывать программы на тех языках, на которых люди программируют. Это тупо неэффективно с точки зрения компьютера.
Такие предсказания не имеют смысла. Полная замена инженера на AI невозможна без достижения полноценного AGI, способного находить решения новых, несуществующих в настоящий момент задач. Если же вы ставите на скорую возможность появления такого AGI - значит вы неизбежно ставите на скорую технологическую сингулярность. Сложно предположить причину, по которой этот AGI окажется фундаментально неспособен улучшать себя.
ИИ сейчас программирует лучше чем некоторые мои бывшие коллеги. Это не шутка. Так что вопрос когда он заменит остальных лишь вопрос времени. Полагаю, что это произойдет быстрее чем переход от кнопочных телефонов в голосовому вводу.
Конечно. o1_preview хорош. А DeepSeek R1 показывает что даже маленькая модель может решать letcode hard. Но решать принципиально новые задачи они не могут. Скорее всего - пока не могут.
Полноценной агентности, даже на задачах кодинга тоже нет - даже если дать модели возможность работать с файлами, запускать отладку и т.д. она пока не справляется с комплексными задачами.
Но это как раз не отменяет моих тезисов - если (или когда) AI это сможет - здраствуй сингулярность, ты уже рядом. Так что разговоры об замене програмистов просто не имеют смысла. Когда заменят програмистов - мы будем жить уже в совсем другом мире, который пока не можем себе представить.
Единственные варианты когда сингулярность не наступает в обозримом будущем - это если Ян Ле Кун окажется прав и AGI на трансформерах принципиально невозможен или исследования в области почему-то резко прекратятся.
Но решать принципиально новые задачи они не могут
Ну конечно же... Ведь 99% разработчиков каждый день только и делают, что решают принципиально новые задачи. Принципиально новый круд. Принципиально новая формочка. И разумеется принципиально новое перекладывание принципиально нового json.
Принципиально новомодное перекладывание принципиально новых proto файлов для grpc )
Большинство разработчиков каждый день перекладывают требования с непонятного на понятный язык, потом с понятного на более понятный, и так пока не дойдёт до понятного компилятору (от уровня разработчика зависит на каком уровне понятности он начинает перекладывание и на каком заканчивает). Нынешние модели умеют в последние 1-2 шага - можно заменять всех джунов конечно, но джунов заменять нельзя по другим причинам. А когда будут модели которые умеют заменять сеньоров - уже совсем другой мир наступит.
Нынешние модели умеют в последние 1-2 шага
Вы уверены? Пробовали спрашивать у ChatGPT вопросы про архитектуру? Уверен, что он справится достаточно хорошо. Обернуть чат в агента, загрузить в него всю информацию о компании и текущей архитектуре, и заставить выяснять все требования к очередной фиче - кажется решаемой задачей.
Смотря что вы подразумеваете под "архитектурой". Если сборник определений паттернов из книжек по микросервисам - то справится.
Если же понимание полной специфики бизнеса, горящих сроков, чтение между строк, особенностей характера стейкхолдеров, причуды и эго руководства, а также учитывание множества нюансов и ответственность за принятые решения, да еще и обоснование почему так, а не так - то кажется тут несколько сложнее. Тут стоит дождаться "моделей которые умеют заменять сеньоров" и поглядеть на наступивший другой мир.
Новый ИИ-агент OpenAI под кодовым названием «Operator» сможет пользоваться компьютером и выполнять действия от имени его владельца (например, написание кода или бронирование билетов).
Если же вы ставите на скорую возможность появления такого AGI - значит вы неизбежно ставите на скорую технологическую сингулярность.
А мне это все фантазии напоминает.
1) Кто сказал что "уровень интеллекта" не ограничен и ИИ сможет без конца "умнеть", улучшая себя? Возможно, предел интеллектуальных способностей не так уж далек от ученого человека, и "богом" АГИ не станет. Просто будет невероятно быстро соображать и легко анализировать бигдату. Ну ок.
2) На постоянное самоулучшение очевидно нужны все возрастающие ресурсы - как материальные, так и энергетические. Которые вполне конечны, как минимум в пределах нашей досягаемости.
3) Определенно существует набор физических ограничений Вселенной. Каким бы умным ни был интеллект, он не сможет делать что-то, если это что-то запрещено законами Вселенной, в которой он обитает. Например летать быстрее света, получать материю из ниоткуда, изобретать телепортатор, и т.д.
Есть некоторая вероятность что богом не станет - и это было бы прекрасно. Но этого и не нужно.
Для сингулярности хватит масштабирования количеством - сейчас у нас ограниченное количество действительно хороших инженеров и ученых, которые иногда спят, отвлекаются на личную жизнь, ленятся... Умножте их количество на очень большое число и работу 24х7.
Сложно предположить причину, по которой этот AGI окажется фундаментально неспособен улучшать себя.
Рубильник?
мы не будем удивляться, когда помощник разработчика предложит вставить кусок кода, написанный другим программистом месяц назад, похожий по смыслу той задачи, которую мы сейчас реализуем.
То есть, вместо переиспользования кода будем плодить дупликацию? Ну, в принципе, я не удивлюсь, да :)
Когда я вижу вот такие публикации, в которых с лкгкостью манипулируют словами "искусственный интеллект", то сразу появляется тошнота. Может хватает хайповать? Может сказать правду что нет никакого ИИ?
Слушал одно интервью про ИИ. Там был интересный момент. Говорят ИИ нет, ведь он не понимает, что делает. Но штука которая понимает, что происходит называется сознание и она не является безусловной частью интеллекта. Она появилась в процессе эволюции, т.к. давала преимущества. Соответственно ИИ это и есть искусственный интеллект, а появится ли у него сознание это уже другой вопрос.
"нейросеть" не так хайпово звучит
Государство только на 2030 планы построило, а вы уже вперёд бежите...
Ого, да это же очередная статья по замене человека ИИ. Давненько не было таких
В будущем будут востребованы программисты квантовых компьютеров. А потом еще каких-то других компьютеров, а потом еще каких-то.
С квантовыми компьютерами к сожалению пока что не идёт. Получается эффективно решать только очень узкий класс задач, и скорее всего кардинальных изменений в этом плане не будет. Даже если получится собирать достаточно масштабные системы за не-триллиард денег, они будут использоваться для конкретных задач, связанных с вычислениями и перебором больших массивов данных, как серверы - а большинство рутинных задач останутся на обычных транзисторных ЭВМ
Хорошие — будут, плохие — нет. Не благодарите за прогноз, просто делаю свою работу.
Какие айтишники будут востребованы в 2035г, а какие – нет?
Если бы мы знали, но мы не знаем.
Мне, к своему стыду, вообще непонятна фраза "айтишники". Кто именно? Админы, девопсы, программисты, аналитики?
эйчары.
Помню одного эйчара на поза-поза-прошлой работе. Он был абсолютно уверен, что в будущем ИИ заменит всех программистов, а эйчаров заменить будет невозможно. Очень радовался этому)
Мда, он еще был, небось, девочкой с галазами, прозрачными настолько, что сквозь них было видно затылочную кость... В своей жизни я видел только одного незаменимого HR - но это был реально спец по разбирательству в людях, способный очень хорошо предсказывать поведение кандидатов в разных ситуациях. Так у него и в анамнезе была Высшая школа КГБ, а не не пойми что.
И почему сварщики, токари, кузнецы, фрезеровщики, литейщики, шлифовщики, конструктора, термисты и прочие не догодались назвать свою сферу «металлическими технологиями», а себя — MT-специалистами или эмтишниками?
У токарей, фрезеровщиков и т.п. есть обобщенное название "станочники". И, не знаю как сейчас, а я вполне помню времена, когда вся их сфера называлась металлообработкой.
Есть же слово "металлург", которое хоть и не включает в себя токаря и шлифовщика, но всё равно объединяет целую тучу специальностей. Или, там, "работник лёгкой промышленности", в чём проблема? Или вообще "инженер".
Ну Вас же, надеюсь, не сильно удивляет фраза про "врачей в общем"?
Без разделения на терапевтов/хирургов/окулистов... :)
Аналогично, в определённых случаях могут обсуждаться и "айтишники в общем". Без разделения на программистов/железячников/системных интеграторов/сетевиков...
Если бы мы знали, но мы не знаем
Типичный ответ студента на экзамене. /s
Вот беспокойство то. Я просто надеюсь, что 2035 год будет, а там уже разберёмся =)
Понадобятся айтишники, умеющие стрелять из автомата.
Предположу, что на первое место выходят навыки problem-solving с умением выполнять рутину при помощи роботов.
Это будет применимо к любой отрасли человеческой деятельности. Решать будет специализиация, т.к. по-прежнему потребуются тысячи часов вникания в тему, чтобы суметь делать в ней что-либо осмысленное и контролировать работу роботов.
Самыми необходимыми навыками станут:
инженерный/научный подход к решению задач (т.к. интуитивный станет сильно отставать),
высокая самоорганизация (AI-driven в том числе),
развитые навыки выполнения любых объемных работ с помощью ИИ-инструментария,
любознательность и широкая картина мира, умение выявлять взаимосвязи.
А кто этого не осилит неизбежно окажется под руководством самих ИИ за миску {food_type}.
Надо бы поставить будильник на полдень 1 января 2036 года, чтобы сравнить с написанным здесь
TLDR: хорошие, годные специалисты будут востребованы, а плохие, негодные не будут.
Как в "Дознании пилота Пиркса" - заходит кандидат в HR и с порога говорит:" - Я не человек"
Любые статьи в стиле "а что будет через N лет" так любят все писать потому, что автор не несет никакой ответственности за сказанное.
Только 1% лучших и сильнейших останутся нужны, если коротко. Хотите быть востребованным? Будьте в 1% лучших, бегите быстрее чем 99%, конкурируйте, выживайте. С раннего детства изучайте английский, CS, заканчивайте топовые вузы, умейте больше и быстрее чем 99% остальных, и будете получать немного выше МРОТ. Оно того стоит
будете получать немного ВРОТ)
Скрытый текст
Как бы это не звучало жестоко, но тут есть большая доля правды. Чем выше Ваша квалификация (без разницы техническая, организационная и т.д.) тем позже за Вами придет технический прогресс.
Мне нравится пример из мира шахмат: компьютерные программы постепенно побеждали лучших шахматистов мира. Но если взять в одну команду лучшего шахматиста и компьютер, то с таким тандемом справится или играть на равных практически не реально
Не понял аналогию. Компьютер давно играет сильнее любого шахматного чемпиона. Шахматы не потеряли популярность лишь потому что людям интереснее смотреть за людьми, видеть эмоции и их борьбу. Самые продвинутые движки в игре между собой могут делать настолько неочевидные для человека ходы, что обычному зрителю это неинтересно.
IT компаниям нужно развивать бизнес и код с программистами лишь один из способов это достичь. Если появляется ИИ, выполняющий такую же задачу быстрее и лучше, то зачем держать программиста? Никого не интересует его борьба с кодом и эмоции. Не утверждаю что всех программистов заменят, но аналогия с шахматами не совсем точная.
Мне больше нравится аналогия не с шахматами, а с силовыми видами спорта. Трактор сильнее чем тысяча тяжеловесов-спортсменов. Моторная лодка быстрее любого пловца-профессионала. Автомобиль даже самый захудалый уже быстрее не то что бегуна-профи, но даже гепарда. Различные виды вооружения - пулемет, пушка, танк - превратят любого мастера боевых искусств в крошево. Однако ж подобное никуда не делось - тяжеловесы на соревнованиях поднимают штанги и гири, пловцы также соревнуются на скорость, бегуны бегают, а боксеры и борцы ММА те же самые тоже никуда не пропали, и дубасят друг друга, как и раньше.
вот только тяжелоатлеты и до трактора землю плугом не пахали, а трактор никогда на соревнованиях не выступал. Все описанные тобой случаи не имеют конкуренции.
Различные виды вооружения - пулемет, пушка, танк - превратят любого мастера боевых искусств в крошево.
Но только не того, у кого в руках РПГ (с термобарой или кумулем соответственно).
...и чёрный пояс по гранатомётам.
Кстати, вот вы тут ржОте, а пехотинец в ближнем бою даже без гранаты уделывает танк влёхкую (и именно поэтому танки по уставу обязательно идут при поддержке пехоты).
а пехотинец в ближнем бою даже без гранаты уделывает танк влёхкую
Говном залепляет смотровые приборы? Типа как с медведем.
У кого что болит, тот о том и говорит. А вообще-то рекомендовалось плащ-палаткой.
Это плащ-то палаткой влехкую танк уделать?
7. Израсходовав гранаты и бутылки с горючей смесью, бойцы-истребители заготавливают грязь-глину, которой забрасывают смотровые щели танка.
Инструкция по борьбе с танками выпущенная 5 июля 1941 года на Северо-Западном Фронте. Подписана Ватутиным. Это насчет того чем залеплять смотровые приборы)
Смысл в том, что за счёт никакого обзора из танка пехотинец может элементарно к нему подобраться вплотную, а дальше вариантов полно. Самый простейший — ослепить его ещё больше, выведя из строя приборы наблюдения — закрыв плащ‑палаткой ли, глиной ли, или расстреляв из пистолета. Насколько я помню, защита от вражеских пехотинцев была только в «Меркаве», в види лючка, через который экипаж мог выбросить наружу ручную гранату.
Как-то так
См. Иван Середа
пехотинец может элементарно к нему подобраться вплотную, а дальше вариантов полно
Самый вероятный вариант - танк едет и наматывает пехотинца на гусеницы.
Вы почему-то считаете что танк стоит, никуда не едет, не стреляет и даже башней не вертит. А экипажа внутри толи нет, толи все в алкогольном коматозе и вообще ни на что не обращают внимания.
танк едет и наматывает пехотинца
Ну да, а пехотинец в это время стоит столбом и ничего не делает.
Также рекомендую ознакомиться с
углами обзора смотровых приборов
А также собственно с
углами обстрела
У танка преимущество только в скорости по прямой. А вот скорость и радиус разворота сорокатонной дуры — они не идут ни в какое сравнение с таковыми у стокилограммого пехотинца, несмотря на то, что лошадиных сил у того поменьше будет.
Ну да, а пехотинец в это время стоит столбом и ничего не делает.
Если бы он стоял столбом еще бы ничего, если бы удирал от танка, то скорее всего удрал бы. Это если танк его не заметил, а так стрельнет ОФС об землю или стену и аля-улю. А у вас по условию задачи надо забраться на танк и замотать ему плащ-палаткой смотровые приборы. То есть натурально цирковой номер, надо подбежать к танку, на ходу на него заскочить, удержаться и еще лазить по нему как обезьянка по пальме. Влехкую, ага.
Также рекомендую ознакомиться с
Вы не обратили внимание, что большинство смотровых приборов на башне, а башня крутится? Ну и как бы одной плащ-палатки на несколько приборов не хватит)
А также собственно с
Пулемет может и не грозит, зато грозит сама туша танка и ОФС в землю перед собой, если не убьет осколками или ударной волной, то контузит.
Танкисты должны для начала заметить пехотинца, что при вышеприведённых углах обзора решается элементарно путём прикидывания шлангом трупом (каковых на войне как собак нерезаных), до тех пор, пока пехотинец не попадает в непросматриваемую зону.
надо подбежать к танку, на ходу на него заскочить, удержаться и еще лазить по нему как обезьянка по пальме.
А в чём проблема-то? Вы что, в детстве ничем подобным не развлекались?
А в чём проблема-то? Вы что, в детстве ничем подобным не развлекались?
Запрыгивать на танк? Не. Даже запрыгнуть на грузовик или трамвай на ходу идиотов не находилось. Отдельные люди цеплялись сзади к трамваю или грузовику зимой, пока он стоит, а затем он их катил (типа зацеперы). Но даже у них хватало ума не цепляться на ходу.
Проблема в том что танк весит десятки тонн и даже при относительно небольшой скорости у него очень большой импульс, а человек по сравнению с танком это пушинка. Ну если вы можете запрыгнуть на движущийся грузовик или трамвай, то вы реально выдающийся чел.
решается элементарно путём прикидывания
шлангомтрупом
В современных танках стоят тепловизоры, поэтому если лечь на пути у танка, то прикидываться долго не надо будет, совсем скоро труп станет настоящим.
Конечно законам физики все это не противоречит. Если какой-то глупый танк едет совсем один со скоростью пешехода по улице, то наверное можно выскочить из-за угла. И танк не заметит. И при некоторой удаче можно наверное даже на танк залезть. И потом с него не упасть. И танкисты ничего не заметят, и скажем даже как-то испортить им прицел. А что дальше? Правда тут нужны какие-то даже не стальные, а реально адамантиевые шары, сочетание кучи факторов и еще невероятная удача. Назвать это влехкую? Ну фиг знает.
Свежий труп будет выглядеть ровно так же, как и живой лазутчик, только первый не сможет от гусеницы откатиться (а экипаж всё равно не видит, что труп делает — там мёртвая зона).
Удачи никакой не надо. А вот миниатюрная «кошка» сильно облегчит задачу: танк — он не идеально гладкий.
Танкисты-то заметят — но к тому моменту, когда заметят, метаться будет уже поздняк.
И вообще — Вы за кого: за меня или за неприятеля?
Ну в общем арабские противники Израиля регулярно постят видео с "пехотинцем, который смог", но судя по количеству видео - штука не тривиальная, если нет удачи.
Если нет мозгов, скорее.
Впрочем, я и не говорил, что это "штука тривиальная". С другой стороны, когда я говорил "влёхкую", я не имел в виду, что к танку можно подходить вразвалочку, поплёвывая сквозь зубы. Но при минимальной подготовке ничего принципиаьно невозможного в этом нет.
Ну все, что я видел - это развалины и остановившийся танк. Хотя бы на мгновение для выстрела.
А вот если посмотреть кадры с полей СВО, когда очередная колонна под обстрелом идет на новый рубеж - то там такая скорость, что прыгнуть на броню кажется шансов нет.
Фаустпатрон (или что-нибудь соответствующее эпохе) в борт.
Так и программисты порой участвуют в олимпиадах, хахатонах и прочих развлекательных мероприятиях. Но какое отношение это имеет к промышленной разработке?
Айтишник - это переводчик с человеческого языка на компьютерный и не более.
Как сейчас с работой у переводчиков с человеческого на человеческий? Когда-то казалось невозможным, что компьютеры будут переводить речь на лету, теперь вот оно, рукой подать и качество нормальное.
Думать, что программист обладает каким-то особым структурированным мышлением, великим владением предметом, как-то эдак хитрО мыслит на уровне, недоступном простому смертному, большая ошибка.
Это простой смертный, умеющий хорошо и структурированно мыслить, правильно ставить приоритеты и формулировать задачи, рассказывает айт-ишнику-программисту как оно должно быть. Кто этот небожитель, где он? Да вот же он, среди нас: бухгалтер, технолог, проектировщик, продавец и прочие-прочие-прочие, не все поголовно, лучшие, опытнейшие, но это они ставят задачи, говорят граничные условия, задают последовательности и тестируют продукты, определяя какими они должны быть, что делать, да как делать.
А что же программист?
Он всего лишь переводчик хотелок вышеназыванных профессионалов на машинный язык.
И что будет?
Со временем кодер пойдет следом за обычными переводчиками, а кодинг да, согласен с ТС, трансформируется в подробное техзадание на человеческом языке.
Может быть и не очень подробное, и так можно. Пока вы будете натужно и корректно вымучивать свои хотелки, совершенно особенные, под вас заточенные, прям вот творческие по самое не балуйся, ИИ уже выдаст решение и за вас доформулирует. Ка-а-а-ак? Да просто он уже видел все ваши оригинальничанья у статысячпятисот пользователей до вас и решение готовое имеется. Доработал напильником, дарственную надпись выгравировал и нате, получите-распишитесь.
Для самых-самых привередливых и неформально мыслящих творческих личностей останется Тёма Лебедев с неземного цвета волосьями для создания улетного креатива
Айтишник - это переводчик с человеческого языка на компьютерный и не более.
Гораздо более. Можно сравнить, например, со сценаристом. Человек превращает идею "у нас тут будущее, роботы, пыщ-пыщ, он любит ее, а в конце вотэтоповорот" в развернутое структурированное произведение.
Когда-то казалось невозможным, что компьютеры будут переводить речь на лету, теперь вот оно, рукой подать и качество нормальное.
Качество пока на троечку с минусом, но для многих задач этого уже достаточно.
Для бытовых - это да. Разобраться, как у китайского девайса переключить интерфейс на английский, прочитать инструкцию к товару с Али или в заграничной поездке что-то купить или о чём-то поинтересоваться - без проблем. Но для профессиональных задач как раз таки недостаточно. Особенно, если переводить надо не "Paris c'est la capitale de la France", а, скажем, какие-то медицинские, технические или научные тексты, с которыми порой даже углеродная нейросеть ошибается, не говоря уже про кремниевую. Если такое прогнать через машинный перевод, получится адовая чушь.
Как сейчас с работой у переводчиков с человеческого на человеческий?
Да нормально. Попробуйте принести к нотариусу заверять машинный перевод какого-нибудь документа. В литературе тоже не видно потока изданий с машинным переводом. И крутым дядям на саммитах в ухо через наушники не Яндекс.Алиса бубнит.
Вот именно что крутым дядям.
Роботы сделали с переводчиками примерно то же, что аудиозапись с музыкантами. Пропала огромная ниша лабать в кабаках, и воспроизведение музыки по шаблону перестало быть широко распространенной профессией. Так же и с переводчиками: ниша "переводов для себя" (в основном в рабочих целях) исчезла почти полностью. То есть если раньше средний учёный или инженер, не знающий английского, был вынужден нести интересную ему статью переводчику, то сейчас он может загрузить её в переводчик и в общем-то понять смысл, а уточнить только специфические термины (хотя их-то он скорее всего понимает и так).
Пропала огромная ниша лабать в кабаках
Да вообще до сих пор лабают.
Пропала огромная ниша лабать в кабаках
Выше правильно написали -- как лабали, так и лабают.
То есть если раньше средний учёный или инженер, не знающий английского
Этот сектор убивает не машинный перевод, а то, что английский язык окончательно истребил национальные языки (кроме может быть китайского) в науке и теперь инженер/учёный, не способный прочитать и понять с грехом пополам текст по своей специальности на английском превратился в курьёз и остался на таких уровнях квалификации, к которым и раньше переводчика не приставляли.
А если учёному или инженеру понадобится документацию написать или статью для публикации перевести, то он всё равно пойдёт к переводчику.
В языках есть структура, и предложение на любом языке - по сути четко заполненный опросник фичи, которая потом реализуется в виде перевода.
Если будет такой опросник с четкими формтами для разработки и найдется такой клиент/аналитик, который его заполнит идеально - то да, верю, что ИИ по нему может сгенерировать корректную программу.
Так что всего лишь остается создать такой шаблон и научить его заполнять. Кто бы это делать должен? Так этим команда разработки и занимаются!
40 лет назад на волне хайпа тоже все мечтали что вот через 30 лет-то мы будем просторы вселенной бороздить. Ну или хотя бы пиццу гидрировать аки мамаша МакФлай. И как вы думаете, для чего же сейчас используется вся мощь технологий? Держитесь крепче - для трындежа. Вся ИТ-индустрия заточна на одно: чтобы лемминги трындели в чатиках. Ну или строчили комменты на хабре
И как вы думаете, для чего же сейчас используется вся мощь технологий? Держитесь крепче - для трындежа.
Вы не правы. Я вам не скажу за всю ИТ-индустрию, но большая часть того, что связано с вебом, используется для впаривания.Или втюхивания. Короче - для распространения рекламы. И этим кормится.
Если бы сегодня внезапно появился кто-то из 1950-х, что сложнее всего было бы ему объяснить о нашей жизни? У меня в кармане находится устройство, которое имеет доступ ко всей информации, известной человечеству. Но я использую его, чтобы смотреть картинки котов и спорить с незнакомцами.
del
инженер-оператор
Ржанул в голос. И почему нет инженера-импортозаместителя?
на основе Искусственного интеллекта
А почему с большой буквы? Уже подлизываетесь на случай, чтобы, если захватит мир, то сразу не убил, сначала помучил?
Художники не исчезли с изобретением фотографии. Живые музыканты не исчезли с появлением синтезаторов и семплеров. Даже кузнецы и гончары еще встречаются и неплохо себя чувствуют, делая уникальные вещи и продавая их задорого. Так же будет и с программистами. ИИ будет шлепать CRUDы на потоке, а программисты - изобретать новые алгоритмы для нетривиальных задач.
Но если взять в одну команду лучшего шахматиста и компьютер, то с таким тандемом справится или играть на равных практически не реально
Здесь вы ошибаетесь) В шахматах всё что вам необходимо - это иметь быстрое "железо" и одну из последний версий шахматного движка. И управлять этой программой можете вы сами. При том, что вы можете даже не знать как играть в шахматы. И вы 100% выиграете у чемпиона мира и любого гроссмейстера.
То есть "лучший шахматист" в команде абсолютно не нужен. Задумайтесь.
Позволю с Вами не согласиться.
1. Дать 100% гарантию, что движок обыграет черными супер мотивированного Карлсена в разменном варианте дебюта с явными ничейными тенденциями вряд ли кто то даст
2. Если против одного движка выставить команду Карлсена и движок - то я бы поставил на команду (шансы все таки по больше и сейчас редко но бывают ситуации, где движки некоторые стратегические тонкости могут не видеть)
на протяжении нескольких недель, проходили разные алгоритмы сортировок массивов. Как думаете, многие ли программисты сейчас знают такие понятия, как поиск пузырьком
Про поиск пузырьком уже всё сказали, но дело даже не в этом. Вы считаете, что их там учили алгоритмом сортировок пузырьком, чтобы они потом сортировали пузырьком? Я всегда привожу такой пример: у детишек есть игрушка, там надо кубики, шарики и тела других форм засунуть через нужной формы отверстие, а иначе не пролезет. Или ключик нужной формы подобрать. Как думаете, пригодилось в жизни им это умение? Их готовили быть ворами-домушниками, и сейфы вскрывать? Нет ведь. Их учили - программированию, на примере разных сортировок.
Вы верно говорите, разные алгоритмы сортировок проходят что бы
1. Показать многообразие подходов к решению задач
2. Выполнить анализ сложности алгоритма (особенно для таких алгоритмов, где есть недереминированность совсем не тривиальный алгоритм определения сложности)
3. Показать историческое развитие подхода (как со временем мы шли к самым оптимальным вариантам)
Изюминка на торте - доказательство, что в общем случае нет более оптимальных алгоритмов, кроме уже открытых
Интерактивная помощь в разработке. Показ примеров разработки по шаблонам, выявление потенциально ошибочных участков кода. Уже сейчас системы статического анализа кода позволяют находить нетривиальные ошибки. ИИ позволит находить проблемы в коде намного точнее. Более того, мы выходим в эпоху, когда под текущую задачу ИИ может, как пример, подсветить ранее разработанный участок кода. Иными словами, сейчас мы не удивляемся, когда в бизнес приложениях по ключевым словам системы предлагают выбор элемента справочника. Точно так же мы не будем удивляться, когда помощник разработчика предложит вставить кусок кода, написанный другим программистом месяц назад, похожий по смыслу той задачи, которую мы сейчас реализуем.
Какое будущее? GIthub Copilot это настоящее же
После фразы
Дефицит разработчиков на рынке. По разным оценкам у нас в стране сейчас от 750 тыс. до 820 тыс. разработчиков. При этом потребность рынка на текущий момент составляет от 900 тыс. до 1.2 млн.
дальше не читал эту чушь. Своими глазами вижу количество просмотров резюме и число звонков, и ощущаю насколько проще было найти работу 3 года назад и как сыпятся отказы сейчас. Более правдиво цифры поменять местами и потребность еще на 2 поделить
Какие айтишники будут востребованы в 2035г, а какие – нет?