Какие языки программирования стоит изучать в 2024 году?

Привет всем!

Интересно узнать ваше мнение о том, какие языки программирования будут наиболее актуальны в ближайшем будущем. С каждым годом появляются новые технологии и инструменты, и иногда трудно определить, на что стоит обратить внимание.

Лично я думаю, что Python и JavaScript сохранят свои позиции благодаря их широкому применению и сообществу, но также появляются новые интересные языки, такие как Rust и Go. Хотелось бы услышать ваше мнение по следующим вопросам:

1. Какие языки программирования, на ваш взгляд, будут наиболее востребованы в ближайшие 5-10 лет?
2. Какие новые языки программирования или фреймворки появились в последнее время, и что вы о них думаете?
3. Какие языки стоит изучать новичкам в программировании, а какие — опытным разработчикам, желающим расширить свои навыки?
4. Как вы считаете, стоит ли углубляться в популярные языки (например, Python, JavaScript) или лучше изучать более специализированные (например, Rust, Go)?
5. Какую роль в будущем будут играть языки для машинного обучения и обработки данных, такие как Python и R?
6. Как влияют на выбор языка требования к производительности и безопасности?
7. Какие ресурсы и методики вы бы порекомендовали для эффективного изучения новых языков?
Давайте обсудим и поделимся своими мыслями и опытом!

0

Сообщение от Beltar А кто мешает использовать Питон только для вызова C-библиотек, которые можно скормить тем же GPU?

Как выше уже заметили, тогда проще обойтись без Питона.

Но есть и еще одно обстоятельство. По опыту написания разного вычислительного моделирования (а нейронки в этом плане мало чем отличаются) подобная комбинация снижает производительность получающегося где-то примерно раза в три (по сравнению с решением на чистом Си или чистом Фортране).

Сообщение от voraa Назови какие-нибудь полезные, хоть сколько-нибудь широко используемые проги на Python

Широко используемых, наверное, нет, а вот полезные, увы, есть. К сожалению, сейчас в науке оно достаточно часто встречается. Причина именно эта:

Сообщение от voraa А Питон, на мой взгляд используют , что бы что то быстро на коленки сваять для разовых, узкоспециализированных задач. И то те, кто другого не освоил.

но приводит это к появлению довольно большого количества кода, который вынужденно приходится использовать (с помощью лома и какой-то матери, поскольку поддержка чего-либо на Питоне - занятие, кажется, почти невозможное).

0

Когда еще была 1С под ДОС, у меня было 118 отчетов, потому что они писались на языке форматных вставок,
например [ДО50], дебетовый оборот счета 50 "Касса" и я играючи делал скрипты, которые выдавали мне
аналитику из бухучета в любом разрезе, какой душа похощет, потом язык стал усложняться, хотя и возможности
увеличивались.

А про популярность языков, достаточно посмотреть на этом форуме, сколько людей где сидит, сколько тем
поднято, сколько ответов, поэтому прежде чем задать вопрос, достаточно глянуть статистику сайта, хотя
увеличение числа вопросов и тем вызвано еще и сложностью языка и здесь трудно численно измерить
влияние фактора сложности от фактора популярности.

Кстати по моему в Паскале была директива inline , после которой можно было делать ассемблерную
вставку, вот кстати такие фичи придают языку турбонаддув.

0

Сообщение от Pphantom Как выше уже заметили, тогда проще обойтись без Питона. Но есть и еще одно обстоятельство. По опыту написания разного вычислительного моделирования (а нейронки в этом плане мало чем отличаются) подобная комбинация снижает производительность получающегося где-то примерно раза в три (по сравнению с решением на чистом Си или чистом Фортране).

Давайте определимся о чем вообще говорим, о реализации вычислений на интепретируемом Питоне, или о передаче из Питона данных в откомпилированный код, написанный на др. языке. Что-то мне подсказывает в той же NumPy на самом Питоне ничего не считается.

0

Сообщение от Beltar Давайте определимся о чем вообще говорим, о реализации вычислений на интепретируемом Питоне, или о передаче из Питона данных в откомпилированный код, написанный на др. языке. Что-то мне подсказывает в той же NumPy на самом Питоне ничего не считается.

Именно о передаче данных из Питона в код на другом языке.

Если вычисления проводятся в самом Питоне, то падение производительности будет не в три раза, а порядка на два.

0

Сообщение от avedeo Кстати по моему в Паскале была директива inline , после которой можно было делать ассемблерную вставку, вот кстати такие фичи придают языку турбонаддув.

В Паскале ассм вставлять всегда можно было, в Delphi тоже, хотя насчет современных версий, компилирующих под разные платформы, не уверен.

Так-то в Delphi 2005 или 2006 директива inline была добавлена для функций, чтобы развертывать их в прямую вставку по месту вместо вызова.

Добавлено через 2 минуты

Сообщение от Pphantom Именно о передаче данных из Питона в код на другом языке.

За счет чего такая просадка? По крайней мере, если мы рассматриваем реально сложные вещи, когда послал в видеокарту считаться, а сам ушел покурить. И предполагается, что данные 1 раз направлены и 1 раз результат придет, без постоянного обмена с внешней программой.

0

По моему современное программирование прямо таки нуждается в биогеоценозе, когда изощренность
логики и вычислительная мощь одного языка дополняется скоростным компилятором другого,
получается логистическая цепочка обработки данных, будущее за симбиозными инфосистемами

"Российское Минцифры активно изучает и развивает идею создания универсального ИИ-помощника,
который сможет не только автоматизировать рутинные задачи (например, запись к врачу),
но и существенно упростить взаимодействие человека с цифровыми платформами.
Это формирует новую технологическую нишу, для которой уже есть необходимые заделы
в виде отечественных ИИ-моделей различного масштаба. Ожидается, что подобные решения
смогут качественно повысить уровень цифрового сервиса и облегчить повседневную жизнь граждан."

0

Сообщение от Beltar За счет чего такая просадка? По крайней мере, если мы рассматриваем реально сложные вещи, когда послал в видеокарту считаться, а сам ушел покурить. И предполагается, что данные 1 раз направлены и 1 раз результат придет, без постоянного обмена с внешней программой.

Не знаю, детально не копался. Это попросту статистика по многим подобным случаям.

0

Сообщение от Beltar По крайней мере, если мы рассматриваем реально сложные вещи, когда послал в видеокарту считаться, а сам ушел покурить. И предполагается, что данные 1 раз направлены и 1 раз результат придет, без постоянного обмена с внешней программой.

Не думаю, что можно один раз послать данные для решения системы 10000 уравнений и видеокарта сама все решит. Данные придется посылать порциями много раз для разных операций. А уж про численное решение систем диф.уравнений можно и не говорить.

0

Я когда то задумывался , а почему народ не использует VBA, и его достаточно для написания простых
информационных систем прикладного значения, но видимо существуют мифы, что VBA это какая то
отстойная хрень для офисного планктона и серьезному программеру не стоит об него мараться, а
если он скажет своим коллегам кодерам, что он всерьез юзает VBA , на него посмотрят как на
моль.

0

Я видел такие системы, даже на Visio, тем более в Visio рисунки удобные объекты. Точно так же у меня сдохли АРМы в странном формате .adp, когда появилась Win7. Пришлось переписывать их на норм. инструментарии.

Но как бы был и обычный Visual Basic.

Малое использование профессионалами означает и мало экспертной информации. Кроме того, а как подключить какую-нибудь стороннюю библиотеку, если нужно?

Принципиальная проблема - VBA-код хранится вместе с данными, что радикально усложняет жизнь. Я использую БД Access для лок. баз, хотя поработав немного с SQLite, думаю, что может в след. раз на нем делать, преимущество как бы подавляющее, но я не пишу в Access никакого кода, только данные.

VBA применяется в iFix.

0

Сообщение от avedeo а почему народ не использует VBA

Потому, что есть инструменты удобнее и лучше.

0

Сообщение от avedeo и его достаточно для написания простых информационных систем прикладного значения,

Может быть и потому, что простые информационные системы не очень то и нужны кому то.
Если на предприятии будут делать кучу простых, несвязанных между собой информационных систем, да еще разными людьми и на разных средствах, то про целостность данных можно забыть.
А в РФ есть еще такая страшилка, как импортозамещение. А ну как сверху прикрикнут - Эй, вы! Почему на вражеской винде, а не на скрепном линухе!? И чо тогда с этим VBA делать?
Я это не из пальца высасываю. Просто сам в нулевые делал для нескольких контор (совсем государственных) простые информационные системы на Access и VBA. В одной из них они до сих пор работают и радуют коллектив. А мне за небольшую копеечку иногда приходится их обслуживать (то слегка поменять что то, то на новые компы перенести и настроить). И с целостностью данных бывают проблемы, и на импортозамещение им сверху иногда намекают.

0

Осталось только найти тех 3.5 программистов, которые будут что-то писать под этот Линукс. Щаз пусть вот пусть ко мне подойдут, я просто скажу, что, в принципе, на Delphi в Линукс можно, и кто-то даже пробовал, только я понятия не имею, как под него писать. Давайте изучу, вы мне это оплатите, т. к. по видосикам с ю-тубчика такие вещи не делаются. И тогда перепишу систему, которая 7 лет без сбоев работает. Годика через два. А на это время я ее вырубаю, т. к. вас она, получается, не устраивает. А если устраивает, то на фига переписывать? Да и обновы на винде последние все стоят по организации. Вообще, я с этим импортозамещением, в принципе, не согласен, оно обречено, но я не буду распинаться почему, и как я считаю, надо.

У меня тут вон китайцы оборудование смогли запустить, с которым после ухода западных поставщиков, никто из наших не справился. У них там самый обычный софт, вроде, того же MS SQL Server. Давайте всё бросим и побежим переделывать на каком-то доморощенном форке Postgresql под линукс.

Сообщение от voraa Если на предприятии будут делать кучу простых, несвязанных между собой информационных систем, да еще разными людьми и на разных средствах, то про целостность данных можно забыть.

А их и делают. Именно так и делают. А потом это связывать вместе, голова распухнет, в отличие от внедрения изначально продуманной системы. Потому что спецы, умеющие делать, как надо, и деньги, чтобы оплатить этих спецов, находятся где-нибудь в "Росатоме", "Газпроме", "Сухом", "Сбербанке",... Это вопрос из разряда, почему Россия сейчас контролирует более половины рынка АЭС, от строительства до полного цикла обслуживания, или на 30 лет опережает всех в системах ПВО, что требует какого-то просто невообразимого уровня организации работы сотен предприятий, но не может, порой, нормально сделать довольно простые вещи.

0

Сообщение от Beltar Осталось только найти тех 3.5 программистов, которые будут что-то писать под этот Линукс.

Прикинь, я - не программист, но уже больше 20 лет пишу под линукс. Можешь посмотреть, что у меня на гитхабе лежит.
В общем, не нужно фантазировать.

Добавлено через 2 минуты

Сообщение от Beltar не может, порой, нормально сделать довольно простые вещи

Элементарно: "простые вещи" требуют новых вливаний, а АЭС - база СССР!
Вот, если мы таки наконец восстановим социализм, для начала, ну и, естественно, возобновим вменяемое образование, то лет через 50 в России появятся специалисты. А пока, со всеми этими ЕГЭ/ОГЭ и прочим дебилизмом, мы катимся в /dev/null.
Я вряд ли доживу до 2040, но вот сильно не завидую тем, кто доживет. Им придется "лечиться ромашкой", "учиться в ЦПШ" и, возможно, вообще жить собирательством и охотой…

0

Если ты пишешь, значит ты программист. Если ты пишешь 20 лет, значит хотя бы в том, что тебя касается, разбираешься. Но не получится нормально подготовить программиста под др. ОС за пару месяцев. А если еще и инструментарий придется менять? При этом простота многих вещей для опытного специалиста обманчива. Ему миллион вещей может казаться очевидным, но для незнакомого именно с этой технологией, это будет совсем не так, даже если чел знает что-то похожее.

0

Сообщение от Beltar Именно так и делают. А потом это связывать вместе, голова распухнет, в отличие от внедрения изначально продуманной системы.

Иногда просто технические условия не позволяли делать как надо. Я вот когда делал, многое хотел и предлагал связать. Но нет. "У нас для этой системы рабочие места в другом крыле будут, а туда еще сеть не проведена". Вот и приходилось разъединять их. В одной системе учетные номера и названия. В другой учетные номера и названия. И не всегда они совпадают для одних и тех же сущностей. В одной удалили выбывшее, другим сказать об этом забыли.
А объединять потом, так на это еще и деньги нужны. За так никто (и я в том числе) работать не хочет.

0