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

Но в Фортране модульность появилась только в Фортран 90, а раньше она появилась в языке, страшно сказать, Модула... в 1975-ом)

Ни то, ни другое. Если бы так было, мир бы не захватила винда в 90-х. На субстрате человеческой глупости законы выживания извращены.

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

@@icywiener5421 почему это? Винда как раз наиболее приспособлена была к человеку в отличие от DOS и прочих безоконных систем.

Пример с датчиком температуры был же в конце)

да, а в простейшую математику не смог с расчетами сэкономленных машин при улучшении производительности ПО на 1%. Но джавистам это простительно. Он же сам сказал, что Java допускает, что программист имеет право чуть-чуть что-то не понимать, что он делает

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

@@QuadRomb > Самые производительные языки без GC > "Производительность и наличие сборщика мусора между собой не связаны"

​@@user-xj9hn3fg8nЯ не редактирую, то что я написал. У меня было написано- "напрямую не связаны". Кстати, ассемблер, при должном тщании, наверное позволит написать Вам самое-самое производительное приложение. И к такому приложению будет несколько риторических вопросов: 1) сколько будет стоит это тщание? 2) сколько в нём будет ошибок, 3) как такой результат можно будет дальше хотя бы поддерживать, а не то, что развивать?

​@@QuadRomb Что же значит тогда "напрямую" связаны? Корелляция четкая - GC это оверхед. В реально нагруженных системах где каждая аллокация/деаллокация не вес золота ни о каких GC речь не идёт или его использование стараются свести к минимуму. Ассемблер ваша идея, не вижу смысла идти в крайность. Пример отличной скорости и надёжности - Rust, при использовании которого у Вас будет гарантировано меньше ошибок связанных с памятью, чем даже при использовании условной Java, C#, Go. И исходя из использование Rust ответа на ваши вопросы: 1) тщание у вас, здесь же скорость разработки будет ниже, которая компенсируется на порядок более надежным кодом 2) Гарантировано меньше чем при использовании GC 3) С использованием SOLID такой проект можно развивать и поддерживать проще, чем условно написанный проект на Java с корявой архитектурой

@@user-xj9hn3fg8n "Корелляция четкая - GC это оверхед" Дьявол в деталях. На каких этапах это оверхэд? На старте? Что такое JIT, я думаю, Вы знаете. Узлы Кафки неделями можно не перезапускать - а это один из самых популярных компонент шин данных в высоконагруженных проектах. То, что у неё узлы будут стартовать раз в месяц, условно, за 8 секунд, а не за 5 - никого не волнует, и уж точно, абсолютно ни на что не влияет. А это, напомню, Java чистой воды. Rust - это тот же С++, по большому счёту. Просто относительно молодой и без такого груза унаследованных решений. Причём, С++ тоже уже не тот, что в каком-нибудь 2000-ом. Писали или пишут ли большие высоконагруженные проекты на C++? А как же! Почему бы и на Rust их не писать? Будут пробовать, к гадалке не ходи. Но их будут продолжать писать и на управляемых языках, и делать это не без успеха. А уж в поддержке и скорости добавления новых возможностей в приложения у управляемых языков оч-ч-чень большая фора перед неуправляемыми.

Вы видели другой легаси код?

Ну если брать популярные языки, каждый привносит что-то свое уникальное: Rust про безопасную работу с памятью без GC, Go про лёгкую конкурентность и т.д. Есть куча хобби-языков ни о чём и они-то вот популярность не получают

Универсального ЯП "на все случаи жизни" быть не может. Все определяется конкретной задачей, требованиями заказчика и/или наличием "под рукой" имеющихся проверенных практикой инструментальных средств. Сейчас разработка новых языков программирования и соответствующих им IDE, скорее всего, преследует именно коммерческие цели. В принципе, при существующих технологиях разработки ПО и самих методов программирования , имеющихся наборов инструментальных средств для разных ОС более чем достаточно и выдумывать что-то своё это значит "за деревьями не видеть леса".

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

@@vladig6649 Да, это беда. Поэтому я и работаю над новым ЯП уже много лет, пытаясь постепенно исправить все эти моменты. Благо - это не коммерческий проект, поэтому в ущерб времени, есть возможность сделать все максимально качественно...

@@flamehowk Универсального ЯП "на все случаи жизни" быть не может. Все определяется конкретной задачей, требованиями заказчика и/или наличием "под рукой" имеющихся проверенных практикой инструментальных средств. На мой взгляд, сейчас разработка новых языков программирования и соответствующих им IDE, скорее всего преследует именно коммерческие цели. В принципе, при существующих технологиях разработки ПО и самих методов программирования , имеющихся наборов инструментальных средств для разных ОС более чем достаточно и выдумывать что-то своё это значит "за деревьями не видеть леса". Определенные условия возникают при разработке ПО для разных операционных систем. Поэтому исходный текст на некоторых языках программирования компилируется (а точнее переводится) в некоторый единый промежуточный код, который исполняется соответствующей виртуальной машиной работающей на разных операционных системах (живой пример Java). Но за кроссплатформенность все равно нужно чем-то платить. Скорость современных CPU достигла такого уровня, что грань между программой откомпилированной чисто в машинные инструкции и программой в промежуточном коде попросту стирается и спорить тут о быстродействии и выигрыше в производительности попросту не имеет смысла.

@@vladig6649 "Универсального ЯП "на все случаи жизни" быть не может." Вы удивитесь, но он есть - алгоритмический язык называется. Конечно же, если речь идет именно о языках программирования, а не о языках описания, стилей или еще чего-то подобного. "Все определяется конкретной задачей, требованиями заказчика" Еще ни разу не видел, чтобы под требования заказчика разрабатывали новый язык программирования. То, что некоторые языки заняли определенные ниши и в них доминируют - это да, но вот что бы прям так как Вы говорите... дак нет. "На мой взгляд, сейчас разработка новых языков программирования ... преследует именно коммерческие цели." В течении своей жизни мне приходилось иметь дело с 18 различными языками и ни разу я не заплатил ни одной копейки ни за один из них. И не потому, что я - пират, а просто потому, что они все - безплатные. А некоторые из них еще и с открытым исходным кодом (компиляторы/трансляторы имеются ввиду, конечно же). Не сильно то с таким подходом заработаешь. И даже история возникновения многих из них говорит о том, что как правило их начинают разрабатывать по причинам весьма далеким от коммерческого интереса. Один из немногих подобных случаев был упомянут докладчиком в видео. Так что я не согласен с Вашим представлением. Это еще могло бы быть уместным, если бы реально использование ЯП можно было бы удачно монетизировать. Но в реальности все наоборот - приходится прикладывать усилия, чтобы распространить новый ЯП и подтолкнуть программистов его изучать и использовать. "более чем достаточно и выдумывать что-то своё это значит "за деревьями не видеть леса"" Достаточно было и машинного языка. (Неужели программисты за деревьями леса не видели?) Но я не думаю, что Вы были бы от восторга от программирования на нем. Когда все лопаты вокруг тупые, зазубренные и с кривыми держаками, нужно очень сильно не замечать деревьев, чтобы не понять, что нужно разработать и сделать одну качественную, удобную и эффективную лопату, вместо десятка огрызков, с трудом выполняющих свою функцию. "и спорить тут о быстродействии и выигрыше в производительности попросту не имеет смысла" А кто ж с Вами взялся об этом спорить? Чтобы спорить - нужно иметь в этом смысл. А смысл может быть только один - познание истины. Вы же предпочитаете пребывать в своих иллюзиях, поэтому аргументы противоположной стороны для Вас "попросту не имеют смысла". Ну вот и не спорьте. Поживите еще лет с 10 и Вам подобные любители ООП, превращающие любое ПО в мегалодона, способного забить любое количество памяти и пожрать любой объем процессорного времени, еще донесут до Вашего внимания те самые недостатки подобного подхода, о которых Вам со мной пока "не имеет смысла спорить". А это время неизбежно наступит, потому что рост производительности процессоров и памяти уже практически остановился, а ООП-фанатики, которые даже не хотят думать об оптимизации производительности, энергозатратах и прочих нюансах, только начали разгоняться в своем процессе масштабирования мухи до размеров слона...

с аналогии заорал

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

@@redneck_prm5429 "ООП возникло естественным путем как надстройка над процедурным программированием" Если над крышей надстроили еще один дом вместе с фундаментом - это еще не говорит о естественности данного процесса. Многоэтажные здания - это совершенно отдельный тип конструкции и их проектировать нужно с нуля именно как многоэтажки, с учетом всех особенностей конкретной конструкции. "И возникло не просто так, а как ответ на проблемы" В школе, когда учитель задает вопрос, многие ученики тоже дают ответы... только не правильные. Популярность ООП + резкое падение качества кода = кто-то у кого-то просто списал. А кто списывает - хорошо известно... обычно это самые ленивые и хитрые ученики, хотя и не самые умные. "но каких-то новых подходов по их решению вне рамок ООП пока не заметно" Так всегда бывает, когда пойдешь не тем путем и вопрешься в какой-нибудь тупик, а мужества признать, что пошел не туда - не хватает. Ну или черные очки, которые нацепил "для крутости" слишком уж затмевают свет в темных местах... "поэтому приходится обходиться решениями на уровне архитектуры приложения" Двоечникам, которые не умеют сами находить решения, всегда приходится "обходиться чьими-то". Что мы и наблюдаем...

На мой личный взгляд ООП соответствует основным принципам проектирования - модульности, декомпозиции. Например на С++ я могу используя всю мощь этого языка описать некий класс, помучаться, протестировать, написать гору тестов а потом... а потом пользоваться красивым и аккуратным классом, который всю работу содержит под капотом. В итоге основные принципы соблюдены, понимаемость на высоте, читаемость на высоте и можно с помощью класса спокойно писать другие части программы. Например MacAddress mac = new MacAddress("00:00:fe:2d:12:fe"); mac.increment(3); Console.WriteLine(mac); =========================== 00:00:FE:2D:13:01 ООП - это улучшенное процедурное программирование. Процедуры / функции - великая вещь В 7 главе Совершенного кода Стив Макконел приводит причины создания методов (процедур/функций): * Снижение сложности * Формирование понятной промежуточной абстракции * Предотвращение дублирования кода * Поддержка наследования (да, это только ООП) * Сокрытие очередности действий * Сокрытие операций над указателями * Улучшение портируемости * Упрощение сложных булевых проверок * Повышение быстродействия Стоит отметить, что часть этого функционала точно также выполняют и классы. Да, есть модули и порой классы используются как модули. Но ведь иногда и модули не такие большие, чтобы быть "модулем". Зачем нужно что-то кроме процедур? Да потому что программирование это не только действие - пойди, сделай, сохрани, но еще и реальные объекты. ООП выводит работу с кодом и данными на новый уровень. MAC и IP адреса, IP подсети и интерфейсы это вполне реальные объекты, которые есть в реальной жизни: они имеют некие данные и есть операции, которые можно выполнить над ними. И мне было бы удобно и в коде использовать их как объекты, попутно инкапсулируя код и данные (всю логику) в одном месте, что уже хорошо с точки зрения проектирования (если мы конечно не говорим про Data Orienter Programming). Предполагаю, что хороший процедурный код подразумевает работу с объектами: const int MAC_ADDR_LEN = 6; byte mac[MAC_ADDR_LEN] = get_mac_from_str("00:00:fe:2d:12:fe"); increment_mac(var mac, 3); //передача по ссылке print(mac_to_str(mac)); =========================== 00:00:FE:2D:13:01 Если так и есть, то ООП - лишь логичное развитие процедурного программирования, которое упрощает код за счет всех "сахаров" и открывает дорогу знаменитым ООП паттернам. Если все так, то противопоставлять ООП и процедурку нет смысла (С++ позволяет писать код и с объектами и без объектов). Вот что реально отличается - парадигмы Функционального программирования и программирования ориентированного на данные. Но тут уже каждой задаче свой инструмент наверное.

@@vladimirpo Вы видите один только позитив, потому что трещина на розовых очках еще не достаточно сильно разъехалась, чтобы через нее Вам стала видна болезненная реальность. Но время, когда это начнет становиться очевидным для тех, кто любит все розовое - уже грядет... И как только это время наступит, Вы перестанете считать логичным то, что логичным ни разу не является. Но Вам нужен стимул... и цветочки уже отцвели.

не совсем стыкуется с реальностью, где популярность названными вами языком не растте. Растет она у Го, который простой как дверь и позволяет быстро создавать работающие продукты

Вы предлагаете в замен одной головной боли, накинуть себе ещё больше головной боли в виде дотнета. Если вы за простоту, то вам к Го, учится за два обеденных перерыва, футпринт меньше только у си/раста, по перформансу тоже самое. Если не нравится духота Жабы, возьмите Котлин, красивый и приятный синтаксис и имеется доступ к огромной экосистеме джавы.

А мне понравился доклад - обзорный, ненапряжный

Да ниче вродь. Тебя заставляют может?

да и вообще, всех на россии кто использует богомерзкие американские языки программирования - определить в ГУЛАГ на 25 лет. Одобряю.

и тех кто пользуется англосанкские платформы, уже нет силы это терпеть!