Здравствуйте, FR, Вы писали:

FR>Не синтаксис, а процесс программирования. Мне сейчас функциональные языки в этом отношении кажутся похожими на forth, написание любой программки это тренинг мышления, попытка понять через месяц что написал тоже

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

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

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

Вот мне и кажется, что дело не в абстрактности, а в форме выражения. Я назвал это синтаксисом, но возможно это не подходящее слово.

Здравствуйте, FR, Вы писали:

FR>При желании наверно можно, но питон как и C++ мультипарадигменный. Хотя так и ocaml можно отнести к императивным

Согласен, относить язык к типу парадигмы на основании поддержки фич в корне не верно. При такой формализации можно развать ФЯ языки вроде ОКамла императивными, а С++ и C# функциональными, только по тому что они обладают возможностями писать в разных стилях.

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

Здравствуйте, Quintanar, Вы писали:

Q>Причем тут вообще Haskell? Никто никогда нигде не утверждал, что он работает быстро, тем более на задачах связанных с интенсивной работой с массивами. Его прелесть совсем в другом.

Дык теоретическая прелесть интересна только эстетам. Всем нужна практическая прелесть.

К сожалению, красота резко меркнет когда встают вопросы производительности.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Дополню.
INT>Препроцессор P4 в Ocaml — это не макроподстановки. Это инструмент, который работает непосредственно с синтаксисом языка. Например, он позволяет не только добавлять, но и убирать правила из грамматики.
INT>Пример с удаленями правил можно посмотреть в туториале.
INT>Вот простой пример добавления правил — добавление конструкции repeat/until.

INT>

INT>       open Pcaml;;
INT>       EXTEND
INT>         expr: LEVEL "expr1"
INT>           [[ "repeat"; e1 = expr; "until"; e2 = expr ->
INT>                 <:expr< do { $e1$; while not $e2$ do { $e1$; } } >> ]];
INT>       END;;
INT>

Кстати, отдельная тема очень интересная лично мне в разрезе R#.

ЗЫ

Может не кстати, но все же... Прошу господ приверженцов ФЯ высказаться по поводу названия для нового форума: Название нового форума (того что по ФЯ)

Автор: VladD2
Дата: 28.09.04

. А то время то идет...

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Это не макросообразная конструкция?
Это да но это печальное наследие С.
Многие С++ компиляторы понимают #pragma once

INT>Темплейты — почему они не могут определяться только в хедерах?
В доступных тебе реализациях. Есть реализации где это не так.
INT>Не потому ли, что ониявляются просто замаскированными макросами?
Нет. Это не так. Шаблоны не болие макросы чем функции в функциональных языках.
INT>Не говоря уж о других их "приятных" особенностях...
А именно?

INT>Была бы строгая — не были бы возможны контейнеры.
1)Полиморфные контейнеры не отменяют типизированые контейнеры.
2)Динамическую типизацию ни кто не отменял.
3)В C#2 есть генерик коллекции.

INT>Он уже вышел? Я просто не в курсе. Может, дашь ссылку?
Релиз нет. А бета дано гуляет.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Здравствуйте, FR, Вы писали:

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

Здравствуйте, VladD2, Вы писали:

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

VD>Как видишь все равно с начала не привычно. То есть само человеческое естество не очень то принимает подобные подходы.
VD>Вот мне и кажется, что дело не в абстрактности, а в форме выражения. Я назвал это синтаксисом, но возможно это не подходящее слово.

ИМХО, не в естестве дело. Костность мышления да, имеет место.
Я знаю много людей, хорошо владещих процедурным программированием. Но при попытке пересадить их за ООП получается ПООП (псевдо ООП).
Люди все равно думают строчками кода, а не сущностями, которые за ними стоят.
Трудно переучиваться. Особенно если учишь процедурные языки со школы.
А вот если бы в школах учили не паскалю, а смолтеку — щас бы грамотных С++шников было пруд пруди (это я так, наболело).

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

Здравствуйте, WolfHound, Вы писали:

INT>>Не потому ли, что ониявляются просто замаскированными макросами?
WH>Нет. Это не так. Шаблоны не болие макросы чем функции в функциональных языках.

Ну уж... Это конечно тут офтопик, но приведу пример.

template<class T>
class A
{
    int x = (int)(T::x)+1;
};

Когда компилятор С++ видит такое, как ему распознать строку в классе? Ведь T::x может быть или типом, или идентификатором.
В зависимости от этого, семантика строки будет совсем разная. Так как такие вещи вляиют на синтаксический анализ, компиляторам приходится пропускать весь код между { и }. А потом при каждой инстанциации возвращаться к шаблону и компилировать его. Это ли не макроподстановка?

Здравствуйте, prVovik, Вы писали:

FR>>>Ну не надо ИЯ сводить только к процедурному программированию, есть еще и ООП, тоже насквозь императивный.
INT>>ООП, как ни странно, работает лучше, если использовать его только там, где оно действительно необходимо.
V>То есть где?

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

Обычно же в С++ в классы заворачивают все, что можно, а потом еще внутрь классов набивают методов от души. Так как кроме классов средств модульности нет и функциональные средства (которые позволили бы эффективно использовать функции вместо методов) слабые и неудобные.

Здравствуйте, FR, Вы писали:

FR>>>Не синтаксис, а процесс программирования. Мне сейчас функциональные языки в этом отношении кажутся похожими на forth, написание любой программки это тренинг мышления,
INT>>Да.

FR>Это плохо, это значит что язык мешает работать.

Тут даже не в синтаксисе дело. В ИЯ оснвной объект мышления — данные. Переменные, объекты, etc. В ФЯ основноя объект — действие. В ИЯ функции высшего порядка и темплейты — advanced issues. В ФЯ — основа языка. И синтаксис заточен соответственно. И нужно время, чтобы к нему привыкнуть.

Здравствуйте, WolfHound, Вы писали:

INT>>Не говоря уж о других их "приятных" особенностях...
WH>А именно?
То, что говорил _Nick. И то, о чем писал Страуструп. Почитай "Design & Evolution of C++". Каждая из проблем темплейтов, упонмянутая Страуструпом, в Ocaml решена.

INT>>Была бы строгая — не были бы возможны контейнеры.
WH>1)Полиморфные контейнеры не отменяют типизированые контейнеры.
WH>2)Динамическую типизацию ни кто не отменял.
WH>3)В C#2 есть генерик коллекции.
Ок, в C# есть почти строгая типизация

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Тут даже не в синтаксисе дело. В ИЯ оснвной объект мышления — данные. Переменные, объекты, etc.
Интересный поинт. По-моему, в ия основной объект мышления — абстрактная машина. И собственно инструкции машине, как менять ее состояние, включая instruction pointer. Гранулярность состояния машины зависит от языка. Это может быть стек для форта, регистры для асм, переменные для С, объекты для С++...
INT>В ФЯ основноя объект — действие.
Я твк понял, что все же именно зависимости. Действий в "активном" смысле в ФП не должно быть. Это скорее математика, ФП очень созерцательно по своей сути. Функциональная программа как бы отражает взгляд разработчика на предметную область. Он замечает, что очередное число Фибоначчи равно сумме двух предыдущих, и констатирует этот факт в своей программе. При этом он не только не говорит потенциальному собеседнику "складывай два числа, затем прибавляй к сумме второе и.т.д.". Он избегает говорить даже "для получения очередного числа Фибоначчи надо сложить два предыдущих". Чего, для чего и кому надо — не его забота.

Функциональное программирование такого уровня осваивается людьми гораздо проще любого императива. Потому как имеет дело с "незыблемыми фактами", истинность которых независит от предыстории. Справедливость моего смелого утверждения косвенно подтвердят миллионы людей учетных специальностей, прекрасно справляющихся с Excel. Именно из-за того, что в нем достаточно указать зависимости между данными.
INT>В ИЯ функции высшего порядка и темплейты — advanced issues. В ФЯ — основа языка. И синтаксис заточен соответственно. И нужно время, чтобы к нему привыкнуть.
Ага. Трудно сказать, основа ли оно . Вон как теоретики называют объектными языки, которые предоставляют базовые концепции ООП, и отличают их от объектно-ориентированных, где обязаны поддерживаться такие концепции, как классификация, наследование и т.д, которые с точки зрения абстрактной теории выглядят лишь не столь уж интересным частным случаем гораздо более всеобъемлющей модели сущностей и сообщений
Если мы возьмем даже старое доброе ИП безо всяких объектов, то окажется, что базовые концепции ИП легко осваиваются людьми. Нарисовать домик на Лого после получаса тренировки может даже подросток с нарушениями в развитии. Но потом мы увидим, что в ИП непременно нужны такие управляющие конструкции, как ветвление, циклы, подпрограммы и т.д. Есть переменные, области видимости, ссылки и указатели. Освоение этого материала занимает весьма значительное время. Просто мы все настолько рано обучаемся этому, что трудно вспомнить тот момент, когда простейшие вещи казались непостижимыми.
Это я даже не начал еще пугать вас действительно сложными концепциями ИП, типа исключений с их великолепной раскруткой стека и параллельным программированием.

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

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

Здравствуйте, Sinclair, Вы писали:

S>Это я даже не начал еще пугать вас действительно сложными концепциями ИП, типа исключений с их великолепной раскруткой стека и параллельным программированием.

А кстати, каковы методы обработки ошибок в ФЯ? Наверное, там вся идеология на корню другая?

Здравствуйте, Дм.Григорьев, Вы писали:

S>>Это я даже не начал еще пугать вас действительно сложными концепциями ИП, типа исключений с их великолепной раскруткой стека и параллельным программированием.

ДГ>А кстати, каковы методы обработки ошибок в ФЯ? Наверное, там вся идеология на корню другая?

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

Здравствуйте, Nick_, Вы писали:

N_>Ну уж... Это конечно тут офтопик, но приведу пример.

В данном случае это не тип.

template<class T>
class A
{
    int x = (int)(T::x)+1;
};

Если написать так

template<class T>
class A
{
    int x = (int)(typename T::x)+1;
};

то это будет тип.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>То, что говорил _Nick.

INT>И то, о чем писал Страуструп. Почитай "Design & Evolution of C++". Каждая из проблем темплейтов, упонмянутая Страуструпом, в Ocaml решена.
Не ну ты давай конкретно по пунктам.

INT>Ок, в C# есть почти строгая типизация
Ну печему же почти?
Ты про рантайм не забывай. Там работать с объектом можно только если он будет того типа какой требуется в данном месте.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Nick_, Вы писали:

WH>

Это была шутка?

Назови мне хоть один компилятор, который не скомпилирует этот код. И попробуй доказать, что T::x в шаблоне — это не тип.

$ cat template.cpp
template<class T>
class A
{
        static const int x = (int)(T::x)+1;
};

class B
{
public:
        typedef int x;
};

int main()
{
        A<B> x;
}

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Здравствуйте, Sinclair, Вы писали:

S>>Это я даже не начал еще пугать вас действительно сложными концепциями ИП, типа исключений с их великолепной раскруткой стека и параллельным программированием.

ДГ>А кстати, каковы методы обработки ошибок в ФЯ? Наверное, там вся идеология на корню другая?

Смотря где. В SML, OCaml это делается с помощью исключений, которые почти ничем не отличаются от исключений в C#.
В Haskell исключений нет, поскольку они не укладываются в идеологию ленивого языка. Но можно их эмулировать с помощью монад. Это накладываем определенные ограничения, но что делать. Есть еще возможность использовать CPS или возвращать тип-вариант — либо результат, либо ошибка.

search_list [] = Right []
search_list h:t =
  case search_list t of
    Right l -> if something_wrong_with h then Left "error" else Right h:l
    Left err -> Left err -- передать ошибку дальше

Этот вариант геморойный, лучше использовать соответствующую монаду.
CPS вариант:

search_list l = search_list_cont l (\x -> Right x)

search_list_cont [] cont = cont []
search_list_cont (h:t) cont = 
  if something_wrong_with h then Left "error"
  else search_list_cont t (\x -> cont (h:x))

Здравствуйте, Nick_, Вы писали:

N_>Назови мне хоть один компилятор, который не скомпилирует этот код.
Странно. Буду разбираться какого это компилится...
N_>И попробуй доказать, что T::x в шаблоне — это не тип.
Тут доказывать нечего
14.6/2

A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword typename.

ЗЫ А ты попробуй откомпилить это(без typename)

template<class T>
struct A
{
    typename T::x x;
};

struct B
{
    typedef int x;
};

int main()
{
    A<B> x;
}

Только на нормальном компиляторе.
VC++7.1

------ Build started: Project: idkfa, Configuration: Release Win32 ------

Compiling...
idkfa.cpp
idkfa.cpp(501) : warning C4346: 'T::x' : dependent name is not a type
        prefix with 'typename' to indicate a type
        idkfa.cpp(502) : see reference to class template instantiation 'A<T>' being compiled
idkfa.cpp(501) : error C2146: syntax error : missing ';' before identifier 'x'
idkfa.cpp(501) : error C2501: 'A<T>::x' : missing storage-class or type specifiers

Build Time 0:00
Build log was saved at "file://e:\work\idkfa\Release\BuildLog.htm"
idkfa - 2 error(s), 1 warning(s)


---------------------- Done ----------------------

    Build: 0 succeeded, 1 failed, 0 skipped

Здравствуйте, WolfHound, Вы писали:

WH>Только на нормальном компиляторе.
WH>VC++7.1

Да?

C:\>cl template.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

template.cpp
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:template.exe
template.obj

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