усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
Первобытное общество
усы2
tonsky

Я тут опять записался в подкасте и затеял спор о популярном заблуждении.

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

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

Так вот, языки программирования, как инструмент, сделаны таким образом, чтобы человеку, конкретному биологическому виду с вполне конкретным строением мозга, было удобно возможно с ним работать. И тут выясняется, что это конкретное биологическое существо медленное и невнимательное до невозможности. Соответственно, размер программы ограничен не временем, которое существо просидит за клавиатурой, а ее сложностью. Для компьютера нет никакой проблемы жонглировать шестьюстами мутабельными переменными в произвольном порядке. Для человека — есть. Человек запутается и ошибется, и это не ограничение компьютера, языки вообще не ограничены возможностями со стороны компьютера. Это ограничение человека. Он не смог отдать правильную команду, причем даже не в реальном времени, а в спокойной обстановке, заранее, с произвольно большим временем на подумать.

И это все приводит нас к идее о наращивании уровней абстракции. Чтобы количество деталей в каждый момент времени помещалось человеку в голову, вводится новый уровень, на котором целые кластеры деталей собираются и прячутся «под капот». Классно. Работает. Это и есть прогресс. Каждый следующий уровень позволяет строить качественно новые и/или бо́льшие системы. Структурное программирование, управление памятью, реляционная модель, символьные вычисления, модель акторов, иммутабельность и так далее.

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

Вернемся к исходному постулату. Человеку дали ассемблер, у него куча времени, здоровья и нет проболем с мотивацией. Если он будет писать просто на ассемблере, он очень быстро упрется в предел своих способностей. Напомню, у нас в гостях не абстрактный всемогущий мозг в банке, а обычный программист (или сколь угодно большая группа программистов), у которых есть биологические пределы. Как бы им ни хотелось, но предел сложности реален и хорошо ощущается, и он не сдвигается лозунгами вроде «будем сильнее стараться» или «просто подольше посидим». Если им захочется пойти дальше, им придется повысить уровень абстракции.

Теперь внимание: они могут либо воспользоваться одним из уже известных способов, которые они наблюдали в существующих языках, либо придумать что-то качественно новое. Поскольку мы говорим об обычных людях и вообще об эксперименте на применимость ассемблера, а не о передовых исследованиях в Computer Science, считать, что они изобретут качественно новый способ повышения абстракции повода нет. Значит, чтобы повторить существующий софт на ассемблере, нашим героям придется сделать себе инструменты по образу и подобию того, что мы уже знаем, и писать уже на них. Что и требовалось доказать. (Замечу, что речь не идет о создать в точности условный Хаскель, а скорее о том, чтобы повторить идею Хаскеля. Хаскель как реализация в этом контексте не несет ценности, а как идея — несет. Если она там, конечно, есть — ну или подставьте вместо него любой другой язык с идеей).

Sanity check. Эксперимент кажется абстрактным, но в реальности он ставится каждый день. Софт, написанный на языках с маленьким набором абстракций, существует, его полно, есть очень большой, есть даже ультрасложный, и даже его можно сказать что много. Язык не ассемблер конечно, но близко — C и C++, на которых тебе и браузеры, и ОС, и игры, и БД. Все это миллионы строк. И это как раз тот случай, когда недостатки языка разработчики вынуждены компенсировать прямо в проекте, чтобы хоть куда-то продвинуться. В каждом из таких проектов есть все давно знакомые нам способы борьбы со сложностью, только свои, кривые, наколенные, родные.


  • 1
Скажите что-нибудь очевидное — и все с вами согласятся!

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

Диалектический материализм в деле, да?

Во-первых, запоминание идёт не количеством информации, а количеством фреймов. Много связанной информации обрабатывается лучше, чем мало несвязанной.

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

Это безотносительно к ассемблеру. Против самоката можно соревноваться на любом велосипеде.

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

В общем, выходит гипотеза лингвистической относительности в применение к языкам программирования?

"В каждом из таких проектов есть все давно знакомые нам способы борьбы со сложностью, только свои, кривые, наколенные, родные."

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

А я со своей стороны предложу альтернативное заключение: если существуют тонны кода на C++ со своими наколенными решениями, то это кому-то да нужно.

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

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

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

Пример: язык Elm с первоклассными сайдэффектами и реактивностью(это прям bleeding edge). Но обязательно ли для этого создавать новый язык? Похоже нет - Cycle.js обьемом 100 с копейками строк дает все теже свойства(кроме конечно типобезопастности - это уже к flow или typescript) - полная изоляция сайдэффектов и написание 99% процентов времени абсолютного pure кода.

Хорошие концепции обычно _простые_ и для их реализации не нужно практически ничего в языке. И если их можно реализовать без написания нового языка то может так и стоит делать?

Да, абстракции важнее языков. Это не значит, что языки не нужны — там куча всего появляется дополнительного. В каждой конкретной ситуации нужно думать отдельно.

STEPS Toward The Reinvention of Programming http://www.vpri.org/pdf/tr2007008_steps.pdf

Edited at 2016-07-07 11:42 (UTC)

Как тут не вспомнить известную хохму о том, что введение нового уровня абстракции позволяет решить любую проблему, кроме одной: "Слишком много уровней абстракции".

Вот очень красивая столбовая дорога: "Каждый следующий уровень позволяет строить качественно новые и/или бо́льшие системы. Структурное программирование, управление памятью, реляционная модель, символьные вычисления, модель акторов, иммутабельность и так далее."

Но, кажется, в какой-то момент на этой дороге что-то пошло не так. Где вся эта молодая шпана, которая сметёт хотя бы сишечьку?

\\Структурное программирование, управление памятью, реляционная модель, символьные вычисления, модель акторов, иммутабельность и так далее.

Есть сомнения, что вот это вот написанное,
есть "уровни абстракции".

Если отследить, то вопрос ухода от асма определялся двумя вещами -- наличием многих архитектур процессоров и перехода от представления кода программы в виде набора записей (на перфокартах, ага) к текстовому.

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

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

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

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

Так какие же тогда еще уровни абстракции мы можем найти/назвать?

Я тут голосую за "интерактивность" -- идею о том что код может представлять не просто реализацию какого-то алгоритма, какой-то функции, а целую какую-то систему с внешним поведением и закрытыми за-черноящечной внутренней реализацией.
Объектно-ориентированное программирование, ага.
Которое основано на идее обмена сообщениями по протоколу и инроспекции.

И как бы... все.

Современное программирование ИМХО больше никуда не продвинулось.
Оно даже эту интерактивность-диалоговость не очень качественно реализует.
Обмен сообщениями еще туда-сюда, а интроспекции практически нигде и нет.

Я тут в первую очередь на последжних времен ФПшный хайп тыкаю пальцем -- потому что, а что они реально такого сдеали, чего раньше не было?
Просто реализовали возможность записывать те же алгоритмы что и раньше, но типа другим, безопасным, способом...

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

Вместо присущей настоящей инженерии стандартизации, массового производства и мат.методов.

  • 1
?

Log in

No account? Create an account