Почему программисты не боятся искусственного интеллекта? Потому что им достаточно сказать заказчику: «Объясните компьютеру, что именно вы хотите». Так шутили еще недавно, но теперь такие шутки становятся не такими веселыми, как раньше. Искусственный интеллект, воплощенный в ChatGPT, продолжает совершенствоваться, в то время как IT-сообщество делится на скептиков и энтузиастов. Одни верят, что программистам не нужно меняться, другие думают, что новые языки и подходы в разработке окончательно похоронят ручной кодинг. На недавней дискуссии Artezio мы собрали влиятельных разработчиков и попросили предсказать, как будет меняться программирование в будущем, какие языки обещают быть на волне успеха и как оставаться в тренде.
Посмотреть полную версию дискуссии можно на Youtube-канале Artezio. Подпишись и сможешь принять участие в жарких дискуссиях.
«Мы наблюдаем тенденцию использования языков нового поколения»
Будущее программной разработки сложно представить без новых языков программирования. Об этом говорят многие разработчики, которые делят языки на старые и новые.
Петр Туголуков, корпоративный архитектор Xsolla: «Сейчас мы наблюдаем тенденцию к использованию все большего количества языков нового поколения. Множество компаний различного масштаба переходят на новые Python, Go, Kotlin, а в сфере мобильной разработки - на Swift. Языки C++, C, PHP, Java можно отнести к предыдущему поколению.
В нашей компании также используются приложения на PHP и Go. Мы стремимся разрабатывать новые продукты на Go из-за его эффективности, низкого порога входа и развитой экосистемы, включающей множество пакетов для решения широкого круга задач, что подтверждается огромным количеством репозиториев на GitHub. Предполагаю, что эта тенденция сохранится и в 2024 году.
Нельзя игнорировать влияние всемогущего JavaScript, который используется как на сервисной, так и на клиентской стороне, профессии разработчиков на JavaScript становятся всё более востребованными. Есть и исключения, связанные с разработкой устройств специфического назначения (Интернет вещей, игровые платформы), где использование Go и JavaScript возможно только при особом подходе».
Аналогичная ситуация складывается и в игровой индустрии. Однако, по словам Андрея Карсакова, руководителя разработки Nau Engine, традиционные языки (C++, C#), продолжают оставаться де-факто стандартами в этой области.
«Мы наблюдаем значительный интерес к Python в сфере разработки инструментов для GameDev. Всё больше вспомогательных инструментов создаётся на Python, и у многих игровых движков теперь есть Python API. Кроме того, некоторые энтузиасты в GameDev углубляются в уникальные языки программирования для создания игровых движков, например, Rust, который использовался группой разработчиков для создания игрового движка (Bevy).
Как правило, мы склоняемся к использованию C++, который является установленным стандартом и позволяет гибко работать с различными платформами. Однако мы осознаем тенденцию к появлению множества новых и интересных языков, активно используемых в продакшене. Именно поэтому мы планируем создать систему, позволяющую энтузиастам легко интегрировать языки программирования по их выбору. Это критически важно для удобства разработчиков, ведь мы создаём инструмент именно для них. Мы хотим предоставить разработчикам свободу в выборе языка, а не ограничивать их использованием традиционных, “олдскульных” (C++). Поэтому, хотя наша база и состоит из C++, мы программный интерфейс нашего продукта будет доступен для более широкого спектра языков, в том числе и для новых», — сказал руководитель разработки российского игрового движка Nau Engine.
А вот Илья Стешков, разработчик информационных систем OZON, подтверждает мысль, что в последние три года стало заметно предпочтение Go для новых проектов, благодаря его совместимости с микросервисной архитектурой и удобством при работе со старыми монолитными системами. «По моим наблюдениям, Go сохранит свою популярность в области бэкенд-разработки», - говорит эксперт.
По словам Александра Тырышкина, Head of WMS AliExpress CIS, сейчас увеличивается интерес к JavaScript.
«Мы также рефакторим старые монолиты, но используем Java и Kotlin, придерживаясь современных стандартов микросервисной архитектуры и принципов DDD. Мне кажется, вопрос о тенденциях в программировании тесно связан с новостным контекстом. Например, Илон Маск может влиять на тенденции, подчеркивая значимость искусственного интеллекта, что приводит к повышенному интересу к определенным языкам программирования. Несмотря на мою преданность Java и Spring Framework, я должен признать, что сейчас тенденции склоняются в пользу JavaScript из-за его значительного влияния на множество фреймворков. JavaScript оказывается востребованным во фронтенде и мобильной разработке, например, в Flutter. AI, Python, JavaScript - тренды сегодняшнего дня», - отмечает он.
Антон Мартынов, архитектор SimbirSoft, считает, что TypeScript играет значительную роль в современной разработке, функционируя как уже устоявшийся инструмент.
«В области мобильных приложений активно используются такие технологии, как Android с Kotlin, iOS с Swift, и в последнее время всё большую популярность набирает Flutter. Если мы говорим о разработке для рынков, где преобладают веб-решения, то здесь, безусловно, лидирует PHP. За ним следует Python, который благодаря своим многочисленным фреймворкам постепенно уступает место Go. Наша статистика показывает, что PHP занимает первое место, затем идёт Python, а уже после - Go. Это обусловлено тем, что чем раньше язык начинал своё развитие, тем больше готовых решений, которые можно эффективно применять, он накопил.
Похожая ситуация наблюдается и в области разработки корпоративных порталов, где важную роль играют готовые фреймворки и CRM-системы, написанные в основном на PHP, хотя существуют и классические решения на .NET и Java. В задачах, связанных с автоматизацией бизнес-процессов и учётом ресурсов, всё чаще применяется Go, так как он хорошо подходит для микросервисной архитектуры и позволяет достигать высокой производительности в определённых областях. Тем не менее, Java и .NET по-прежнему остаются популярными в этом секторе.
Что касается перспектив развития, мы видим, что существует значительный спрос на переход на новые платформы или миграцию с устаревших монолитных систем на микросервисную архитектуру. По нашей статистике, при таком переходе половина приходится на Java, около 30% - на Go, и оставшиеся 20% - на .NET. В то же время количество случаев миграции с .NET на другие языки увеличивается, что отражает тенденции в области программирования. «Динозавры» Java и PHP со временем будут вытеснены новыми языками.
Что касается веб-разработки, здесь изменений особо не наблюдается, JavaScript остаётся вне конкуренции, поддерживаемый тремя ключевыми фреймворками: Angular, Vue и React. В последнее время Angular немного теряет позиции, в то время как React и Vue постепенно приближаются друг к другу по уровню популярности, хотя React все же остаётся немного впереди», — отмечает эксперт.
В мире мобильной разработки преобладают три основных языка: Kotlin и Swift для соответствующих платформ, а также Dart как кроссплатформенный язык, который уже нашёл применение во многих проектах. Об этом говорит Максим Сидоров, тимлид команды системных сервисов SberDevices.
«Следует отметить, что Kotlin, будучи сравнительно молодым языком, амбициозно осваивает новые ниши, и я уверен, с появлением мультиплатформенного Compose Kotlin активно войдёт на платформу iOS и, возможно, станет доминирующим языком. Я согласен с тем, что мы оцениваем текущую ситуацию, исходя из графиков и отчётов о распространённости языков. Но важно также смотреть на несколько лет вперёд. В последнее время наблюдается появление таких интересных молодых языков, как Kotlin, Dart, Rust и Go, которые занимают около 1% на рынке согласно отчётам. Однако, по моему мнению, именно они представляют будущее программирования, и Java и PHP со временем будут вытеснены этими новыми языками с более продуманным дизайном, богатым выбором функций и интересной архитектурой.
А вот Алексей Шарыпов, Lead Backend Developer Playrix, считает, что выбор языка для бэкенда часто не критичен, хотя для программирования устройств и фронтенда, где лидирует JavaScript, это имеет значение. Основная характеристика – это стоимость и скорость разработки. Компании выбирают Python, потому что разработчиков легче найти и они доступнее, в отличие от разработчиков Go.
«Для текущего и следующего года тренд, как мне кажется, идет в сторону упрощения. Python привлекателен своей простотой и сниженной стоимостью разработки, что важно, в то время как количество проектов не растет так быстро. Компании выбирают технологии, которые дешевле в имплементации и поддержке. Крупные компании, вроде Amazon и AliExpress, используют свой собственный стек, поскольку уже вложились в развитие и обучение своих разработчиков. Но стартапы или компании, меняющие проекты, предпочтут более доступные языки.
Python сейчас популярен среди студентов из-за низкого порога входа, и в ближайшие пару лет рынок, скорее всего, наполнится разработчиками, предпочитающими этот язык. Что касается Go, его стоимость разработки в два раза выше, чем у Python, поэтому многие, особенно небольшие компании, стараются его избегать. Но крупные компании продолжают работать с Go, несмотря на стоимость», — отмечает он.
«Важен не язык, а парадигма, которую вы применяете при написании логики»
Существует мнение, что при выборе языка, особенно в игровой индустрии, ключевым является не конкретный язык программирования, а принципы и методы (парадигмы), применяемые для решения задач.
«Важен не столько язык программирования, на котором вы пишете, сколько парадигма, которую вы применяете при написании игровой логики: объектно-ориентированный и ориентированный на данные. Основная сложность заключается не столько в выборе языка, сколько в том, чтобы не усложнять инструменты разработки больше чем необходимо, и предоставлять языки, чей синтаксис знаком большинству. В игровой разработке это обычно C# или C++, в зависимости от того, какой базовый инструментарий был у разработчиков изначально», — рассказывает Андрей Карсаков.
«Далее важность приобретают хорошо оформленная документация и чётко описанный API игрового движка. Затем разработчики применяют уже отточенные навыки для изучения и использования функций движка. В целом, процесс разработки игр довольно стандартизирован в индустрии, изменения могут касаться лишь названий функций, методов, классов, но основные технологии и подходы остаются понятными и доступными. Мы хотим, чтобы любой разработчик, имеющий опыт в игровой разработке, мог без труда приступить к работе с нами, ознакомившись с документацией. Отдельно стоит заметить, что знание языка программирования в контексте конкретного игрового движка не всегда перекладывается на широкие знания этого языка в целом. Например, разработчика на C# в Unity сложно считать разработчиком на .NET, поскольку это совсем разные сферы применения языка», - говорит Андрей Карсаков.
По мнению эксперта, тот, кто умеет писать скрипты на C++ в Unreal Engine, не обязательно сможет сразу же приступить к скриптованию на C++ в Nau Engine, именно из-за разных инструментов, хоть и использующих один язык. Но если разработчик обладает глубоким пониманием основ программирования и математики, т. е. хорошей базовой подготовкой, и писал на чистом С++ или другом языке, то переход с одного языка на другой, особенно между C-подобными языками, обычно не представляет трудности.
«Однако, если речь идет о разработчике, который обучался работать только в Unity или Unreal и изучал C++ исключительно в контексте конкретных функций и синтаксиса, используемых в этих движках, переход может быть более сложным. Такому разработчику, возможно, потребуется больше времени для адаптации к новому движку по сравнению с тем, кто обладает более широкими и фундаментальными знаниями в программировании, а не ограниченным использованием языка в рамках одного инструмента или фреймворка», — резюмирует руководитель разработки Nau Engine.
«Владение одним языком не означает лёгкости перехода между разными сферами его применения»
Но есть проблема, с которой часто сталкиваются менеджеры в IТ-компаниях. Она касается использования одного языка программирования в таких разных областях, как фронтенд и бэкенд.
Петр Туголуков, корпоративный архитектор Xsolla, отмечает, что владение одним языком не означает лёгкости перехода между разными сферами его применения. Например, бэкенд-разработчику проще сменить язык программирования с PHP на Go, поскольку сфера задач схожа, и концепции middleware, сервера и базы данных остаются общими.
«Однако переход фронтенд-разработчика в бэкенд или наоборот, даже при знании JavaScript, может быть сложным. Это частая ошибка, приводящая к непредвиденным задержкам и проблемам в разработке. Фронтендер, пытаясь работать над бэкендом, может столкнуться с недостаточной производительностью, так как он не имеет опыта в этой сфере. Аналогичная ситуация возникает и в игровой разработке. Знание работы с игровыми движками позволяет разработчику легче перейти с C++ на C#, если у него достаточный опыт. Но даже знание C# не обеспечит легкого перехода из разработки игр на Unity к бэкенд-разработке. Такой переход потребует, фактически, нового обучения, так как, несмотря на общие циклы и условные операторы, специфика задач совершенно иная», - отметил Петр Туголуков.
«Возвращаясь к более серьезной разработке, необходимо понимать, что разработчик, занимавшийся бэкендами в компании вроде Яндекса, не сможет просто так перейти к работе в игровом движке. Даже если язык программирования один и тот же, архитектура движка и клиентские концепции отличаются от тех, с которыми он сталкивался на бэкенде, где важны другие аспекты (работа с памятью, оперативка), о которых бэкенд-разработчики обычно не думают. И если рассматривать Dart и Flutter, которые могут работать повсеместно, знание языка, используемого для бэкенда, не позволит автоматически перейти к разработке на десктопе, где есть свои специфические концепции, например, реестр в Windows, с которым бэкенд-разработчики обычно не сталкиваются», - добавил он.
По словам Петра, знание программного языка само по себе не достаточно для работы с этими областями. Нельзя однозначно сказать, что работа в одной сфере проще, чем в другой — ни в бэкенде, ни в мобильной разработке. Возьмите, к примеру, задачу создания распределенного приложения, сложного, аналогичного тому, что используют банки, — это может оказаться чрезвычайно трудным. Можно разрабатывать сложные архитектуры как на уровне команд, так и в играх, или десктопных приложениях. Попробуйте создать чат для фронтенда крупного классифайд-сайта — это очень непростая задача.
«Знание одного языка программирования не гарантирует, что вы сможете легко переключиться на разработку в другой области. Необходимо обладать соответствующими архитектурными знаниями. Язык может немного облегчить переход, но чтобы совершить его мгновенно, просто щелкнув пальцами — нет, я в этом совсем не уверен», — резюмировал корпоративный архитектор Xsolla.
«Уникальные навыки могут быть дорогими»
Вопрос о зарплатах всегда волнует, и люди действительно стремятся туда, где можно заработать больше. Говоря об ИТ, люди очень часто связывают работу в этой области с огромными зарплатами.
«Если вы специализируетесь на чём-то узком, вашу работу могут хорошо оплатить, но только когда такие навыки потребуются. Например, разработчики на Эликсире не всегда находят множество вакансий с высокой оплатой. Поэтому при выборе языка для изучения следует смотреть на рынок, анализировать исследования и реальные вакансии. Уникальные навыки могут быть дорогими, но не всегда востребованными, как в случае с разработчиками Cobol в США. Я рекомендую обратить внимание на такие более популярные и востребованные языки, как Swift и Kotlin для мобильной разработки, C++ и C# для игровых движков, Flutter для десктопа, а также Go, Python, Java, C# для бэкенда и, конечно, JavaScript для фронтенда. Знание одной области позволяет легко перейти к другому языку в этой же сфере. На личном опыте, для начала работы с Go после C++ мне хватило одной ночи в поезде и книги. Главное — выбрать сферу, в которой вы хотите развиваться», — говорит Петр Туголуков.
По словам Ильи Стешкова, основа разработки — это мышление программиста. Язык программирования является лишь инструментом для решения задач.
«Важна база, а выбор конкретного языка, как высказались многие эксперты сегодня, не столь важен. Выбор зависит от личных предпочтений и сферы, в которой вы хотите работать. Если стремитесь заработать, например, 400 тысяч, вы можете пойти в банки, или если хотите заниматься разработкой игр, то вам подойдут API движки.
Сначала нужно получить общее понимание решения задач, а затем уже можно выбирать специализацию и язык. При этом, даже если выбор сферы ограничен, например, фронтендом, в других областях лучше следовать сердцу, а не только рациональным расчетам. Выбранный вами инструмент будет вашим спутником на долгие годы, помогая решать задачи и достигать финансовых целей. Лично я, проработав некоторое время с PHP и поняв, что что-то меня не устраивает, перешел на Go, и это оказалось несложным», - сказал он.
«Психотип влияет на общие способности»
Андрей Карсаков считает, что переходя от одного языка программирования к другому, мы сталкиваемся с вариациями в удобстве использования, сложности конструкций и т. д. Но важно учитывать и психотип разработчика.
«Психотип может повлиять на то, насколько успешным вы окажетесь в программировании. Если у вас есть усидчивость и желание неустанно учиться новому, то программирование в любом его виде подойдет вам, так как оно требует постоянного обучения. И не стоит думать, что после изучения первого языка вы обречены оставаться с ним на всю жизнь. В большинстве случаев это не так», — уверен он.
«Да, усидчивость и склонность к экстраверсии или интроверсии имеют значение. Экстраверты обычно предпочитают взаимодействовать с людьми, а не с кодом. Среди разработчиков существует разделение. Есть те, кто любит визуальный результат своей работы, например, фронтенд, десктоп или мобильные приложения, где можно нажать кнопку и немедленно увидеть то, что сделано. И есть те, кого больше привлекает внутренняя сложность, кто предпочитает бэкенд. Это различие достаточно очевидно, особенно при найме новых сотрудников и работе со стажерами. Будущим специалистам следует задать себе вопрос, что им больше нравится - работать с API без пользовательского интерфейса или с самим интерфейсом. В зависимости от ответа можно определить свой путь в разработке, будь то фронтенд, десктоп или мобильные приложения», - добавил Петр Туголуков.
«Связь между выбором языка и уровнем зарплаты некорректна»
Максим Сидоров считает, что связывать выбор языка программирования с доходами не совсем корректно.
«Важны ваше увлечение и интерес к программированию. Если вам интересна ваша работа, вы, используя любой язык, например, PHP, R или C++, сможете заработать много. Главное, чтобы вы были вовлечены в программирование, тогда успех придет сам собой. Если говорить о начале карьеры, Python и JavaScript могут быть хорошим стартом для быстрого входа в профессию, и от них легче переходить к другим языкам. В целом, изучение всех языков доступно. Я, к примеру, учил C# и Java всего по две недели, имея опыт с другими языками», - сказал он.
«Я не спорю, что сейчас требуется много специалистов с разными языками, возможно, больше, чем традиционных программистов на C++. Важно отметить, что если вы изучаете программирование исключительно ради заработка, это может быть не лучшим подходом, с точки зрения менеджмента и воздействия на вас и продукты, которые вы создаете. В любой ремесленной профессии (программирование – это тоже ремесленное занятие, несмотря на его творческую сторону) ключевым является ваш энтузиазм в решении задач, независимо от языка», — говорит Андрей Карсаков.
«Повышение зарплаты может улучшить работу сотрудника, но только на первые недели. Затем всё возвращается к обычному уровню. Однако если специалист действительно ценный и хочет зарабатывать больше рыночного уровня, придётся ему платить выше рыночных ставок, иначе он может уйти в другую компанию. Зарплата тесно связана не столько с тем, насколько человек горит на работе, сколько с тем, какую пользу он приносит проекту, компании, команде и какой уникальный вклад может внести. Если он выделяется среди 80% разработчиков, то и будет зарабатывать больше. В России действительно лишь 3-5% разработчиков получают зарплаты 400K+, большинство имеют доход ниже. Чтобы претендовать на высокие зарплаты, нужно достичь уровня эксперта. Но независимо от вашего стремления зарабатывать, в начале карьеры вам вряд ли удастся получать большие суммы. Неизвестны случаи, когда новички сразу зарабатывали много. Нужно сначала что-то доказать», — добавил Алексей Шарыпов.
«В 2024 JS будет актуален»
Говоря о том, какие языки стоит изучать в 2024 году, эксперты составили свой собственный список актуальных инструментов.
«С точки зрения заработка и личного развития, я бы порекомендовал обратить внимание на JavaScript. Он нужен везде, в том числе в Ecom, FinTech и других бизнес-секторах для разработки фронтенда, вместе с TypeScript. В бэкенде я люблю Go и рекомендовал бы его, но сначала стоит посмотреть, что используют крупные компании (банки, VK, OZON, Вита). Если они используют Go, скорее всего, будут использовать его и в дальнейшем», — сказал Петр Туголуков.
«Если говорить о фронте, то да, JavaScript действительно актуален, я согласен с Петром. В случае бэкенда самый доступный язык для старта — это Python. Go — тоже отличный язык, но он может быть немного сложнее, и не ясно, каково будет его будущее. Python сейчас очень востребован и, судя по всему, так и останется, так что с ним проблем не предвидится», - говорит Алексей Шарыпов.
«По фронту нового не скажу — JS. Если ваше сердце лежит к бэкенду, следует изучать то, что активно используется в крупных компаниях, ведь они вряд ли откажутся от выбранного инструмента в ближайшие годы. Я бы также посоветовал Go. Спрос на квалифицированных специалистов высок, а порог вхождения, на мой взгляд, не так уж высок по сравнению с Python», - отмечает Илья Стешков.
Максим Сидоров считает, что учить нужно однозначно Python, так как он применим не только в бэкенде, но и в науке, в нейросетях.
«Он популярен на рынке и имеет широкий спектр применения. В бэкенде стоит обратить внимание на Java и C Sharp, если нет страха перед привязкой к платформам. Для мобильной разработки — Kotlin, который, как мне кажется, скоро захватит все платформы. Kotlin также привлекателен тем, что активно используется в различных сферах и может компилироваться в другие языки», - говорит эксперт.
«По фронту — JavaScript, и стоит посмотреть на такие фреймворки, как React или Vue, чтобы лучше понимать современные требования. По бэкенду — Python и Go. Если рассматривать более традиционные языки, то Java и C Sharp, но ожидаю постепенное замещение их Python и Go, или возможно появится что-то новое», — отметил Антон Мартынов.
«Стоит определить сферу интересов. Можно сосредоточиться на мобильной разработке, изучая Flutter и Kotlin, учитывая, что мобильная разработка востребована повсеместно и имеет меньше сервисов, связанных с AI, что является преимуществом для начинающих», — добавил Александр Тырышкин.
Андрей Карсаков советует, что если вы выбираете свой первый язык программирования и планируете заниматься программированием на долгосрочной основе, лучше всего предпочесть си-подобный мультипарадигменный язык, который позволит вам функционально экспериментировать и познакомиться с объектно-ориентированным программированием и др.
«Если вы хотите разрабатывать игры, то, несомненно, C++. Большинство проприетарных движков написаны на C++. Если же ваш путь лежит в скриптинг, то обычно используется C# или скриптовые языки вроде Lua или Python. Что касается бэкенд-разработки в геймдеве, то она не сильно отличается от общеизвестных бэкенд-технологий», — резюмировал эксперт.
Вместо вывода - комментарии
Мы заинтересованы в вашем мнении о теме, которую мы обсудили во время дискуссии. Для нас важно узнать, какие языки программирования вы видите актуальными в 2024 году и что думаете про наступление AI. Поделитесь своим мнением в комментариях под видео.
Автор самого интересного комментария будет награжден трехмесячной подпиской на Литрес, которая дает доступ к аудиокнигам, текстовым версиям книг, подкастам и лекциям.
Не забудьте подписаться на наш канал - впереди новые обсуждения и выступления экспертов. Кстати, если вы хотите выступить экспертом на наших дискуссиях, напишите нам.
Комментарии (35)
LordDarklight
21.11.2023 08:05+3Будущее за ещё более новыми языками программирования, которые ещё даже не появились на свет. Позволяющими эффективно разрабатывать логику "условно" бизнес-приложений (но этом могут быть и игры и какие-то медиа приложения или управляющие железом - в т.ч. роботами) с активным применением интегрированных AI технологий (это не означает, разработку систем машинного обучения, а просто интеграция AI-помощников как в сферу разработки программы, так и в сферу их дальнейшего применения), с минимальным уровнем прямого кодирования инструкций, с всё большим уровнем декларативного кодирования. Ни один из ныне популярных ЯП на эту роль не годится - все они заточены на куда более примитивный низкий уровень кодирования - но эти ЯП могут стать промежуточным слоем для кодогенерации со сторон AI, что уже происходит сейчас.
Так же частично нынешние ЯП буду ещё долго востребованы для системного программирования, но всё больше ужимаясь до драйверов и низкоуровневой аппаратной работы, ну или каких-то высокопроизводительных библиотек.
Прикладное программирование будет смещаться в сторону очень высокоуровневых API - максимально удаляющихся от технической аппаратной базы. А всю чёрную работу, генерацию паттернов и оптимизацию будут выполнять AI-помощники. От программиста будет требоваться только боле-менее чётко формулировать описания для этих AI-помощников - всё-таки пока я считаю требования к описаниям должны быть достаточно строгими (условно - математически строгими) - чётко декларирующими требования - чтобы в итоге получаемый код сразу интегрировался целевую систему (без доработок). А затем AI мог бы его ещё и динамически профилировать и при необходимости самостоятельно перестраиваться (ну или на первых порах информировать о своих предложениях программиста, давая статистически подкреплённые обоснования, и свои новые предложения). Да и сами итоговый код может существовать сразу в нескольких вариантах - и динамически переключаться между ними, быстро подстраиваясь под меняющиеся обстоятельства. Так же AI будет постоянно накапливать свою базу знаний - и при пересмотре ранее сгенерированных алгоритмов черпать и новые знания из такой базы знаний - заменяя устаревшие паттерны новыми - более эффективными - и всё под его же непрекращающимся контролем автоестирования и автопрофилирования - можно сказать вообще без вмешательства программиста - хотя человек всё тоже может контролировать (всю статистику ему AI преподнесёт на блюде), и сможет даже вмешиваться - внося специальные хинты в исходные программные декларации - специально направляя AI в заданное русло. Но рядовые программисты навряд ли этим будут активно заниматься - не их уровень! Это уже надо будет устраивать периодический (но не часто) аудит таких решений со стороны, чаще всего, аутсорсинговых компаний - где команда программистов будет заточена именно под анализ автогенерируемого кода, а не на тонкости логики, эффективность UX или красоту выходных форм (хотя тут свои специалисты тоже найдутся - для совершенствования и в данных аспектах)
Но, пожалуй, такой подход - это всё-таки пока ещё будущее. Оно не настанет "завтра" - таких ЯП ещё нет - но, думаю, эпоха начала их появления это дело 10-20 лет.
А пока рулить будут актуальные ЯП и вряд ли в ближайшие годы тут что-то принципиально изменится
Nipheris
21.11.2023 08:05+2От программиста будет требоваться только боле-менее чётко формулировать описания для этих AI-помощников - всё-таки пока я считаю требования к описаниям должны быть достаточно строгими (условно - математически строгими) - чётко декларирующими требования...
... и в качестве такого чёткого описания требований отлично подойдёт код на C#, ну или на Kotlin.
LordDarklight
21.11.2023 08:05Не совсем. Всё-таки описание должно быть более декларативным. Но отчасти да - даже в декларативном описании всегда найдутся блоки с более ярко выраженными инструкциями в императивном или функциональном стиле - а тут синтаксис данных ЯП очень неплох, но.... всё-таки на мой взгляд через 20 лет устареет - оба этих ЯП не самые всё-таки не идеальны для лёгкого абстрактного и многопоточного распределённого программирования - хотя в них и заложены некоторые правильные идеи - но это всё надо ещё доводить до ума!
И синтаксис Kotlin и C# сейчас несколько громоздок - нужно что-то ещё более синтаксически простое - но при этом ещё более выразительное и позволяющее писать ещё меньше кода - получая затем (после обработки AI) ещё больше выгоды.
Но C# и Kotlin - это отличные высокоуровневые промежуточные ЯП для AI кодогенерации - а она должна сначала идти в такие вот выскоуровневый ЯП - AI не должен сильно заморачиваться насчёт кросс-платформенности - его цель именно генерировать эффективный алгоритм, а не оптимизация под конкретное железо - впрочем этим на следующем этапе займётся уже AI-оптимизатор (формируя низкоуровневый промежуточный код под определённую железную архитектуру и ОС) и AI-JIT-компилятор на финальной стадии машинной оптимизации в runtime.
Ну и когда надо будет проанализировать что там AI нагенерировал - то тут тоже удобнее иметь хорошо аннотированный и комментированный высокоуровневый код
Dancho67
21.11.2023 08:05В ближайшие лет 20-40 обычные ЯП никуда не денутся. Как минимум, ИИ будут их использовать как генерируемый"байт код" на выходе, чтобы можно было его скармливать компилятору. Не умеют они сразу машинный код генерировать, по той простой причине, что любителей писать прямо на нулях и единицах или том же LLVM IR ну скажем так мало, а обучать смарт унитазы на чем то нужно. А когда наступит пора сильного само обучаемого ИИ, необходимость писать, что-то отпадет впринципе, ведь зачем, если оно само будет принимать решения и заниматься их реализацией.
И синтаксис Kotlin и C# сейчас несколько громоздок
Ну не знаю, короче этого только натуральный язык или простонародье промпт. Написал "сделай, чтобы было хорошо" и радуешься.
LordDarklight
21.11.2023 08:05В ближайшие лет 20-40 обычные ЯП никуда не денутся. Как минимум
Разве кто-то говорил обратное. Обычные ЯП и через 100 лет скорее останутся (не знаю какие из нынешних доживут до середины XXII века, но какие-то точно доживут, ну а так же буду появляться ещё и условно классические новые ЯП. Потребность в них никто не отменял. Но вот доля их прямого применения будет во второй половине XXI века постепенно сокращаться.
Как минимум, ИИ будут их использовать как генерируемый"байт код" на выходе, чтобы можно было его скармливать компилятору.
Я же напрямую об этом говорю - но это не стоит считать прямым применением программистами - это уже косвенное использование - хотя его доля как раз будет расти, так что такие ЯП ещё долго буду в ходу.
Ну не знаю, короче этого только натуральный язык или простонародье промпт. Написал "сделай, чтобы было хорошо" и радуешься.
Всегда есть что упростить у C# большое наследие от Си и от ранних версий - которые в нынешних реалиях уже не так актуальны. У Kotlin с этим получше - но всё-равно и тут найдётся что хотя бы формально подсократить.
Например, лично я считаю что у обои ЯП (особенно у C#) очень сильно раздута база ключевых слов. В этом плане, скажем Nemerle был куда сдержаннее (хотя Kotlin тоже старается) - но тем не менее - многое можно было бы перевести на макрофункции, функуии-расширения, функции-операторы и аннотации, или вовсе пустить под нож. Но это всё формальщина - по сути токены для изучения то никуда не делись бы, просто сменили форму, но синтаксически языки стали бы проще как и проще стал бы их синтаксический разбор.
С другой стороны - параллельное/асинхронное программирование, со всеми своими прибамбасами, всё ещё желает иметь ещё большее упрощение без потери надёжности.
Что до "натурального языка" - мне такой подход не нравится - ранее уже пытались (но не особо глубоко) Objective-C и SAP ABAP (были и ещё более глубокие представители - но уже канули в лету) - хреново получается. Такой подход хорош для работы, условно, через ChatGPT - который на выходе уже будет давать более формализованный код
k-morozov
21.11.2023 08:05+5Важна база, а выбор конкретного языка, как высказались многие эксперты сегодня, не столь важен
Лицемерие на публику. Ряд этих экспертов почему-то в свои команды требуют опыт на конкретном языке от N-лет. и если этого нет, ты даже на собес не попадешь. А если попадешь, то будешь общаться на тему этого языка и съехать, что ты писал на чем-то другом будет крайне сложно. Раньше тот же ozon допускал такое, сейчас практически нет - извольте 1.5 года именно на Go писать иначе не пройдете даже hr'a.
AndyKy
21.11.2023 08:05Без конетекста как-то смысл меняется, там по-моему не совсем об этом. Речь о том, что если у вас хорошо работает голова, то вы можете много зарабатывать и на Go, и на Java, и на JS. Конечно, компания, которой нужно делать бэк на Go отдадут предпочтение человеку с релевантным опытом, который прям завтра сядет и начнет приносить пользу. Но если на рынке нет таких специалистов, то действительно достаточно убедиться что вы нормально соображаете и потом ждать какое-то время, пока вы набьете руку в конкретном языке (что видимо раньше и было в Ozon) и только потом начнете создавать что-то полезное для бизнеса. Когда на рынке полно уже готовых специалистов, конечно компания скорее выберет готового, чем того, в которого надо еще инвестировать.
Другая сторона этого вопроса, например, разработчик пирносил пользу компании и проявляет себя как толковый специалист, но технологии устарели, не востребованы. Совершенно не обязательно его скидывать со скалы и искать свежего на замену. Вполне может оказаться взаимовыгодным решением переобучить.
k-morozov
21.11.2023 08:05+1делать бэк на Go отдадут предпочтение человеку с релевантным опытом
Отдать предпочтение навыку, который со слов "экспертов" не так важен при условии наличия опыта на другом языке? Кажется кто-то здесь лукавит...
"Отдать предпочтение" и "не рассматривают в принципе без N-лет на этом языке" немного разные вещи?
Я не спорю, что лучше нанять человека с уже готовым навыком. Но зачем так лицемерить в статье?
Ravager
21.11.2023 08:05Лицемерие на публику. Ряд этих экспертов почему-то в свои команды требуют опыт на конкретном языке от N-лет. и если этого нет, ты даже на собес не попадешь.
Я попрошу заметить, что кроме этого вас ещё хорошенько прогонят по базе. Так что тут придется вывернуться наизнанку, чтобы пройти этих экспертов. Причем даже поработав в озоне, ты придёшь в какой-нибудь xsolla, и там все будет тоже самое. Эксперты такие эксперты, что даже друг другу не доверяют.
BlackSCORPION
21.11.2023 08:05+1Множество компаний различного масштаба переходят на новые Python, Go, Kotlin, а в сфере мобильной разработки - на Swift. Языки C++, C, PHP, Java можно отнести к предыдущему поколению.
Python появился в 1991, Java в 1995
Source
21.11.2023 08:05+1А PHP в 1994. Так себе эксперт, если не в курсе, что Python - относительно старый язык, с тяжелым наследием, которое из него уже никогда не уйдёт.
Go концептуально тоже старый, даже ближе к языкам поколения C.
Новые: Kotlin, Swift, Elixir, Rust, Julia.
LordDarklight
21.11.2023 08:05У Python уже был очень сложный переход от 2-ой к 3-ей версии без обратной совместимости, но, думаю, наврядли на такое пойдут снова - уж очень болезненным и трудным был переход, а и до сих пор есть много активных проектов, так и оставшихся на 2-ой версии.
Наверное через несколько лет надо будет говорить о ЯП Mojo - как более современной версии языка Python, но без сильного желания быть очень совместимым, но... всё-таки и тут такое желание есть - так что по сути Mojo (по крайней мере в нынешнем его воплощении, ещё далёком до релиз 1.0) - это лишь немногим больше, чем условный Python 4.0 (вернее тут лучше сравнивать более конкретно с CPython компилятором). Так что да - не совсем удачного наследия и в Mojo хватает. Но всё же - именно Mojo тут более современный ЯП, чем старый Python
Source
21.11.2023 08:05Если им яиц хватит сделать действительно новый язык, это будет интересно. Но есть большая вероятность, что они просто повторят судьбу Perl и Raku (aka Perl 6).
Updated: Загуглил Mojo. Он же от других разработчиков. С таким же успехом можно и Nim сюда приплести.
LordDarklight
21.11.2023 08:05Да, это другая команда, поэтому это и не Python 4.0 - но ЯП Mojo основан на диалекте Python.
И да, судьба Mojo пока не определена, но так как это не абсолютно новый ЯП, а с некоторой совместимостью, и обещают ещё и поддержку ключевых питоновских библиотек, а разработчики весьма опытные в деле компиляции - то может и получится что-то, вполне конкурентное с питоном, а питоном нынче вроде бы на первое место вышел по популярности (по некоторым исследованиям) - так что есть за что побороться. Но тут нужно время - и до 1.0 релиза, и даже до 2.0 надо будет подождать, ну а потом ещё лет 10 уйдёт на "завоевание" аудитории, и, попытку, войти хотя бы в 3-5-ку самых популярных ЯП (ну это если к тому моменту уже удастся войти хотя бы в 10-ку или даже хотя бы в 20-ку чтобы быть в шортлисте популярных ЯП)
Source
21.11.2023 08:05Популярность языка нынче не стоит ничего. Она сейчас говорит только о двух вещах: либо язык всё ещё преподают в ВУЗах, либо его пиарят на курсах для тех, кто самостоятельно не может программирование освоить. И в том и в том случае будет много запросов в поисковики и мусорных/учебных репозиториев.
А по поводу Mojo, в чём его киллер-фичи по сравнению с Nim? Который уже аж до 2.0 дошёл.
LordDarklight
21.11.2023 08:05Я не адепт ни Python, ни Nim, ни Mojo (который ещё и в финальный релиз не вышел). Поэтому полноценно Вам ответить не могут. Предполагаю, что в двух вещах - для Mojo: большей синтаксической свободе и приверженности классическому синтаксису питона (Python и Mojo синтаксически простые ЯП, NIM - нет), и заметно большей производительности. И статическая типизация, как ни странно, даёт много удобства и надёжности при разработке, ограниченный специфичный ООП - но это я больше с Python сравниваю, т.к. с NIM не особо знаком, но знаю, что Mojo уже сравнивали с NIM, и считают, что Mojo его превзойдёт, а вот что важно для NIM в сравнении с Mojo - так это кросс-платформенность - и вот тут у NIM не всё гладко (он транслируется в C++ а там такая чехарда с компиляторами и типами данных - да и NIM в итоге легко сгенерирует код, который потом С++ компилятором не компильнётся с классической для него кучей широченных и непонятных ошибок); конечно он может ещё и в JavaScipt - это хорошо - но достаточно узкоспециализировано - хотя JS сейчас активно соперничает с Python за первое место по популярности) Но, наверное это два прямых конкурента, хотя Mojo более питоно-ориентированный чем NIM. И, вероятно, Mojo буду более активно продвигать и багфиксить - так там очень именитые дядьки его разрабатывают! И что там у NIM с надёжностью и удобством многопоточности вообще не совсем ясно, доки хромают!
Лично для меня NIM - это жалкая поделка даже в сравнении с Python (причём перенявшая от него всё самое неудачное), который мне тоже не особо нравится, но хотя бы питон прост и боле-менее лаконичен.
Но вообще я адепт из другого лагеря (и, как можно прочесть тут выше в моих комментариях, вообще пропагандирую рождение концептуально совсем иных ЯП в недалёком будущем)
PavelKuptsov
21.11.2023 08:05"За ним следует Python, который благодаря своим многочисленным фреймворкам постепенно уступает место Go."
Вот оно оказывается в чем дело! Нужно уменьшать кол-во фреймворков, иначе совсем продадет python.
SpiderEkb
И чем "новые" языки принципиально отличаются от "старых"? Вот прямо так чтобы радикально?
Не устаю приводить пример из личного. Есть банк, центральные сервера где все задачи - работа с БД и коммерческая бизнес-логика. И есть (на той платформе, на которой работают сервера) специализированный язык, ориентированный именно на работу с БД и ту самую бизнес-логику.
И да, там нет и половины того, что сейчас модно. Обычный (казалось бы) процедурный язык. Даже без ООП (которая там не сильно нужны т.к. все задачи связаны с формированием потока данных - выборок - и дальнейшей с ним работы).
Что отличает его от "обычных" языков?
Нативная поддержка всех типов данных, что есть в БД - все эти char, varchar, date, time, timestamp, numeric, decimal - все они нативно поддерживаются языков ровно как традиционные (int, float...) типы данных
Встроенные средства работы с БД - хоть напрямую (открыли файл, спозиционировались на запись по ключу, прочитали запись, изменили содержимое, обновили запись и т.п.), хоть посредством SQL - непосредственно в год может быть вставлено практически любой сложности SQL выражение, в том числе с использованием хост-переменных
Что это дает?
Не нужно подтягивать разные зависимости для реализации типов данных. Не нужны никакие "обертки" чтобы работать БД типами данных. Достаточно просто описать структуру (не класс с конструкторами и методами, обычный байтовый буфер где написано "от сих до сих у тебя поле типа decimal, а от сих до сих - varchar"), прочитать туда блок данных (запись) из файла и потом работать с полями структуры как с обычными переменными, а не "объектами какого-то типа"
Не нужны библиотеки для работы с БД. Ни напрямую, ни с использованием SQL. Все что нужно уже есть в языке. И оно эффективно работает. Более того, там можно как "динамический" SQL (строка запроса формируется в рантайме, план строится в рантайме), так и "статический" - строка запроса указывается явно, валидируется компилятором, план запроса формируется на этапе компиляции.
В итоге имеем быстрый, эффективный и удобный язык для решения конкретного класса задач.
Плюс к тому еще есть возможность "мультиязыковой" разработки - все компиляторы на этой платформе генерируют единый промежуточный код (это отдельная тема, весьма обширная) что позволяет написать несколько модулей на разных языках и собрать их в одну программу (главное - правильно описать прототипы функций для межязыковых кросс-вызовов). В частности, из кода на вот этом спецязыке можно вызывать любую функцию из С-шной библиотеки. Достаточно просто корректно описать ее прототипа со ссылкой на соответствующую "внешнюю процедуру".
Таким образом при решении конкретной задачи каждая ее часть может решаться с использованием того инструмента (языка), который подходит наилучшим образом.
Этот подход кажется непривычным и не сразу "заходит", но когда привыкаешь, понимаешь что это действительно удобно и эффективно.
Kanut
Ну вот а теперь представьте что вместо этого языка у вас есть выбор использовать C или C++.
Ну так именно про это и написано в процитированном вами куске.
SpiderEkb
Представьте, что такой выбор у нас есть. А теперь расскажите, что мне делать с записью, где содержатся поля varchar, date, numeric, в С, где эти типы не поддерживаются на уровне языка?
Накручивать на них обертку вместо того, чтобы сразу их использовать? Извините, но это лишнее время, которое становится ощутимым когда речь идет о десятках и сотнях миллионов записей...
Смогу я в С/С++ вот такое?
zoned здесь - тип соответствующий numeric в SQL.
Результат запроса сразу кладется в структуру dsHDARes и дальше с ней уже работаем без лишних телодвижений.
Если пытаться делать это на языке общего назначения с привлечением каких-то дополнительных библиотек, это все будет работать медленнее и кода будет больше.
Да, но там приводятся примерно одинаковые языки общего назначения. А я говорю о специализированных под конкретный класс задач языках, обладающих специфическими для этого класса задач возможностях, принципиально облегчающих решение задачи и дающий максимально эффективный результат.
Мне немало приходилось работать с разными БД на С/С++. Так что есть возможность сравнивать.
Kanut
Вы по моему всё ещё не понимаете о чём речь. Речь как раз о том что сейчас у большинства программистов нет особого выбора на каком языке писать. И есть только выбор вроде "C или C++" или там "C# или Java".
Где? Там как раз речь о том чтобы создать систему, позволяющую интегрировать различные языки.
SpiderEkb
Насколько я знаю, такая система есть - LLVM называется.
На нашей платформе не она, там свое, но на другие платформы оно не переносимо в силу отсутствия тем ряда ключевых концепция и сущностей.
Но LLVM вполне себе портируема на разные платформы. И это как раз то, что позволяет реализовать мультиязыковый подход к разработке.
Возможно. Отчасти потому что там много каких-то частностей, но нет четко сформулированной общей концепции в стиле "этот кусок я пишу на С потому что он тут лучше, а это на Go потому что он тут эффективнее". Потом каждый кусок компилируем своим компилятором а результаты работы компиляторов собираем в один исполняемый файл.
Так это работает у нас (это называется ILE - интегрированная языковая среда), так это работает в LLVM.
Это не "мы для своего движка, который писали на С сделали API для питона" - все это было еще в виндовых dll которые просто имели стандартный ABI позволяющий писать dll на чем угодно и вызывать функции оттуда откуда угодно.
Это совместимость промежуточного (объектного) кода, выдаваемого компиляторами разных языков.
Мне кажется, что это наиболее перспективный путь развития в текущей ситуации.
Наш пример я привел просто потому что он очень "контрастен". И потому что работа с БД достаточно распространенное явление, а реализация через "SQL библиотеки" и классы-обертки SQL типов не самое эффективное решение когда речь заходит о работе с большими объемами данных - хотелось бы что-то узкоспециализированное, но с возможностью стыковки с уже существующими языками, чтобы не городить еще один мегаязык "как С++, но с
вистом и профурсеткамивозможностью прямой работы с SQL в коде и поддержкой SQL типов данных". Чтобы можно было выделить в отдельную часть работу с БД и написать ее на отдельном языке.Kanut
Это не значит что она везде применима и уж тем более что все ей пользуются.
LordDarklight
По человечески это должно выглядеть как-то так (оставлю только совсем не "человеческие" идентификаторы) на декларативном псевдокоде
Несколько пояснений по номерам:
#dbfieldgroup - это макрос, который ещё на этапе компиляции (а так же в indesigne) возвращает тип, производный от базового FieldGroup - описывающего группу полей, с возможными псевдонимами, расчётами и т.п.
Псевдоним для поля с формулой (формула транслируется в операторы БД в той части, насколько возможно - остальные вычисления будут выполнены в объектной модели), тут может быть и перевод группы полей в одно поле, если нужно несколько полей для расчёта
#dbfieldmap - это макрос который ещё на этапе компиляции (а так же в indesigne - далее все макросы такие же) производит реструктуризацию списка полей по заданной строковой формуле переименовывая и задавая соответствие псевдонимам
&dbparameter - аннотация - определяющая псевдоним как параметр (запроса) - учитывается в строке с меткой //8
#dbsource - этот макрос определяет источник данных из базы данных - весь код внутри будет "видеть" структуру этого источника, в т.ч. в indesigne. При компиляции может подставляться другой ресурс пути, в т.ч. неопределённый и генерироваться более параметризованный код внутри блока - например, чтобы динамически брать пути таблиц из каких-то настроек
#dbtablekey - это макрос, задающий таблице базы данных метанастройку - ключ соответствия по умолчанию! По переданной группе полей
указание источника данных для начинающейся выборки с настроенными левыми соединениями ("левые" два идут по настроенным ключам групп полей, "правое" идёт с персональным фильтром и персональным ключом соединения.
Кстати GPVPF.where(GPVITM=="DAMBN") можно был бы сократить до GPVPF(GPVITM=="DAMBN"). А <-GPVPF(GPVITM=="DAMBN").on(GPVVLE==HDAMBN) превратить в LEFT(GPVVLE==HDAMBN) GPVPF(GPVITM=="DAMBN")
Группа полей напрямую преобразуется условие фильтра - здесь преобразование простое - такое же как при соответствии - но псевдонимы становятся параметрами вызова запроса, согласно данной им аннотации.
Непосредственно получение в переменной источника данных - потока, из котором потом можно получать элементы данных согласно переданной группы полей
Обращение к источнику данных с передачей параметров как аргументов функции - открывается выборка - поток - коллекция и тут же начинает поэлементно перебираться
Все фактически не найденные в группах поля без пометки "require" игнорируются!
Многие макросы предполагается выполнять единожды где-то в общем коде, а не всё время по месту использования.
Вот такое у меня виденье как это должно быть оформлено на более продвинутом ЯП - причём тут даже AI не нужен - это достаточно конкретный псевдокод, а с AI его формирование было бы ещё более простым!
Прошу строго не судить - писал "на лету" и "на коленке" - всё-таки это просто очень предварительная концепция.
Будь идентификаторы полей более "удобными", а вся метачасть вынесена в отдельный блок и максимально обезличена от конкретных идентификаторов (бОльшая должно браться из ресурсов настроек или каких-то других источников, а не прописываться жёстко в коде - и тут метапрограммирование и JIT компиляция должны свести все абстракции в итоге в конечные оптимизированные константные цепочки инструкций) - то сам алгоритм вообще выглядел бы смехотворно коротким, с максимальным уровнем абстрагирования от имён полей и таблиц
SpiderEkb
А теперь скажите - как вы будет работать с полями типа zoned или timestamp? Потребуется для них какие-то преобразования в рантайме прежде чем вы сможете написать, скажем,
или
В нашем случае не потребуется ничего. Вот просто прочитали запись и работаем с нее. Типы zoned, timestamp и т.п. - точно такие же нативные типы в языке как int, float и т.п. Т.е. не требуют оберток, преобразований и прочего, что требует времени в рантайме.
LordDarklight
Как уже написал - первым делом кодогенгератор должен стараться вынести все эти преобразования в API на стороне СУБД
Там где это не удастся - т.е. в выражении будут вызываться функции, не доступные в СУБД (и которые не удаётся туда импортировать, без заметной потери производительности или когда они чёрный ящик или завязаны на какие-то внешние API) - то выражение должно перестраиваться так - чтобы постараться всё что можно оставить для выполнения в СУБД, а в объектной модели выполнить остальное - кстати тут хорошо иметь клиент-серверный модуль на стороне СУБД - в рамках которого и будут выполнены такие преобразования
Если на придётся работать на стороне объектной модели с какими-то специфическими типами - то выход только один - иметь, условно плагин/расширение, поддерживающее эти типы на бинарном уровне - т.е. из СУБД придётся вернуть бинарные данные, но для ряда случаев может быть и какая-то конверсия на стороне СУБД в более удобоваримый тип (если точность не теряется) - это определяется настройкой правил трансляции. Но тут уже особый случай - это программист сам должен понимать (а анализатор кода ему об этом сообщить) о тонкостях такого подхода - и либо смериться, либо пересмотреть своё выражение - чтобы проблемная часть сместилась на сторону СУБД.
ВНИМАНИЕ! ТРЕБУЕТСЯ ПОНИМАНИЕ ТОГО, ЧТО: Мой код - это не инструкции выполнения в объектной модели - это декларация намерений - и весь этот код может быть перестроен в рамках различных контекстов (взаимодействующих друг с другом) при конкретной трансляции в конкретных условиях! За это отвечает транслятор и его правила! Программист несколько ограничено может влиять на принятие решений особыми хинтами - маркерами специфических требований для транслятора!
Даже вот это "var dsHDARes = get dsHDAResFM" никак не гарантирует, что тут будет обязательная выгрузка в объектную модель - таблица может остаться на сервере СУБД - Таблица даже может быть разделена на части - где часть останется на стороне СУБД, часть в объектной модели - и даже несколько раз они могут туда-сюда перегоняться разделяться и соединяться (но это уже профилировщик сам должен решить как лучше поступить - в случае просадки производительности - сообщить о проблемных местах алгоритма программисту).
Кстати, объектная модель может тоже подключаться прямо в контекст СУБД (как это умеют MS SQL Server, Oracle, отчасти PostrgreSQL, и некоторые NoSQL СУБД) - но безусловно с некоторой просадкой производительности, в сравнении с наивным ЯП самих СУБД).
Поэтому весь код далее может продолжить своё выполнение на стороне СУБД (если там есть доступный API для трансляции) - а тут СУБД буду дальше ещё продолжать эволюционировать, расширяя свой внутренний API - но опять же тут дело за профилировщиком - ему оценивать и решать где лучше продолжить выполнение кода - даже в динамике - в зависимости от балансировки нагрузки в текущий момент времени! Человек так никогда не сможет сделать!
Да, безусловно, в большинстве случаев будут некоторые потери в производительности - но навряд ли сильно большие - когда в итоге данные так или иначе нужны будут в объектной модели (или должны быть переданы на другой сервер или просто другому микросервиса виртуальной среды), а не останутся в той же БД той же СУБД.
Для особо критичных алгоритмов буду писать прямые реализации алгоритмов - но это будут доли процента в общей массе!
И ещё, надо понимать что такой подход больше ориентирован на абстрактное составление алгоритмов - даже вот эта строка
не совсем абстрактна - в идеале должно быть так
где все идентификаторы в верхнем регистре (они так для наглядности) определяются где-то в другом месте (наряду с метанастройкой соединения таблиц) - и текущий код о них ничего не знает (но может что-то проверять, требовать, приводить к каким-то другим интерфейсам и типам). Состав полей и условий тут не известен и не фиксирован - они могут собираться из разных частей отдельных модулей и настроек, меняться со временем - а этот код останется неизменным, пока вороне не изменится логика или архитектура. Это настоящее абстрактное программирование! На самом деле даже этот код не идеален а идеал он где-то здесь
Тут источник данных SOURCE тоже абстрактен и его структура тоже определяется где-то в другом месте (и даже не ясно где фактически расположены данные, они даже на момент данного выражения ещё могут и не быть вычисленными) - согласно заложенной какими-то иными декларациями и настройками архитектуры хранения данных!
ДЕКЛАРИРОВАНИЕ, АБТРАГИРОВАНИЕ И ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ - вот ключевые аспекты нового ЯП (не забывая про ООП, АОП, функциональное и императивное программирование)
LordDarklight
...и МЕЖКОНТЕКСТНАЯ КОДОГЕНЕРАЦИЯ с ПРОФИЛИРОВАНИЕМ, СБОРОМ СТАТИСТИКИ, ГЛУБОКИМ АНАЛИЗОМ, ИСПОЛЬЗОВАНИЕМ БАЗЫ ЗНАНИЙ и ДИНАМИЧЕСКОЙ ПЕРЕТРАНСЛЯЦИЕЙ алгоритмов!
sdramare
Что мешает на уровне драйвера маппить прочитанные данные га заранее определенные структуры с нулевой стоимостью? Это вообще не вопрос языка. Вы так пишите как будто у вас в памяти эвм реально существуют раздельные int и char
LordDarklight
Не очень удачно написал выражение " GPVDSC -> MBND = left(it ?? "",35) //2"
вот так на ООП выглядит лeчше (во многом позаимствовано у C# и немного из Kotlin):
По сути здесь много синтаксического сахара - это описание соответствия образующего тип KeyValueTriple в виде кортежа
где ${ } - это описание выражения (его раскроет макрос)
it - это автопеременная - в макросе будет макроцикл по коллекции слева - имена полей - здесь будут эти имена - ну а остальное - это просто обработка NULL значений -
затем с большой долей вероятности это выражение уже будет отранслировано в реализацию конкретной СУБД (если источник данных приложения этоой группы полей будет таблицу расположенная в СУБД на момент вызова)
впрочем, оптимизатор может ещё как-то это оптимизировать под конкретную СУБД и конкретную таблицу и конкретное описание поля в этой таблице
LordDarklight
Со скрипом в душе (т.к. я не рьяный адепт ООП), но я бы выбрал Си, а не С++ - уж больно долбанутый ЯП этот плюсанутый - черт голову в нём сломит. Но это если сравнивать современные редакции. На момент выхода С++ он действительно имел ряд неоспоримых преимуществ (особенно для адептов ООП), хотя и имел ряд жутких проблем - хотя бы в части жутко реализованной идеи шаблонов!
Но сейчас выбирая между ним и более современным C# (хотя, увы, тоже перенявшим туеву кучу неудачных, на мой взгляд, концепций от своих прямых прародителей. и и за свои 20 лет обросший некоторыми своими неудачными решениями) - я однозначно выбираю C# (тем более, что его производительность на прикладном уровне уже не так уж далека от C++ - и есть большой простор для глубокой ручной оптимизации; и теперь уже с широким акцентом на кросс-платформенность, в т.ч. для WEB приложений). Но, вот, Kotlin всё же покрасивее будет. С другой стороны - платформа .NET (без учёта ЯП), с технической стороны, куда интереснее и шире в применении, чем JVM (трансляция Kotlin в JavaScript - это уже другая тема) - но это дело поправимое, хоть JetBrains пока отреклись от разработки компилятора для .NET - это не так уж сложно - и у меня уже есть свой проект Kotlin.NET. Ну а оригинальный Kotlin Native multiplatform - тоже отличная концепция, но пока ещё не выстрелившая и по сути ещё находящаяся в разработке!
Что до Python (или уж лучше тогда более современный, но пока не вышедший в релиз ЯП Mojo) - язык неплохой, но несколько ложек дёгтя в нём уж больно сильно для меня отравляют данную бочку мёда (хотя в мире полно любителей химического привкуса).
Что до Rust - неплохой и перспективный ЯП, но, всё-таки далёкий от идеала - любопытно посмотреть про появление конкурентов в данной концепции!
Kanut
Не-не-не. Вы не поняли: C или C++. И всё. Если вообще. И так сейчас живёт куча айтишников. То есть ЯП или даже фреймворк выбрать нельзя и пиши на чём дают.
И на этом фоне системы с возможностью интеграции различных ЯП выглядят заметно приятнее. Хотя конечно даже в них тебе не дадут разводить зоопарки из 100500 различных ЯП.
SpiderEkb
Очень понимаю :-)
Я начинал с С, потом появился С++, который был "С с классами". Тогда это было хорошо.
В целом, на С/С++ писал более 25-ти лет пока не попал в банк и основным не стал вот этот вот специальный язык. Хотя низкоуровневое, близкое к системному (а оно попадается и тут), до сих пор пишу на С/С++.
Не могу сказать что нравится куда идет современный С++... По мне, так туда просто пытаются тащить все на свете что в других языках увидели. Не уверен что это хорошо. Но раз он до сих пор популярен - значит кому-то это нужно.