Часто слышу отголоски дискуссии, что через 10-15 лет за разработчиков будет писать код искусственный интеллект, он же будет находить и фиксить баги, автоматически создавать интерфейсы, анализировать пользовательский опыт и так далее. Так ли это?
Поскольку в Гринатоме сегодня мы уже не только выполняем функцию ИТ-интегратора для Росатома, но и создаем свои ИТ-продукты и выводим их на рынок, у нас очень высокая потребность в кадрах: более 7 тысяч ИТ специалистов, а к 2035г. их должно стать более 12 тыс. Поэтому хочу поделиться с вами опытом и своим видением будущего, каким рынок станет через 10 лет, какие специальности будут востребованы, а какие постепенно уйдут в историю.
Что сейчас происходит с рынком
Недавно посмотрела проходные баллы в ведущие ВУЗы, и обнаружила, что на востребованные ИТ-факультеты самых престижных ВУЗов на бюджетное направление можно не попасть, даже имея за плечами средние баллы по ЕГЭ в районе 98. Шансы есть только у победителей и призеров олимпиад или у тех, кто за три экзамена имеет 300 баллов. А еще недавно самыми престижными профессиями в России были физики, в том числе атомщики, летчики, экономисты и юристы, а сейчас безусловное первое место занимает ИТ. Как так получилось, и надолго ли это?
Откуда такая огромная потребность в кадрах сегодня:
Повсеместное использование информационных технологий. Мы даже не заметили, как ИТ стало сферой, плодами которой в повседневной рутине пользуется каждый житель планеты. Уже не найти технику, для которой не нужно программное обеспечение.
Информационные системы перестраивают бизнес. То, что было для всех в диковинку еще 10-15 лет назад, сейчас превратилось в норму жизни. Нет ни одной отрасли современной экономики, в которой ИТ не занимает одно из ведущих мест. Очевидно, ИТ позволяет оптимизировать процессы, загружать сотрудников более сложными и креативными задачами, забирая базовые задачи на себя. Как давно вы видели организацию, в которой нет направления ИТ? Я думаю, если и видели, то это было в начале девяностых годов прошлого века, уж точно не позже.
Импортозамещение. Если раньше зарубежные компании приходили на рынки развивающихся стран со своим ПО, то сейчас этот процесс прекращен. Все критично важные отрасли экономики должны работать только на российском или открытом программном обеспечении. Если попытаться оценить масштаб внедренного ранее программного обеспечения в период с 1991 по 2022 годы, то только для замены операционных систем, систем СУБД, бизнес приложений, коммуникационных систем и т.д. на отечественные аналоги нам потребуются многие годы.
Дефицит разработчиков на рынке. По разным оценкам у нас в стране сейчас от 750 тыс. до 820 тыс. разработчиков. При этом потребность рынка на текущий момент составляет от 900 тыс. до 1.2 млн. Причин дефицита несколько, одна из основных — неготовность рынка к взрывной потребности из-за ограничений в применении зарубежных технологий. Пятнадцать лет назад ВУЗы выпускали по 30-40 тыс. специалистов в год, сейчас это 150-250 тыс., но не всегда количество выпускников соответствует качеству, необходимому работодателю.
Требования к квалификации. Может показаться, что для решения проблемы с разработчиками ВУЗам или онлайн школам достаточно сделать шаг на встречу и выпускать ежегодно на 15-20% больше студентов, и проблема будет решена. Но есть одна тонкость – на рынке крайне востребованы Senior-специалисты. Для наработки такой квалификации требуется базовое ИТ-образование и опыт в среднем 6-8 лет. Сейчас практически все ВУЗы выпускают ИТ-специалистов, многие переходят в ИТ направление из других специальностей. Я уверена, что у вас и ваших знакомых есть примеры, когда сотрудники решили сделать карьеру в ИТ сфере, перейдя из бухгалтеров, математиков, преподавателей и т.д. Эта практика на рынке не нова, и многие организации помогают своим специалистам переквалифицироваться. Но этот процесс кардинально пока не меняет ситуацию.
Что может угрожать разработчикам в ближайшей перспективе?
Использование Искусственного интеллекта в разработке ПО. Современные системы на основе Искусственного интеллекта уже бросают вызов человеку. Мало кого удивляют примеры, когда компьютерные программы самостоятельно решают текстовые задачи – то, что всегда было козырем человека против машины. В сильнейших ИТ олимпиадах среди студентов ИИ занимает места в середине турнирной таблицы и чуть выше. Нет сомнений, что пройдет несколько лет, и ИИ программы будут занимать самые высокие места. Но одно дело – решать какую-то частную задачу, другое дело – найти в работающем ПО ошибку и исправить ее, выполнить доработку существующего ПО, перейти с одной технологии на другую. Эти задачи в качестве вызова для искусственного интеллекта сейчас далеко не на первом месте. В ближайшие 3-5 лет ИИ точно займет роль незаменимого помощника разработчика. Программисты постепенно станут операторами искусственного интеллекта.
Снижение потребности в новом ПО? Все технологии развиваются по спирали. Может ли возникнуть ситуация, когда уровень информатизации и степень удовлетворенности бизнеса от ПО будет велик настолько, что доработка или разработка нового ПО будет давать настолько маленькую ценность, что лучше будет оставить работающую систему в том виде, как она есть сейчас? Издалека это звучит фантастически. Но если это наступит, то будет касаться специфического программного обеспечения, применяющегося в очень узком спектре. Разработке программного обеспечения в масштабах какой-то отрасли или страны это точно не грозит. В ситуации, когда ИТ составляющая играет существенную, а иногда и решающую роль, является основным конкурентным преимуществом, говорить о снижении потребности в ПО не приходится.
Будет ли за нас все делать ИИ?
Каких ключевых направлений коснется внедрение ИИ в процесс разработки:
Тестирование. В тестировании будет все меньше и меньше ручного труда. Сейчас уже степень покрытия автоматическими сценарными и дымовыми тестами современных систем достаточно велика, и она будет неумолимо расти. В Гринатоме для выпускаемой новой версии программного обеспечения обычно степень покрытия дымовыми тестами составляет порядка 90%, а для автоматических сценарных тестов степень покрытия начинается от 20% (в основном только критически важные цепочки покрываются такими тестами). ИИ будет тестировать любые ИТ системы в десятки раз быстрее и точнее, чем мы привыкли как это выглядит сейчас.
Интерактивная помощь в разработке. Показ примеров разработки по шаблонам, выявление потенциально ошибочных участков кода. Уже сейчас системы статического анализа кода позволяют находить нетривиальные ошибки. ИИ позволит находить проблемы в коде намного точнее. Более того, мы выходим в эпоху, когда под текущую задачу ИИ может, как пример, подсветить ранее разработанный участок кода. Иными словами, сейчас мы не удивляемся, когда в бизнес приложениях по ключевым словам системы предлагают выбор элемента справочника. Точно так же мы не будем удивляться, когда помощник разработчика предложит вставить кусок кода, написанный другим программистом месяц назад, похожий по смыслу той задачи, которую мы сейчас реализуем.
Быстрое решение типовых задач. Многие помнят, как в школах или институтах на протяжении нескольких недель, проходили разные алгоритмы сортировок массивов. Как думаете, многие ли программисты сейчас знают такие понятия, как поиск пузырьком? Современные средства разработки позволяют нам не задумываться о сортировке, поддерживая ее в своих базовых библиотеках. Если еще лет 15 назад, в различных системах сортировку приходилось реализовывать самостоятельно, то сейчас такая задача решается за программиста. Безусловно в ближайшее время нас ждет серьезное расширение базовых библиотек, в том числе с использованием средств ИИ, позволяющих еще на более высоком уровне проектировать и разрабатывать информационные системы.
Таким образом, чем более сложные задачи будет решать ИИ, тем больше ИТ-команд потребуется на его развитие и поддержание. И второй ИТ-профессией будущего станет инженер-оператор ИИ, для которого ИИ будет инструментом написания блоков кода.
ИТ-специальности, на которые стоит обратить внимание уже сегодня
Архитекторы по КИИ. Критическая информационная инфраструктура (КИИ) — объединяет все системы, работоспособность которых жизненно важна для общества: банковские системы, атомная энергетика, дата центры и медицинские сервисы. Рынку уже сейчас нужны архитекторы, которые умеют проектировать, разбираются в безопасности и отказоустойчивости, умеют писать хороший индустриальный, поддерживаемый код, который не стыдно пускать в продакшн. Кстати, чтобы растить таких специалистов, Росатом совместно с Университетом Сириус запустил экспериментальную магистерскую программу, бесплатную, еще и обучение на берегу моря.
Специалисты в области бизнес автоматизации (в том числе 1С). Автоматизация бизнес-процессов позволяет снизить затраты, повысить производительность и улучшить качество обслуживания клиентов. Бизнес-процессы становятся все более сложными, и эффективная автоматизация требует глубокого понимания как технологий, так и специфики автоматизируемой отрасли. Специалисты, способные интегрировать различные системы и инструменты, будут в большом спросе.
Специалисты по анализу данных и принятию решений. С ростом объемов данных растет потребность в автоматизации анализа этих данных для принятия обоснованных решений. Специалисты, способные разработать и внедрить автоматизированные системы анализа, будут особенно ценны.
Специалисты по информационной безопасности. Как известно, миром правит тот, кто обладает достоверной информацией. С увеличением объема данных, хранящихся в цифровом формате, возрастает и риск их утечки или потери. Специалисты по IT-безопасности, способные разработать и внедрить меры защиты, чтобы сохранить конфиденциальность и целостность важной информации, будут незаменимы.
ИТ-руководители. Ни одна технология в ближайшие годы не сможет приблизиться к тому, чтобы эффективно управлять ИТ-командами. Как бы это не звучало странно, но хорошие, опытные и талантливые ИТ-руководители – это огромная редкость. Уметь грамотно спланировать работу, распределить задачи, балансировать между требованиями бизнеса и объективными возможностями команды – те составляющие, которые сейчас доступны очень и очень немногим.
Вместо заключения
Есть ли причины разработчикам беспокоится за свое будущее? Я считаю, чем более высококлассным разработчиком вы будете, тем меньше вероятность, что ИИ заберет Ваш хлеб... не в ближайшие 10 лет уж точно.
За последние 60 лет разработка сделала огромный шаг вперед: усложнялось ПО, ускорялись темпы разработки, возникали новые потребности, но людей в ИТ индустрии становилось только больше. Нет оснований полагать, что новая революция в разработке ПО пройдет по другому сценарию.
Мне нравится пример из мира шахмат: компьютерные программы постепенно побеждали лучших шахматистов мира. Но если взять в одну команду лучшего шахматиста и компьютер, то с таким тандемом справится или играть на равных практически не реально. Вероятнее всего, именно в направлении такого же тандема сейчас будут разрабатываться современные средства искусственного интеллекта для помощи разработчикам.
Хочу сказать начинающим специалистам и тем, кто задумывается над переходом в ИТ: выбирая направление, не стоит ориентироваться только на заработные платы или престиж, выбирайте то, что вам по душе. Если Вы в качестве профессии выберете дело, которое Вам не нравится, добиться успеха будет крайне тяжело. За более чем 15 лет моей карьеры в ИТ я точно поняла, что успех неизбежно приходит к тем, кто умеет трудиться, вкладывает в работу душу и любит свое дело!
Комментарии (191)
webhamster
21.11.2024 07:13Как думаете, многие ли программисты сейчас знают такие понятия, как поиск пузырьком?
Сортировка. Сортировка пузырьком.
Zayana89 Автор
21.11.2024 07:13Конечно! Видите, так давно не пользовалась этим термином, что допустила ошибку))
NeoNN
21.11.2024 07:13Раньше ее в школе изучали на информатике, в 9 классе, наряду со схемой Горнера. Разве сейчас не так? Любой
программистшкольник-старшеклассник должен знать такую базу историческую. Странные в тексте примеры.Iknwpwd
21.11.2024 07:13Да так и есть, просто автор невывез
webhamster
21.11.2024 07:13Но мы же знаем, что и такая дичь бывает:
Разбираясь в появившемся год назад проприетарном коде Qualcomm Technologies для Android, он обнаружил, что неизвестный программист решил в production-коде использовать сортировку пузырьком для того, чтобы найти максимум в массиве.
https://habr.com/ru/articles/333782/
Надеюсь, что в Гринатоме, конечно же, таких специалистов нет.
Skyguardians
21.11.2024 07:13Раньше не во всех школах была информатика, к сожалению.
Newbilius
21.11.2024 07:13А даже когда и была - порой на уровне "вот вам
ВордЛексикон и Norton Commander, ну и хватит, пожалуй".Cruz_Castillo
21.11.2024 07:13Электроника MC 0511, где-то ДВК. Писюки из-за бугра - уже потом...
DennisP
21.11.2024 07:13у меня в школе в начале 90-х был Поиск-2
ioannes
21.11.2024 07:13На информатике БК-001ш, из программ только инетпретатор бейсика.
unreal_undead2
21.11.2024 07:13"ш" ещё ничего по сравнению с обычным 0010 с фокалом и мембранной клавиатурой.
un1t
21.11.2024 07:13еще лет 15 назад, в различных системах сортировку приходилось реализовывать самостоятельно
Это в каких таких системах? Программирую с 2004, что-то ни разу не приходилось сортировку реализовывать. Может не 15, а 30 или больше.
saipr
21.11.2024 07:13Когда с округлением разобрались, то надо было разобраться с механизмом сортировки списка членов кассы. Ничего другого кроме сортировки методом слияния, имея в своем распоряжении 4К ОЗУ (оперативное запоминающее устройство), перфокарты и магнитные ленты, придумать было нельзя.
Это было в 1977 году!
Zayana89 Автор
21.11.2024 07:13Может помните ещё такие языки программирования как Pascal или ранние версии Delphi. Вот там точно приходилось самой реализовывать))
un1t
21.11.2024 07:13Паскаль помню и Дельфи тоже. Но реальное программирование у меня начиналось с python и php. Неужели в Дельфи не было сортировки?
mvv-rus
21.11.2024 07:13Была, конечно. Но - для объектов (наследников TObject), а они размещались в динамической памяти (куче, по нынешнему). А если хотелось осортировать массив записей (record, аналог struct) свежеиспеченного типа, то надо было это делать самому.
У меня в те далекие годы где-то раз полгода возникала потребность один раз сделать отсортированный список из десятка-другого каких-нибудь записей, чтобы потом много раз искать по нему бинарным поиском. И каждый очередной раз я писал (точнее - копировал и правил) этот код (правда там были простые вставки, а не пузырек). И очень завидовал тем, кому было разрешено использовать C++: там под это дело уже тогда были template и STL, и я про это знал (но не не знал, что многим из плюсовиков суждено было быть покусанными Александреску, если бы знал - меня бы это утешило).Starkom
21.11.2024 07:13Да у всех на дискетке лежал какой-нибудь MyUtils.pas, где сортировка уже была написана.
Qlavrt
21.11.2024 07:13Справедливости ради, с самого начала сортировка сразу была в Делфи в базовом классе TList - метод Sort, который использовал быструю сортировку элементов списка, вызывая функцию сравнения в этом же классе (или переопределенную в его потомках, например TStringList). Стандартных библиотечных сортировок обычного массива не было, потому что изначально в синтаксисе Делфи не было дженериков и пришлось бы авторам этой среды разработки делать функции для всех вариантов типов элементов массива. И, по моему мнению, они и не требовались, потому что Делфи изначально задумывалась и проектировалась как среда ускоренной разработки пользовательских приложений, а не для написания драйверов, микросервисов бэкэнда, движков баз данных и т.п. И упомянутый TList.Sort() решал задачу сортировки во всех списках элементов в компонентах библиотеки VCL, и любой свой список, созданный на основе TList, разработчик также мог отсортировать.
Voland69
21.11.2024 07:13Приходилось в продуктовом коде потому что нет библиотечной функции или потому что писали лабу по теме "сортировка данных" и за вызов qsort() зачет не ставили?)
Потому что популярные алгоритмы сортировок известны, реализованы, отлажены и положены в библиотеки вот уже лет 50 как.
un1t
21.11.2024 07:13Я помню на плюсах собеседовался, меня попросили напсать стэк.
Ну я и написал #include <stack>
Но конечно же они хотели, чтобы я реализовал это руками. И я даже что-то там написал. Возмжоно оно не компилилось, но наборосок был в нужном направлении.
В итоге меня взяли. Я открыл их код и увидел, что они нигде не используют библиотечные функции, а все пишут руками. Код не выносится в функции, а просто копипастится. Я спросил, почему они не используют std, они сказал, что там якобы баги. А в их говнокоде конечно багов не было. В итоге я сказал, что не собираюсь с этим работать и ушел.
venanen
21.11.2024 07:13Это был мой препод, судя по всему. У него прямо лицо скашивало, когда я вместо того, что три часа рисовать модельку и посадочное микрухи брал готовые библиотеки, и когда вместо убогого ручного управления юартом на слипах просто взял готовую библиотеку. Он каждый раз говорил, что так делать нельзя, а вдруг там баги, как их чинить - и ведь правда думал, что он напишет менее забагованный код и понятный код, чем стандартная библиотека, которой уже больше 10 лет, которая покрыта тестами и имеет кучу звезд на гитхабе. А дальше так же как у вас - код копипастился, переменные односимвольные, комментариев нет, куча магических констант.
Fragster
21.11.2024 07:13Не-не-не. В обучении - надо все самому сделать один раз. Чтобы понимать. Потом уже библиотеки не только можно, но и нужно использовать. Но в первый раз - самому.
venanen
21.11.2024 07:13Разумеется первые разы самому. Если сам не понимаешь - тут библиотеки не очень помогут. Это было уже сильно после того, как я это все делал сам - и такое было почти везде. Автотрассировщики, библиотеки компонентов и моделей, STD и еще куча всего - была под запретом, потому что сам препод, будучи практикующим разработчиком, их никогда не использовал.
powerman
21.11.2024 07:13Очевидно, что Ваш препод перегибал. Избегать вообще всех библиотек по абстрактным причинам - безумие. Тем не менее, одна из Go-шных "поговорок" от Роба Пайка: A little copying is better than a little dependency. Затаскивать в проект библиотеку на каждую мелочь просто потому, что её уже кто-то где-то реализовал - тоже идея очень так себе.
Hermion_Joya
21.11.2024 07:13ух, какие воспоминания вы всколыхнули! ну кстати в университете 10-13 лет назад меня обучали именно этим двум языкам, специалистов по ООП и более сложным вещам не везде хватало.
HemulGM
21.11.2024 07:13Буд-то это невероятно сложный алгоритм в десятки строк кода.
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;
Но важнее, просто понимать принцип. Потому как уже давно сортировка есть и для массивов и для обобщенных списков.
kasthack_phoenix
21.11.2024 07:13Может помните ещё такие языки программирования как Pascal
Первый релиз Pascal вышел 54 года назад.
Если мы посмотрим чуть ближе, то во всех стандартных библиотеках sort есть с первого релиза. Например, .NET 1.1(2002, 22 года назад), JavaScript в виде стандарта ECMA-262 первой версии(1997, 27 лет назад), Java 1.2(1998, 26 лет назад). На самом деле, можно заглянуть и на пятьдесят лет назад. Так, qsort доступен в стандартной библиотеке C аж 1972-го года, т.е. более полувека назад.
Время писать сортировки руками давно прошло.
shushara4241
21.11.2024 07:13Но для собеседований знать как реализовать все равно обязаны. Может через 10000 лет понадобится, кто знает... /s
Viacheslav01
21.11.2024 07:13А мне приходилось и не раз, когда сортировка из либы работает не так как хочется на именно твоих данных.
Mizar91
21.11.2024 07:13Вы не поверите, но многие все еще программируют для систем с низкой производительностью и многое должны делать руками, а не готовыми библиотеками с миллионом зависимостей!
un1t
21.11.2024 07:13Даже для таких систем не имеет смысла спрашивать эти сортировки на память, это же просто справочная информация, гуглится за 5 минут. А сейчас и вовсе генерируется ИИ за 5 секунд.
un1t
21.11.2024 07:13Я полагаю, что ИИ заменит программистов. Возможно программисты остануться, но работа их будет совершенно другой. Грубо говоря раньше в перфокартах дырки делали, а сейчас программируют на языках высокого уровня. Возможно программисты будут делать, то что сейчас делают аналитики - подготавливать текстовое описание для ИИ. А сгенеренный код мало кто сможет читать, примерно как сейчас мало кто понимает ассемблер.
Я сейчас склоняюсь в версии, что из современных профессий ничего не останется. Будут ли какие-то другие профессии не известно. На какую профессию не взгляни, есть потенциал вытеснения ее ИИ и роботизацией.
Flux
21.11.2024 07:13Сейчас мало кто понимает ассемблер потому что его понимать не надо, но он тем не менее очень лёгкий для освоения.
Сгенерированный LLM код понимать надо, потому что гарантий того что он правильно транслирует бизнес требования в код нет, в отличии от гарантий того что компилятор правильно транслирует условный С++ в ассемблер, которые есть.
Из этого следует фатальный недостаток современной кодогенерации - в проектах которые должны работать правильно она не уменьшает, а увеличивает когнитивную нагрузку на разработчика.semmaxim
21.11.2024 07:13Не факт. Лет через 5 код понимать уже будет не нужно. Ты просто тестируешь сгенерированную программу и если она не соответствует требованиям или проявляются баги, то не лезешь в сам код, а просто говоришь LLM что у неё не так и она генерирует новый код. В который ты опять не лезешь, а просто проверяешь работу.
terek_ambrosovich
21.11.2024 07:13Мне кажется, вы просто не работали с критическими, высоконагруженными системами, при работе над которыми за такие итерации, и без гарантированного результата с вас голову снимут и обратно уже не прикрутят. Реальные системы не могут быть покрыты тестами на 100%, иначе вам для тестов потребуется ещё одна параллельная вселенная, где квантовый ИИ будет бесконечно гонять свои итерации.
Во многих областях требуется детерминизм и конечная ответственность, упёртая в юридический субъект, и если LLM таковым не станет, то лично моей работе ничего не угрожает. Болванчики-операторы же, который смогут только кивать на ИИ с невнятным бормотанием "не виноватая я, оно как-то само там унутре, где у ней неонка" не нужны уже сейчас.
semmaxim
21.11.2024 07:13Это то понятно и само собой будут критические и особые области, где итерационный подход неприемлем. Но много ли таких систем? Как бы сейчас тоже нужны разработчики на COBOL-е, но в мизерном количестве.
Wesha
21.11.2024 07:13вы просто не работали с критическими, высоконагруженными системами, при работе над которыми за такие итерации, и без гарантированного результата с вас голову снимут и обратно уже не прикрутят.
"Если ты не работаешь над системой, то система работает над тобой!"
pes_loxmaty
21.11.2024 07:13кажется это стимулирует LLMку просто писать новый if на новые тестовые данные )))
Flux
21.11.2024 07:13Написание исчерпывающего набора тестов проверяющих все крайние случаи плюс быстродействие сложнее чем написание самого кода.
un1t
21.11.2024 07:13Есть довольно много областей где пофигу как работает код и если он время от времени падает, то ничего страшного. Всякие одноразовые скрипты, парсеры и т.п.
Обычная кодогенерация мне тоже не нравиться. Но тут дело другое, ИИ может не только генерировать код но и менять его по запросу.
Mizar91
21.11.2024 07:13Вы для начала машинистов в поездах замените хотя бы, там ровно две опции всего - ехать на указанной скорости и тормозить, один входной канал управления - зеленый/красный семафор. Но что-то пока не выходит.
piton_nsk
21.11.2024 07:13один входной канал управления - зеленый/красный семафор.
Семафор и светофор вещи все-таки разные. Железнодорожного светофоры бывают разные, в т.ч. желтые, синие, белые, а еще бывают комбинации огней. Система сильно сложнее автомобильных светофоров. Это не считая всего прочего. Вот метро без машинистов уже много где и довольно давно существует.
Mizar91
21.11.2024 07:13Три цвета - это сильно сложнее двух?
piton_nsk
21.11.2024 07:13Ну вообще не три, а больше. Но суть в том, что "один входной канал управления - зеленый/красный семафор" сильно не так.
Mizar91
21.11.2024 07:13Посмотрел на систему сигналов для железнодорожного транспорта Германии - и близко нет ни белых, ни синих, так что на 100% уверен, что можно обойтись и без них.
piton_nsk
21.11.2024 07:13А в Норвегии пять цветов, и сигналы не только светофором передаются. Вам в который раз указывают, что дело устроено сильно сложнее "зеленый/красный". А там, где дело проще (метро) автоматические поезда уже ездят который год. Но вы упорствуете - все просто! Если все просто, почему не сделали, вот как вы сами думаете?
Посмотрел на систему сигналов для железнодорожного транспорта Германии - и близко нет ни белых, ни синих
Где вы смотрели? Вот даже банально в википедии есть желтый свет "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, в Японии есть желтый и везде плюс минус одинаково - двойные, мигающие, всякие сочетания. И куча еще всякой другой разметки.
Mizar91
21.11.2024 07:13Не сделали явно не потому, что эти сигналы сложно распознать, а потому, что есть определенные процедуры сертификации, и обойти их, ссылаясь на какие-то "суперпроверенные" алгоритмы ИИ не выйдет, никто такое не пропустит в тираж, потому что на миллионе ситуаций система сработает, а на одной даст петуха. ИИ - это лотерея, и никто в нее играть в таких вещах не собирается.
MaFrance351
21.11.2024 07:13В метро наоборот сложнее - в рельсовую цепь подаётся частота, кодирующая разрешённую скорость. Плюс ещё стоят стационарные устройства (конкретно в Питере, где используется система автоведения ПАКСД-М, это расположенные на станции и у въезда на неё рейки, при обнаружении которых датчиками на составе запускается соответствующая программа торможения). На ЖД же используются только сигналы светофора и записанная в память прибора безопасности электронная карта.
piton_nsk
21.11.2024 07:13В метро наоборот сложнее
Я имел в виду все в целом, не просто езду по рельсам. В метро все-таки движение более предсказуемо, нет переездов, нет осадков (хотя где-то может быть наземная часть), человек на путях может оказаться только на станции, составы одинаковые. Расстояние между станциями маленькое, если даже что-то сломается, то дойти пешком до поезда дело пяти минут. Опять же железка это не только поезда которые ездят из пункта А в пункт Б, это еще сортировка, погрузка/разгрузка и еще всякое. Но тут я думаю вы знаете это лучше меня)
Еще остается экономический аспект - сколько зарплата машиниста/помощника составляет от затрат на перевозку грузов. Повысится ли безопасность. Есть ли смысл внедрять полностью автономный ИИ (которого пока нет)? А всякие помогайки и автоматика существуют давно и все это не стоит на месте.
DMGarikk
21.11.2024 07:13проще некуда..я когда ЖД симуляторами увлекался..ох орал с такого, капец там лампочек и сочетаний
наши красный-желтый-зеленый-белый-зеленаяполоса и мигающие сочетания выглядят горааздо проще
===
вообще на всех ЖД мира довольно заумные сочетания светофоров...просто так там без поллитры неразобраться точно, в РФ далеко не самая сложная вариация этой штуки
Mizar91
21.11.2024 07:13Есть-то они есть, но абсолютно точно они не стоят на каждом перегоне. И, сильно подозреваю, для автоматизации они не очень и нужны.
DMGarikk
21.11.2024 07:13желтые, синие, белые, а еще бывают комбинации огней.
только они нужны машинистам-человекам
если все 100% локомотивов на ЖД станут автоматическими, потребность в таких заумных системах пропадет
piton_nsk
21.11.2024 07:13Ну когда-нибудь может быть и будет. Надо еще остальной транспорт полностью автоматическим сделать, чтобы дурачки всякие на переезды не лезли когда там поезд едет)
DMGarikk
21.11.2024 07:13в данном случае переезды и т.п. практически никак не влияют на то кто там за контроллером поезда сидит
машинист никаких особых действий не может предпринять сверх тех что может предпринять ИИ, это не авто рулить нельзя...
там регламент тупой - видишь препятствие - тормозишь, всё. это может делать и автомат.
Wesha
21.11.2024 07:13Надо еще остальной транспорт полностью автоматическим сделать
И оленей, и лосей.
MaFrance351
21.11.2024 07:13Неа. Управление поездом сильно сложнее, чем просто "газовать/тормозить".
Была у нас такая штука как УСАВПП, в общем-то, позволявшая делать многое без участия машиниста. Можно было задать ей программу, а она бы довела поезд до станции с соблюдением ограничений скорости и профиля торможения.
Вот только машинист (на пару с помощником) - он не только кнопки жмякает и контроллером щёлкает. Выход из нештатных ситуаций (в отличие от метро, где при правильном обслуживании условия ну почти идеальные), иногда исправление неполадок и ещё много чего - это всё тоже его обязанности. И никакой ИИ в ближайшие годы туда не поставят - если вдруг модель, пусть даже и сто раз проверенная, заглючит, то поезд взбесится.
zabelinleo
21.11.2024 07:13ИИ научился играть лучше в шахматы, но от этого люди в шахматы не перестали играть.
Я наблюдаю столько проблем и нехватки кадров во всех сферах. Половина интернет-приложений работает с тормозами или серьезными ошибками в моем телефоне. Почитаете отзывы про мегамаркет от сбера. В офлайн магазинах нет продавцов. В днс в моем районе давно работает один(!) человек на кассе. А это магазин витрина размером с пятерочку.
Что я хочу этим сказать? Мы думаем о 2035 и пока корабли бороздят просторы вселенной... Что ии скоро все порешает... о люди-руководители... тут земных проблем выше крыши. Наймите хоть кого-нибудь для их решения!
vedenin1980
21.11.2024 07:13ИИ научился играть лучше в шахматы, но от этого люди в шахматы не перестали играть.
Вообще, определенный спад интереса к шахматам после создания ИИ был. Сейчас всякие онлайн соревнования не очень имеют смысл, если любой может жульничать, получая подсказки со смартфона, который играет не хуже гроссмейстера. Да и переодически возникают скандалы, что кто-то жульничает с компьютером на соревнованиях.
Spaceoddity
21.11.2024 07:13Да причём здесь ИИ? Дип Блю с трудом (и со скандалами) выиграл матч у Каспарова ещё в 1997-м.
vedenin1980
21.11.2024 07:13Вот имено, Дип Блю с трудом выиграл в 97, а сейчас чуть ли не обычный смартфон может выиграть у чемпиона мира. Если противник может легко жульничать - интерес к игре теряется.
ManulVRN
21.11.2024 07:13Спад интереса к шахматам совпал по времени с появлением программ, способных обыграть чемпиона мира, но вызван был не только этим. В 60-80-е годы шахматы были одной из площадок политического противостояния. Фишер! Отщепенец и перебежчик Корчной против Карпова! Шахматисты - самый умные люди, а самый умный человек должен жить где? В самом передовом обществе (СССР) или в самом демократическом (США). А потом шахматы превратились просто в игру.
AllexIn
21.11.2024 07:13Машины появились, но люди не перестали возить грузы на лошадях... Хотя постойте... Люди не перестали играть в шахматы потому что хотят. Бессмысленно обсуждать игру в контексте автоматизации.
rukhi7
21.11.2024 07:13ИИ научился играть лучше в шахматы
там вроде не ИИ, а алгоритм написали, он же на простом десктопе работает, играет как гросмейстер.
Spaceoddity
21.11.2024 07:13Алгоритм давно известен - это элементарный перебор позиций на несколько ходов вперёд. Быстродействие процессоров подтянулось, что позволило полностью просчитывать партии. Современный Стокфиш (популярный шахматный движок) на смартфоне порвёт Магнуса Карлсена в десяти играх из десяти без каких либо шансов на победу для последнего))
Это всё довольно удручающе повлияло, разумеется, на шахматы как на вид спорта. Теперь, когда проходит матч за шахматную корону, складывается ощущение что в шахматы не умеют играть лишь те двое за доской - весь остальной мир смотрит обсуждение партии с анализом и оценкой каждого хода от шахматных движков))
Уже очень трудно становится оценить красоту того или иного хода - движок же сразу даёт весь расклад. Ход необычный, но бесперспективный и т.п.
KvanTTT
21.11.2024 07:13Алгоритм давно известен - это элементарный перебор позиций на несколько ходов вперёд.
Это не элементарный перебор, потому что дерево растёт экспоненциально - нужно быстро и хорошо выбирать нужные ходы на каждом шаге. Особенно это актуально для таких игр как Го, в которых ИИ значительно продвинулся именно благодаря нейросетями. И стокфиш после этого тоже продвинулся.
Быстродействие процессоров подтянулось, что позволило полностью просчитывать партии.
Партии до конца не просчитаны в шахматах и скорей всего не будут - количество комбинаций слишком огромное. Подтянулись не только количественные изменения, но и качественные.
Fedorkov
21.11.2024 07:13Алгоритм давно известен - это элементарный перебор позиций на несколько ходов вперёд.
Элементарный перебор называется минимакс. Из‑за экспоненциальной сложности он вчистую проигрывает разным эвристическим алгоритмам отсечения, использующимся в шахматных движках аж с 1956 года.
Быстродействие процессоров подтянулось, что позволило полностью просчитывать партии.
Полный перебор невозможен — опять же из‑за экспоненциальной сложности. Все движки оценивают благоприятность позиции, которая появится через несколько ходов. Классические движки (типа Stockfish до 11 версии) оценивали позицию по определённому алгоритму, но в районе 2019–2020 годов движки с нейронной оценкой начали выносить классические движки вперёд ногами.
Главный фактор, повлиявший на профессиональные шахматы — это то, что в оценке партий и позиций гораздо меньшую роль стал играть авторитет топов. Раньше Каспаров мог пойти конём и сказать «я чемпион, я так вижу», а десятки мастеров потом тратили дни и недели, чтобы понять, насколько глубок был его замысел. А сейчас — «Kasparov is almost as good at playing chess as my iPhone».
rukhi7
21.11.2024 07:13«Kasparov is almost as good at playing chess as my iPhone»
вот-вот. Потому что, как минимум, у любого к-аспарова (с маленькой как обобщение) есть шанс зевнуть, а машина зевать не умеет. Машина также не может встать не с той ноги, поругаться с супругом, ... и по этому быть не в форме.
Fedorkov
21.11.2024 07:13Дело вовсе не в форме. У Карлсена на пике формы десять лет назад был рейтинг 2882; у Stockfish сейчас (на стареньком железе) — 3642. Значит, нынешний Stockfish победил бы тогдашнего Карлсона с вероятностью 99% (по этой формуле). Обыграл бы вчистую, на классе.
saag
21.11.2024 07:13Из описания вакансии с какого-то работного сайта: "...наличие импланта будет предпочтительным". Ну как у Андрея Ливадного в его фантастике.
vedenin1980
21.11.2024 07:13Скорее Геном Лукьяненко. Сделали ген.модификацию в детстве - работаешь программистом , нет - идешь в дворники.
REPISOT
21.11.2024 07:13Нет. Дворники в "Геноме" тоже были генно-модифицированные.
vedenin1980
21.11.2024 07:13Вряд ли все. Там где жили натуралы (так называли немодифицированных) вероятно были простые дворники. Работяги-натуралы там были, значит были и простые профессии.
TerryChan2003
21.11.2024 07:13С текущей тенденцией нужны будут люди которые из палки и камня могут копья делать
KvanTTT
21.11.2024 07:13Мне нравится пример из мира шахмат: компьютерные программы постепенно побеждали лучших шахматистов мира. Но если взять в одну команду лучшего шахматиста и компьютер, то с таким тандемом справится или играть на равных практически не реально.
А мне не нравится этот пример. Современные программы и так побеждают любых шахматистов и без помощи ассистента. Т.е. человек тут скорей мешает, чем помогает. С натяжкой подходит игра Го (Бадук), потому что там намного больше комбинаций, и она более абстрактная.
trig-ger
21.11.2024 07:13Нет оснований полагать, что новая революция в разработке ПО пройдет по другому сценарию.
Не соглашусь, потому что до сих пор не было в истории аналогов появления сильного ИИ, или хотя бы сильного в области разработки программ - т.е. эффективной автоматизации мыслительной деятельности (а потенциально и мыслительной, и физической).
До сих пор лишь человек мог заниматься разработкой ПО. Сложность задач и, соответственно, самого ПО, росла, но, поскольку программируют люди, то их требовалось всё больше.
Когда же ИИ окажется способен сам разрабатывать ПО, по самым общим выданным ему техзаданиям, или даже вербальному описанию проблемы (и ожидаемо дешевле людей), то увеличения числа задействованных человеческих работников не будет необходимым, т.к. ИИ можно множить, сколько потребуется (и сколько хватит мощности, но вряд ли это будет ограничением надолго), а небольшое "количество" людей будут формулировать ему проблемы для решения.
Разумеется, это тоже предположение, но оно кажется более вероятным.
killyself
21.11.2024 07:13Такую ставку мало смысла рассматривать, потому что если появится достаточно сильный ИИ чтобы по высокоуровневым требованиям выстраивать системы в миллионы строк, и тысяч взаимодействующих модулей - у человечества будут проблемы намного больше, чем ненужность разработчиков. А с тем что есть сейчас, даже с учетом масштабирования - просто получим снижение стоимости ПО и по тому же маршруту пойдём как уже проходили не раз - по крайней мере еще лет на 25.
paluke
21.11.2024 07:13Что-то разрабатывать по самому общему описанию? Ну да, конечно. Но только всё, что может быть понято неправильно, будет понято неправильно. А чтобы не допускать никакого недопонимания, надо все максимально подробно расписать на специальном языке, не допускающем неоднозначных толкований.
trig-ger
21.11.2024 07:13Правильное понимание вероятно можно обеспечить контекстом, заранее заложенным в ИИ (fine tune или более какой там будет продвинутый будущий аналог) направлением работы компании, примеры предыдущих заказов и т.д., чтобы снизить число возможных вариантов при недосказанности. В конце концов, человек-работник же тоже может понимать якобы с полуслова, а на самом деле опираясь на уже отработанные в компании хорошие решения для реализации деталей большой задачи.
Речь про то, что нет причин, что нельзя научить ИИ делать всё, что может в разработке делать человек. Даже встречаться с заказчиками (пусть и не физически пока) для формирования задач на разработку. Разве что фуршет ИИ ниасилит )
Source
21.11.2024 07:13А чтобы не допускать никакого недопонимания, надо все максимально подробно расписать на специальном языке, не допускающем неоднозначных толкований.
И вот мы получили определение термина "программирование" xD
Source
21.11.2024 07:13Так нет пока никакого ИИ. А если он когда-нибудь и появится, то он уже точно не будет разрабатывать программы на тех языках, на которых люди программируют. Это тупо неэффективно с точки зрения компьютера.
Aniro
21.11.2024 07:13Такие предсказания не имеют смысла. Полная замена инженера на AI невозможна без достижения полноценного AGI, способного находить решения новых, несуществующих в настоящий момент задач. Если же вы ставите на скорую возможность появления такого AGI - значит вы неизбежно ставите на скорую технологическую сингулярность. Сложно предположить причину, по которой этот AGI окажется фундаментально неспособен улучшать себя.
un1t
21.11.2024 07:13ИИ сейчас программирует лучше чем некоторые мои бывшие коллеги. Это не шутка. Так что вопрос когда он заменит остальных лишь вопрос времени. Полагаю, что это произойдет быстрее чем переход от кнопочных телефонов в голосовому вводу.
Aniro
21.11.2024 07:13Конечно. o1_preview хорош. А DeepSeek R1 показывает что даже маленькая модель может решать letcode hard. Но решать принципиально новые задачи они не могут. Скорее всего - пока не могут.
Полноценной агентности, даже на задачах кодинга тоже нет - даже если дать модели возможность работать с файлами, запускать отладку и т.д. она пока не справляется с комплексными задачами.
Но это как раз не отменяет моих тезисов - если (или когда) AI это сможет - здраствуй сингулярность, ты уже рядом. Так что разговоры об замене програмистов просто не имеют смысла. Когда заменят програмистов - мы будем жить уже в совсем другом мире, который пока не можем себе представить.
Единственные варианты когда сингулярность не наступает в обозримом будущем - это если Ян Ле Кун окажется прав и AGI на трансформерах принципиально невозможен или исследования в области почему-то резко прекратятся.AlekseyPraskovin
21.11.2024 07:13Но решать принципиально новые задачи они не могут
Ну конечно же... Ведь 99% разработчиков каждый день только и делают, что решают принципиально новые задачи. Принципиально новый круд. Принципиально новая формочка. И разумеется принципиально новое перекладывание принципиально нового json.
tolyanski
21.11.2024 07:13Принципиально новомодное перекладывание принципиально новых proto файлов для grpc )
killyself
21.11.2024 07:13Большинство разработчиков каждый день перекладывают требования с непонятного на понятный язык, потом с понятного на более понятный, и так пока не дойдёт до понятного компилятору (от уровня разработчика зависит на каком уровне понятности он начинает перекладывание и на каком заканчивает). Нынешние модели умеют в последние 1-2 шага - можно заменять всех джунов конечно, но джунов заменять нельзя по другим причинам. А когда будут модели которые умеют заменять сеньоров - уже совсем другой мир наступит.
squaremirrow
21.11.2024 07:13Нынешние модели умеют в последние 1-2 шага
Вы уверены? Пробовали спрашивать у ChatGPT вопросы про архитектуру? Уверен, что он справится достаточно хорошо. Обернуть чат в агента, загрузить в него всю информацию о компании и текущей архитектуре, и заставить выяснять все требования к очередной фиче - кажется решаемой задачей.
tolyanski
21.11.2024 07:13Смотря что вы подразумеваете под "архитектурой". Если сборник определений паттернов из книжек по микросервисам - то справится.
Если же понимание полной специфики бизнеса, горящих сроков, чтение между строк, особенностей характера стейкхолдеров, причуды и эго руководства, а также учитывание множества нюансов и ответственность за принятые решения, да еще и обоснование почему так, а не так - то кажется тут несколько сложнее. Тут стоит дождаться "моделей которые умеют заменять сеньоров" и поглядеть на наступивший другой мир.
redfoxxy12
21.11.2024 07:13Если же вы ставите на скорую возможность появления такого AGI - значит вы неизбежно ставите на скорую технологическую сингулярность.
А мне это все фантазии напоминает.
1) Кто сказал что "уровень интеллекта" не ограничен и ИИ сможет без конца "умнеть", улучшая себя? Возможно, предел интеллектуальных способностей не так уж далек от ученого человека, и "богом" АГИ не станет. Просто будет невероятно быстро соображать и легко анализировать бигдату. Ну ок.2) На постоянное самоулучшение очевидно нужны все возрастающие ресурсы - как материальные, так и энергетические. Которые вполне конечны, как минимум в пределах нашей досягаемости.
3) Определенно существует набор физических ограничений Вселенной. Каким бы умным ни был интеллект, он не сможет делать что-то, если это что-то запрещено законами Вселенной, в которой он обитает. Например летать быстрее света, получать материю из ниоткуда, изобретать телепортатор, и т.д.Aniro
21.11.2024 07:13Есть некоторая вероятность что богом не станет - и это было бы прекрасно. Но этого и не нужно.
Для сингулярности хватит масштабирования количеством - сейчас у нас ограниченное количество действительно хороших инженеров и ученых, которые иногда спят, отвлекаются на личную жизнь, ленятся... Умножте их количество на очень большое число и работу 24х7.
Wesha
21.11.2024 07:13Сложно предположить причину, по которой этот AGI окажется фундаментально неспособен улучшать себя.
Рубильник?
Daemonis
21.11.2024 07:13мы не будем удивляться, когда помощник разработчика предложит вставить кусок кода, написанный другим программистом месяц назад, похожий по смыслу той задачи, которую мы сейчас реализуем.
То есть, вместо переиспользования кода будем плодить дупликацию? Ну, в принципе, я не удивлюсь, да :)
NeriaLab
21.11.2024 07:13Когда я вижу вот такие публикации, в которых с лкгкостью манипулируют словами "искусственный интеллект", то сразу появляется тошнота. Может хватает хайповать? Может сказать правду что нет никакого ИИ?
un1t
21.11.2024 07:13Слушал одно интервью про ИИ. Там был интересный момент. Говорят ИИ нет, ведь он не понимает, что делает. Но штука которая понимает, что происходит называется сознание и она не является безусловной частью интеллекта. Она появилась в процессе эволюции, т.к. давала преимущества. Соответственно ИИ это и есть искусственный интеллект, а появится ли у него сознание это уже другой вопрос.
zodchiy
21.11.2024 07:13В будущем будут востребованы программисты квантовых компьютеров. А потом еще каких-то других компьютеров, а потом еще каких-то.
killyself
21.11.2024 07:13С квантовыми компьютерами к сожалению пока что не идёт. Получается эффективно решать только очень узкий класс задач, и скорее всего кардинальных изменений в этом плане не будет. Даже если получится собирать достаточно масштабные системы за не-триллиард денег, они будут использоваться для конкретных задач, связанных с вычислениями и перебором больших массивов данных, как серверы - а большинство рутинных задач останутся на обычных транзисторных ЭВМ
Source
21.11.2024 07:13Ну вот пусть ИИ делом наконец-то займётся и создаст дешевую реализацию квантового компьютера для задач общего назначения, а то пока только информационный мусор клепать научился xD
saipr
Полностью согласен с выводом автора. В этом я убедился на собственном опыте, занимаясь разработкой программного обеспечения более чем 55 лет.
wassup666
>Полностью согласен с выводом автора
аффтар - директор одноэсников, ей бы рассуждать про пузырьки и вечное.
Я вот вижу как опенсорс семимильными шагами пожирает пропиетарщину, даже проклятых негрософтов почти сьел. эмбедщину и сервера ещё сильнее пожрал. А теперь задумайся, с чего будет расти потребность в прогерах, если всё больше и больше библиотек уже написаны и под горизонтальное масштабирование допилены. Через 10-15 лет LLM вполне сможет клей и крудошлёпие писать намного дешевле межмешей, а "либы писать" с прочим матаном будет задачей для избранных (штук этак 50-100к на всю планету)
slonpts
Когда появился SQL (1974), все думали, что программисты скоро будут не нужны, т.к. запросы сможет писать любая секретарша. Как много человек, кроме программистов, пишет на SQL в наше время?
Сдается мне, что-то подобное будет и с ИИ в области разработки. Задачи, которые ИИ решает, станут более сложными, и для того, чтобы их женить с реальностью, надо будет вникать в кучу деталей (уже каких-то новых, не обязательно похожих на те, что важны сейчас). И вот этим и будут заниматься разработчики. Просто разработка еще раз изменится, и все
powerman
Для современных программистов SQL - это слишком сложно, они так и норовят вместо того, чтобы его писать, воткнуть какой-нибудь ORM. :-)
General_Failure
ORM - это про удобство написания, отладки и т.д., а не про снижение сложности
Также ORM очень сильно снижает время на разработку, когда могут быть разные СУБД (я как-то участвовал в проекте, где у одних клиентов был MSSQL, у других Oracle).
Ну а ваш комментарий выглядит как "нахер тракторы, деды коней в плуг запрягали".
tolyanski
На одном ЯП, где в целом не принято пользоваться ОРМками, есть в экосистеме одна ОРМка которая позиционирует себя как супер легковесная и вообще идиоматичная со всех сторон.
Решил я ею начать пользоваться в одном проекте. У этой ОРМ заявлен список полезных фич, начал их постепенно внедрять.
Внедрил фичу 1: увидел что как-то она хреново работает. Ну ладно, буду пользоваться остальными фичами, а этой не буду.
Внедрил фичу 2: увидел что она под капотом неявно может творить лютую дичь, и это может навернуть всю СУБД на проде если данных в таблице много. Ну ладно, от фичи 2 отказался, буду пользовать в этой ОРМ все кроме фич 1 и 2.
...
Внедрил фичу N. Ой, ну ее нах. - подумал я, и в итоге от ОРМ остался только query builder.
---
И такой путь мне довелось пройти в экосистеме более чем одного ЯП. Выбирал самые топовые ORM и спотыкался немножко.
pes_loxmaty
Понятное дело, ОРМ - не серебряная пуля.
Но если БД изначально спроектирована хорошо, то скорей всего не придется писать 7этажных замысловатых запросов и тут ОРМ справится. Не идеально но хорошо.
Зато она даст возможность купить обезьянку-программиста подешевле, и легче его заменить на другого. А еще, если ею правильно пользоваться, то позволит относительно просто перескочить на другую СУБД, потому что настало импортозамещение...
Ну а если вам нужно выжать максимальную производительность из кривой косой легаси БД, где на протяжении десятилетий десятки команд городили кто во что горазд, то да скорей всего придется писать запросы вручную.
rpc1
Аналитики у нас писали SQL, которые не знают ни одного ЯП. А когда работал в банке, у нас даже некоторые бухгалтера просили доступ к консоли SQL и писали запросы. Сейчас на работе продакты иногда пользуются
Cryvage
Оно не то чтобы сложно, оно просто избыточно и вообще является не тем, что в большинстве случаев нужно программисту. SQL это язык программирования, пусть и специализированный. Но программист и так уже пишет программу на языке программирования и само собой, не на SQL, потому что помимо запросов к БД в программе должно быть ещё куча всего. Ну и зачем ему язык программирования внутри языка программирования (yo_dawg.jpg)? Для программы на условном JavaScript, код на SQL - это просто строка. Зачем это программисту? Ну давайте в код на JavaScript ещё воткнём код на Python в виде строки и будем его каким-нибудь eval'ом выполнять. Или, зачем далеко ходить, можно часть кода на том же JavaScript хранить в строке и выполнять eval'ом. Это прям вообще "best practice", за такой код сразу сеньёра дают. Ну а если серьёзно, то чем вот эти вот строчки SQL в программе лучше любого другого кода, хранимого в строке и выполняемого eval'ом? Да ничем не лучше. Потому и используется либо ORM, либо хотя бы построитель запросов. Но на практике, разница только в объёме дополнительного функционала, а основная идея одинаковая - с самим SQL мы не работаем, а работаем с сущностями на нашем основном языке программирования. SQL предназначен либо для тех, кто напрямую базе запросы шлёт, например из консоли, либо тем кто пишет хранимые процедуры, т.к. они хоть и пишутся не на чистом SQL, но SQL является подмножеством того языка, на котором написана процедура, и там запрос это не просто строка, а полноценная часть кода.
tolyanski
Программисту нужно делать так чтоб не навернуть БД на проде, когда ОРМ любезно начинает творить дичь.
кхм, чтобы использовать построитель запросов, надо как минимум знать язык этих самых запросов. То есть надо знать SQL
затем, чтобы контролировать что происходит ваще
DMGarikk
как ни странно, но довольно много менеджеров, есть даже софт у которых основной интерфейс - это SQL консоль, встречается в банковской сфере и вообще где большие объемы данных...например отчеты о продажах, анализы всяких рынков, акций и т.п.
PanDubls
В банках, скажем, почти все в бэк-офисе. Курс по SQL есть во всех уважающих себя экономических университетах. Он очень односторонний обычно, могут просто не давать никакой инфы про создание и администрирование БД, только запросы select.
killyself
Правильный вопрос здесь - как много человек пишет на SQL вместо программистов
Flux
Чёт в голос. Это тот самый опенсорс у которого разработчики практически всех проектов с более чем 10к пользователей сидят на зарплате в очередном редхате или МС?
А, ну всё понятно,
P(token|context)
похоронит нас всех, так же как нас похоронили экспертные системы. Ваше любимое хобби - экстраполяция?ASTRIO
Есть платный корпоративный опен сорс. Их бесплатные версии для мощного тестирования и обкатки на коммунити. Чтобы корпораты были более счастливы.
kozel_rogatiy
Пишу на PHP, про другие языки не знаю и, поэтому, говорить не буду.
В контексте используемого мной языка абсолютно согласен с озвученной позицией - на github есть просто всё, что нам нужно для работы. Очень за редким исключением приходится форкать и допиливать, но 99% работы за нас уже сделали люди с разных концов планеты. Бери и собирай это всё через composer и пиши тривиальную клиентскую логику, оперируя лишь интерфейсами. Ну вот просто не было ещё такого, что бы что-то не найти.
В итоге то, что программист лет 15 назад писал бы минимум полгода, сегодня внедряется за 1 минуту и исправно работает из коробки. Есть решения, которые уже работают так же надежно, как автомат калашникова - там приложили усилия сотни контрибьютеров.
Уже доходит до того, что ты берешь код двух разных библиотек и понимаешь, что они очень похожи, ибо общая грамотность по технологии достигла того предела, что люди пишут почти идентичные решения.
С матаном - может быть, а вот либы с рядовыми задачами пишут вполне обычные люди, а не профессора. И этих либ с каждым днём всё больше.
Wesha
Да у Вас и с русским тоже как-то не задалось...
ASTRIO
Другими словами, если оптимистично:
Будут разработчики ИИ и no code систем. Программисты.
Будут внедренцы. Кто с помощью ИИ будет создавать и обслуживать бизнес процессы. Тоже типа программисты.
И все это даст прирост в эффективности ИТ отрасли.
Вот так ИИ будет вполне полезен человечеству.