недоказанность монотонности зависимости функционала от входных данных
Вы, ведь, про монотонное возрастание количества функционала при добавлении источника или стока данных говорите? Это утверждение опирается на определение программы, как списка правил для преобразования данных между источником и стоком информации, а так же на третий принцип термодинамики, утверждающий, что при преобразовании информации мера хаоса не уменьшается, а понижение меры хаоса (его упорядочивания) по сути требует задания новых правил. Ещё вопросы? :)
этот источник данных может дополнять входные данные, делая суммарный вход более простым, с точки зрения функционала
Пожалуйста, пример, когда мы можешь считать информацию из конфига, не зная его структуры.
интерфейс это только обертка вокруг уже имеющегося функционала. В идеальном случае функционала добавляет самый минимум — только что бы обеспечить работу протокола передачи данных. Функционал собственно программы реюзиться
Мы же рассматриваем функцию возрастания сложности программы, а не функцию накопления, не так ли?
Нигде не показана равнозначность входящих данных и конфигов или API, поэтому не понятно банальное удвоение сущности, если зависимость не определена и более того не монотонна.
Давайте рассмотрим конфиг подробнее. Конфиг — это какая-то структура данных, заполненная данными и вынесенная за пределы программы. Так? Так. Соответственно, согласно самому определению конфига, добавление этого конфига приводит к двум следствиям:
1. мы добавляем к программе новый источник данных (а значит по закону о сумме функционала неизбежно увеличиваем меру функционала материнской программы — программы которая раньше работала без конфига)
2. мы добавляем в материнскую программу знание о структуре данных, которой является конфиг, т.е. косвенным путём добавляем ещё один источник данных, тем самым опять же наращивая функционал программы.
Если сравним минимальное количество правил обработки, которые необходимо написать для добавления информации на языке родном для правил и минимальное количество правил, которое нужно декларировать для описания программы и конфига, увидим, что добавление конфига обходится минимум вдвое дороже, чем без него :)
А уж про равнозначность конфига и API могли бы уж и сами догадаться: API — это интерфейс программного модуля для получения и отправки данных. API прикрывает собственно правила по обработке информации. Информация о структуре конига является частным случаем API.
Вы считаете, что это не база? Что же тогда является базой для вас — может быть, структуры данных? Но они появились позже. Может быть, теорию конечных автоматов? Но и они не являются базой по языкам программирования.
Чистый полиморфизм — это когда когда одна и та же функция выполняется к произвольному списку параметров. В случае чистого полиморфизма есть одна функция (тело кода) и несколько ее интерпретаций.
Другой случай — это когда имеется множество различных методов с одним именем, но разным списком параметров (с разными сигнатурами методов). Собственно, это и называется перегрузкой или полиморфизмом ad hoc. Между этими двумя крайностями лежат переопределяемые методы. А абстрактные классы тут не при чём — они только задают API :)
В .h не бывает императивного кода, а в .c/.cpp описания структур данных?
Конечно бывают, но тип данных в .c файле не опишешь, да и, вообще, файлы заголовков предназначены для описания структур данных и предоставляемого API.
HTML как часть PHP? Покажете где это в спецификации?
Я буду рад, если вы мне подскажите ссылочку на спецификацию PHP :) А, вообще, там, как бы, есть включения между ?> и <?, которые предназначены именно для вывода HTML
По этому критерию нормальные алгоритмы Маркова логичнее и понятнее, чем, например Django или Rails. Почему же их не используют для разработки приложений?
Может быть по тем же причинам, по которым не используют таблицу переходов состояний Тьюринга?
У меня в компании была другая система мотивации сотрудников. Премиальный фонд состоял 15% зарплатного фонда. В случае нормального хода работ работник просто получал эти 15% в дополнении к авансу. В случае допущенных косяков, внеочередных отгулов или болезней, эти 15% начислялись в качестве премии тем, кто выполнял работу за этого работника или исправлял его ошибки. Могу как-нибудь написать об этом подробнее, как это было, какие были правила и к чему это всё привело.
Вы, ведь, про монотонное возрастание количества функционала при добавлении источника или стока данных говорите? Это утверждение опирается на определение программы, как списка правил для преобразования данных между источником и стоком информации, а так же на третий принцип термодинамики, утверждающий, что при преобразовании информации мера хаоса не уменьшается, а понижение меры хаоса (его упорядочивания) по сути требует задания новых правил. Ещё вопросы? :)
Пожалуйста, пример, когда мы можешь считать информацию из конфига, не зная его структуры.
Мы же рассматриваем функцию возрастания сложности программы, а не функцию накопления, не так ли?
Подтвердите это утверждение, пожалуйста, ссылкой на документацию PHP первых версий :)
Давайте рассмотрим конфиг подробнее. Конфиг — это какая-то структура данных, заполненная данными и вынесенная за пределы программы. Так? Так. Соответственно, согласно самому определению конфига, добавление этого конфига приводит к двум следствиям:
1. мы добавляем к программе новый источник данных (а значит по закону о сумме функционала неизбежно увеличиваем меру функционала материнской программы — программы которая раньше работала без конфига)
2. мы добавляем в материнскую программу знание о структуре данных, которой является конфиг, т.е. косвенным путём добавляем ещё один источник данных, тем самым опять же наращивая функционал программы.
Если сравним минимальное количество правил обработки, которые необходимо написать для добавления информации на языке родном для правил и минимальное количество правил, которое нужно декларировать для описания программы и конфига, увидим, что добавление конфига обходится минимум вдвое дороже, чем без него :)
А уж про равнозначность конфига и API могли бы уж и сами догадаться: API — это интерфейс программного модуля для получения и отправки данных. API прикрывает собственно правила по обработке информации. Информация о структуре конига является частным случаем API.
Другой случай — это когда имеется множество различных методов с одним именем, но разным списком параметров (с разными сигнатурами методов). Собственно, это и называется перегрузкой или полиморфизмом ad hoc. Между этими двумя крайностями лежат переопределяемые методы. А абстрактные классы тут не при чём — они только задают API :)
Конечно бывают, но тип данных в .c файле не опишешь, да и, вообще, файлы заголовков предназначены для описания структур данных и предоставляемого API.
Я буду рад, если вы мне подскажите ссылочку на спецификацию PHP :) А, вообще, там, как бы, есть включения между ?> и <?, которые предназначены именно для вывода HTML
Может быть по тем же причинам, по которым не используют таблицу переходов состояний Тьюринга?
Много деталей специально опущено, чтобы напомнить главное и побыстрее перейти к практике :)
java -Xms1024m -Xmx1024m -cp ./;./jai_core.jar;./jai_codec.jar;./clibwrapper_jiio.jar;./mlibwrapper_jai.jar;./jai_imageio.jar;./map_cutter.jar ru.ak.tools.MapCutter 17498 18520 17498 18520 0 0 214 214 outimg source/cheb24576x24576.png
pause 0
Этого вполне достаточно, чтобы его взяли на работу. Как плюс — это отсутствие неправильных паттернов программирования.