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

D>имхо, конечно, изменения, вошедшие в Ada 2005, тянут на новую версию стандарта...

Так новая версия как раз планируется. В этом году или в следующем. ISO/IEC 8652:2007. Я о том и говорил, как раз, что нового стандарта еще нет, но он будет.

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

FR>Я серъезно не тестировал, но реализованно там все удобно, и скорее противоположно Эрлангу, не процессы — локальный парлелизм, прочитать можно тут:http://www.ps.uni-sb.de/alice/manual/futures.html

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

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

K>>Не делает ли это Alice, в каком-то смысле, вещью в себе?
EC>Ты про то, что если не JVM или CLR, то это уже маргинальщина?

Про маргинальщину я ничего не говорил. Если своя VM нужна им для поддержки легких потоков — это оправдано, но подробной информации об этом я так и не нашел. Правда за все надо платить — создание VM это весьма нетривиальная задача, требующая значительных ресурсов. Они же сами пишут, например, что JIT у них есть пока только для x86 — на x86-64 и Power PC Alice фактически интерпретируется.

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

FR>Вряд ли, к тому же у ребят подержка паралельности на таком уровне который на NET/java сейчас не достижим.

Если бы ты прочел указанную статью, то такой бред не сказал бы.

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

E>Вероятно, моя информация устарела. Последний раз, когда я смотрел на Mono, их C# компилятор не полностью поддерживал с C#2.0 от MS.

Очень, вероятно...

Если кому интересно. Есть еще такой любопытный язык: Nice.
Осваивается (в отличии от Eiffel) в лет. И работает поверх JVM, так что интеграция с Java прозрачная + весь JDK в нагрузку. Жалко, только, что этот проект производит впечатление заглохшего.

А так очень симпатичный. Вот пример benchmark-а binary trees на нем в моей реализации:

class TreeNode
{
    int    item;
    ?TreeNode left = null;
    ?TreeNode right = null;

}

int itemCheck( ?TreeNode self )  
{
    if( null != self )
    {
        if( null != self.left )
            return self.item + itemCheck(self.left) - itemCheck(self.right);
        else
            return self.item;
    }
    return 0;
}

TreeNode bottomUpTree( int item, int depth )
{
    if( depth > 0 )
        return new TreeNode(
                item: item,
                left: bottomUpTree( 2 * item - 1, depth - 1 ),
                right: bottomUpTree( 2 * item, depth - 1 ) );
    else
        return new TreeNode( item: item );
}

void main( String[] args )
{
    let N = 1 == args.length ? Integer.parseInt( args[0] ) : 1;

    let minDepth = 4;
    let maxDepth = minDepth + 2 > N ? minDepth + 2 : N; 
    let stretchDepth = maxDepth + 1; 

    let startTime = System.currentTimeMillis();

    let stretchTree = bottomUpTree( 0, stretchDepth );
    println( "stretch tree of depth " stretchDepth "\t check: "
            stretchTree.itemCheck );

    let longLivedTree = bottomUpTree( 0, maxDepth );

    for( int depth = minDepth; depth <= maxDepth; depth += 2 ) 
    { 
        var check = 0;
        let iterations = 1 << (maxDepth - depth + minDepth);

        for( int i : 1..iterations )
        { 
            var tempTree = bottomUpTree( i, depth );
            check += tempTree.itemCheck;

            tempTree = bottomUpTree( -i, depth );
            check += tempTree.itemCheck;
        } 

        let totalTrees = iterations * 2;
        println( "" totalTrees "\t trees of depth " depth "\t check: " check ); 
    } 

    println( "long lived tree of depth " maxDepth "\t check: "
            longLivedTree.itemCheck );

    let stopTime = System.currentTimeMillis();
    let duration = stopTime - startTime;
    println( "" duration "ms" );
}

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

E>Если кому интересно. Есть еще такой любопытный язык: Nice.
E>Осваивается (в отличии от Eiffel) в лет. И работает поверх JVM, так что интеграция с Java прозрачная + весь JDK в нагрузку. Жалко, только, что этот проект производит впечатление заглохшего.

Ты б лучше сказал чем он тебе нравится (кроме интеграции с Java).

Здравствуйте, Andrei N.Sobchuck, Вы писали:

E>>Если кому интересно. Есть еще такой любопытный язык: Nice.
E>>Осваивается (в отличии от Eiffel) в лет. И работает поверх JVM, так что интеграция с Java прозрачная + весь JDK в нагрузку. Жалко, только, что этот проект производит впечатление заглохшего.

ANS>Ты б лучше сказал чем он тебе нравится (кроме интеграции с Java).

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

E>Казалось бы, языков программирования море. Как говорят некоторые, каждый год появляется и исчезает порядка двухсот языков. А как начнешь выбирать что-нибудь достойное, так кроме C++, Java, C# и еще нескольких функциональных (OCaml, Haskell) ничего и не видно (это я утрирую, конечно, но не сильно).

E>В общем, ищется не сильно мейнстримовый язык

Удалось оформить причины, вынудившие меня задать этот вопрос, в виде небольшого раздела моей home page

В рамках этого же мероприятия получилось более плотно познакомиться с языком Eiffel.

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

E>>Казалось бы, языков программирования море. Как говорят некоторые, каждый год появляется и исчезает порядка двухсот языков. А как начнешь выбирать что-нибудь достойное, так кроме C++, Java, C# и еще нескольких функциональных (OCaml, Haskell) ничего и не видно (это я утрирую, конечно, но не сильно).

E>>В общем, ищется не сильно мейнстримовый язык

E>Удалось оформить причины, вынудившие меня задать этот вопрос, в виде небольшого раздела моей home page

E>В рамках этого же мероприятия получилось более плотно познакомиться с языком Eiffel.

На своей странице ты просишь указывать ошибки. Пока дочитал до "Обзор языка Eiffel", выкладываю, что нашел.

Почему я ищу новый язык? — ръяно (мягкий знак нужен); А при появляении (появлении) параллельный for_each может оказаться, что selector_t будет просто-напросто глючить. — может параллельного?

Что не так с C++? — чтож (нужно что ж).

Что хочется найти? — определеть (определить); Неотъемлиной (Неотъемлимой); матиматическом (математическом); Не сложный (Несложный); C++ здесь является плохим примером, (запятая нужна) т.к. его сложно изучать; Эмоциональная составляющая при выборе языка является едва ли не более важным критерием; И как каждый инструмент, он должен хорошо "ложиться в руку" ("хорошо" кавычить не надо); Тот же C++ еще недавно был (а может и сейчас есть) самым настоящим мейнстримом, (запятая нужна) и это было хорошо; интероперабильности (интероперабельности); Так же мне кажется, что мейнстримовые языки должны быть ближе к примитиву, чем мне того хотелось бы. — Тут я не понял, что хотел сказать автор. Расшифровал мысль как "Хочу, чтобы мейнстрим был примитивнее". Так вот, я с ней категорически не согласен .

И еще.

Пожалуй, двумя примерами языков, которые мне никогда не нравились, являются Java и Perl

Ну ладно Perl, но за что Java никогда не нравилась? Сам собираюсь плотнее изучить ее.

С интересом продолжаю читать

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

S>На своей странице ты просишь указывать ошибки. Пока дочитал до "Обзор языка Eiffel", выкладываю, что нашел.

За найденные ошибки огромное спасибо.
Может лучше мне их по мылу высылать, чтобы здесь место не занимать?

S>

S>Пожалуй, двумя примерами языков, которые мне никогда не нравились, являются Java и Perl

S>Ну ладно Perl, но за что Java никогда не нравилась? Сам собираюсь плотнее изучить ее.

Это достаточно долгая история. Которая началась еще где-то в 96-м. Java рекламировалась как "улучшенный" C++. Соответственно, были большие ожидания от использования Java. Но меня жестоко обманули. Первые несколько лет Java была тормознутой и убогой поделкой. Со временем ситуацию улучшили. Но, например, спецификация исключений все равно портит все впечатление.

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

цитирую твой сайт:

E>Очень большой дискомфорт после Ruby в C++ вызывает объем С++ кода. Например, пусть нужно пройтись по вектору объектов и поместить их часть в два вектора-приемника, в зависимости от удовлетворения какому-нибудь условию.

на хаскеле и любом другом языке с поддержкой лямбд:

let (even, odd) = partition isEven numbers

вообще, C++ с STL — это более-менее функциоанльный стиль программирования (в том смысле, что алгоритмы, структуры данных определяются только один раз). но как многословно использование этих алгоритмов! в этом плане более современные языки с выводом типов, лямбдами и GC гораздо лучше


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

во-первых, половина функциональных языков (*ml, lisp) являются императивными. во-вторых, на хаскеле также можно писать императивный код, есть императивные ссылки, массивы, хеши. в-третьих, lazy структуры данных не требуют полного внесения изменений при обновлении. впрочем, это зависит от конкретного способа использования данных

вот в твоём случае — если сотни раз производятся обновления, а сканирование идёт реже, то у тебя будет прсто строиться ленивое вычисление на их обновление, а реально вычисляться оно будет только при сканировании. если же сканирования идут часто, то так и так на нег потребуется много времени, верно?


далее. имхо в настоящее время хаскел лучше подходит для системного программирования, нежедли доля прикладного. почему? во-первых, какие у него преимущества:

1) большая надёжность. большая часть ошибок обнаруживается компилятором. это, кстати, наиболее важный аспект статической типизации. система типов в хаскеле — это основное направление его развития и можно сказать, что здесь именно тип описывает контракт. при этом благодаря type inferring ты не платишь за использование сложных типов как в C++ необходимостью их явного описания. в моих программах типы вообще практически не упоминаются

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

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

4) это уже мелочь, но опять-таки в хаскеле легко определить любые структуры управляения, в том числе RAII-обёртки типа "не забудь закрыть файл", и механизмы обработки исключений. к слову скажу, что у меня их совсем немного — ведь нужно контролировать только внешние ресурсы

недостатки же хаскела, как и любого другого не mainstream языка, связаны с отсутвием IDE (навигация по коду, визуальное редактирование GUI/SQL, отладка), недостатком библиотек, книг, специалистов и т.д. и эти недостатки имхо менее существенны для системного программирования, нежели для прикладного

ещё существенной проблемой является неэффективность генерируемого кода. ну тут уже надо смотреть по реашемым задачам — насколько это существенно и как это можно обойти. у меня например в программе основное время проводится в сишных библиотках сжатия, остальные расходы идут в основном на ввод/вывод и зависят главным образом от ОС, и только в одном паттерне использования медлительность хаскела оказывается существенна — когда нужно прочитать (десериализовать) каталог архива, содержащего десятки тысяч файлов


что касается сложности постижения ФП — то это чисто воображаемая проблема. имхо нужна просто практика. если ты работал с прологом, знаком с apl, используешь возможности ФП руби/питона, то это будет проще. если хочешь, можем устроить некий практикум по ФП — т.е. все желающие придумывают задачи, а я говорю, как решил бы их в хаскеле. кстати, ты http://rsdn.ru/Forum/message/2602368.1.aspx

Автор: BulatZiganshin
Дата: 28.07.07

читал?

E>* безопасный. Т.е. либо работающий на какой-нибудь виртуальной машине, либо компилируемый в нативный код, но с тотальными проверками (в частности, указателей и индексов на валидность);

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

* отсутствия null
* отсутствия адресной арифметики (большинство проблем с указателями С возникает именно здесь)
* строгой типизации указателей и отсутствия преобразования их типов
* gc

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

E>Хочется более простого и стройного языка, чем Java. Без спецификации исключений, без различия между int и Integer, с более простым обобщенным программированием (что-нибудь в духе шаблонов C++ или обобщенного программирования в Eiffel).

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

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

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

BZ>что касается сложности постижения ФП — то это чисто воображаемая проблема. имхо нужна просто практика. если ты работал с прологом, знаком с apl, используешь возможности ФП руби/питона, то это будет проще. если хочешь, можем устроить некий практикум по ФП — т.е. все желающие придумывают задачи, а я говорю, как решил бы их в хаскеле. кстати, ты http://rsdn.ru/Forum/message/2602368.1.aspx

Автор: BulatZiganshin
Дата: 28.07.07

читал?

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

Т.е. от последовательного описания шагов программы никуда не денешься. Поэтому вопрос упирается в то, насколько раздутым или ужатым будет описание. Скажем подходы C++ и Eiffel черезчур многословны. Подходы функциональных языков с их стремлением к математической лаконичности, напротив, слишком ужаты.

У Ричарда Гэбриеля есть хорошее эссе "Reuse versus Compression", в котором он указывает, что ООП -- это не столько путь к повторному использованию, сколько к компрессии программ. Мне кажется, что ФП (по крайней мере по результатам моих попыток познакомиться с Haskell и OCaml) есть не более чем еще один способ компрессии, даже более сильный, чем ООП. А недостатком сильно ужатого текста является сложность его восприятия.

Так что я пока подожду, посмотрю, что проиходит, чем же закончится всплеск интереса к ФП (если он вообще есть за пределами программистких форумов и раскрученных блогов).

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

E>>Хочется более простого и стройного языка, чем Java. Без спецификации исключений, без различия между int и Integer, с более простым обобщенным программированием (что-нибудь в духе шаблонов C++ или обобщенного программирования в Eiffel).

BZ>кстати, насколько я понимаю, проблема в том, что ООП и полиморфизм — это разные вещи.

Попробуй это Бертрану Мейеру рассказать. Я думаю он очень удивится.

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

E>>>Хочется более простого и стройного языка, чем Java. Без спецификации исключений, без различия между int и Integer, с более простым обобщенным программированием (что-нибудь в духе шаблонов C++ или обобщенного программирования в Eiffel).

BZ>>кстати, насколько я понимаю, проблема в том, что ООП и полиморфизм — это разные вещи.

E>Попробуй это Бертрану Мейеру рассказать. Я думаю он очень удивится.

насколько я понимаю, в нём реализовано подмножество возможностей явы. т.е. параметр generic класса можно ограничит снизу, но нельзя его ограничить сверху. таким образом, по возможностям взаимодействия classes+generics он находится посерёлке между C++ и Java. я всё-таки считаю все эти тонкости взаимодействия generic-классов с иерархией классов в их параметрах проявлением именно того, что этоо скрещение двух разных технологий. в чистом ООП описание типа "T extends Numeric" ни к чему, в хаскеле оно является единственным способом описания полиморфных параметров. в смешанных же языках приходится одновременно иметь возможность передвать по ссылке T* любой тип-наследжник T и в то же время иметь этот "extends" механизм отдельно для generics

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

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

BZ>>что касается сложности постижения ФП — то это чисто воображаемая проблема. имхо нужна просто практика. если ты работал с прологом, знаком с apl, используешь возможности ФП руби/питона, то это будет проще. если хочешь, можем устроить некий практикум по ФП — т.е. все желающие придумывают задачи, а я говорю, как решил бы их в хаскеле. кстати, ты http://rsdn.ru/Forum/message/2602368.1.aspx

Автор: BulatZiganshin
Дата: 28.07.07

читал?

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

знаешь, то, для чего в 50-е писали целые императивные программы, сейчас может быть выражено в excel или mathematica с помощью набора формул без необходимости явно записывать все эти циклы и порядок вычислений. решаемые задачи не изменились, но для них нашли более краткую форму, которая описывает только то, какой результат нам нужно получить. Excel иногда сравнивают с таким функциональным языком, где нет возможности описывать свои функции

хаскел, в котором i/o строго отделено от вычислительной части, предлагает несколько иной взгляд на программу, нежели твой. для меня программа — это последовательность императивных действий, между которыми происходят вычисления:

x <- action1
y <- action2(f(x))
z <- action3(g(x,y))

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

if h(x,y,z)
  then procedure1
  else procedure2

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

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

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



E>Т.е. от последовательного описания шагов программы никуда не денешься. Поэтому вопрос упирается в то, насколько раздутым или ужатым будет описание. Скажем подходы C++ и Eiffel черезчур многословны. Подходы функциональных языков с их стремлением к математической лаконичности, напротив, слишком ужаты.

E>У Ричарда Гэбриеля есть хорошее эссе "Reuse versus Compression", в котором он указывает, что ООП -- это не столько путь к повторному использованию, сколько к компрессии программ. Мне кажется, что ФП (по крайней мере по результатам моих попыток познакомиться с Haskell и OCaml) есть не более чем еще один способ компрессии, даже более сильный, чем ООП. А недостатком сильно ужатого текста является сложность его восприятия.

стоп. а ты сам можешь писать на них неужатые программы? мне кажется, что ты просто пытался читать чужой код и его было сложно понять. однако имхо причина этого не в том, что ФП *заставляет* ужимать код, а в том, что она предоставляет новые сжатые идиомы. пока ты их не освоил — этот код кажется такой же абракадаброй, как например для несишника *p++=*q++ (кстати, ты будешь смеяться, но я сейчас в хаскел-кафе имею дело именно с такими людьми). по мере того, как ты осваиваешь хаскел и выучиваешь эти идиомы, функциональный код будет казаться более естественным и понятным. ну а то, что для тебя неестественно, всегда можно записать в более многословной манере. я напримере, никогда не пользуюсь foldr — голова не пареваривает; вместо этого описываю явную рекурсию. или вот, к примеру:

add_version str = if verbose
                    then str++" v2.0"
                    else str

или

add_version = verbose &&& (++" v2.0")

мне лично вторая версия нравится больше как описывающая только суть дела и не содержащая ничего лишнего. опять-таки, в первое время работы с хаскелом меня коробило от point-free стиля (когда при описании функций опускаются их параметры), сейчас я отношусь к нему спокойно


E>Так что я пока подожду, посмотрю, что проиходит, чем же закончится всплеск интереса к ФП (если он вообще есть за пределами программистких форумов и раскрученных блогов).

а мне казалось, что это не всплеск, а постепенное нарастание со временем. может, оно ускорилось в последние лет 10 в связи с увеличением мощности персоналок и перспектив многоядерности. по крайней мере, аудитория haskell-cafe сейчас в абсолютном выражении растёт быстрее, чем раньше, а в относительном — наверно так же. просто это экспоненциальный рост

BZ>>>кстати, насколько я понимаю, проблема в том, что ООП и полиморфизм — это разные вещи.

E>>Попробуй это Бертрану Мейеру рассказать. Я думаю он очень удивится.

BZ>насколько я понимаю, в нём реализовано подмножество возможностей явы.

вот кстати, сейчас вычитал, что eiffel/c++ нельзя делать виртуальными полиморфные методы, а в c#/яве — можно. так что это всё же две разные вещи, и сложность явы вызвана попыткам полностью реализовать все возможные сценарии их взаимодействия, а простота c++/эйфеля — тем что взаимодействие между ними в полном объёме не реализовано

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

BZ>>насколько я понимаю, в нём реализовано подмножество возможностей явы.

BZ>вот кстати, сейчас вычитал, что eiffel/c++ нельзя делать виртуальными полиморфные методы, а в c#/яве — можно. так что это всё же две разные вещи, и сложность явы вызвана попыткам полностью реализовать все возможные сценарии их взаимодействия, а простота c++/эйфеля — тем что взаимодействие между ними в полном объёме не реализовано

Что такое "виртуальные полиморфные методы"?