Языки программирования: прошлое, настоящее и будущее / Дмитрий Завалишин (ГК Digital Zone)

Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
--------
--------
Saint HighLoad++ 2022

Презентация и тезисы:

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

[Alexey-gpvc]

- слайд на 27:00 минуте - довольно странные примеры языков, если кратко - у Python ещё (3.12) нет JIT (PyPy не в счёт), JS(V8/Deno) в этом классе самая шустрая и, внезапно, LuaJIT может быть на уровне.
- слайд на 41:00 минуте - видимо имелась в виду не "строгая", а "статическая" типизация? т.к. иначе масло масляное с третьим пунктом, да и по контексту понятно, что речь про статику.
Видел упоминание функциональных структур данных, жаль не раскрыли тему. В целом - видно, что сказали треть от задуманного. От просмотра ощущение, что доклад начался, но даже не перешел к основной части, не говоря уже про выводы.
Некоторые мысли интересные, многие темы спорные.
p.s. Go - новый язык? смешно)
p.p.s. - про такое уж преимущество JIT хотелось бы на слайдах видеть хоть какой-то бенчмарк/код/график/пруф т.к. с одной стороны логика понятна, но, с другой стороны, в повседневке все мы видим как jit сливает. И не на проценты, а в разы и даже порядки.

[vadimrumyantsev]

Часть претензий к статической компиляции является на самом деле претензиями конкретно к компилятору Си. В языках с развитой модульной структурой (начиная, страшно сказать, с современного Фортрана) код вполне разворачивается вглубь.

[lmqwbim]

Почему про ос фантом ничего не слышно?

[alievrauf]

Маленькое уточнение: "понятно, что выживают сильнейшие" в контексте эволюции совсем не понятно. Сильнейшие не выживают, выживают наиболее приспособленные

[vladshut]

30:41 ошибка, у Go управляемая память

[fqnnqlg]

Все ясно, Java (JVM) - forever and ever!😉

[AOperatingSystem]

39:15 Ну, есть аннотации и в Go и в C#

[fixgn]

Мне не хватило каких-то выводов, реальных примеров хороших и плохих подходов. Такое чувство, что весь доклад была подготовка к чему-то и не случилось апогея

Ну и большинство тем пройдены по верхам... Хотелось бы более глубокого разбора, особенностей языков, подходов и т.д.

[artemsokolov]

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

аутсорс на госуху такой аутсорс, конечно

[marksto]

"Сущности собираются где-то там, куда-то прилетают, и для того, чтобы понять, что происходит вот в этом объекте/в этой функции, нужно проводить расследование, которое занимает 2-3 часа... и ужасно то, что на самом деле вы не в состоянии вычислить все пути поступления этой информации в эту точку... и, когда вы начнёте модификацию программы, вы обязательно потеряете какой-нибудь из путей, потеряете какой-нибудь краевой случай... и программа ваша взрывается!"
Батенька, да у вас high coupling and low cohesion... Прописываю вам ФП, чистые функции и иммутабельность.

[xjhnfgn]

C# и Java догнали по производительности Си?

Каким образом сборщик мусора может быть быстрее ручного управления памятью в теории

[usovmv]

Крутой доклад от программера с офигенным опытом. Кому кажется скучным - вы в другой Вселенной просто.😅

[sirokuza]

Заводы которых нет управяются бизнес процессами.

[flamehowk]

44:35 Не придем. Эта модель устарела и не соответствует возможностям эффективного масштабирования вычислительных систем. Есть такая наука - Кибернетика. Вот ее стоит учить, чтобы понимать, к чему мы неизбежно придем... А то, что Вы описываете - это для тех, кто ничего не смыслит в управлении и распределении задач. Особенно с учетом требований к безопасности и строгости вычислений, при сохранении скорости обработки данных.

[denispronin]

10000 машин и улучшение производительности на 1% дает возможность сэкономить 100 машин, а не 10

[icywiener]

Основная причина создания авторами каждого очередного языка- осознание фатального недостатка уже существующих: их создали НЕ ОНИ! Эта проблема появилась еще в начале 90-х и сейчас доведена до абсурда. Каждый год новые названия и аббревиатуры в вакансиях. Абсолютно никакого смысла нет учить что-то новое, потому что сколько вакансий- столько названий и технологий. Все это появляется и умирает чуть ли не за месяцы. Дурдом.

[flamehowk]

45:15 От Ваших верований ничего не зависит. К счастью... СК дожила до сегодня и еще долго будет жить в силу целого ряда совершенно очевидных причин, которые, явно, для Вас не явны. Далеко не нужно ходить, худшая практика, которую только можно придумать - сборщик мусора, Вами определяется как неизбежное будущее, хотя ему давно уже во всю пилят гильотину и точат для нее ножи... Вот как раз этот динозавр неизбежно будет заклан.

[flamehowk]

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

[-dubok-]

Вообще не согласен, что есть плохие и хорошие языки программирования, которые помогают писать понятный код. На чём угодно можно написать как понятный, так и не понятный код. Чтобы писать понятно, нужна культура программирования, нужно сперва писать документацию, нужно документировать каждую функцию и все её параметры. Тогда не нужна будет никакая типизация на уровне языка и всё будет понятно. Проблема программистов в том, что они сперва пишут, а потом думают. А нужно сперва думать, создавать схемы, инженерные конструкции в голове, на бумаге, а только потом это всё реализовывать. В эту же культуру входит и методика TDD.

[flamehowk]

42:05 Объектное Программирование это ни разу не правильно! Особенно, когда его ставят в позицию "правильности", оппозитно к вообще единственно возможному и реальному Процедурному Программированию, как "неправильному". Объектное Программирование, равно как и любое другое (вроде функционального), не способно существовать без использования Процедурного Программирования. При этом оно похоже на явное недоразумение, смысл в котором может иметь место только в узком спектре задач. И когда некоторые "программисты" оказываются не способны написать хэллоуворлд без использования ООП, то их пора вычеркивать из списков тех, кому вообще разрешено приближаться к программированию, ибо именно из-за них потом черт ногу сломит прежде, чем разберется в их мегатонных кодах.