| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 3222 05-10-2007 09:53 |   |
Ответ на »сообщение 3218« (...)
___________________________
У меня появляется чувство, что Ваша скрытая цель - дать Илье Ермакову возможность доказать, что он прав. Сначала вы даете ему совершенно невнятный пример с continue. Потом такой же невнятный пример на генераторы/yield. yield лучше давать на совсем простом примере. Например, реализацию питоновского xrange() на самом питоне.
| № 3221 05-10-2007 09:52 | |
Ответ на »сообщение 3218« (...)
___________________________
Ответ на »сообщение 3215« (Илья Ермаков)
yield return... - это синтаксический сахар, позволяющий легко и наглядно сделать это. И без yield break здесь тоже никак. Кстати, такими финтами, когда функция возвращает не саму коллекцию, а интерфейс, можно эмулировать ленивость вычислений.
Т.е. возвращается композиция элементов, собранных на разных витках цикла? Пардон, тогда это конструкция языка с особой семантикой, к обычному циклу отношения не имеющая. То, что авторы языка решили её выстроить на базе обычного цикла с доп. ключевым словом, смотрится не очень красивым решением.
| № 3220 05-10-2007 09:49 | |
Ответ на »сообщение 3216« (...)
___________________________
Ответ на »сообщение 3214« (Илья Ермаков)
___________________________
Аналогия не совсем верна. Учитывая ваше стремление к простоте и чистоте языка, я бы привел аналогию с pidgin english - английским языком, на котором говорят туземцы. Или с европейской кампанией по упрощению английского, высмеянной в пародии Ze drim vil kam tru (The dream will come true) :)))
Мне кажется, что Ваша аналогия ещё менее верна. "Язык" программирования не имеет никакого отношения к естественному языку. Это формализм, формальная нотация (кстати, Вирт неоднократно подчёркивал, что слово "нотация программирования" лучше, чем "язык программирования").
Речь ведь не идёт о том, чтобы писать картины, используя только минимум оттенков. Картины - это "неформальный" мир, так же, как и естественный язык.
Но стоит нам уйти от искусства к полиграфии или к архитектуре, и оказывается, что лафа кончилась, и нам придётся работать в рамках небольшого, выбранного для конкретного изделия, цветового базиса, следуя всем его правилам. Иначе результаты будут малоудовлетворительны.
| № 3219 05-10-2007 09:45 | |
Ответ на »сообщение 3214« (Илья Ермаков)
___________________________
Как насчет такого варианта?
def hasitem(list, value):
for item in list:
if item == value:
return True
return False
В реальности так на Python не пишут, конечно :)
Это просто для иллюстрации. Не желаете переписать по всем правилам структурного программирования и обосновать гораздо большую понятность варианта с while?
| № 3218 05-10-2007 09:44 | |
Ответ на »сообщение 3215« (Илья Ермаков)
___________________________
Поясните, если не трудно - не то даже, КАК это работает, а главное - то, ЧТО Вы этим делаете...
Функция с типом IEnumerable<bool> возвращает сразу коллекцию (или массив, в зависимости от контекста) булевых значений. yield return... - это синтаксический сахар, позволяющий легко и наглядно сделать это. И без yield break здесь тоже никак. Кстати, такими финтами, когда функция возвращает не саму коллекцию, а интерфейс, можно эмулировать ленивость вычислений.
| № 3217 05-10-2007 09:40 | |
Выбросить из языка for-циклы и перечислимые типы - дело нехитрое; учить студентов азам программирования вполне возможно и без этих конструкций. А вот программировать в срок и согласно заданным требованиям огромные, сверхсложные, долгоживущие, развиваемые и сопровождаемые системы - не знаю...
Вспоминается Эллочка-Людоедка с ее словарным запасом в 33 слова. Говорить на таком языке вполне можно, а вот думать - навряд-ли.
| № 3216 05-10-2007 09:36 | |
Ответ на »сообщение 3214« (Илья Ермаков)
___________________________
В таком случае лично я бы отказался от foreach Упаси Господи, только не это!
Такие элементы как foreach или yield return/brek - это и есть привнесение элементов функциональности в C#. Тут ведь ветка по функциональному программированию, а не по Оберону :)
Насчет for вы тоже погорячились. Глядя на цикл мы сразу можем сказать, что код внутри него не меняет индексатор, что не скажешь про while.
Но народ, как обычно, делает другой вывод: нужен стоп-кран, и всегда пользоваться только стоп-краном... :-) Аналогия не совсем верна. Учитывая ваше стремление к простоте и чистоте языка, я бы привел аналогию с pidgin english - английским языком, на котором говорят туземцы. Или с европейской кампанией по упрощению английского, высмеянной в пародии Ze drim vil kam tru (The dream will come true) :)))
| № 3215 05-10-2007 09:26 | |
Ответ на »сообщение 3211« (...)
___________________________
Ответ на »сообщение 3209« (Илья Ермаков)
___________________________
Хотя... Не хочу превращать форум в хлам из кусков выдранного кода, но вот вам еще примерчик. :)
Ну если уж примерчик... То почему бы и не пошшелкать :-)
Но я предупредил, что C# не знаю. Поэтому до конца понять семантику Вашего куска с ходу не могу. Поясните, если не трудно - не то даже, КАК это работает, а главное - то, ЧТО Вы этим делаете...
| № 3214 05-10-2007 09:19 | |
Ответ на »сообщение 3213« (...)
___________________________
Ответ на »сообщение 3208« (Trurl)
___________________________
Кстати, конструкция foreach более функциональна, чем указанный WHILE (не_достигнут_конец) & ~(условие_на_искомый_элемент) DO смещаемся к следующему элементу END., т.к. foreach абстрагируется от ненужного в данном случае индексатора коллекции. И без break здесь никак, вот так
В таком случае лично я бы отказался от foreach (кроме его прямого назначения - пройти всё от начала до конца). Ввели когда-то в язык цикл for. Потом foreach. Почему? Потому что цикл для удобного применения в частных случаях. В каких? По определению for - для тех случаев, когда число раз, которое должен выполниться цикл, известно до его начала. "Поезд запущен от станции до станции". Спрыгнуть нельзя. Но очень нужно. А раз нужно - то вывод: "не на тот поезд сели". Т.е. не тот цикл использовали. Но народ, как обычно, делает другой вывод: нужен стоп-кран, и всегда пользоваться только стоп-краном... :-)
| № 3213 05-10-2007 09:11 | |
Ответ на »сообщение 3208« (Trurl)
___________________________
Кстати, конструкция foreach более функциональна, чем указанный WHILE (не_достигнут_конец) & ~(условие_на_искомый_элемент) DO смещаемся к следующему элементу END., т.к. foreach абстрагируется от ненужного в данном случае индексатора коллекции. И без break здесь никак, вот так
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
