COKPOWEHEU писал(а):вот уж в чем смысла не вижу, так это зубрить википедию
википедия сейчас заменяет учебник. раньше ссылались на учебники именитых авторов, приводя из авторитетное мнение в качестве аргумента или подтверждения. сейчас - википедия, которая на 90% состоит из выписок из учебников и других источников, которые можно считать авторитетными.
COKPOWEHEU писал(а):Термин "подпрограмма" появляется в ассемблере и первых бейсиках для определения выделенных кусков кода, не обладающих еще интерфейсами ввода и вывода.
начало верное. любая классификация начинается от прародителя и далее по древовидной структуре расширяется путем выделения наследников прародителя, обладающих большинством свойств предка, но так же наделенными и новыми свойствами. ничего не напоминает? правильно, наследование ООП. так вот, сначала было слово, и слово это было подпрограмма. оно и является отправной точкой всей последующей классификации.
COKPOWEHEU писал(а):этот термин можно использовать либо в узком смысле (простейшая недо-процедура), либо в широком (любой выделенный кусок кода, допускающий вызов извне). Мне больше по нраву "узкое" определение.
по нраву вам или нет, но классификация подразумевает рассмотрение всех классификантов последовательно, от предка к наследнику, и никак иначе. узкий предок или широкий, все охватывает он или не все - не должно влиять на классификацию. в основе всего живого лежит клетка - так она охватывает абсолютно все категории и характеристики живого мира или не все? можно судить и так, и этак, порождая споры. а можно придерживаться другого подхода, очевидно не вызывающего двоякого толкования - клетка есть основа всего живого. и точка. и отсюда пляшем дальше. я давно и упорно настаиваю на аналогичного подхода в выборе исходной точки в наших дебатах - такой точке, беспорность которой очевидна всем. пока что это только один вариант: сначала была подпрограмма - кусок кода, выделенный обособленно для многократного использования при помощи особых вызовов из и возвратов в основную программу. это не может вызвать споров, не так ли? а ваш вариант - может.
COKPOWEHEU писал(а):Термин "процедура" обозначает выделенный кусок кода (подпрограмма в "широком" смысле), обладающий стандартизованным интерфейсом ввода. Подпрограмма не может / не обязана обладать этим интерфейсом, а процедура обязана.
нет, вы передергиваете. формально отличие процедуры от подпрограммы заключается в том, что она МОЖЕТ иметь интерфейс обмена данными, но не обязана. простейший пример из паскаля: procedure init; - нет ни входных, ни выходных параметров, т.е. нет интерфейса. если перестаните притягивать за уши несущественные особенности в качестве существенных, мы никогда не кончим спор.
COKPOWEHEU писал(а):То есть он является надмножеством подпрограммы в "узком" смысле.
каким надмножеством?! классификация всегда рассматривается от начала к концу, и никакой рекурсии или возврата к вышестоящему уровню не допускает! процедура вышла из подпрограммы - все, точка. обобщающий термин породил частный случай. какие могут быть иные подходы?!
COKPOWEHEU писал(а):Термин "функция" обозначает ту же подпрограмму в "широком" смысле, обладающую интерфейсами ввода и вывода. Причем, в отличие от подпрограммы и процедуры обязана обладать обоими интерфейсами.
нет, опять передергивание! функция обязана иметь только один интерфейс вывода результата своей работы! только один! именно наличие этого неотъемлемого свойства и отличает ее от всех прочих членов множества подпрограмм! это ведь очевидно! представить себе функцию без параметров легко, представить себе функцию без результата - невозможно (это будет процедура).
COKPOWEHEU писал(а):Теперь два соображения почему "значением по умолчанию" для подпрограммы стоит считать именно "узкое" определение. Во-первых, подпрограмма в "широком" смысле оказывается синонимом функции, а зачем использовать два названия для одного и того же объекта.
вы умудряетесь противоречить сам себе, не считая противоречий логике и здравому смыслу! ранее вы говорили о приверженности узких толкований, тут аппелируете к широким. изначально функция родилась из ранее существовавших подпрограмм, и никакого иного отношения между этими категориями быть не может! поэтому хотя наследники зачастую превосходят по своим функциям и возможностям предков, они не являются эквивалентами предков! вы можете быть в 100 раз умнее неандертальца, но вы - совсем другой вид, вы никак не можете считаться "множеством, охватывающим и возможности неандертальцев", хотя справитесь с любыми задачами, ставившими вашего предка в тупик. не смешивайте в кучу все, придерживайтесь последовательной логики.
COKPOWEHEU писал(а):Наиболее общий тип - функция
если бы это было наиболее общим типом, то оно исторически появилось бы раньше и в процессе эволюции породило бы появление других, более простых наследников - согласно вашей логике. но вся теория развития возражает вам! именно в процессе развития появляются более сложные, более гибкие и обладающие большими возможностями типы [функций], но не наоборот, из сложного путем деградации рождаются примитивные!
COKPOWEHEU писал(а):Если в этих рассуждениях есть нестыковки или противоречия, прошу на них указать.
достаточно ли я указал вам на противоречия в ваших суждениях? или вы снова скажете, что философские правила и методы поиска истины мне чужды, и я пойду своим путем? вы вообще философию изучали в ВУЗе? не марксистско-ленинскую, а обычную, науку о методах познания?
COKPOWEHEU писал(а):хотелось бы все-таки хотя бы один пример, опровергающий, что процедура - частный случай функции.
цыпленок - частный случай курицы. однако цыплята бывают петушки и курочки - и они оба суть курица. вы меня втягиваете в спор о глупостях вроде "если курица способна родить петуха, можно ли считать, что она заменит его? "
давайте рассуждать без применения Си, паскаля и т.п. языковых реализация функций и процедур, обратимся к матери всех наук - математике. математическая функция и по записи и по действию суть аналог рассматриваемой нами проблемы. грубо говоря, в математике функция - это подстановка некоего числа, аналитически получающегося абсолютно однозначно из некоего множества других чисел. итак, признаки функции:
- всегда есть число, подстанавливаемое вместо записи функции в нужное место
- может быть некоторое множество (в том числе пустое) чисел, определяющих это самое число для подстановки
- существует однозначная связь между множеством входных чисел и единственным выходным
теперь попробуем найти в математике аналог процедуры. думаете, его нет? он есть. это - алгоритм, т.е. последовательность действий для решения, например, квадратного уравнения. в этом алгоритме используется несколько формул, которые отлично попадают по всем признакам в определение функции! то есть алгоритм использует более низшее по иерархии понятие функции! не смотря на то, что сама по себе функция благодаря третьему своему отличительному признаку тоже является алгоритмом!
а теперь зададим главный вопрос: математические процедуры и функции - это эквиваленты друг друга? могут ли одни быть заменены другими? может ли функция, в частности, всегда заменить алгоритм, т.е. процедуру? ответ, по-моему, очевиден: существует масса задач, которые не могут быть решены никакой одной функцией, сколь сложной она ни была бы! т.к. математика - наука абстракций, для подтверждения своего утверждения мне придется прибегнуть к физике: задача движения трех тел в поле тяготения, если мне не изменяет память, это предельная задача, решаемая аналитически, т.е. по формуле. уже для 4-х тел не существует этого решения, чего уж говорить о пяти и более! но алгоритмы решения этих задач существуют!!! т.е. последовательность действий известна, а готовой функции не существует.
теперь к нашим баранам.
язык программирования - это не философское понятие (хотя может быть подвергнуто анализу по принципам философии), а достаточно убогая реализация формального описания человеческой логики для ее повторения электронными машинами. поэтому в языках программирования существует масса всяких противоречий, возникающих из того, что убогими инструментами сложно повторить бесконечную многогранность мира. для узких задач, решаемых языками программирования, можно пренебрегать этими противоречиями, просто имея их ввиду. можно пытаться бороться с ними, порождая противоречия более высоких порядков. наверное, существуют и другие варианты...
но одно должно быть неизменно: логика не должна страдать при любых обстоятельствах. если логика страдает (а это проявляется во всяких исключениях из общих правил, наличии "особых" случаев, оговорках об области применимости и т.п.) - это плохой признак. история развития языка Си - это история противоречий, для устранения которых использовались наспех придуманные затычки, которые, как затем выяснялось, рвали тонкую ткань логики языка еще больше, в итоге придумывали все новые и новые заплатки, и т.д. тип void - это живой пример того, как изначально ущербная логика синтаксиса потребовала введения полностью абстрактного, не имеющего никаких осмысленных толкований, объекта void с типом void! древние греки придумали вакуум, как эквивалент именно полного отсутствия чего-либо, но, как все-таки ясно теперь, полного отсутствия чего бы то ни было вообще не существует! кроме как в Си (точнее, в программировании вообще), где еще и существует конкретное местоположение этого "ничего" - (void*)!
кстати, функция всегда сможет заменить процедуру только если мы примем априори, что результат функции МОЖНО ИГНОРИРОВАТЬ. т.е. снова согласимся с исключением из правил, опровергающим основное назначение функции - устанавливать связь одного выходного числа с множеством других, входных. т.е. все ваши утверждения будут верны только в условиях искаженной логики: если основным желаемым эффектом функции "построить дом" для вас будет расходование кирпича и цемента, то разумеется, не надо переживать о том, что готовый дом можно просто стереть в порошок за ненадобностью.
Для программирования все эти философские противоречия не играют особой роли, ввиду убогости выразительных средств. В сущности, эти акценты языка Си нам не мешают писать и понимать программы. Но кода выясняется, что и наша мозговая логика подстроилась под убогие средства языка Си так, что уже не может видеть глубокую разницу между процедурой и функцией, не видит явных противоречий в "возврате ничего" - это плохо.
