Federalist No. 6

На самом деле я считаю важным только одну вещь: чтобы самые простые выгодные контракты заключались и исполнялись. Более точно речь конечно идет про трагедии общин и дилеммы заключенных, но технических выкладок не будет. Например правило "всегда плати художникам и программистам, за тестовое, которое занимает день" — правило хорошего тона. У нас, если судить по жалобам в интернете, его не соблюдают примерно никогда. Конечно с точки зрения бизнеса идея "всегда плати" за то, что можно получать бесплатно звучит странно. Но почти все кооперативные стратегии имеют смысл только если ситуация систематически повторяется. Хотя вообще-то, именно в такой ситуации мы и живем. А также, такая стратегия не требует перекроить весь рынок. Просто если все контрагенты знают, что Дарк-Корп-Мафия всегда всех кидает, а Лайт-Корп-Альянс всегда платит свои долги, то все, кто хотят сотрудничать, а не кидать в ответ предпочтут Лайт-Корп-Альянс. Если рассматривать интеллектуальный ландшафт, то есть два вида хороших сделок: те, которые есть прямо сейчас, просто в другом месте. Либо те, что чисто технически являются оптимальными в глазах всех кто шарит в этой теме и не ангажирован в пользу современных практик. Почти все такие сделки уже были в истории, просто мы отошли от них. Как, например, индексируемый интернет. Сейчас большинство контента в неиндексируемых проприетарных сервисах и это результат удобства таких сервисов, а не то, что пользователи заботятся об анонимности. Проблема исполнения таких контрактов в том, что сперва это требует дополнительных расходов, а все остальные контрагенты не будут добросовестны. Тот же Uber не сделал такси полноценным аналогом личного авто, на которое ты можешь рассчитывать в любое время и в любом месте. Из-за желания держать низкие цены и конкурировать с общественным транспортом агрегаторы такси стали скорее потогонкой для таксистов, а не средой, где человек без машины легко заключает контракт с человеком за рулём. Есть принцип хуже это лучше (https://en.wikipedia.org/wiki/Worse_is_better), мой принцип better is better. В эволюции нельзя создать механизмы B, C, D, E, F, чтобы когда появится адаптация A она работала очень круто. Если A не дает преимущества, то дальнейшее не разовьется. Цивилизация удивительно неразумна, поэтому те кто действовал из идеи хуже это лучше и делал только А, заняли большую часть рынков. Но отдельные люди разумны. Поэтому можно потратить ресурсы на B — правильную деловую инфраструктуру возникающего института. Так, чтобы его можно было улучшать и перестраивать, не застревая в механике неразумной эволюции. Я не прошу идеальной разумности, я требую один маленький шаг разума, чтобы мы отличались от природы. Можно подумать, что я говорю о технологиях. Почти совсем нет, речь только о праве, технологии лишь нюансы. Почти все вопросы того, какую техническую архитектуру будет иметь инфраструктура это политико-правовой вопрос, а не технический. Собственные сайты vs страницы в соцсетях, котел в доме vs центральное отопление, автомобиль vs общественный транспорт. В большей части это вопросы права и его инерции, а не технологий. Люди переплывают океаны и тонут в лужах Дополнение. Иллюстрация к принципу "лучше это лучше": https://www.paulgraham.com/icad.html Если вы посмотрите на эти языки в порядке убывания: Java, Perl, Python, вы заметите интересную закономерность. По крайней мере, вы заметите эту закономерность, если вы занимаетесь программированием на Lisp. Каждый из них постепенно становится все больше похожим на Lisp. Python копирует даже те функции, которые многие разработчики Lisp считают ошибками. Вы можете переводить простые программы на Lisp в Python строка за строкой. На дворе 2002 год, а языки программирования почти догнали 1958 год. Догоняют математику. Я имею в виду, что Lisp был впервые открыт Джоном Маккарти в 1958 году, и популярные языки программирования только сейчас начинают догонять идеи, которые он тогда разработал. Как такое могло быть? Разве компьютерные технологии не меняются очень быстро? Я имею в виду, в 1958 году компьютеры были гигантами размером с холодильник, обладающими вычислительной мощностью наручных часов. Как могла такая старая технология быть актуальной, не говоря уже о превосходстве над последними разработками? Я вам скажу, почему. Дело в том, что Lisp изначально не задумывался как язык программирования, по крайней мере, не в том смысле, в котором мы его понимаем сегодня. Под языком программирования мы подразумеваем то, что используем, чтобы сказать компьютеру, что делать. Маккарти в конечном итоге намеревался разработать язык программирования в этом смысле, но Lisp, который мы в итоге получили, был основан на чем-то другом, что он сделал в качестве теоретического упражнения — попытке определить более удобную альтернативу машине Тьюринга. Автор: Light