четверг, 7 июля 2016 г.

[prog.flame] Прочел тут прекрасное на тему непризнанных индустрией средств борьбы со сложностью

Сперва на глаза попалось вот это. Буквально на следующий день -- вот это. На мой взгляд, авторы обоих опусов стенают об одном и том же: ну вот есть же классные средства борьбы со сложностью, ну есть же. Только вот клята индустрия как сидела на старых и допотопных инструментах, так и сидит. И в упор не принимает продвинутых инструментов с высоким уровнем абстракций. В общем, не хотят массы писать на нормальных языках, сидят, редиски, на С и C++. Ну в лучшем случае на какой-нибудь убогой Scala. Нет, чтобы взять Хаскелль или Кложу...

А мне вот вспоминается 1995-й год. 486-й компьютер, с тактовой частотой 40MHz, 4MiB RAM. Windows 3.11, 150-ти страничный документ в Word 6.0. Нормально редактируется, разве что проверку орфографии приходится отключать. 16-битовое приложение, в 16-битовой ОС.

Для тех, кто не понял: всего четыре(!) мегабайта памяти и всего сорок мегагерц. И 16-битовый код.

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

Вот и получается, что C и C++, как жили себе, так и живут, ибо хоть как-то позволяют справляться и со сложностью, и с расходом ресурсов. Пусть даже это и не вписывается в чьи-то представления о прекрасном.


PS. Может быть этот пост и не появился бы, если бы мне сейчас не требовалось за пару дней найти способ так разместить один набор данных в памяти, чтобы он занимал не 500MiB, а хотя бы 150-170MiB.

Отправить комментарий