Помогите пофиксить баги

[COKPOWEHEU]

формально отличие процедуры от подпрограммы заключается в том, что она МОЖЕТ иметь интерфейс обмена данными, но не обязана. простейший пример из паскаля: procedure init; - нет ни входных, ни выходных параметров

Да сколько ж можно! Интерфейс определяется не конкретным экземпляром процедуры, а компилятором. Скажем, один компилятор предпочитает передавать параметры через регистры, другой через стек. Будет ли этот интерфейс использоваться в данной конкретной процедуре не важно, главное что он есть и может быть использован. Вот для подпрограммы такого интерфейса просто нет, поэтому для передачи туда значений приходится каждый раз писать его заново.

каким надмножеством?! классификация всегда рассматривается от начала к концу, и никакой рекурсии или возврата к вышестоящему уровню не допускает! процедура вышла из подпрограммы - все, точка. обобщающий термин породил частный случай. какие могут быть иные подходы?!

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

нет, опять передергивание! функция обязана иметь только один интерфейс вывода результата своей работы! только один! именно наличие этого неотъемлемого свойства и отличает ее от всех прочих членов множества подпрограмм! это ведь очевидно! представить себе функцию без параметров легко, представить себе функцию без результата - невозможно (это будет процедура).

Приведите хоть один пример языка, в котором не определен интерфейс передачи параметров в функцию. Любая функция обладает интерфейсами передачи данных внутрь и наружу, они в компиляторе прописаны, но может ими не пользоваться.

изначально функция родилась из ранее существовавших подпрограмм, и никакого иного отношения между этими категориями быть не может!

Опять путаете с биологической эволюцией?

если бы это было наиболее общим типом, то оно исторически появилось бы раньше и в процессе эволюции породило бы появление других, более простых наследников - согласно вашей логике. но вся теория развития возражает вам! именно в процессе развития появляются более сложные, более гибкие и обладающие большими возможностями типы [функций], но не наоборот, из сложного путем деградации рождаются примитивные!

Изначально человеком были придуманы натуральные числа, потом это множество расширили до целых чисел, потом до дробных и так далее. Зачем вы утверждаете что раз все числа произошли от натуральных, они ими и являются?

достаточно ли я указал вам на противоречия в ваших суждениях?

Пока что вы показали противоречия в своих рассуждениях. Жду противоречий в моих. Только, пожалуйста, постарайтесь на этот раз использовать логику.

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

И вот это называется логикой? По-вашему, любой цыпленок является курицей? И, между прочим, как раз с термином "родить" это ваши высказывания. Если от подпрограммы (курицы) произошла (рождена) процедура (петух) то подпрограмма заменит процедуру.

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

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

сама по себе функция благодаря третьему своему отличительному признаку тоже является алгоритмом!

Алгоритм это последовательность операций, а математическая функция - однозначное соответствие, в лучшем случае - одна операция. Видите разницу?

задача движения трех тел в поле тяготения, если мне не изменяет память, это предельная задача, решаемая аналитически, т.е. по формуле. уже для 4-х тел не существует этого решения, чего уж говорить о пяти и более! но алгоритмы решения этих задач существуют!!! т.е. последовательность действий известна, а готовой функции не существует.

Не путайте "невозможно" и "невозможно в настоящий момент". Записать формулу движения возможно, но сейчас не известно методов ее аналитически решить. Не говоря о том, что функция это не алгоритм, хотя для ее расчета алгоритм и может использоваться.

история развития языка Си - это история противоречий

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

но, как все-таки ясно теперь, полного отсутствия чего бы то ни было вообще не существует!

Я смотрю, вы весьма плохо знакомы с физикой и физическими моделями. "абсолютно твердое тело", "абсолютно упругое столкновение", "сферический конь в вакууме" даже обычные числа - это всего лишь абстракции, придуманные для упрощения (более того, хоть какой-то возможности) расчетов. И как раз для абстрактных расчетов компьютер приспособлен идеально - он не оперирует физическими объектами, только их моделями. Впрочем, это не относится к вашему любимому void, как впрочем и он к теме разговора.

кстати, функция всегда сможет заменить процедуру только если мы примем априори, что результат функции МОЖНО ИГНОРИРОВАТЬ. т.е. снова согласимся с исключением из правил, опровергающим основное назначение функции - устанавливать связь одного выходного числа с множеством других, входных. т.е. все ваши утверждения будут верны только в условиях искаженной логики: если основным желаемым эффектом функции "построить дом" для вас будет расходование кирпича и цемента, то разумеется, не надо переживать о том, что готовый дом можно просто стереть в порошок за ненадобностью.

Почти правильно, только вот это как раз не исключение, а правило: язык (а точнее, компилятор) обязан предоставить для функции стандартизованные интерфейсы ввода и вывода. Они могут использоваться, а могут и нет. И мои утверждения все также остаются верными в условиях нормальной логики: если мне захочется воспользоваться основным назначением функции, результат вполне можно проигнорировать. Часто вы смотрите возвращаемое значение у printf()? Или код возврата программы?
Ну, радует, что хотя бы согласились с тем, что функция всегда может заменить процедуру, но не наоборот. Хотя почему очевидная возможность отбросить ненужный результат вызывает у вас негодования, я не понимаю. Если в контроллере встроен интерфейс JTAG или DebugWire, основное предназначение которых внутрисхеманая отладка, вы же не возмущаетесь когда кто-то использует их только для программирования или даже (о ужас!) использует вместо них ISP.

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

Эк бомбит человека от Си. Ну вот особенность языка такая, не стали выделять процедуры из функций, вместо этого заставили "возвращать" спецтип, нужный скорее для компилятора.

COKPOWEHEU, твои рассуждения о появлении терминов связанное с конкретными языками программирования - это от частного к общему...
И, как мне кажется, критерий в основе классификации у тебя другой.

Конечно, от частного к общему! Откуда возьмется общее если частного нет? В этом вся суть человеческого познания - наблюдая различные частные проявления вырабатывать все более и более общие теории.

Подпрограмма - повторяющиеся действия в алгоритме. Критерий, свойство непосредственно "кусочка" алгоритма - повторяемость.
А ты исходишь из критерия функциональности способа вызова повторяющегося фрагмента.

То есть вам тоже не нравится, что я использую термин "подпрограмма" как "процедура без входных параметров"? Так предложите более подходящий общеизвестный термин!

Вот это "пофиг" как раз и вносит всякие исключения и алогичности/нестыковки в Си.

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

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

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

[Kavka]

Изначально человеком были придуманы натуральные числа, потом это множество расширили до целых чисел, потом до дробных и так далее. Зачем вы утверждаете что раз все числа произошли от натуральных, они ими и являются?

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

Конечно, от частного к общему! Откуда возьмется общее если частного нет? В этом вся суть человеческого познания - наблюдая различные частные проявления вырабатывать все более и более общие теории.

Никто вам не говорит, что так нельзя. Но на какой-то момент накопления знаний происходит их переклассификация. И в этой области знаний она уже давно состоялась...

То есть вам тоже не нравится, что я использую термин "подпрограмма" как "процедура без входных параметров"? Так предложите более подходящий общеизвестный термин!

Вам о классификации, а вы опять в частности.

Так что "исключения и нестыковки в Си" обусловлены самим языком, а не философской концепцией функции.

Тебе об этом же и толкуют, а ты это сейчас за свою мысль выдаёшь. Ну-ну.

Я исхожу из практики.

Вот-вот. А вам о теории толкуют.

Ещё раз повторю IMHO, вы пользуетесь другим критерием. Лично я понимаю логику вашего рассуждения. У вас получается просто другая классификация. А ты всё пытаешься "притянуть" всё к своему варианту. Они разные в виду разных критериев. Если ты не можешь понять вариант приводимый нами - ну, флаг тебе в руки, барабан на шею, как говориться Я со стеной спорить тоже не буду.

PS: Попалось тут на днях, к стати - тынц.

[ARV]

Да сколько ж можно!

вот именно!

Интерфейс определяется не конкретным экземпляром процедуры, а компилятором.

уважаемый, если вы не можете объяснить свою теорию без залезания внутрь компилятора и ассемблера, ваша теория не обладает полнотой. все мои рассуждения не страдают привязкой к низкоуровневому поведению компилятора, ядра или еще чего-то, они основаны на абстракциях, имеющих четкие определения и являющихся полностью законченными, самостоятельными объектами рассмотрения. в моих рассуждениях под интерфейсом подразумевается только видимая программисту часть: процедура может иметь или не иметь параметры, функция может иметь или не иметь параметры, но обязана иметь результат - вот это интерфейс верхнего уровня, о котором только и следует говорить. когда я прибегаю к конкретике языковых реализаций - это от безысходности, т.к. вы просто не воспринимает мои абстракции!

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

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

Приведите хоть один пример

это бесполезно: я вам приводил море примеров, которые вас не убеждают. примеры для вас ничто (void). я пытаюсь расшевелить вашу логику, которая по идее должна быть способна к абстрактному мышлению, т.е. обходиться и без примеров. но тщетно...

Опять путаете с биологической эволюцией?

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

Алгоритм это последовательность операций, а математическая функция - однозначное соответствие, в лучшем случае - одна операция. Видите разницу?

функция это не алгоритм, хотя для ее расчета алгоритм и может использоваться

я говорил, что математический аналог процедуры - это алгоритм, что функция всего лишь устанавливает однозначное соответствие своего выходного параметра набору входных - вы повторили мои слова и считаете, что открыли Америку? ощущение такое, что вы даже не понимаете, что слова "видите разницу" в этом случае надо обращать не ко мне, а к вам...

Мы сейчас обсуждаем именно абстрактные подпрограммы, процедуры и функции.

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

только вот это как раз не исключение, а правило

именно об этом я и говорил: по мере развития ошибочной концепции ее несуразности принимают вид неразрешимых в рамках принятых логических концепций конфликтов, после чего единственный выход официально признать их исключением. иначе говоря "то не баг, а фича". или вспоминаем аристотелевское "камень падает на землю, а перо порхает в воздухе потому что такова их природа". не можем объяснить - переводим в разряд догмы, это так и не спрашивай, где логика.

То есть вам тоже не нравится, что я использую термин "подпрограмма" как "процедура без входных параметров"? Так предложите более подходящий общеизвестный термин!

так уже стопицот раз предлагали, причем общепризнанные определения, попавшие даже в википедию! не верите? прочтите 2-3 последних моих объемных поста, там все предложено, четко структурировано и разложено по полочкам. без противоречий вообще.

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

[COKPOWEHEU]

Ключевое слово, верхний уровень классификации - числа! И никак уж не натуральные. Опять у тебя критерий не тот, которым пользуется подавляющее большенство.

Учитывая что речь идет именно о числах, глупо называть это верхним уровнем. С тем же успехом (и той же пользой) можно назвать это "выдуманными человеком терминами". А верхний уровень классификации чисел из приведенных - дробные числа.

Тебе об этом же и толкуют, а ты это сейчас за свою мысль выдаёшь. Ну-ну.

Вы в этом ARV убеждайте, не меня.

Если ты не можешь понять вариант приводимый нами - ну, флаг тебе в руки.

Понять могу. В основном другое определение "подпрограммы" (и с ним я готов согласиться если предложите альтернативу) и попытка четкого разграничения процедур и функций. Несмотря на то, что в реальности такого разделения нет и оно бы только мешало.

если вы не можете объяснить свою теорию без залезания внутрь компилятора и ассемблера

Мы обсуждаем программирование а не математику. Хотя бы на определенном уровне абстракций придется упоминать принцип работы.

в моих рассуждениях под интерфейсом подразумевается только видимая программисту часть

Именно! Может ли программист передавать данные в процедуру не залезая на низкий уровень, может ли он получить данные из функций не лазая по стеку и регистрам. А не то, используются эти интерфейсы в данной конкретной функции. Да и почему вы решили делить именно по наличию интерфейса "наружу" а не "внутрь"? Давайте отдельно выделим процедуры без параметров и отдельно функции без параметров.

моя классификация элементов программирования именно такова - и исторически все было именно так, и логически именно так построено. вы предлагаете нечто странное.

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

это бесполезно: я вам приводил море примеров, которые вас не убеждают. примеры для вас ничто (void). я пытаюсь расшевелить вашу логику, которая по идее должна быть способна к абстрактному мышлению, т.е. обходиться и без примеров. но тщетно...

Для вас будет откровением, что доказать несуществование чего-то много сложнее чем существование. Для последнего достаточно одного примера. Вот его я и жду уже которую страницу. От вас же слышно больше негодование по поводу Си и void.

я говорил, что математический аналог процедуры - это алгоритм, что функция всего лишь устанавливает однозначное соответствие своего выходного параметра набору входных - вы повторили мои слова и считаете, что открыли Америку? ощущение такое, что вы даже не понимаете, что слова "видите разницу" в этом случае надо обращать не ко мне, а к вам...

Видимо, невнимательно прочитал ваше сообщение.

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

Единственный раз когда я полез в частности - когда демонстрировал заменяемость подпрограммы на процедуру и процедуру на функцию. Все остальное - разговор об абстракциях.

именно об этом я и говорил: по мере развития ошибочной концепции ее несуразности принимают вид неразрешимых в рамках принятых логических концепций конфликтов

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

так уже стопицот раз предлагали, причем общепризнанные определения, попавшие даже в википедию! не верите? прочтите 2-3 последних моих объемных поста, там все предложено, четко структурировано и разложено по полочкам. без противоречий вообще.

Термин в студию!

есть статья в википедии

которая не противоречит тому что я пытаюсь доказать. Разве что там термин "подпрограмма" используется в широком смысле. Но он так используется и в литературе, так что придется оставить этот костыль "так исторически сложилось". И не указано вхождение (как впрочем, и обратное) множества процедур в функции.

думаю, если ваша редакция доживет до конца 2016

Думаю, нам надоест столько ждать. Не стоит этот дурацкий спор такого времени.

[ARV]

Вы в этом ARV убеждайте, не меня

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

Хотя бы на определенном уровне абстракций придется упоминать принцип работы

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

Давайте отдельно выделим процедуры без параметров и отдельно функции без параметров

это можно сделать, и это совершенно не нарушит мою классификацию, только сделает ее более детальной на определенном уровне. вышестоящие уровни (функция - процедура) от этого не перестанут существовать и не изменятся. просто для сути спора это мне не требуется.

Видимо, невнимательно прочитал ваше сообщение

в этом ваша проблема - читать не внимательно, думать непоследовательно... торопиться с выводами

Единственный раз когда я полез в частности

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

Вы сначала докажите ошибочность концепции и наличие неразрешимых противоречий.

неразрешимость противоречий вами решается просто "это так есть, значит так правильно" - против такого "доказательства" нет у меня аргументов. если бы вы могли следовать логике - вы бы сами увидели все противоречия.

Разве что там термин "подпрограмма" используется в широком смысле. Но он так используется и в литературе, так что придется оставить этот костыль "так исторически сложилось". И не указано вхождение (как впрочем, и обратное) множества процедур в функции.

в этом самом "разве что" и кроется источник проблем - то, что всем сообществом программистов принимается, как истина, полученная в ходе исторической эволюции средств программирования, вошедшая в анналы и ставшая де-факто основой всего программирования, для вас - костыль. все шагают не в ногу, и только один вы в ногу...

нам надоест столько ждать

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

жду со страшной силой. надеюсь, как джентльмен, вы от своих слов не отступитесь и исправите мировую ошибку википедии.

[COKPOWEHEU]

это глупость

в этом ваша проблема

это был далеко не единственный случай, это постоянное ваше действие

неразрешимость противоречий вами решается просто "это так есть, значит так правильно" - против такого "доказательства" нет у меня аргументов. если бы вы могли следовать логике - вы бы сами увидели все противоречия.

Вот переход на личности комментировать бессмысленно.

то, что всем сообществом программистов принимается, как истина

Посмотрите, что принимается всем сообществом физиков как единица измерения времени. Посмотрите чему равна диэлектрическая проницаемость вакуума в научной системе единиц СИ и объясните ее физический смысл - что там в вакууме настолько сильно поляризуется. Это тоже исторически сложившиеся костыли, все о них знают, но исправлять уже слишком сложно.

докажите всему миру, что он не прав

Я спорю не с миром а с вами. Неужели для вас настолько сложно разбить мои рассуждения строгой логикой?

это можно сделать, и это совершенно не нарушит мою классификацию

Ваша теория это не только допускает - она этого почти требует.

ваша теория не может остановиться - она недостаточно завершена

Вы так говорите как будто это недостаток. Я вас разочарую, незавершенность означает возможность изменения и дополнения.
.
Если в программировании (речь не об абстрактной философии) функция часто используется в роли процедуры, зачем выносить их в непересекающиеся множества?
Попытайтесь применить свою хваленую теорию на практике и скажите, что из этого подпрограмма, что процедура а что функция

Код: Выделить всё

1: init();
2: uart_set_speed(9600);
3: printf("text\n");
4: asm_func:
      ldi r24,0xFF
    ret
5: sei();

Как в вашу теорию входят методы ООП? А операторы?

[ARV]

Вот переход на личности комментировать бессмысленно

т.к. вы единственный мой оппонент, это не переход на личности, а оценка вашей манеры ведения дискуссии. если это на самом деле так - почему об этом нельзя говорить?

Это тоже исторически сложившиеся костыли, все о них знают, но исправлять уже слишком сложно.

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

Неужели для вас настолько сложно разбить мои рассуждения строгой логикой?

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

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

опять спускаемся вниз по уровням иерархии? вы же призывали абстрагироваться от конкретной реализации? снова не видите противоречий даже в собственных суждениях?

Как в вашу теорию входят методы ООП? А операторы?

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

[Z_h_e]

В любой сфере деятельности есть такое понятие как "Термины и определения". Они вводятся для некой стандартизации и для того чтобы люди понимали друг друга. Можно долго спорить Плутон планета или астероид. Но правильно его называть именно так, как он заявлен в соответствующем документе.
Возможно, уважаемый ARV, на электрических схемах Вы указываете направление тока от минуса к плюсу. Ведь так же правильно, но это ни к чему хорошему не приведет. Вас просто перестанут понимать.
Если Вы желаете, называйте функцию void процедурой. Но от этого она не станет процедурой, потому что нет такого термина в С или я ошибаюсь?

"A function is a block of code that performs some operation.A function can optionally define input parameters that enable callers to pass arguments into the function.A function can optionally return a value as output."

Функции — это блоки кода, выполняющие определенные операции.Если требуется, функция может определять входные параметры, позволяющие вызывающим объектам передавать ей аргументы.При необходимости функция также может возвращать значение как выходное.

Взял отсюда. В других источниках, определение аналогичное.

Так что повторюсь, если Вы не согласны с этим, то вопрос к разработчикам С. Эти гады еще знак равно используют как присвоить, а ведь это неверно, нельзя так, равно есть равно .

[ARV]

Взял отсюда. В других источниках, определение аналогичное.

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

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

я уже приводил пример про корову и быка - вы не согласились с тем, что было бы вполне приемлемо использовать слово "бык" для наименования коровы... хотя что поменялось бы в этой жизни? - ровно ничего: пол животного не изменился бы, молоко давать оно не перестало бы и т.д. а вот в программировании вы предлагаете забыть о разнице между функцией и процедурой - дескать, и так сойдет. спор только об этом, и ни о чем ином. каждому свое наименование - логичное и непротиворечивое.

[Z_h_e]

Функция в математике и в языке программирования есть разные понятия. Даже в разных языках - разные. Это омонимы.
Пример с быком Вы привели крайне неудачно контексте данного спора. Я Вас поправлю. Есть бык - животное, есть бык - опора моста. И Вас уже какую страницу данного топика возмущает, что опору моста называют быком. У этих терминов одно случайное совпадение - они оба очень хорошо не производят молока. И наверняка рогатый бык появился раньше мостатого. По Вашей логике неверно называть опору моста быком.

[Jack_A]

Сколько же можно, в конце концов! Спор по бессмысленному вопросу - об определениях. Увидев пушистого зверька на дереве, вы будете утверждать, что это - белка, хотя я совершенно точно знаю, что это - вавёрка (бел) .
В Вики приведено абсолютно ясное определение подпрограммы, процедуры и функции. Поскольку Вики - не для всех авторитет ( вполне справедливо, я думаю, и в научных публикациях, особенно в диссертах, ссылка на нее не допускается ), то вот еще: http://informatics.mccme.ru/mod/book/view.php?id=529 . Если кто-то скажет, что и это - не авторитет ( мало ли что напишут неучи для обучения чайников, а нам, умникам, потом переучивать этих чайников на нашу, едино правильную терминологию), то пусть даст ссылку на то, где утверждается, что у подпрограммы не бывает параметров, как он считает. Тогда на френа она нужна? Изменять глобальные переменные - так это считается дурным тоном в программировании.
В общем, картина мира видится мне следующая:
- есть подпрогрвммы = многократно выполняемые куски кода, которые могут быть вызваны из любого места основной программы с последующим возвратом в точку вызова. Они могут иметь параметры, могут и не иметь.
- среди них есть те, что возвращают данные определенного типа в определенное место, их называют функциями этого типа.
- те, что этого не делают, назваются в одних языках процедурами, в других - функциями типа void.
Если есть желание продолжать жевать эту жвачку, давайте откроем Кобол и поищем аналоги термину ПАРАГРАФ в других языках.
Dixi.

[ARV]

Функция в математике и в языке программирования есть разные понятия.

чтобы доказать, что это разные понятия, надо провести анализ. как делается анализ? составляется список признаков одного объекта и список признаков другого. признаки должны выбираться не абы какие, а во-первых, однородные (т.е. если у одного объекта цвет и размер, то и у другого цвет и размер), а во-вторых, основные, определяющие, т.е. важные (например, для сравнения автомобилей цвет не является определяющим признаком, а количество ведущих колес или осей - является). как определить, является ли выбранный признак определяющим? очень просто: надо ответить на вопрос "может ли существовать этот объект без этого признака, и при этом оставаться самим собой?" - если ответ "да" - признак выбран неверно.
когда определены перечни признаков, производят просто их сравнение между собой и, если разница невелика, оба объекта можно считать одинаковыми, сходными, или, в вашей терминологии - синонимами. если же разница кардинальна (например, для одного объекта найдено 5 определяющих признаков из которых 4 вообще неприменимы к другому объекту), то следует сказать "это разные объекты". объекты, понятия - это не важно, анализировать можно что угодно, подход остается прежним.

чтобы понять, насколько понятия функции в математике и понятие функции в программировании (вообще в абстрактном программировании, а не в конкретике Си или там Java) разные, я прошу вас подвергнуть эти понятия анализу и показать всем, насколько сильно они отличаются. сумеете? похоже, проблема кроется именно в том, что кое-кто не способен (либо не дает себе труда) выделить основные признаки предметов спора и провести по ним классификацию...

ваш пример про быка моста и млекопитающегося, если подвергнуть его анализу, мгновенно прекращается на моменте, что оба эти объекта не имеют вообще ни одного совпадающего отличительного признака, кроме наименования (но, т.к. наименование у нас и подвергается анализу, этот признак учитывать нельзя). поэтому вы не правы, приводя этот пример - он вообще не о рассматриваемой проблеме.

[COKPOWEHEU]

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

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

исправьте исторический костыль в википедии

Может мне еще исправить определение секунды в учебниках физики?

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

То есть вы полагаете, что назвать корову млекопитающим или позвоночным будет ошибкой? По вашей логике надо строго разделить - есть отдельно млекопитающие и отдельно коровы и это совсем-совсем разные понятия и общего у них только то что и те и другие позвоночные.

мы спорим именно о теории. т.к. Си появился гораздо позже того, как вполне состоялась общая теория

Вы уверены? Честно говоря, не силен в истории, но разве не примерно в одно время они появились? Ну и обзывать теорию статичной, неизменяемой - значит называть ее ненаучной либо неполной.

хотя я совершенно точно знаю, что это - вавёрка (бел) .

Ну что вы, как можно! У нас ведь научное общество, а значит это существо надо называть не иначе как Sciurus(лат.)

(например, для сравнения автомобилей цвет не является определяющим признаком, а количество ведущих колес или осей - является). как определить, является ли выбранный признак определяющим? очень просто: надо ответить на вопрос "может ли существовать этот объект без этого признака, и при этом оставаться самим собой?"

"Может ли существовать автомобиль без цвета?" В какие же дебри философии вас потянуло!

чтобы доказать, что это разные понятия, надо провести анализ

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

ваш пример про быка моста и млекопитающегося

Вы бы хоть биологическое определение без ошибки написали... да и техническое тоже.

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

опять спускаемся вниз по уровням иерархии? вы же призывали абстрагироваться от конкретной реализации? снова не видите противоречий даже в собственных суждениях?

"эксперимент - критерий истины". Примените свою теорию на практике, докажите что она лучше. Так что из приведенного является подпрограммой, что процедурой, а что функцией?

Код: Выделить всё

1: init();
2: uart_set_speed(9600);
3: printf("text\n");
3а): writeln('text'); - если вам так не нравится Си, напишем тоже самое на Паскале.
4: asm_func:
      ldi r24,0xFF
    ret
5: sei();

операторы в данном контексте не рассматриваются, как более мелкие единицы программы.

Опять с математикой смешиваете? В программировании операторы это тоже "куски кода", и я говорю не только о машинной реализации. Скорее, о классах, где оператор присваивания это отнюдь не побитовое копирование, про перемножение векторов и не говорю. Так что попытка вынести методы и операторы из классификации отклонена. Ждем конкретного ответа. По вашему определению, подпрограмма - любой выделенный участок кода. Процедура это подпрограмма, никогда не возвращающая результат вызывающей программе, а функция - возвращающая обязательно. Так что же такое по этой классификации метод и оператор?

[ARV]

соревноваться с вами, COKPOWEHEU, в демагогии и умении троллить я не желаю.

поскольку вместо рассуждений идут ссылки на авторитетов, голословные обвинения и так далее

вы лжете! я последовательно сначала рассуждал, убеждал логически, затем, видя вашу невосприимчивость к логике, прибегнул к "силе авторитетов", а затем - даже к правке википедии и т.д.
я прибег к перечисленным вами способам не ВМЕСТО, а В ДОПОЛНЕНИЕ К. вы даже тут не дружите с анализом и логикой, бесстыдно передергивая

Может мне еще исправить определение секунды в учебниках физики?

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

То есть вы полагаете, что назвать корову млекопитающим или позвоночным будет ошибкой?

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

"Может ли существовать автомобиль без цвета?" В какие же дебри философии вас потянуло!

вы хотели продемонстрировать ваше неумение пользоваться философскими инструментами познания? у вас получилось, но даже и без этой фразы - еще раньше вы это продемонстрировали неоднократно. если цвет является определяющим признаком автомобиля, то вопрос следует ставить так "останется ли автомобилем ЭТО, если будет не красного, а синего цвета?". т.к. свойства автомобиля не поменяются от перекрашивания, цвет не является определяющим автомобиль параметром. умение поставить вопрос - это тоже часть философской концепции познания.

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

давайте перечитаем мои высказывания и поймем, что все определения я уже давал, причем в форме, исключающей двоякое толкование. пока вместо моих определений вы, передергивая, будете подсовывать свои, толку не будет.
что касается математики и программирования, то - см. выше - надо определить признаки функции, без которых она перестанет быть функцией. например, функция, которая не делает ничего, не имеет значения для подстановки в выржение - останется функцией или нет? после составления списка таких критериев проведем сравнение.
состоит функция из блоков кода или из математических символов - является несущественным критерием, существенными для нее являются иные свойства.

Вы бы хоть биологическое определение без ошибки написали...

не хватает аргументов - прицепись к грамматике.

Примените свою теорию на практике, докажите что она лучше. Так что из приведенного является подпрограммой, что процедурой, а что функцией?

повторяю для непонятливых и военных в третий раз: приводить конкретные примеры из языков, в разной степени пользующихся теоретическими основами - это глупость. пока не будет решения с теорией, бессмысленно для нее искать примеры. я отвечаю на ваш вопрос ровно в рамках своей терии: все участки кода, которые полностью соответствуют формальным критериям функции являются функциями, а которые соответствуют формальным критериям процедуры - являются процедурами.

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

ну хватит уже демонстрировать свое неумение читать и понимать написанное! не передергивайте! определение подпрограммы я давал давно. просто "блок кода" не попадает под определение подпрограммы вообще, соответственно не может быть определен, как процедура или функция.
так как и подпрограмма вообще, и процедура с функцией обязательно состоят из операторов, они не могут являться определяющим признаком. вам хоть понятно, что определяющий признак - это то, что отличает одно нечто от другого? не то, что объединяет, а отличает! найдите разницу и вы познаете мир.
что касается методов и т.п. properties из ООП - это категории следующих порядков, т.е. дальнейшее развитие процедур, функций и подпрограмм в целом. поэтому пока не разберемся с нужным нам слоем, нет смысла лезть глубже по структуре. на данном этапе дискуссии неважно, произошли ли методы от процедур или от функций, т.е. являются они логическим продолжением тех или иных - это сейчас не принципиально. сейчас принципиально установление отношений между процедурой и функцией, причем важно установить только одно отношение - отношение тождества.

функция тождественна процедуре или нет? вот это главный вопрос дискуссии.

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

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

[COKPOWEHEU]

соревноваться с вами, COKPOWEHEU, в демагогии и умении троллить я не желаю.

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

вы лжете! я последовательно сначала рассуждал, убеждал логически

Да-да, из ваших рассуждений логика просто фонтаном бьет. Я уже третий день пытаюсь от вас добиться строгого и логического опровержения моей классификации. Неплохим бонусом было бы внятно сформулировать вашу теорию. Не ссылками на википедию, а строгими логическими терминами: "Подпрограмма это вот это, процедура это вон то, а функция это вот эдакое. Исходя из этого процедуры и функции это два непересекающихся подмножества, образующих совместно множество подпрограмм" или как-то так.

если вы говорите, что оно не верно - предложите научному сообществу более точный вариант

Убедите англоязычный мир пользоваться метрической системой и градусами Цельсия. Или научный мир использовать СГСЭ.

вы хотели продемонстрировать ваше неумение пользоваться философскими инструментами познания?

Я процитировал ваше высказывание, несомненно представляющее собой образец логики.

Код: Выделить всё

что касается математики и программирования, то - см. выше - надо определить признаки функции, без которых она перестанет быть функцией. 

Месье знает толк... Ну чтож, интересно будет услышать от вас определение математической функции и список ее основных признаков. Я за такое не возьмусь, потому что чем "очевиднее" термин, тем сложнее дать ему определение.

повторяю для непонятливых и военных в третий раз: приводить конкретные примеры из языков, в разной степени пользующихся теоретическими основами - это глупость. пока не будет решения с теорией, бессмысленно для нее искать примеры. я отвечаю на ваш вопрос ровно в рамках своей терии: все участки кода, которые полностью соответствуют формальным критериям функции являются функциями, а которые соответствуют формальным критериям процедуры - являются процедурами.

Вы хотите сказать, что ваша теория не связана с практикой? Что к большинству языков программирования она неприменима?
Общие слова и недоопределения от вас уже слышали, давайте ближе к делу, что из перечисленного является процедурой, что функцией, а что подпрограммой, что из них обладает формальными критериями процедур и функций.

Код: Выделить всё

1: init();
2: uart_set_speed(9600);
3: printf("text\n");
3а): writeln('text');
4: asm_func:
      ldi r24,0xFF
    ret
5: sei();

Зачем вы так старательно увиливаете от этого вопроса?

просто "блок кода" не попадает под определение подпрограммы вообще, соответственно не может быть определен, как процедура или функция.

Желаете поспорить еще и с тем, что процедуры и функции являются кусками кода? Или с тем, что операторы в программировании являются "специальным образом выделенными кусками кода, предназначенными для многократного вызова из различных частей программы и возвращающие управление в ту же точку откуда были вызваны"? (Если не ошибаюсь, это ваше определение подпрограммы или что-то очень близкое к нему).

так как и подпрограмма вообще, и процедура с функцией обязательно состоят из операторов, они не могут являться определяющим признаком. вам хоть понятно, что определяющий признак - это то, что отличает одно нечто от другого?

Я вам привел несколько общих признаков, позволяющий классифицировать эти структуры. От вас же ожидаю именно построения этой классификации: какие множества пересекаются, какие входят друг в друга, какие являются наследниками и так далее.

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

Неужели для этого надо настолько сильно менять вашу теорию?

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

То есть для термина "метод" в вашей классификации просто нет места? А нет ли случайно другого отличия метода от процедуры и функции? Например, механизма передачи информации о "привязанном" экземпляре класса?

операторы, как ранее и было сказано, пока не рассматриваем, как категории более низкого уровня. если вы о "переопределяемых" операторах ООП, то они по определению являются функциями, хотя все это к теме дискуссии не относится

Переопределенные операторы ООП по определению являются методами а не функциями. Ну ладно если с этим определились, оставим операторы.

функция тождественна процедуре или нет? вот это главный вопрос дискуссии.

Скорее, "можно ли считать процедуру разновидностью функции".

[Kavka]

функция тождественна процедуре или нет? вот это главный вопрос дискуссии.

Скорее, "можно ли считать процедуру разновидностью функции".

Разные критерии нужны для утверждения или опровержения этих фраз. О чём я ранее тут писал.

Лирическое отступление. Из жизни студентов:
Сегодня на уроке социальных проблем наш профессор поднял черную книгу и сказал "эта книга красная". И мы все такие: "Нет". А он: "Да, красная". И мы опять: "Это не так". Он повернул книгу, а её задняя обложка была красной. И он сказал: "Не говорите кому-то, что он не прав, до того момента, пока не посмотрите на ситуацию с его точки зрения".

[ARV]

Неплохим бонусом было бы внятно сформулировать вашу теорию.

вы меня утомили. вот в этом посте я писал

функция, которая не возвращает значения, это процедура - смотрите определение паскаля, если уж на то пошло. логически и функционально между ними нет никакой разницы. тип void для функции Си всего лишь дань синтаксису, на самом деле НИКАКОГО РЕЗУЛЬТАТА физически не существует, так что от процедуры паскаля это ничем не отличается (конечно, если не лезть в глубины передачи параметров через стек). смотреть в ассемблерную реализацию бессмысленно, т.к. она апаратно- и компиляторо-зависима.

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

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

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

пока вы не перестанете смешивать уровни программирования, диалога не получится.
подпрограмма - термин частично низкоуровневый, частично устаревший. исключаем его из рассмотрения и ограничиваемся парой процедура-функция.
определения возьмем по образцу паскаля, т.к. Си не подразумевает понятие процедуры.

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

скажите, мне продолжать цитировать ранее сказанное, или вы все-таки прочтете это самостоятельно?

у вас нет оснований обвинять меня в непоследовательности, а так же в отсутсвии желания четко сформулировать "свои определения". я все это сделал очень давно, и старался (как мог!) сделать это максимально однозначно так, чтобы никакие последующие мои выкладки не потребовали ИСКЛЮЧЕНИЯ ИЗ МОИХ ЖЕ ПРАВИЛ, чем постоянно грешите вы с вашим утверждением, что "функция может возвращать ничего, т.е. ничего не возвращать, но при этом она все равно останется функцией, а не выродится в процедуру".

интересно будет услышать от вас определение математической функции и список ее основных признаков. Я за такое не возьмусь, потому что чем "очевиднее" термин, тем сложнее дать ему определение.

осознавая сложность определения простых истин, все-таки попробую. я бы назвал функцией (в широком смысле, т.е. математическом, физическом, алгоритмическом или каком-то ином) запись, удовлетворяющую следующим критериям:
- используется в выражениях
- используется в качестве краткой записи некоторой последовательности действий, устанавливающих соответствие единственного значения-результата с некоторым множеством "входных" значений
- может быть отображена в виде графика зависимости своего значения от одного или нескольких входных (либо от иных условий, не поддающихся строгому описанию)
иначе говоря, функцией я бы назвал любую запись, которая используется в качестве операнда в выражениях и по своему смыслу эквивалентна определенному значению. возможно, мое определение не полное, но во-первых, я думал не более 5 минут над ним, а во-вторых, коллективными усилиями можно его улучшить. а в-третьих, я не сказал ничего более нового, чем говорил и ранее - см. вышеприведенные цитаты. оказалось, ранее данные определения для программной функции вполне себе подходят и для математической, что, с моей точки зрения, является только плюсом моей классификации - она универсальна.

Вы хотите сказать, что ваша теория не связана с практикой? Что к большинству языков программирования она неприменима?
Общие слова и недоопределения от вас уже слышали, давайте ближе к делу, что из перечисленного является процедурой, что функцией, а что подпрограммой, что из них обладает формальными критериями процедур и функций.

Код: Выделить всё

1: init();
2: uart_set_speed(9600);
3: printf("text\n");
3а): writeln('text');
4: asm_func:
      ldi r24,0xFF
    ret
5: sei();

Зачем вы так старательно увиливаете от этого вопроса?

я не увиливаю, вы просто не даете себе труда читать мои сообщения. я уже отвечал вам на это

я отвечаю на ваш вопрос ровно в рамках своей теории: все участки кода, которые полностью соответствуют формальным критериям функции являются функциями, а которые соответствуют формальным критериям процедуры - являются процедурами.

кроме того, я только что дал вам свое определение того, что есть функция. я понимаю, что самостоятельно вы не сможете вывести следствие из определения, потому снова сделаю его для вас: результат функции не должен игнорироваться, т.к. в противном случае теряется сам смысл ее работы. только проблема в том, что теория - это теория, а практика, к сожалению, такова, что кроме малого подмножества языков, среди которых Pascal, мало кто стремится следовать этой теории... в результате чего появляются исключения из правил (см. выше - моё стремление избежать исключений, т.к. любые исключения это противоречие строгой логике):
- результат функции может не использоваться
- функция может не возвращать результат
последнее "исключение" - это просто пощечина логике, матери наук!
именно поэтому невозможно дать однозначный ответ на ваш вопрос, без того, чтобы не назвать конкретные языки, на которых написаны ваши пронумерованные "участки кода". я пытался донести это до вас следующим своим высказыванием

приводить конкретные примеры из языков, в разной степени пользующихся теоретическими основами - это глупость

отказалось - тщетно... поэтому отвечаю КОНКРЕТНО, как смогу: это все примеры участков кода, которые на паскале все без исключения являются ПРОЦЕДУРАМИ (кроме ассемблера, т.е. п.4), для языка java, Си и т.п. это будут функции только по одной причине, что ничего иного там не существует. но отличить по внешним признакам void-функцию от "нормальной" с результатом по вашим примерам невозможно. попробуйте видоизменить примеры так, чтобы они представляли собой выражения с оператором отношений или присваивания - тогда можно будет ответить более конкретно. ассемблер вообще следует исключить из рассмотрения, как низкоуровневый язык.

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

Я вам привел несколько общих признаков, позволяющий классифицировать эти структуры. От вас же ожидаю именно построения этой классификации: какие множества пересекаются, какие входят друг в друга, какие являются наследниками и так далее.

я все это делал многократно, читайте предыдущие посты. всю свою классификацию я вам приводил. более того, она на 100% совпадает с классической, приведенной в учебниках и даже (!!!) википедии - на что я так же давал вам ссылки. хотя бы из уважения прочтите это!

Переопределенные операторы ООП по определению являются методами а не функциями.

неужели вы и этого не читали:

если вы о "переопределяемых" операторах ООП, то они по определению являются функциями

что касается методов и т.п. properties из ООП - это категории следующих порядков, т.е. дальнейшее развитие процедур, функций и подпрограмм в целом

разве не следует из моих слов, что вы не открыли Америку, сказав, что переопределяемый оператор - это метод? вы не умеете понимать прочтенное или намеренно не читаете?

Скорее, "можно ли считать процедуру разновидностью функции"

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

[COKPOWEHEU]

скажите, мне продолжать цитировать ранее сказанное, или вы все-таки прочтете это самостоятельно?

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

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

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

Ладно, опустим это несоответствие если вначале термин "подпрограмма" употреблен в "узком", в потом в "широком" смысле.

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

Говорите, "процедура не обязана возвращать значение"? Значит - может. Пример просить даже не буду, все равно будете пытаться отвертеться, но если процедура возвращает значение, чем она отличается от функции?

не потребовали ИСКЛЮЧЕНИЯ ИЗ МОИХ ЖЕ ПРАВИЛ, чем постоянно грешите вы с вашим утверждением, что "функция может возвращать ничего, т.е. ничего не возвращать, но при этом она все равно останется функцией, а не выродится в процедуру".

Ну и кто из нас не умеет читать доводы оппонента? Я нигде не утверждал, что процедура обязана принимать входные параметры, а функция - возвращать результат. Я писал, что для процедуры определен интерфейс передачи данных внутрь, а для функции - внутрь и наружу. Иными словами, можно просто вызвать процедуру с параметрами и не заботиться как именно они будут переданы. Точно так же можно просто получить результат функции не лазая по стеку и регистрам. Итак, где вы нашли исключения из правил?

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

Для вас будет откровением, что далеко не всегда возвращаемое значение является основным результатом работы функции? Пример с printf'ом я приводил. Или вы предпочли бы делать два варианта - процедуру и функцию?

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

Даже Паскаль не следует первому из ваших правил - результат функции можно игнорировать. Как впрочем, и Си - его функции всегда что-то возвращают, другое дело что возвращаемое значение типа void невозможно использовать. А если бы вы читали свои же ссылки на википедию, увидели бы, что в первых версиях Си типа void не было, функции всегда возвращали хотя бы int.

это все примеры участков кода, которые на паскале все без исключения являются ПРОЦЕДУРАМИ

Да ну? А если я объявлю function init():integer; она резко станет функцией? Кусок ассемблерного кода вполне может быть вызван из Си (например) как функция extern char asm_func();

приводить конкретные примеры из языков, в разной степени пользующихся теоретическими основами - это глупость

Если ваша теория оторвана от практики - так и скажите.

я очевидно показал вам, что ваши примеры ничего не доказывают

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

разве не следует из моих слов, что вы не открыли Америку, сказав, что переопределяемый оператор - это метод? вы не умеете понимать прочтенное или намеренно не читаете?

Вы говорили что это функция, а не метод. Это не синонимы и я все еще жду, куда вы разместили метод в своей теории.

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

Это ваш уровень. Мой же - считать ли число 1 натуральным числом, целым или дробным. Считать ли рыбу млекопитающим, позвоночным или многоклеточным?

Лирическое отступление. Из жизни студентов:

Студенты были правы - книга не была красной, разве что красно-черной.

[ARV]

Наличие такого места это как раз низкий уровень.

место - это место в коде программы, а не в стеке, регистре или еще где-либо "внизу". и далее я уточняю, что место это - в выражении.

опустим это несоответствие если вначале термин "подпрограмма" употреблен в "узком", в потом в "широком" смысле.

не наблюдаю этого - где вы это увидели?

Значит - может. Пример просить даже не буду, все равно будете пытаться отвертеться, но если процедура возвращает значение, чем она отличается от функции?

хочется хамить, ибо вы тролль. может - значит может вообще, но не так, как функция. функция обязана вернуть результат в выражение, а процедура формально может вернуть результат куда-угодно, например, в глобальную переменную. а может и не вернуть. но функция - обязана, причем единственным способом.

Я нигде не утверждал, что процедура обязана принимать входные параметры, а функция - возвращать результат. Я писал, что для процедуры определен интерфейс передачи данных внутрь, а для функции - внутрь и наружу. Иными словами, можно просто вызвать процедуру с параметрами и не заботиться как именно они будут переданы. Точно так же можно просто получить результат функции не лазая по стеку и регистрам. Итак, где вы нашли исключения из правил?

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

Или вы предпочли бы делать два варианта - процедуру и функцию?

во-первых, я предпочел бы всего лишь правильно называть сущности - функцию функцией, процедуру - процедурой, корову - коровой, а идиота - идиотом, не более того. во-вторых, если вы такой грамотный, сами скажите, вот это функция dsfklghkdjhfkjhgkjd(kerghkdhfg, kdskjsg) или что-то иное? в вашей любимой libc, примеры из которой вы так любите приводить, существует масса вариантов, когда не основной результат "функции" возвращается в глобальной переменной, а основной является void - и этот "косяк" так же никого не смущает.

Даже Паскаль не следует первому из ваших правил - результат функции можно игнорировать

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

А если бы вы читали свои же ссылки на википедию, увидели бы, что в первых версиях Си типа void не было, функции всегда возвращали хотя бы int.

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

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

странно, как вы умеете из моих слов сделать мой же вывод так, будто я не был прав - это ж уметь надо так искаженно воспринимать реальность! если вас и негра вымазать в говне, отличить вас будет невозможно, но это не сделает вас эквивалентными однояйцевыми близнецами! теория гласит, что врать нехорошо, практика - все врут. теория гласит, что убивать не хорошо - многие убивают. разве это свидетельствует, что теория не верна? нет, это говорит о том, что теории не все следуют! то, что некоторые программисты разучились мыслить логично, и тупо используют "шаблоны мышления" из не подчиняющихся теории и здарвому смыслу стандартов языков, вовсе не отменяет факта существования теории и ее правильность!

Если ваша теория оторвана от практики - так и скажите

только что сказал - соблюдение закона с качеством закона никак не связано. и тем не менее законы существуют и признаются всеми, хотя бы формально. если вы этого не понимаете, мне очень жаль. а если вы тролль - я в ярости.

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

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

Студенты были правы - книга не была красной, разве что красно-черной.

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

[COKPOWEHEU]

хочется хамить, ибо вы тролль.

я убедился, что с троллем разговаривать бесполезно

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

не наблюдаю этого - где вы это увидели?

Ну только что же процитировал!
"подпрограмма - это аналог процедуры, а не функции."
"подмножеством подпрограмм являются процедуры и функции"

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

Вот это выверт! В глобальную переменную или по переданному адресу процедура не возвращает значения, а напрямую работает с ОЗУ. Эта область в процессе работы процедуры может быть изменена несколько раз и даже использована во время работы процедуры. В то время как возвращенное функцией значение именно передается в вызывающий код. Для внешней программы это значение - константа.

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

Разумеется не обязана! Никто вас не накажет если напишете такую функцию

Код: Выделить всё

function func():integer;
begin
//вот если дописать func := 1; - функция будет возвращать значение 1.
end;

Как видите, функция не возвращает значения и ведет себя как процедура. Отличие в том, что она может вернуть значение, а внешняя программа может этим значением воспользоваться, например, x := func(); В то время как процедура вернуть значение не может и, соответственно операция x := proc(); для нее не определена.

вот это функция dsfklghkdjhfkjhgkjd(kerghkdhfg, kdskjsg) или что-то иное

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

в вашей любимой libc, примеры из которой вы так любите приводить, существует масса вариантов, когда не основной результат "функции" возвращается в глобальной переменной, а основной является void - и этот "косяк" так же никого не смущает.

А где тут "косяк" или нарушение правил?

нет, паскаль этого не допускает.

Borland Pascal 6 (досовая) вполне допускал, с более старыми дела не имел.

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

Я вам на нее уже сколько времени киваю: тип void был введен для защиты от ошибок. И его введение не отменило факта, что формально в Си процедур нет, есть функции, которые не могут быть использованы иначе, чем в роли процедур.

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

Если биологу показать плохо сохранившийся скелет животного, он сможет сделать вывод что, раз есть позвоночник, животное было позвоночным; если зубы разных размеров и формы - скорее всего это было млекопитающее и т.д. Когда характерные признаки заканчиваются - заканчивается и классификация. Причем обнаружение новых признаков не приведет к внезапному превращению белки в летучую мышь.

теория гласит, что убивать не хорошо - многие убивают. разве это свидетельствует, что теория не верна? нет, это говорит о том, что теории не все следуют!

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

только что сказал - соблюдение закона с качеством закона никак не связано. и тем не менее законы существуют и признаются всеми, хотя бы формально

Вы только что смешали принятые нормы морали и научный закон. Не видите разницы? Тогда попробуйте нарушить закон, скажем, курения в общественных местах, и закон Ома.

функцию от процедуры отличить элементарно

Именно поэтому на моих простых примерах вы этого сделать не смогли. А причина проста - любая функция может быть использована в роли процедуры. Что я и продемонстрировал: init() может быть как функцией, так и процедурой, но если видеть только ее вызов как процедуры, провести дальнейшую классификацию невозможно.
И продолжаю настаивать на ответе на вопрос "какое место в вашей классификации занимает метод?"