суббота, 21 сентября 2019 г.

[prog.history] Между тем COBOL-у исполняется 60 лет и исчезать он никуда не собирается

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

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

Свежая статья на тему COBOL-а: "COBOL turns 60: Why it will outlive us all"

А я нескромно дам ссылочку на аналогичную запись из этого блога, написанную к 50-летию COBOL-а. Там ряд интересных фактов приведен. Ряд из которых, наверное, продолжает оставаться актуальным до сих пор.

пятница, 20 сентября 2019 г.

[prog.facepalm] Никогда такого не было и вот опять: Ошибки аллокации достаточно бесполезно ловить в пользовательской программе.

Ну вот как же задалбывают горе-программисты, которые проповедуют вот такие взгляды:

Ошибки аллокации достаточно бесполезно ловить в пользовательской программе.

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

Во-вторых, как минимум на десктопных Linux по умолчанию включён overcommit, который делает невозможной локальную обработку ошибки выделения памяти.

В-третьих, если вы пишете прикладную программу, близкую к системной в плане управления ресурсами (веб-сервер, сервер БД), то у вас и так весьма особенные нужды в выделении памяти. Часто используются пулы, маппинг файлов/анонимной памяти прямо от системы. Куча в первую очередь интересна "совсем прикладным" программам, которым нехватка ресурсов неинтересна.

Уже столько раз эта тема поднималась, в том числе и мной в этом блоге (пример), что уже нет сил расписывать контраргументы в очередной раз.

Хотелось бы надеяться, что чем больше будет таких криворуких говнокодеров, тем больше будет спрос затем на услуги тех, кто более ответственно подходит к написанию кода. Но, что-то практика показывает, что слова про качество -- это одно, а как дело доходит до обсуждения конкретных работ, так начинается "а что так долго, а что так дорого"...

Так что особого энтузиазма по поводу светлого будущего софтостроения я не питаю :(