Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Проблема в том, что чтобы такое сделать, нужно таки сделать стандартизированный API Для Декларирования Всего На Свете.
В конечном счете, невозможность чисто логического построения такого API следует из теоремы о неполноте формальных систем. Именно поэтому в разработку включаеются люди, носители знаний, которые отсутствуют внутри логической модели конкретных API
В моей версии будущего API мы избавимся от человеческого участия в документировании
А документирование-то куда денется? Кто как не человек должен описать интерфейс сервиса и его смысловой словарь? Только человек знает, что сервис публикует температуру воздуха и где-нибудь, а в Париже.
Хуже того, может быть такое, что сервис C работает по шкале Цельсия, сервис F — по Фаренгейту, Р — по Реомюру, Z — по Кельвину, а K — по шкале Куковлева. И что с этим бардаком делать?
Документировать!
Документировать для людей или для машин?
Для человека… Замкнутый круг получается :(
Чтобы компьютер-компьютер общались по новому API, нужен код. Чтобы был код, его нужно написать, даже при наличии унифицированного АПИ. (да ладно). А чтобы написать код, нужен или человек, или ИИ.
Собственно, это и есть содержание поста.
Чтобы компьютер-компьютер общались по новому API, нужен код. Чтобы был код, его нужно написать, даже при наличии унифицированного АПИ. (да ладно). А чтобы написать код, нужен или человек, или ИИ.
Собственно, это и есть содержание поста.
Содержание поста состоит в том, что предлагается создание некоего мета-API, которое позволит соединить воедино все возможные API на свете.
Это я к тому, что идее «А давайте встроим все приложения во все приложения» уже не один десяток лет. Идея в итоге порождает жирнейших нестабильных монстров, изучение которых становится сизифовым трудом (пока вы познаете новый API, уже наклепают пачку новых), а сами программы работают как машина Голдберга.
Микрософт таким занимался с самой windows 3.1
Сначала были Windows API и DLL Hell. Революцией №1 стало появление DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoftовской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «in place», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, и возникли MFC, решившие все наши проблемы еще раз.
Но OLE не собиралось, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – их писали не они! Они немедленно исправили этот недочет, создав ATL, которая как MFC, но другая, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoftовской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «in place», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, и возникли MFC, решившие все наши проблемы еще раз.
Но OLE не собиралось, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – их писали не они! Они немедленно исправили этот недочет, создав ATL, которая как MFC, но другая, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Это я к тому, что идее «А давайте встроим все приложения во все приложения» уже не один десяток лет. Идея в итоге порождает жирнейших нестабильных монстров, изучение которых становится сизифовым трудом (пока вы познаете новый API, уже наклепают пачку новых), а сами программы работают как машина Голдберга.
> А чтобы написать код, нужен или человек, или ИИ.
В идеальном случае, достаточно интерфейса/контрактов. Пример из мира PHP – puli/discovery/httplug, «который сам находит адаптеры» – достаточно сделать composer require. Это позволит использовать человека только на этапе написания кода поставщика сервиса.
Но тогда нужно стандартизировать интерфейсы для каждой «категории» апи, что мне не кажется реальным (см. картинку xkcd) для всего подряд.
В идеальном случае, достаточно интерфейса/контрактов. Пример из мира PHP – puli/discovery/httplug, «который сам находит адаптеры» – достаточно сделать composer require. Это позволит использовать человека только на этапе написания кода поставщика сервиса.
Но тогда нужно стандартизировать интерфейсы для каждой «категории» апи, что мне не кажется реальным (см. картинку xkcd) для всего подряд.
К сожалению, мечтам автора оригинала вряд ли суждено сбыться математически в ближайшее время. Мне кажется основная проблема не в интрефейсах АПИ, а в семантике оного. И сколько нибудь внятных методов точного семантического описания систем мы не смогли пока придуматьпока даже для человека. Проблема сложности адаптации АПИ прежде всего в его семантически неполном описании. Скажем, заменить + на * — для реальных чисел интерфейс не измениться, а вот семантика и поведение в граневых условиях — да. А уж результат…
В более сложных случаях еще хуже. С математической точки зрения большинство алгоритмов мало того что обобщаемы, еще и обобщаемы разными способами для одних и тех же множеств.
В более сложных случаях еще хуже. С математической точки зрения большинство алгоритмов мало того что обобщаемы, еще и обобщаемы разными способами для одних и тех же множеств.
На протяжении всей статьи ждал что речь сведется к Онтологиям и OWL.
Не свелась, слава Тьюрингу.
Вообще правда человек выглядит как лишнее звено, но как и формализация самого процесса разработки ПО — неясно что с этим делать, пока что (подчеркиваю). Но взглянуть хотя бы на стандарт ACORD, который покрывает лишь область Страхования, и становится не по себе от обилия и глубины данных.
Не свелась, слава Тьюрингу.
Вообще правда человек выглядит как лишнее звено, но как и формализация самого процесса разработки ПО — неясно что с этим делать, пока что (подчеркиваю). Но взглянуть хотя бы на стандарт ACORD, который покрывает лишь область Страхования, и становится не по себе от обилия и глубины данных.
люблю когда статья расширяет кругозор. Про механического турка историческая отсылка понравилась. Жаль чаще статьи ограничиваются техническим минимумом, без лирических отступлений.
Разве онлайн конструкторы веб-сайтов нельзя считать автономным API?.. Человек говорит: «Хочу вот эту красивую кнопочку. А на нее наложить свойство onclick, которое будет открывать hide объект...» и т.д., и т.п.
Проблема документации в теории сейчас может быть решена с помощью код-анализатора на нейронных сетях, но окупаемость такого проекта, я думаю, будет за гранью разумного(в плохом смысле)…
А проблема изменяемости API может быть также решена с помощью своеобразной программы переводчика из одного API(старого) в другой API(новый), или из одного языка в другой… Но опять же без нейронных сетей, с некоторыми наперед прописанными шаблонами, переход на новый API не будет давать ускорения, а если что-то уже стало за это время deprecated?
Как я вижу будущее: надо создавать что-то наподобие умной нейронной сети, которая будет уметь конвертировать код между похожими языками(Pascal <-> C, Lua -> Python, ...), сама будет понимать иерархию класов и давать возможность сложной замены, содержать несколько шаблонов проектирования. Разрабатываться новые стандарты будут либо с помощью шаблонного программирования(+моментальное добавления нового API, т.к. мы считаем, что шаблоны не содержат в себе багов(были протестированны). Первичную документацию тоже будет легко добавлять, т.к. мы знаем способы «сложения» шаблон, и что каждый из них делает...), либо добавлением новых фич со сложным процессом внедрения(потребуется протестировать, найти места в старом API, которые можно улучшить с помощью этих фич, написать понятную документацию).
Обобщая сказаное в последнем параграфе на известном мне примере, у нас должен получиться своеобразный гибрид компилятора-транслятора,unity3d(простота),MSDN(Microsoft док. по С++ и др. языкам),STL(огромное кол-во шаблонов) и нейронных сетей анализа и оптимизации.(может что еще, да я не могу сформулировать)
В общем, учитывая тот факт, что я не видел хороших примеров программ, подходящих даже первому пункту, такое событие настанет ой как не скоро…
P.S. я еще молод и мало занимался веб разработкой и программированием под мобильные платформы, но могу сказать с точки зрения знаний по своей области(низкоуровневое программирование), что нам для начала нужно перейти на новое поколение языков программирования. Не в том смысле, что нужен более высокий уровень абстракции(хотя и он тоже), а отойти от канонов языка С. Этот язык действительно быстр и могуч, но написание на нем программ под современные платформы с большим кол-вом строк кода превращается в ад.(Для понимания в чем суть проблеммы возмите старый TurboC30(выполняющийся под эмулятором)(могу дать ссылку), и попробуйте написать на нем ассемблерные вставки(asm), графические объекты(graphics.h) и т.д.(там есть помощь по Ctrl+F1) Вы удивитесь насколько просто писать все это в тех далеких 90-х… А сейчас? средства графики — пожалуйста, directx и opengl, разбирайтесь, что нужно написать чтобы нарисовать простой круг; asm вставки — тоже легко, выбирай из 2 синтаксисов и не факт, что заработает; SSE(векторные) оптизации, ха, ну попробуй; а ведь еще, так за 40+ лет не додумались добавить в язык динамические объекты(функции, в частности, для С. Хотя бы возможность получения «сырого» адреса)) Этот язык безнадежно устарел, а как следствие устарели и все производные от него языки, как бы не хотел я этого признавать...(Python из-за этого сильно теряет в скорости) Поэтому сейчас я хочу как раз создать этот язык нового поколения… Пока есть только наброски, и неодобрение в первом чтении(версия 0.01), но надеюсь к версии 1.0 все изменится…
Проблема документации в теории сейчас может быть решена с помощью код-анализатора на нейронных сетях, но окупаемость такого проекта, я думаю, будет за гранью разумного(в плохом смысле)…
А проблема изменяемости API может быть также решена с помощью своеобразной программы переводчика из одного API(старого) в другой API(новый), или из одного языка в другой… Но опять же без нейронных сетей, с некоторыми наперед прописанными шаблонами, переход на новый API не будет давать ускорения, а если что-то уже стало за это время deprecated?
Как я вижу будущее: надо создавать что-то наподобие умной нейронной сети, которая будет уметь конвертировать код между похожими языками(Pascal <-> C, Lua -> Python, ...), сама будет понимать иерархию класов и давать возможность сложной замены, содержать несколько шаблонов проектирования. Разрабатываться новые стандарты будут либо с помощью шаблонного программирования(+моментальное добавления нового API, т.к. мы считаем, что шаблоны не содержат в себе багов(были протестированны). Первичную документацию тоже будет легко добавлять, т.к. мы знаем способы «сложения» шаблон, и что каждый из них делает...), либо добавлением новых фич со сложным процессом внедрения(потребуется протестировать, найти места в старом API, которые можно улучшить с помощью этих фич, написать понятную документацию).
Обобщая сказаное в последнем параграфе на известном мне примере, у нас должен получиться своеобразный гибрид компилятора-транслятора,unity3d(простота),MSDN(Microsoft док. по С++ и др. языкам),STL(огромное кол-во шаблонов) и нейронных сетей анализа и оптимизации.(может что еще, да я не могу сформулировать)
В общем, учитывая тот факт, что я не видел хороших примеров программ, подходящих даже первому пункту, такое событие настанет ой как не скоро…
P.S. я еще молод и мало занимался веб разработкой и программированием под мобильные платформы, но могу сказать с точки зрения знаний по своей области(низкоуровневое программирование), что нам для начала нужно перейти на новое поколение языков программирования. Не в том смысле, что нужен более высокий уровень абстракции(хотя и он тоже), а отойти от канонов языка С. Этот язык действительно быстр и могуч, но написание на нем программ под современные платформы с большим кол-вом строк кода превращается в ад.(Для понимания в чем суть проблеммы возмите старый TurboC30(выполняющийся под эмулятором)(могу дать ссылку), и попробуйте написать на нем ассемблерные вставки(asm), графические объекты(graphics.h) и т.д.(там есть помощь по Ctrl+F1) Вы удивитесь насколько просто писать все это в тех далеких 90-х… А сейчас? средства графики — пожалуйста, directx и opengl, разбирайтесь, что нужно написать чтобы нарисовать простой круг; asm вставки — тоже легко, выбирай из 2 синтаксисов и не факт, что заработает; SSE(векторные) оптизации, ха, ну попробуй; а ведь еще, так за 40+ лет не додумались добавить в язык динамические объекты(функции, в частности, для С. Хотя бы возможность получения «сырого» адреса)) Этот язык безнадежно устарел, а как следствие устарели и все производные от него языки, как бы не хотел я этого признавать...(Python из-за этого сильно теряет в скорости) Поэтому сейчас я хочу как раз создать этот язык нового поколения… Пока есть только наброски, и неодобрение в первом чтении(версия 0.01), но надеюсь к версии 1.0 все изменится…
Представьте, что есть гигантская сеть, связывающая множество галактик и соединяющая разумных существ, которые никогда не встречались ранее. Вопрос следующий: Как они будут общаться, когда они встретятся?
forecast = service.retrieve(WeatherForecast, { GeoCoordinates: … })
А где-то в далекой-далекой галактике, нечто смотрит в наш код и не понимает что такое GeoCoordinates
У 1С тоже есть что-то подобное, но свое
Формат EnterpriseData — тоже словарь, по сути
http://v8.1c.ru/edi/edi_stnd/enterprisedata/1.0/
Формат EnterpriseData — тоже словарь, по сути
http://v8.1c.ru/edi/edi_stnd/enterprisedata/1.0/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будущее API