Skynin, да, примерно так. А вот ещё один взгляд на вопрос, вроде бы то же самое, а свои нюансы тоже имеются
http://ru.wikipedia.org/wiki/%D0%9F%D1%80%...%D0%B8%D0%B5%29

Сам топик о различии функций и "нефункций" в C#, и родился из статьи о C#. В каждом конкретном языке разделение на функции и процедуры или есть, или его нет. Если в шарпе разделения нет, то ввести его, сославшись на "обещпринятые определения" не получится. Если бы C# был васиком или паскалем... если бы у бабушки были яйца, то она была бы дедушкой.  Какая практическая причина разделения на функции и не функции? Кроме букоедства, и желания притянуть в C# определения из басика?


Насколько это "общепринятое" определение?  Так всех учили в школе/универе - так там основным языком был паскаль. Скорее можно утверждать что в некоторых языках это разделение ввели. 

В C# понятия функции/процедуры нет, зачем его притаскивать за уши? Тем более что в C# 3.5 понятие функции (математической) ввели, но обозвали им ... лямбда выражения. Которые вообще-то даже "блоками кода" не являются.


Ага, вот только линк на английский вариант редиректит на http://en.wikipedia.org/wiki/Subroutine и для функций и для процедур. В котором явно сказано что subroutine, subprogram, procedure, method, function, routine - это синонимы. И это определение используется в литературе, документации, статьях и даже сообщениях форумов. Это к вопросу об общепринятости...

Ну так и всё тогда, значит это всё одно и тоже  

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

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

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

Не из статьи, а из кирса интуита. А их, кстате, сурьйозныи дятьки пишут.

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

Сурьезные - это Рихтер, Эспозито, Фаулер, Гамма и компания. А Биллиг В. А. - просто дядька, хотя курс вполне нормальный 

Весьма общепринятое в истории развития языков программирования. При чем тут - паскаль?

Процедуры, еще раньше назывались подпрограммами, SUBPROGRAM, subroutine. И во многих языках отдельный синтаксис вызова был:
DО MYPROC WITH PAR1, PAR2
и
=myfunc(par1,par2) или $$myfunc(par1,par2) (= и $$ нужно было указывать обязательно)
для функций.

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

Речь шла - о "путанице", я и пытался рассказать о ее причинах.


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


Все есть - блок кода. Как Вы кодите без кода то?   


Я и не притаскиваю. И в той теме о делегатах как раз и наехал за использование "функция" в применении к C#. 

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



Это сообщение отредактировал(а) Skynin - 10.12.2009, 10:40

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

Ты кого имеешь в виду?  


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

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

Это общепринятое название в одной ветке ЯП - заточенных под процедурное программирование. 

Есть общие термины, а есть нюансы осмысления в процедурных ЯП.
Есть история развития терминов, в пределах процедурных ЯП и концепций.

C# - мультипарадигменный язык, с уклоном в ОО и поддержкой ФП. В ОО нет функций и процедур. Есть объекты и их методы. Статический метод еще можно фунцией/процедурой назвать, но метод - это понятие, которое во времена процедурных языков не сущестовало. 

Функциональные языки появились до процедурных. Там свое понятие функции. Понятие фукнции (в документации по С#) унаследовано из F#, по крайней мере в доках по linq.

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


Википедию можно исправить 
Что-то меня ни C, ни C++, ни даже ассеблер за вызов "функции" как "процедуры" не ругал. 
Это ограничение вообще существовало где-нибудь, кроме пары древних однопарадигменных процедурных ЯП? 21 век уже, чисто процедурные языки надо забыть как страшный сон.


Лямбда при копмиляции как Expression первращается в кусок данных, а не в "блок кода", и при этом вызвать ее нельзя и "код" в ней не выполняется. Вот так и кодим.


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


Ок, пример:


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

Добавлено через 11 минут и 34 секунды

Нас ес-но %)

Это сообщение отредактировал(а) PashaPash - 10.12.2009, 17:51

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

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

Да она как бы и не выполняется, в том и фишка с лямбдами. Компилятор делает из него дерево объектов типа Expression. А уже конктретный linq provider решает что с этим деревом делать. Может откомпилировать в делегат и вызвать как код. 
Может оттранслировать в строчку SQL и скормить SQL Server-у. Но тогда на самом деле ни вызова геттера row.Field, ни вызова > на самом деле выполнено не будет. Может превратить в JOIN, если эта лямбда в LoadOptions, типа LoadWith(task => task.Project) - тогда код вообще не "выполняется".

По аналогии - аттрибут на каком-нибудь свойстве - не выполняется ведь. Аттрибут [DefaultValue(42)] - не выполняется в "общепринятом" смысле. Лямбда в цепочке вроде config.SetDefaultFor<MyClass>(c => c.MyProperty).To(42) тоже не выполняется, используется просто как способ указать на свойство.

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

А при чем к коду - компиляция?


Замечательно!   


Это все объясняет  
Винигрет из лямбд, компиляции и Expression

В рассуждения о видах рифмы в стихах приплести качество типографской краски и бумаги.

Это сообщение отредактировал(а) Skynin - 10.12.2009, 21:10

Да, зато у тебя все строго и по классике 
row => row.Field > 42
Блок кода. Немиенованный. Не функция по твоему определению, так? Может винигрет все-таки у тебя? Книжки неправильные читаешь, или еще что-то.... 

Смотри, простой пример:

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


Блок кода, неименованый, вызвать напрямую нельзя. Все три строчки отрабатывают задолго до "выполнения" в любом виде. Ну никак не функция? А ведь полный аналог примера выше.

diadiavova, Я утвреждаю, что вы пытаетесь притянуть термин из процедурного программирования в ООП. 

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

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

Это сообщение отредактировал(а) PashaPash - 10.12.2009, 22:19