Синтаксический сахар — это вообще, по определению, синтаксическая конструкция, которая заменяет собой другую синтаксическую конструкцию того же самого языка программирования.
Окэй, а в тексте что написано? Невнимательность вас погубит:
«Синтаксический сахар — общее обозначение дополнений к синтаксису ЯП, которые делают использование языка более удобным, но не добавляют ему новых возможностей.»
В рамках этого добавление команд pop push в ассемблер являлось синтаксическим сахаром по отношению к этому языку. То, что эти команды в дальнейшем входят в синтаксический стандарт языка на суть не влияет. И так практически с каждой языковой фичей. Будете спорить? Тогда конкретный пример синтаксической конструкции, которую имеетязык высокого уровня и которая не появилась ранее в языках-предках, как сахар.
Если вы говорите о языках программирования, то всё началось с великих и ужасных Fortran и Lisp… Если вы говорите о языках машинных инструкций… То с этого ничего не началось, это было где-то посрединке.
Вам не стыдно нести этот бред? В каком году был изобретён фортран? В каком году — лисп? А в каком году был эниак для программирования которого была разработана таблица коммутации, фактически породившая регистровые языки?
Вы понятия не имеете, что такое машина Тьюринга, в которой просто по определению нет регистров.
Языки, в которых не использовался стек (тот же Fortran) появились гораздо раньше.
Если не сложно, напишите реализацию на ассемблере части синтаксиса фортрана:
CALL f(a,b...)
Мне очень интересно понаблюдать, как вы это сделаете без стека.
А, вообще, конечно, учите матчасть. Именно для того, чтобы в спорах старшим товарищам не было так сильно стыдно за младших, мы и читаем курсы молодым программистам.
То есть вы утверждаете, что в языках высокого уровня присутствует некие уникальные возможности, нереализуемые с помощью машинных кодов? Или вы утверждаете, что синтаксический сахар не приводит к повышению уровня абстракции и, как следствие, повышению уровня языка?
недоказанность монотонности зависимости функционала от входных данных
Вы, ведь, про монотонное возрастание количества функционала при добавлении источника или стока данных говорите? Это утверждение опирается на определение программы, как списка правил для преобразования данных между источником и стоком информации, а так же на третий принцип термодинамики, утверждающий, что при преобразовании информации мера хаоса не уменьшается, а понижение меры хаоса (его упорядочивания) по сути требует задания новых правил. Ещё вопросы? :)
этот источник данных может дополнять входные данные, делая суммарный вход более простым, с точки зрения функционала
Пожалуйста, пример, когда мы можешь считать информацию из конфига, не зная его структуры.
интерфейс это только обертка вокруг уже имеющегося функционала. В идеальном случае функционала добавляет самый минимум — только что бы обеспечить работу протокола передачи данных. Функционал собственно программы реюзиться
Мы же рассматриваем функцию возрастания сложности программы, а не функцию накопления, не так ли?
Нигде не показана равнозначность входящих данных и конфигов или API, поэтому не понятно банальное удвоение сущности, если зависимость не определена и более того не монотонна.
Давайте рассмотрим конфиг подробнее. Конфиг — это какая-то структура данных, заполненная данными и вынесенная за пределы программы. Так? Так. Соответственно, согласно самому определению конфига, добавление этого конфига приводит к двум следствиям:
1. мы добавляем к программе новый источник данных (а значит по закону о сумме функционала неизбежно увеличиваем меру функционала материнской программы — программы которая раньше работала без конфига)
2. мы добавляем в материнскую программу знание о структуре данных, которой является конфиг, т.е. косвенным путём добавляем ещё один источник данных, тем самым опять же наращивая функционал программы.
Если сравним минимальное количество правил обработки, которые необходимо написать для добавления информации на языке родном для правил и минимальное количество правил, которое нужно декларировать для описания программы и конфига, увидим, что добавление конфига обходится минимум вдвое дороже, чем без него :)
А уж про равнозначность конфига и API могли бы уж и сами догадаться: API — это интерфейс программного модуля для получения и отправки данных. API прикрывает собственно правила по обработке информации. Информация о структуре конига является частным случаем API.
Вы считаете, что это не база? Что же тогда является базой для вас — может быть, структуры данных? Но они появились позже. Может быть, теорию конечных автоматов? Но и они не являются базой по языкам программирования.
Чистый полиморфизм — это когда когда одна и та же функция выполняется к произвольному списку параметров. В случае чистого полиморфизма есть одна функция (тело кода) и несколько ее интерпретаций.
Другой случай — это когда имеется множество различных методов с одним именем, но разным списком параметров (с разными сигнатурами методов). Собственно, это и называется перегрузкой или полиморфизмом ad hoc. Между этими двумя крайностями лежат переопределяемые методы. А абстрактные классы тут не при чём — они только задают API :)
В .h не бывает императивного кода, а в .c/.cpp описания структур данных?
Конечно бывают, но тип данных в .c файле не опишешь, да и, вообще, файлы заголовков предназначены для описания структур данных и предоставляемого API.
HTML как часть PHP? Покажете где это в спецификации?
Я буду рад, если вы мне подскажите ссылочку на спецификацию PHP :) А, вообще, там, как бы, есть включения между ?> и <?, которые предназначены именно для вывода HTML
По этому критерию нормальные алгоритмы Маркова логичнее и понятнее, чем, например Django или Rails. Почему же их не используют для разработки приложений?
Может быть по тем же причинам, по которым не используют таблицу переходов состояний Тьюринга?
Окэй, а в тексте что написано? Невнимательность вас погубит:
«Синтаксический сахар — общее обозначение дополнений к синтаксису ЯП, которые делают использование языка более удобным, но не добавляют ему новых возможностей.»
В рамках этого добавление команд pop push в ассемблер являлось синтаксическим сахаром по отношению к этому языку. То, что эти команды в дальнейшем входят в синтаксический стандарт языка на суть не влияет. И так практически с каждой языковой фичей. Будете спорить? Тогда конкретный пример синтаксической конструкции, которую имеетязык высокого уровня и которая не появилась ранее в языках-предках, как сахар.
Вам не стыдно нести этот бред? В каком году был изобретён фортран? В каком году — лисп? А в каком году был эниак для программирования которого была разработана таблица коммутации, фактически породившая регистровые языки?
Вы опять невнимательны.
Если не сложно, напишите реализацию на ассемблере части синтаксиса фортрана:
CALL f(a,b...)
Мне очень интересно понаблюдать, как вы это сделаете без стека.
А, вообще, конечно, учите матчасть. Именно для того, чтобы в спорах старшим товарищам не было так сильно стыдно за младших, мы и читаем курсы молодым программистам.
На самом деле, понимать, что HTML и другие конфиги — это программы на декларативном языке важно, чтобы не начинать программировать на конфигах.
Вы, ведь, про монотонное возрастание количества функционала при добавлении источника или стока данных говорите? Это утверждение опирается на определение программы, как списка правил для преобразования данных между источником и стоком информации, а так же на третий принцип термодинамики, утверждающий, что при преобразовании информации мера хаоса не уменьшается, а понижение меры хаоса (его упорядочивания) по сути требует задания новых правил. Ещё вопросы? :)
Пожалуйста, пример, когда мы можешь считать информацию из конфига, не зная его структуры.
Мы же рассматриваем функцию возрастания сложности программы, а не функцию накопления, не так ли?
Подтвердите это утверждение, пожалуйста, ссылкой на документацию PHP первых версий :)
Давайте рассмотрим конфиг подробнее. Конфиг — это какая-то структура данных, заполненная данными и вынесенная за пределы программы. Так? Так. Соответственно, согласно самому определению конфига, добавление этого конфига приводит к двум следствиям:
1. мы добавляем к программе новый источник данных (а значит по закону о сумме функционала неизбежно увеличиваем меру функционала материнской программы — программы которая раньше работала без конфига)
2. мы добавляем в материнскую программу знание о структуре данных, которой является конфиг, т.е. косвенным путём добавляем ещё один источник данных, тем самым опять же наращивая функционал программы.
Если сравним минимальное количество правил обработки, которые необходимо написать для добавления информации на языке родном для правил и минимальное количество правил, которое нужно декларировать для описания программы и конфига, увидим, что добавление конфига обходится минимум вдвое дороже, чем без него :)
А уж про равнозначность конфига и API могли бы уж и сами догадаться: API — это интерфейс программного модуля для получения и отправки данных. API прикрывает собственно правила по обработке информации. Информация о структуре конига является частным случаем API.
Другой случай — это когда имеется множество различных методов с одним именем, но разным списком параметров (с разными сигнатурами методов). Собственно, это и называется перегрузкой или полиморфизмом ad hoc. Между этими двумя крайностями лежат переопределяемые методы. А абстрактные классы тут не при чём — они только задают API :)
Конечно бывают, но тип данных в .c файле не опишешь, да и, вообще, файлы заголовков предназначены для описания структур данных и предоставляемого API.
Я буду рад, если вы мне подскажите ссылочку на спецификацию PHP :) А, вообще, там, как бы, есть включения между ?> и <?, которые предназначены именно для вывода HTML
Может быть по тем же причинам, по которым не используют таблицу переходов состояний Тьюринга?