Здравствуйте, bigger longer and uncut, Вы писали:

BLA>Вот именно это и забило окончательный гвоздь в мое терпение. Как можно беседовать с человеком, когда он говорит агитками?

Хм. Но я же с тобой бесудую? Ты в своей агитке

Автор: bigger longer and uncut
Дата: 23.03.06

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

BLA>Разве можно апеллировать к агитке? По-моему, нельзя.

Тогда с тобй вообще нельзя разговаривать.

BLA>Ну здесь как — вообще термин "функциональный язык" достаточно условная вещь, конечно,

+1

BLA> но одно видимо можно сказать — это языки, которые в основе своей имеют лямбда-исчисление.

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

BLA>То есть лямбда-функции являются основным и единственным строительным блоком и все конструкции в языке(ну как минимум все функции) состоят из лямбд. лямбда — это анонимная функция, которая так же является замыканием — то есть помнит родительский контекст.

В общих чертах можно согласиться. Хотя мнение несколько натянутое на мой взгляд.

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

Это цель любого современного ЯП.

BLA>Это конечно все очень упрощенно, но примерно так.

Я бы даже скзал очень расплывчато и натянуто.

Классическое определение функционального программирования звучит как-то так:

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

BLA>Так вот — Nemerle никакого отношения к этому описанию не имеет. В нем даже лямбд нет — то, что там называется таковой, на самом деле макрос, который генерирует делегат.

Ошибаешся. Лямбда в Немерле описывается так:

fun(список параметров){ тело }

С макросами это никак не связано.
Есть макрос позволяющий записывать лябды с одним параметром таким образом:

lambda x -> тело

но он преобразуется во все ту же конструкцию fun.

Что до делегатов, то функция никак не может являеться делегатом, просто потму, что делегат — это ссылка на функцию.

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

BLA>Причем макросы в немерле — это вообще говоря антифункциональная вещь.

Во как? Прэлесно!

BLA> То есть они не first-class values,

Ну, и что? Кому-то это мешает? Мне — нет.

BLA> их нельзя передавать куда-то или возвращать, хотя со стороны они выглядят как функции. Удачи маленьким любителям функциональных языков.

Действительно удачи любителям функциональных языков. А лично мне это все на фиг не упало. Внутри макроса я без проблем могу использовать любой стиль. Сами макросы я опять же могу использовать из любого стиля. Обернуть макрос в фнкцию проблемы не составляет.

В общем, мне не нужна фунциональщина любой ценой. Как приятный бонус я ей рад. Но как единственно-верное учение — увольте.

BLA>То есть немерль не более функциональный, чем, скажем, С++. Javascript к слову гораздо более функциональный, если на то пошло.

Логика откровенно никудышная. Нэмерле и без макросов позволяет писать в функциональном стиле (использовать функциональную парадигму, если угодно). Более того фунциональный стиль в нем является основным. Как раз императивный стиль там на макросах в основном реализаван. Даже циклы макросами переписываются в рекурсивные функции/замыкания.

Учитывая, что непосредственно во функциональных языках макросы встретить можно не часто, вообще не ясно о чем речь.

BLA>Если же мы идем дальше и пытаемся сравнить с Хаскелем и Окамлом, то все еще хуже.
BLA>То есть достаточно было бы упомянуть отсутствие карринга в немерле, чтобы выкинуть гигантский кусок выразительной мощи из окамла с хаскелем,

Хм. С каких это пор карринг стал неотемлемой частью ФЯ? А как же тогда Схема, Лисп и т.п.? И чем же это его отсуствие так сильно угнетает выразительность?

Карринг конфликтует с перегрузкой. Естественно, что в языке претендующем на С-подобный синтаксис выбрали перегрузку, а не карринг.

Собственно на практике и без каринга получается жить очень неплохо. Например:

def list1 = [1, 3, 5, 9];
def Add(a, b) { a + b } // функция с двумя аргументами
def list2 = list1.Map(Add(_, 1)); // Применяем ее как функцию с одни аргументом

Ну, и естественно никто не мешает комбирировать фунции явно с помощью создания лябд или локальных функций (как в Лиспах).

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

BLA>но еще ведь есть типы.
BLA> Которые в немерле — это просто дотнетовские классы на самом деле, со всеми их проблемами.

И достоинствами. Про них тоже забывать не стоит.

BLA>То есть кроме всего прочего понятно, что они еще динамические и т.п.

В смысле динамически создаются в динамически выделяемой памяти? Да, и что? Это совершенно нормально для любого языка претендующего на звание ОО. И уж просто обязательно для любой компонентной системы.

BLA>Ну и как вишенка на тортике — Null_pointer_exception.

Ужас какой! И как люди с этим живут?

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

И тем неменее все это в нем есть.

Например, те же варианты:

variant Tree [T]
{ | Node { left : Tree[T]; mid : T; right : Tree[T]; }
  | Leaf

  public override ToString () : string
  {
    match (this)
    { | Node (l, m, r) => $"($l $m $r)"
      | Leaf           => "."
    }
  }
} 

def tree = Tree.Node(Tree.Node(Tree.Leaf(), 1, Tree.Leaf()), 2, Tree.Leaf());
System.Console.WriteLine(tree.ToString());

выводит:

((. 1 .) 2 .)

BLA>Вот такие у нас нынче пошли типобезопасные функциональные языки.

Ага. Только не функциональные, а скорее поддерживающие функциональный стиль. Впрочем это определение полностью подходит и ОКамлу.

А ты просто неверно трактушь понятие "типобезопасный".
http://en.wikipedia.org/wiki/Typesafe

BLA>Еще принято считать, что ленивые языки как минимум в два раза выразительнее, чем энергичные (небезосновательно).

Видимо по этой причине ты тут все время пиаришь ОКамл.

Рельно линивые по умолчанию языки порождают медленный код и иногда приводят к не очень очевидному коду. В Немерле, как и в ОКамле можно выборочно помечать части кода как линивые. А можно использовать подход из C# 2.0 и использовать итераторы.

BLA>Вот теперь вы можете отличать функциональные языки.

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

E>>Переход же на личностные разборки просто убивает интерес к первоначальной теме.

BLA>Да.

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