Является ли API языком?

Еще есть язык танцев, тебя это не волнует?

API это DSL

Не является.

Почему?

Заметь Эллиот написал

a language for communicating

а не язык програмирования
Любую знаковую систему можно рассматривать в качестве некого языка. То есть API язык общения, но не програмирования. В качестве ЯП оно может рассматривася лишь как вырожденный случай.

Это образное выражение.

Заметь Эллиот написал

a language for communicating

Хм. И правда.

Язык - это API + соглашения об именах и сущностях.

луговский - лох..об чём неоднакратно был ткнут. Но популярен среди нюфагов. Новальный уровня ЛОр

И даже цветов. Но ник ТС выдаёт его с потрохами.

API язык общения, но не програмирования.

В видео он не противопоставляет одно другому.

В видео он говорит: when we design a library, we design a language to communicate about something. library создаются для программирования с ними, а не только для того, чтобы кому-то что-то объяснить в предметной области не-естественным языком.

Как бы сказать... Всем изветный ПриветМир это код иллюстрирующий работу с библиотекой ввода-вывода. Он может быть и довольно многообразным если взять printf например. Но это вырожденый случай ЯП. Знание которого недостаточно для того что бы быть програмистом. ЯП он именно програмирования потому что заточен на реализацию алгоритмов.В интерфейсе библиотеки(API) как-таковом нет алгоритмов.

library создаются для программирования с ними, а не только для того, чтобы кому-то что-то объяснить

Только понимай английский правильно:) Communication - это не что-то «объяснять», а разделение на источник, получателя сообщения и протокол общения. Библиотека это описаный протокол общения между твоим и понятным тебе кодом и кодом реализации библиотеки котрый сам по себе может быть write-only лапшой.
И в разделении на програмирование и комуникацию есть глубокий смысл. Ты можещь запрограмировать никому не понятный, но рабочий код. И тебе будет очень трудно с коммуникационной точки зрения совершать арифметические действия если ты не сможешь «комуникацировать» c вторым концом линии связи. Вспомни например ассамблер. Там арифметика есть но своеобразная «машинная»

Какая разница кто там что говорил? Talk is cheap, show me the code (c)

Только понимай английский правильно:) Communication - это не что-то «объяснять»

Да, я неудачное слово подобрал. «объяснить в предметной области» == «описать взаимоотношения объектов предметной области».

API - это словарь (сигнатуры функций) и язык (протокол последовательностей вызовов) одновременно. Цените и лелейте API, если используете или создаёте свой.

Не всегда.

луговский - казел

О, у кого-то похоже жопа болит с тех времен. То есть лет 15 уже, бедняжка.

Почему именно этот вопрос ? Это действительно важно? Какую проблему это решает?

Почему именно этот вопрос ?

Под руку попалось.

Это действительно важно?

Нет.

Какую проблему это решает?

Снимает внутренний конфликт.

Читал книгу по ФП, там ООП обвиняли в том, что у каждого класса по сути свой язык взаимодействия и мол легче выучить 100 функций , чем выучить 100 классов с 10 функциями в каждом.

легче выучить 100 функций , чем выучить 100 классов с 10 функциями в каждом.

Некорректное сравнение. Надо сравнивать 1000 функций с 100 классов, в каждом из которых по 10 функций. Выкинь книгу, аффтар не научился умножать.

P.S. почему-то тег «is a» написан слитно, админы, поправьте, пожалуйста.

Он и должен быть написан слитно. Это шина такая. А троллинг толстоват, надо бы потоньше.

Это не так работает, в FP есть ограниченное число типов, для них создается некоторый стандартный набор функций, а в ООП постоянно создаются новые типы данных, потому методов там априори больше. А вообще FP я не осилил, потому не эксперт. Но то что API это язык для меня очевидно.

в FP есть ограниченное число типов, для них создается некоторый стандартный набор функций, а в ООП постоянно создаются новые типы данных

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

Функциональный подход действительно имеет свои преимущества, в т. ч. связанные и с простотой, но искать их надо не там, где ищет автор этой книги, судя по тому, что ты написал. В этом смысле ООП-язык как раз проще. Потому что проще запомнить названия и назначение методов drow, fill и clear, например, для классов circle, triangle и rectangle (всего 6 названий), вызывая их circle.drow() и т. д, чем запоминать 9 функций drowcircle(struct circle*), drowtriangle(struct triangle*), drowrectangle(struct rectangle*), fillcircle(struct circle*) и т. д., вызывая их drowcircle(circle) и т. д.

Но то что API это язык для меня очевидно.

Если и язык, то не язык программирования.

но искать их надо не там, где ищет автор этой книги,

Ну если интересно, я потом найду и скину где я такое прочитал, кажется в одной книжке по clojure. Завтра гляну, может что с числами я напутал.

В любом функциональном языке, включая ассемблер,

Толсто.

Они называются там структурами

Нет

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

И опять нет

Потому что проще запомнить названия и назначение методов drow, fill и clear, например, для классов circle, triangle и rectangle (всего 6 названий), вызывая их circle.drow() и т. д, чем запоминать 9 функций drowcircle(struct circle*), drowtriangle(struct triangle*), drowrectangle(struct rectangle*), fillcircle(struct circle*) и т. д., вызывая их drowcircle(circle) и т. д.

Кто-то не осили класс типов и полиморфизм

Они называются там структурами

Нет

Да

И от ООП-классов отличаются только отсутствием

И опять нет

И опять да

Потому что проще запомнить названия и назначение методов drow, fill и clear, например, для классов circle, triangle и rectangle (всего 6

Кто-то не осили класс типов и полиморфизм

При чём тут вообще полиморфизм и шаблоны классов? Я говорю исключительно об удобстве/неудобстве использования готовых классов по сравнению с обычными функциями.

Функциональный подход действительно имеет свои преимущества, в т. ч. связанные и с простотой, но искать их надо не там, где ищет автор этой книги, судя по тому, что ты написал. В этом смысле ООП-язык как раз проще. Потому что проще запомнить названия и назначение методов drow, fill и clear, например, для классов circle, triangle и rectangle (всего 6 названий), вызывая их circle.drow() и т. д, чем запоминать 9 функций drowcircle(struct circle*), drowtriangle(struct triangle*), drowrectangle(struct rectangle*), fillcircle(struct circle*) и т. д., вызывая их drowcircle(circle) и т. д.

Всё правильно, но ты описываешь не функциональный подход, а структурный. В ФП будут классы типов, трейты, etc, а функция draw будет полиморфной относительно условного интерфейса Drawable.

Всё правильно, но ты описываешь не функциональный подход, а структурный. В ФП будут классы типов, трейты, etc, а функция draw будет полиморфной относительно условного интерфейса Drawable.

Сорри. Я действительно перепутал функциональное программирование с процедурным или структурным. А на функциональных языках не писал, поэтому тут сравнивать не могу. Кастую Aber, которого невольно ввёл в заблуждение.

Я тоже кое в чем ошибся, цитата цитаты из «Clojure programming».

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. 1 —Alan J. Perlis in the foreword to Structure and Interpretation of Computer Programs, http://mitpress.mit.edu/sicp/toc/toc.html

И язык тела.

А вообще эти двое имели в виду разные значения слова «язык». В широком смысле API - безусловно, язык, на котором общаются две системы. Вот X11, например, вводит свой язык, который некоторые сейчас хотят похоронить.

А В.Л., видимо, имел в виду именно ЯП. API, конечно же, не ЯП. По-хорошему, надо смотреть контекст, но ты сам пишешь, что не можешь найти, а мне так это просто не интересно - схоластический спор о терминах. Человеку, интересующемуся ЯПами и API, на мой взгляд, куда интереснее программу какую полезную для опенсорса написать или патч для чужой программы.

Talk is cheap, show me the code (c)

Ну да, грубовато, но по сути верно.

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. 1 —Alan J. Perlis in the foreword to Structure and Interpretation of Computer Programs, http://mitpress.mit.edu/sicp/toc/toc.html

С этим трудно поспорить. Только я не представляю себе полноценного языка, способного обходиться одной структурой. Если только этой структурой не является байт, а вместо остальных структур не используются массивы байтов разной длины. Но такой язык наоборот был бы очень неудобным.

а можно ссылочки, где он был ткнут.

Да, конечно, является. «Проект библиотеки - это проект языка» (ц) фольклор.

Хотя можно подобрать такое определение «языка», при котором API - не язык.

По-хорошему, надо смотреть контекст, но ты сам пишешь, что не можешь найти

Ну так я видел это ХЗ сколько лет назад. А сейчас увидел презентацию Эллиота и всплыло в памяти.

Естественно, я уже не помню, где конкретно я видел переписку с Луговским: то ли на ЛОРе, то ли на RSDN (где вообще спорно — он или не он, но вроде он), то ли это вообще в FIDO/Usenet было (читал архивы в гуглгрупз).

Он и должен быть написан слитно. Это шина такая.

А точно не instruction set architecture?

Как уже тут сказали, API - это язык, но не язык программирования. API - это DSL. На различных языка программирования DSL реализуются с разной степенью удобства и результат имет разную степень «естественности» - приближенность к естественному объяснению задачи на жаргоне предметной области.

Тот кто ведёт споры о терминологии ***сосит сам себя.

пахнем анонiмусом.

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. 1 —Alan J. Perlis in the foreword to Structure and Interpretation of Computer Programs, http://mitpress.mit.edu/sicp/toc/toc.html

Ага, особенно если эта структура данных называется void*. (шутка)

Фраза показалась мне странной, стал пытаться нагуглить объяснение. То, что дают на stackoverflow и на quora (https://www.quora.com/Why-is-it-better-to-have-100-functions-operate-on-one-d...) как раз топит за ООП: вместо того, чтобы учить функции отдельно для всех наследников, мы учим функции для базового класса и на халяву получаем знание о них же в наследниках.

Это шина такая.

А точно не instruction set architecture?

Возможно. А может, MS Internet Security and Acceleration Server. Или Израильское космическое агентство, или американская Служба поддержки разведки, или Международная социологическая ассоциация, или Международная исследовательская ассоциация, или Международная ассоциация сёрфинга, или Международное сообщество по автоматизации, или Международные исследования за рубежом, или Интеллектуальное зондирование где угодно, или Международная организация по морскому дну. Ну и есть ещё другие варианты.

An API is a language for communicating about a domain

Тут «язык» имеет смысл не «язык программирования».

Формально api языком не является, но. Любой недоязычок есть api, а он за язык считается. У пациентов grep является башем и т.п.

Мало в мире есть вещей, более глупых, чем спор о терминах. ТС, дай определение понятия «язык». От него и пляши.

программный интерфейс приложения

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

То почему тогда нельзя API назвать языком?...

Думаю таки да - можно.

Это не вполне язык, а так, трудовые выкрики по Н. Марру. Сал! Йон! Рош!