VD>>>Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.
T>>We all yet to see your article entitled like "Хаскель, как шаг к теории типов", ага.
T>>Уж коли ты так хорошо во всём разобрался.
VD>Мы говорили о близости языков. Не о знании глубин, а о возможности понимать текст одного языка зная другой и синтаксические различия между ними.
VD>Ты хочешь сказать, что зная Хаскель и различие его с ОКамлом по синтаксису я не смогу читать код который не использует ООП ОКамла (который и правда сильно отличается от хаскелевского подхода)?

Ты как-то в одну сторону всё повернул. Зная Хаскель, я смогу читать код на ОКамле с меньшим количеством ошибок, чем наоборот. Вот наоборот ты не рассмотрел.

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

В Хаскеле есть классы типов, есть kinds, есть GADT (практически, зависимые типы данных — я про них не зря намекнул).

Разница между OCaml и Хаскелем такая же, как между Си первых Юниксов и современным C++. Ну, или как между ТурбоПаскалем 5.0 и Ада.

VD>>>Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.
T>>We all yet to see your article entitled like "Хаскель, как шаг к теории типов", ага.
T>>Уж коли ты так хорошо во всём разобрался.
VD>Кстати, я не понял, чего ты радуешься? Человек высказал мысль о том, что Хаскель значительно сложнее ОКамла и что последний ему понятен, а первый нет. Ты по идее с ним должен спорить, а не со мной.

Я с тобой и не спорю. Я тебя подкалываю.

L>>Возможно, но ломка привычки в отношении синтаксиса — копейки.
VD>Отнюдь не копейки. Есть масса людей которые программировали на Дельфи в 90-тые. Сейчас Дельфи не в фаворе. Разумно было бы перейти на C#, ведь язык очень близок по духу. Разница только в синтаксисе. Однако многие так и остаются на клонах Дельфи, так как учить эту разницу и нюансы сложно, а работать надо сейчас.

Это значительно более сложный вопрос, чем твоё его изложение.

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

Я, например, оспаривать буду не сам факт, а твоё его изложение.

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

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

Следующий шаг — выбор языка для реализации каждой из частей.

Оные дельфисты писали в стиле "хватай мешки, вокзал отходит!" Не давая себе времени на рефлексию и прочее. Вот и результат.

VD>>>Кстати, то что ты знал Пролог могло сильно упростить тебе изучение ФЯ, так как Пролог уже помог тебе переломить сознание. Как минимум понять паттерн-матчинг в Хаскле не проблема если ты знаком с Прологом.

Я, например, начал изучать Хаскель не зная (практически) ни Лиспа, ни Пролога. Но у меня большое количество проектов содержало тексты программ на более, чем одном языке программирования. Поэтому у меня не было проблем с тем, куда и как можно применить Хаскель.

Именно поэтому я не сторонник IDE. Они мешают использовать ЯП точно по его месту, которое отличается от представления о нём авторов IDE.

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

LP>>Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.

T>Наличие выбора порождает трату времени на разрешение его проблемы.

Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?

LP>>>Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.
T>>Наличие выбора порождает трату времени на разрешение его проблемы.
LP>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?

Да, именно так.

VladD2 пишет:

> На практике использовался Турбо паскаль/Объхект паскаль/Дельфи. Когда
> кто-то говорит сегодня "Паскаль", то большинству программистов
> впоминаются именно они.

Да нет, просто языки это разные. Похожие, по мотивам, и т.д, но разные.
Ладно. Не важно.

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

E>>Откуда информация о том, о чем привык думать императивный программист?

S>Вообще-то — из определения "императивного программиста".
S>Как только программист перестаёт думать императивными конструкциями, он перестает быть императивным программистом. Это не должность, а именно стиль мышления. Это способ декомпозиции любого алгоритма на операции модификации, ветвления, и перехода, применяемые к некоторому глобальному состоянию. "Структурно-императивный" программист, получающийся из "наивного императивного программиста" путем несложной тренировки, предпочитает трактовать все переходы вперед как ветвление, а переходы назад — как цикл. Некоторые фрагменты глобального состояния для удобства получают имена и становятся перемеными.
S>Процедурно-императивный программист уже дополнительно мыслит категориями процедур и стека и т.п.

S>Но цикл остается центральной идеей императивного программирования — просто потому, что никаких других способов обработки "последовательностей" нету. Точнее, есть рекурсия, но
S>а) у наивных программистов при ней доступ к глобальным переменным ведет себя как-то странно
S>б) у продвинутых программистов быстро переполняется стек, "поэтому для больших объемов данных рекурсия неприменима".

Антон, где такая трава растёт?

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

L>Согласен. Однако возьмём два совершенно непохожих синтаксически языка — схема и хаскель. У меня переход был именно такой — от схемы я пришёл к хаскелю. Языки совершенно различны в плане синтаксиса, однако синтаксис совершенно не был для меня проблемой — по крайне мере на фоне всего остального я даже не припомню какие то трудности восприятия. У меня там совсем другие трудности были.

Это потому-что тебе требовалось всего лишь освоить новый синтаксис. Концепция нового языка была для тебя и так знакома. А вот когда человек пытается изучить Схему или Хаскель после опыта работы, скажем, с С++, то для него незнакомыми являются и концепция, и синтаксис, и семантика. В общем, новый мир.

Короче говоря, пересесть со Схемы на CL просто потому, что ты всего лишь осваиваешь новые фичи. Для тебя это просто расширение знаний (не очень большое). Пересесть с ОКалма на Хаскель так же не трудно. Пересесть со Схемы на Хаскель труднее, но вся трудность (особенно учитывая опыт с Прологом) в освоении нового синтаксиса и небольшого количества новых фич. Пересесть же с С++ на Хаскель неимоверно сложно. В прочем как и наоборот, наверное. Хотя почему-то мне кажется (чисто интуитивно), что второе проще (на первых порах, по крайней мере).

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

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Антон, где такая трава растёт?

А причем тут трава? Какие-то постулаты вызывают сомнения?

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

LP>>>>Отличие в том, что фп в принципе отрицает изменение, порождая дерево заново, в случае ИП мы не столь радикальны.
T>>>Наличие выбора порождает трату времени на разрешение его проблемы.
LP>>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?

T>Да, именно так.

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

LP>>>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?
T>>Да, именно так.
LP>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.

Тебе гибкость иметь или программу писать?

Лично мне — программу.

VD>Пересесть с ОКалма на Хаскель так же не трудно.

We all yet to see your article named "Обобщённые алгебраические типы, как шаг к зависимым типам данных", ага.

Поскольку пересесть с Nemerle на Хаскель не будет составлять труда, по-твоему.

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

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

Значительно дольше.

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

VD>Короче говоря, пересесть со Схемы на CL просто потому, что ты всего лишь осваиваешь новые фичи. Для тебя это просто расширение знаний (не очень большое). Пересесть с ОКалма на Хаскель так же не трудно. Пересесть со Схемы на Хаскель труднее, но вся трудность (особенно учитывая опыт с Прологом) в освоении нового синтаксиса и небольшого количества новых фич. Пересесть же с С++ на Хаскель неимоверно сложно. В прочем как и наоборот, наверное. Хотя почему-то мне кажется (чисто интуитивно), что второе проще (на первых порах, по крайней мере).

Осваивать Хаскель после С++ было не просто, но синтаксис Хаскеля не мешал изучению, а скорее помогал. Непривычнее всего было понять что по умолчанию пишется expression, а не statement, но это по началу. Непривычно было возвращать новую функцию, от каринга я вообще в восторге был (сейчас правда в С++ так иногда хочется лямбду куда-нибудь передать ). ИМХО, у Хаскеля очень лаконичный и понятный синтаксис. Да там есть операторы состоящие только из значков, значение которых вовсе неочевидно. Я это к тому говорю, что семантику мы воспринимаем через синтаксис и ситнаксис может как помогать нам в восприятии, так и мешать. Если говорить про Хаскель, то там синтаксис чаще помогает, особенно когда учишь основные концепции языка. А если пытаться учить приёмы ФП используя С++ синтаксис будет только мешать (меня недавно человек спросил: "А что такое функтор?". И получается, что это вроде как класс, но используется как функция. На что последовал следующий, вполне логичный, вопрос: "А зачем?" ).

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

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

DC>А если пытаться учить приёмы ФП используя С++ синтаксис будет только мешать

По мне так это весьма полезно — научиться писать в функциональном стиле на C++. После того, как набъёшь руку с boost::bind, никакой карринг уже не испугает :)

DC>(меня недавно человек спросил: "А что такое функтор?". И получается, что это вроде как класс, но используется как функция. На что последовал следующий, вполне логичный, вопрос: "А зачем?" :)) ).

А в чём проблема ответить? 1) захват контекста (обычно передача окружения в ктор функтора), 2) возможность комбинировать операции (на указателях-на-функцию суперпозиции не сделаешь), 3) возможность манипулирования ФВП (например, сфабриковать внутри функции другую функцию и вернуть её в качестве результата).

В функциональных языках всё готовенькое, меньше пищи для размышлений — прозрачные замыкания, халявный карринг, etc. А C++-программисту волей-неволей приходится врубаться в потроха таких вычислений. Перечисленные выше пункты дают понимание (соответственно): 1) лексических замыканий, 2) деревьев выражений, 3) отложенных вычислений.

Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного :)

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

LP>>>>Не понял. То есть нужно тратить время на придумывание, как именно реализовать (изменять копию или непосредственно объект, по которому происходит итерация)?
T>>>Да, именно так.
LP>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.

T>Тебе гибкость иметь или программу писать?

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

T>Лично мне — программу.

А мне — программу, которая удовлеторяет предъявляемым требованиям, в том числе и по потребляемым вычислительным ресурсам.

LP>>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.
T>>Тебе гибкость иметь или программу писать?
LP>Знаешь, что я делаю в данный момент? Сишу с профайлером и выцепляю узкие места, в которых проблемы с производительностью, коих тьма. Потому как программа написана на 90 процентов и она даже работает, но не устраивает то, как она работает.

Кого не устраивает?

T>>Лично мне — программу.
LP>А мне — программу, которая удовлеторяет предъявляемым требованиям, в том числе и по потребляемым вычислительным ресурсам.

Q>Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного 

Это очень неправильное О.

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

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

Вот и выбирай — потратить два месяца на выяснение, как написать замыкания на C++ или за те же два месяца написать компилятор, например. Отточив мышление в функциональном стиле, в отличии от MPD стиля "ФП на C++". Не говоря уж про знание многих полезных вещей в самом конце — AST, кодогенерация и прочее.

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

Q>>Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного :)

T>Это очень неправильное О.

T>Для этого человека нет ничего невозможного в написании программы...

Я как раз таки имел в виду не возможность (или невозможность) написания программ, а лёгкость в понимании других языков и подходов. Взять, например, ФП на C# (наверное, для хаскельщиков это смешно звучит). Вот новичок видит описание новых фич: замыкания, итераторы (CPS aka «yield return»), LINQ. Но начав использовать, натыкается на грабли: сохранённая лямбда вдруг начинает возвращать разные результаты, некоторые функции легко обрабатывают бесконечные последовательности, а некоторые на них падают со StackOverflow, OrderBy почему-то не сортирует последовательность. Человек без C++-бэкграунда пойдёт копать документацию или спрашивать на форум. А C++-программисту это в большинстве случаев не надо, ведь он знает, как устроено «мясо». Он может вывести ранее неизвестные неочевидные фичи языковых конструкций, просто прогоняя в уме их потенциальную реализацию. Т. о. он получает новые по сути знания, и может предсказать поведение неопробованных конструкций языка, просто с помощью анализа своего предыдущего опыта программирования на C++. Это прекрасно!

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

LP>>>>Зато есть гибкость — если критична скорость, используем прямую модификацию, без всяких, как их там, монад.
T>>>Тебе гибкость иметь или программу писать?
LP>>Знаешь, что я делаю в данный момент? Сишу с профайлером и выцепляю узкие места, в которых проблемы с производительностью, коих тьма. Потому как программа написана на 90 процентов и она даже работает, но не устраивает то, как она работает.

T>Кого не устраивает?

Пока — меня. Потом будет не устраивать пользователей.

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

Q>По мне так это весьма полезно — научиться писать в функциональном стиле на C++. После того, как набъёшь руку с boost::bind, никакой карринг уже не испугает 

После того как увидел карринг в Хаскеле, от boost:bind тошнить начинает . А, вообще, полезно, только язык тебе не помогает, а мешает выражать свои мысли.

DC>>(меня недавно человек спросил: "А что такое функтор?". И получается, что это вроде как класс, но используется как функция. На что последовал следующий, вполне логичный, вопрос: "А зачем?" ).

Q>А в чём проблема ответить? 1) захват контекста (обычно передача окружения в ктор функтора), 2) возможность комбинировать операции (на указателях-на-функцию суперпозиции не сделаешь), 3) возможность
манипулирования ФВП (например, сфабриковать внутри функции другую функцию и вернуть её в качестве результата).

"...А теперь попробуй объяснить им (средневековым монахам) что ты муж ведьмы, не используя обороты типа : Толерантное отношение к магическим меньшинствам..."
© Белянин С.
Человек только начал въезжать в С++ с его ООП и прочей фигнёй. Объяснить не трудно, важно дать понять зачем это надо и как использовать.

Q>В функциональных языках всё готовенькое, меньше пищи для размышлений — прозрачные замыкания, халявный карринг, etc. А C++-программисту волей-неволей приходится врубаться в потроха таких вычислений. Перечисленные выше пункты дают понимание (соответственно): 1) лексических замыканий, 2) деревьев выражений, 3) отложенных вычислений.

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

Q>Имхо, если человек освоит приёмы ФП на C++, то для него вообще нет ничего невозможного 

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