Язык программирования для математика

[cupuyc]

Maslov, в принципе да. На шарпе тоже красиво получается. Но, как я уже говорил, в шарпе исправлены многие плюсные косяки.

-- Ср мар 02, 2011 03:04:50 --

(Оффтоп)

venco в сообщении #418868 писал(а):

cupuyc в сообщении #418863 писал(а):

venco в сообщении #418727 писал(а):

Вы сомневаетесь, что приведённые Вами вычисления можно выполнить быстрее, чем это получилось у Вас? Там всего-то миллион вызовов простой функции.

Я такого не говорил. Речь о другом.

А о чём?

Перечитайте сообщения страницы с пятой - поймёте.

[Maslov]

cupuyc в сообщении #418863 писал(а):

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

Для того чтобы распараллелиться на 500 веток, надо 500 раз вызвать функцию spawn, которая, может быть, и легкая по сравнению с системным вызовом типа CreateThread, но не то чтобы совсем уж невесомая (посмотрите исходный текст функции erl_create_process). Другими словами, бессмысленно создавать отдельную ветку для задачи, решение которой на одном процессоре занимает меньше времени, чем создание новой ветки.

cupuyc в сообщении #418869 писал(а):

в шарпе исправлены многие плюсные косяки.

Для написания подобного кода в C++ не хватает только лямбда-выражений и замыканий (closures). Но дело не в этом. Для любого языка [кроме Objective-C ] можно придумать задачу, которая программируется на нем быстрее и изящнее, чем на других, но это не делает данный язык "лучше" остальных.

[venco]

Некоторое подмножество лямбда выражений есть в библиотеке boost и, возможно, будет добавлено в стандартную библиотеку C++0x.
Вот что можно сделать на этом:

Используется синтаксис C++

#include <iostream>
#include <math.h>
#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>

using namespace std;
using namespace boost;
using namespace boost::lambda;

struct SeqSum {
    template<class Func>
    double operator()(int N, double from, double step, const Func& func) const {
        double ret = 0;
        for ( int i = 0; i < N; ++i )  ret += func(from+step*i);
        return ret;
    }
};

struct ParSum {
    template<class Func>
    double operator()(int N, double from, double step, const Func& func) const {
        double ret = 0;
#pragma omp parallel for reduction(+: ret)
        for ( int i = 0; i < N; ++i ) ret += func(from+step*i);
        return ret;
    }
};

template<class Func, class From, class To, class Sum> struct CalcSimpson {
    Func func;
    From from;
    To to;
    int N;
    CalcSimpson(const Func& func, const From& from, const To& to, int N = 1000)
        : func(func), from(from), to(to), N(N+N%2) {}

    template<class CFunc>
    double calc(const CFunc& func, double from, double to, int N) const {
        double step = (to-from)/N;
        return ( 2*Sum()(N/2-1, from+2*step, 2*step, func) + 
                 4*Sum()(N/2, from+step, 2*step, func) + 
                 func(from) + func(to) ) * step / 3;
    }

    operator double() const {
        return calc(func, from, to, N);
    }

    template<class Arg>
    double operator()(const Arg& x) const {
        return calc(func(x), from(x), to(x), N);
    }
};

template<class Func, class From, class To>
CalcSimpson<Func, From, To, SeqSum>
simpson(const Func& func, const From& from, const To& to, int N = 1000)
{
    return CalcSimpson<Func, From, To, SeqSum>(func, from, to, N);
}

template<class Func, class From, class To>
CalcSimpson<Func, From, To, ParSum>
psimpson(const Func& func, const From& from, const To& to, int N = 1000)
{
    return CalcSimpson<Func, From, To, ParSum>(func, from, to, N);
}

template<class Func, class Arg1> struct PartialBinder1 {
    Func func;
    Arg1 arg1;
    PartialBinder1(const Func& func, const Arg1& arg1) : func(func), arg1(arg1) {}
    template<class Arg2>
    double operator()(const Arg2& arg2) const {
        return func(arg1, arg2);
    }
};

template<class Func> struct PartialBinder0 {
    Func func;
    PartialBinder0(const Func& func) : func(func) {}
    template<class Arg1>
    PartialBinder1<Func, Arg1> operator()(const Arg1& arg1) const {
        return PartialBinder1<Func, Arg1>(func, arg1);
    }
};

template<class Func>
PartialBinder0<Func> partial_bind(const Func& func)
{
    return PartialBinder0<Func>(func);
}

int main()
{
    cout << simpson(bind(pow, _1, 3), 2, 0) << " == " << -4 << endl;
    cout << psimpson(simpson(partial_bind(_1*_2*_2*(2*_1+3*_2)), &sin, &cos), 0, 1)
         << " == " << 0.08849350980197461 << endl;
}
 

Этот код вычисляет то же, что и пример cupuyc.
Два вызова интегрирования в функции main. Второй - параллельный.
Единственное, чего не хватало в boost::lambda - последовательного добавления аргументов функций, я его реализовал темплейтом partial_bind().
Да, параллелизация на самом деле помогает, а не тормозит.

[cupuyc]

venco, Вы бы хоть using namespace не использовали. Скажу честно, я с boost::lambda никогда не работал, поэтому для меня этот код вообще нечитабелен.

[Munin]

cupuyc в сообщении #419121 писал(а):

Скажу честно, я с boost::lambda никогда не работал

А тогда откуда вы набрались наглости C++ ругать, если вы его не знаете?

[cupuyc]

(Оффтоп)

Munin в сообщении #419154 писал(а):

А тогда откуда вы набрались наглости C++ ругать, если вы его не знаете?

А при чём здесь С++??? Откроваю Вам секрет: буст не является частью языка С++.

[Toucan]

Munin в сообщении #419154 писал(а):

А тогда откуда вы набрались наглости ...

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

[Postrelyonysh]

Maslov в сообщении #417021 писал(а):

Munin в сообщении #417016 писал(а):

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

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

Можете реализовать вывод региона в Хиндли-Миллнере через С++ные темплейты?

Maslov в сообщении # писал(а):

В частности, в C# примерами синтаксического сахара являются блоки
Код:
using ( ... ) {
}
и
Код:
foreach (...) {
}
, а в Haskell -- do-синтаксис и list comprehension.

Maslov в сообщении # писал(а):

На самом деле, это как посмотреть. На мой взгляд, такие вещи как
- перегрузка операторов
- a->b вместо (*a).b
- <cond> ? <trueVal> : <falseVal>
вполне себе подпадают под понятие синтаксического сахара.

Чушь.

"СИНТАКСИЧЕСКИЙ сахар" (обращаю внимание - не семантический) - это компактификация синтаксиса, никак не вляющая на архитектуру ПО. Например, когда закалённый программист на Delphi переходит на С++, то первое, на что он обращает внимание - это на необходимость реализовывать properties ручками. Архитектуру это не меняет, но привычный ему контроль усложняется. С другой стороны, когда программист на Си переходит на Delphi, то properties для него будут излишеством - дополнительной непонятно зачем нужной фенечкой, а вот семантической возможности играться с массивами указателей на функции ему будет не хватать просто аццки, т.к. это повлияет уже на архитектуру. Когда программист с Фортрана переходит на Си, то возможность реализовать рекурсивный по своей природе алгоритм без лишних извращений будет для него полезной дополнительной фенечкой - он воспримет её как "сахар", хотя понятно, что возможность рекурсии в языке зависит от семантики. Точно также, когда закалённый языком VB/C++/Delphi/Java программист переходит на Haskell, он будет считать, что... (цитирую из другого топика):

Maslov в сообщении #369567 писал(а):

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

Так что "a->b вместо (*a).b" - это просто синтаксис, а не синтаксический сахар. Перегрузка операторов - это "средство языка для введения сахара в свою программу", а не "сахар собственно языка". Пространство имён - это сахар (длинные идентификаторы разбиваются на зоны, разделяемые спец.символами).

Foreach - это семантическая абстракция, но закалённый языком Delphi программист смотрит на foreach как на сахар - т.е. на встроенный в компилятор "Iterator pattern". А если потребуется сказать нечто вроде "foreach что-то in foreach что-то ещё..." - то он будет смотреть на это либо как на Высочайшую Заумность, либо как на запутывание кода, чреватое скрытыми ошибками, хотя для любого нормального человека это обычная обработка множества.

Maslov в сообщении #418141 писал(а):

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

Ошибаетесь. И держите своё личное мнение при себе, коли не можете подкрепить его формальным обоснованием. Я же так скажу - когнтивное обучение во много раз лучше, чем бихевиористское, и порождает специалистов, много более полезных для общества. У начинающего программиста, который, как выражаются вам подобные люди, "нахватался по верхушкам" всех основных известных семантик, мозг в последствии будет работать намного-пренамного более правильно в архитектурном смысле. Кругозор необходимо развивать сначала вширь, а лишь потом вглубь, и ни в коем случае не наоборот. "Мозг, хорошо устроенный, стоит больше, чем мозг, хорошо наполненный" - (с) Мишель де Монтень. Если угодно, могу привести целую коллекцию высказываний известных личностей на эту тему, у меня под рукой (не из желания превратить беседу в перекидывание цитатами "авторитетов", а просто в наставление - распечатаете и приклеите возле монитора, а ещё лучше прямо на него).

Программирование - есть построение виртуальных систем как иерархии абстракций (ну да, 99% этих абстракций требует математического обоснования, но нельзя путать причину со следствием), а оценить язык на абстрактность и соответствование требованиям системологии можно ТОЛЬКО интуитивно при поверхностном ознакомлении. В последствии же у человека выстраивается сложная система каузальных ментальных моделей, что формирует устойчивую систему ошибочных знаний. Кроме того, лень приводит к тому, что желание видеть достоинства затмевает способность видеть недостатки. Так что суждение о С++ от матёрого программиста на С++ куда менее ценно, чем суждение о нём начинающего программиста с малым опытом разработки, но зато знакомого в равной степени с языками Scheme, SML, Forth, Рефал, Prolog и Smalltalk.

nestoklon в сообщении #417519 писал(а):

То есть, функция должна наследоваться от (скорее всего абстрактного) класса "функция", интеграл будет принимать этот класс и (возможно) класс параметров и области определения. Уверяю Вас, глубоко внутри ФЯП это всё именно так и реализовано.

Картинка из ТРИЗ:



Вдумайтесь.

Munin в сообщении #417538 писал(а):

У большинства критиков С++ даже Design & Evolution не читан.

Дык именно ЭВОЛЮЦИЯ языка как раз и является его главной корявостью. Хороший язык - тот, который в развитии не нуждается, т.к. любые новые веяния времени легко реализуются его собственными средствами в виде библиотек.

nestoklon в сообщении #417069 писал(а):

Ну и в целом, с распараллеливанием насколько я знаю у функциональных языков пока что всё довольно грустно. То есть если речь заходит о неприятных вещах вроде раскидывания матриц по процессорам, они тут точно так же не справляются как и "обычные" языки. А писать низкоуровневые вещи на них сложнее.

Это что, попытка отыскать "универсальный" язык?

nestoklon в сообщении #417628 писал(а):

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

Одним из ключевых недостатков С++ является как раз то, что при желании абстракность любого кода можно легко нарушить. Неудивительно, что индусокодеры именно это в первую очередь и делают.

nestoklon в сообщении #417628 писал(а):

Потому что критерии наглядности очень зависят от привычки.

Наоборот, наглядность в программировании - это когда наглядно даже для малоопытного программиста. Оно же - "самодокументируемость".

nestoklon в сообщении #417426 писал(а):

Просто обсуждать плохость одного из самых распространённых языков программирования "вообще" мне кажется несколько странным.

Вы намекаете, что миллионы леммингов не могут ошибаться?

"Заблуждение не перестаёт быть заблуждением оттого, что большинство разделяет его" (с) Лев Толстой.

Maslov в сообщении #418012 писал(а):

У Вас "любители синтаксического сахара" -- это просто ругательство какое-то. А этих любителей, на самом деле, подавляющее большинство :).

Ну да - людей, способных мыслить системно, очень немного. Большинство - тупицы.

[nestoklon]

cupuyc в сообщении #417430 писал(а):

Все эти проблемы, конечно же решаемы и на С++. Суть не в этом. Суть в том, что В Эрланге этих проблем либо вообще нет (1.1, 1.2), либо они решаются значительно проще (1.3), стандартными средствами языка.

Пожалуй, частично соглашусь. Несмотря на всю надуманность этих проблем, пока что стандартными средствами языка они решаются не супер.
То, что я имел в виду представлено ниже. Я использовал c++0x, на бусте то же самое выглядело всё ещё слишком громоздко. К сожалению, это пока что компилируется только gcc 4.5. Gcc 4.4 не хочет понимать лямбды, M$ VC++ 10 не хочет понимать template функцию с параметром по умолчанию (а без этого некрасиво). То же самое на бусте как я уже сказал выглядит несколько более громоздко чем я рассчитывал. Если прятать всё под ковёр, получается ад внутри классов.

Разделю код на три логически мало связанные части.

Используется синтаксис C++

#include<cmath>
#include<iostream>
#include<valarray>
#include<cstdarg>
class Func{
  int NOA; // Number of Arguments
public:
  virtual double operator()(const std::valarray<double>&)const=0;
  double at(const std::valarray<double>&var)const{return this->operator()(var);} // Shortcut for ()
  Func(const int&n):NOA(n){}
  virtual int get_NOA()const{return NOA;}
};
std::valarray<double> join(const int n,const std::valarray<double> arg,const double x)
{
  std::valarray<double> res(n);
  for(int i=0;i<n-1;i++) res[i]=arg[i];
  res[n-1]=x;
  return res;
}
 
class Primitive_imp:public Func{
  Func*f;
  Func*a;
  Func*b;
  int n;
public:
  Primitive_imp(Func*ff,Func*aa,Func*bb,int nn):Func( (ff->get_NOA()-1) ),n(nn){f=ff;a=aa;b=bb;}
  double operator()(const std::valarray<double>&arg)const{
     if(f->get_NOA()==0) {return f->at(arg);}
     else{
        const int N(this->f->get_NOA());
        double s(0.0), dx((this->b->at(arg)-this->a->at(arg))/static_cast<float>(2*n)), x;
#pragma omp parallel for private(x) shared (s)
        for ( int i=2; i<2*n; i+=2) {
           x = this->a->at(arg)+static_cast<float>(i)*dx;
#pragma omp atomic
           s+= 2.0*this->f->at(join(N,arg,x)) + 4.0*this->f->at(join(N,arg,x+dx));
        }
        s+=this->f->at(join(N,arg,this->a->at(arg)))
          +4.0*this->f->at(join(N,arg,this->a->at(arg)+dx))
          +this->f->at(join(N,arg,this->b->at(arg)));
        return s*dx/3.0;
     }
  }
};
Func* Primitive(Func*ff,Func*aa,Func*bb,int nn){return new Primitive_imp(ff,aa,bb,nn);} 

Это собственно функция и алгоритм взятия первообразной. Для удобства функция, которая автоматом делает первообразные.
Параллелизм через OpenMP -- так я понимю, это именно то что делает Эрланг. Как видите, такой параллелизм тут занимает ровно две строчки (у venco круче, в одну. Но я старался не подглядывать).
В принципе, этим можно было бы и ограничиться, но тогда, как Вы правильно заметили, придётся для каждой функции делать потомка. Что не очень удобно. Можно сделать ход конём, определить действия с такими функциями и несколько базовых функций, но это тоже не очень коротко.
Поэтому сделаем так:

Используется синтаксис C++

typedef double(*c_func)(double); // To use it as a default
template<typename T=c_func,int dims=1> class simple_Func:public Func{}; // Template "inteface"
template<typename T> class simple_Func<T,0>:public Func{ // Constant
   T f;
public:
   simple_Func(T ff):f(ff),Func(0){}
   double operator()(const std::valarray<double>&x)const{ return f;}
};
template<typename T> class simple_Func<T,1>:public Func{ // 1D function
  T f; // Store function reference.
public:
  simple_Func(T ff):f(ff),Func(1){}
  double operator()(const std::valarray<double>&x)const{ return f(x[0]);}
};
template<typename T> class simple_Func<T,2>:public Func{ // 2D function
  T f; // Store function reference.
public:
  simple_Func(T ff):f(ff),Func(2){}
  double operator()(const std::valarray<double>&x)const{ return f(x[0],x[1]);}
};
// ...
template<typename T=c_func,int dims=1> Func* SF_Factory(T ff){return new simple_Func<T,dims>(ff);}

это самая забавная часть -- надо сделать обёртку вокруг функции так, чтобы туда можно было засовывать что угодно. Можно засовывать туда стандартные сишные функции, можно лямбды от буста. Так как последняя функция не поддерживается старым стандартом, а буст всё равно длиннее и неудобнее лямбд из нового стандарта, считаем что мы пользуемся c++0x.
Тут только до двумерных, с помошью copy-paste делается произвольное количество аргументов. Наверное, можно засунуть это в директивы препроцессора чтобы пачка специализаций шаблона генерировались сами -- когда я много лет назад разбирал код одного знакомого программиста и наткнулся на подобное, мне хотелось его убить.

Ну и

Используется синтаксис C++

std::valarray<double> arg( int n, ... )
{
  va_list Numbers;
  va_start(Numbers,n);
  std::valarray<double> res(n);
  for(int i = 0; i < n; i++ ) res[i]=va_arg(Numbers,double);
  va_end(Numbers);
  return res;
}
int main(int argc, char *argv[])
{
   auto L_F=[=](double x, double y) { return x*y*y*(2*x+3*y); };
   Func*F=SF_Factory< decltype(L_F),2 >(L_F);
 
   Func* I=Primitive(Primitive(F,SF_Factory(&std::sin),SF_Factory(&std::cos),500),
                                  SF_Factory<double,0>(0.0),SF_Factory<double,0>(1.0),500);
   std::cout<< I->at( arg(0,0.0) )<<'\n';
////////////////////////
   auto L_ll=[=](double x) { return -std::sqrt(std::abs(1.0-x*x)); };
   Func*ll=SF_Factory< decltype(L_ll),1 >(L_ll);
   auto L_ul=[=](double x) { return  std::sqrt(std::abs(1.0-x*x)); };
   Func*ul=SF_Factory< decltype(L_ul),1 >(L_ul);
   auto L_F2=[=](double x, double y) { return 1.5*std::sqrt(std::abs(1.0-x*x-y*y)); };
   Func*F2=SF_Factory< decltype(L_F2),2 >(L_F2);
   Func*I2=Primitive(Primitive(F2,ll,ul,500),
                                  SF_Factory<double,0>(-1.0),SF_Factory<double,0>(1.0),500);
   std::cout<< I2->at( arg(0,0.0) )<<'\n';
}

Функцию чтобы удобнее было проверять как ведут себя эти функции, оставил. Можно писать что-то вроде

Используется синтаксис C++

Func* P=Primitive(F,SF_Factory(&std::sin),SF_Factory(&std::cos),500);
for(double X=0;X<1.0;X+=0.1) std::cout<<"P("<<X<<")="<<P->at( arg(1,X) )<<'\n';

и смотреть как оно интегрирует.

Два примера -- один Ваш, другой от Maslov.
Первообразная -- настоящая функция, с ней можно обращаться как с функцией, всё такое.

Прошу прощения за то, что так долго тормозил. Последний раз на c++ писал несколько лет назад, слишком многое пришлось вспоминать. Ну и сделайте скидку на то, что я не профессиональный программист. А как физику мне программирование физики на Эрланге -- это очень странная полумера. Или уж Python/Smalltalk/...<кто что любит> для удобства или уж C++/Fortran для скорости. Все компромиссы вызывают большое подозрение.

[Maslov]

Postrelyonysh в сообщении #419195 писал(а):

Maslov в сообщении #417021 писал(а):

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

Можете реализовать вывод региона в Хиндли-Миллнере через С++ные темплейты?[/qoute]

Нет, не могу. Ну и что? В каких языках используется выделение памяти по регионам? Только со ссылками, пожалуйста.
В Lisp, Java, .Net, Ruby, Python и т. п. мусор тоже собирается, и весьма неплохо.

Postrelyonysh в сообщении #419195 писал(а):

Foreach - это семантическая абстракция, но закалённый языком Delphi программист смотрит на foreach как на сахар - т.е. на встроенный в компилятор "Iterator pattern". А если потребуется сказать нечто вроде "foreach что-то in foreach что-то ещё..." - то он будет смотреть на это либо как на Высочайшую Заумность, либо как на запутывание кода, чреватое скрытыми ошибками, хотя для любого нормального человека это обычная обработка множества.

Postrelyonysh, Вы "теоретик", поэтому, скорее всего, просто не в курсе, что в C# конструкция

foreach (var x in collection) {
    …
}

эквивалентна более длинной записи

var enumerator = collection.GetEnumerator();
while (enumerator.MoveNext()) {
    var x = enumerator.Current;
    …
}

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

Теперь по поводу Хаскеля.
Код, записанный с использование do-нотации,

foo :: Maybe String  
foo = do  
    x <- Just 3  
    y <- Just "!"  
    Just (show x ++ y) 

это компактная запись для

foo :: Maybe String  
foo = Just 3   >>= (\x -> 
    Just "!" >>= (\y -> 
    Just (show x ++ y)))

Почитайте про do notation; там все довольно понятно написано.
list comprehension -- это тоже некоторое упрощение синтаксиса и ничего больше

Haskell wiki в статье List comprehension писал(а):

List comprehension
List comprehensions are syntactic sugar like the expression

import Data.Char (toUpper)
[toUpper c | c <- s]

[Postrelyonysh]

Maslov в сообщении #419237 писал(а):

Нет, не могу. Ну и что? В каких языках используется выделение памяти по регионам? Только со ссылками, пожалуйста.
В Lisp, Java, .Net, Ruby, Python и т. п. мусор тоже собирается, и весьма неплохо.

Вы что, не знаете, в каких языках используется типизация по Х-М?

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

Maslov в сообщении #419237 писал(а):

Вы "теоретик"

Не теоретик, а проектировщик и руководитель. Мне программирование как таковое нахрен не вперилось - мои интересы сосредоточены в совсем иных прикладных областях - но я был вынужден потратить и несколько лет на изучение программирования, только лишь для того, чтобы уметь объяснять программистам на их языке что от них требуется, быть защищённым от их умно звучащих оправданий за паршивость выполненной работы, и уметь посадить их в лужу, если упруться. Если бы у наиболее часто встречающихся программистов с восприятием действительности всё было бы в порядке, я бы дальше школьной информатики в него совался. Но кто хочет получить результат - ищет способ, а не оправдания, а результат моей работы зависит не только от меня.

Maslov в сообщении #419237 писал(а):

Вы ... не в курсе, что в C#

Да, C# не пользовался, и надеюсь, не придётся - есть масса более удобных языков. То, что вы сказали - это просто камень в огород C#. В Лиспе же foreach - это много больше, чем синтаксис.

Maslov в сообщении #419237 писал(а):

Ваши глубокомысленные рассуждения о паттернах к делу совершенно не относятся

Относятся прямо и непосредственно. Смысл паттернов в том, что язык не позволяет развивать себя своими же конструкциями, так что программист оказывается вынужден реализовывать одну и ту же абстракцию многократно. Функциональщик же любую конструкцию из числа встречающихся в GoF реализует ровно один раз и забудет про неё навсегда. Ну, кроме "Interpreter", разумеется, который является самостоятельной методологией проектирования, а не "паттерном".

Maslov в сообщении #419237 писал(а):

list comprehension -- это тоже некоторое упрощение синтаксиса и ничего больше

В таком случае реализуйте мне это "синтаксическое упрощение" на любом потомке Алгола. На всякий случай: C++::std::for_each<> - это не оно, а жалкое его подобие, весьма неэффективное. Нужно, чтобы foreach сам выбирал наиболее эффективное представление данных и разбрасывал алгоритм на потоки. Именно в возможности так сделать как раз и заключается смысл слова "абстрагирование", а также и разница между понятиями "синтаксического сахара" и "семантики".

vek88 в сообщении #341231 писал(а):

arseniiv в сообщении #341227 писал(а):

VB — это кошмар, кошмар, из которого следует просыпаться.

Не понял? Давайте уточним предмет обсуждения. Я говорю о VB, встроенном в Excel. Никаких проблем с ним не встретил. Нормальный язык. Годится для начинающих, а можно писать вполне серьезные вещи.

А Вы о каком VB?

Это о любом бейсике.

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
(с) Edsger W. Dijkstra (отсюда)

[Maslov]

Postrelyonysh в сообщении #419301 писал(а):

Вы что, не знаете, в каких языках используется типизация по Х-М

Я знаю, в каких языках используется типизация Хиндли-Милнера, но вопрос-то был в другом: знаете ли Вы, в каких языках 'region inference' применяется для управления памятью?

Postrelyonysh в сообщении #419301 писал(а):

Maslov в сообщении #419237 писал(а):
list comprehension -- это тоже некоторое упрощение синтаксиса и ничего больше

В таком случае реализуйте мне это "синтаксическое упрощение" на любом потомке Алгола.

Без модификации языка этого не сделать, точно так же как и в Haskell его нельзя было добавить без доработки компилятора. Но вопрос опять же был в другом: являются в Хаскеле эти фичи синтаксическим сахаром или не являются. Разработчики языка считают, что являются, а Вы -- что нет. Коллизия, однако.

[cupuyc]

nestoklon в сообщении #419222 писал(а):

Я использовал c++0x

Ага. Учитывая, что окончательно он ещё не появился, насколько я знаю (поправьте, если ошибаюсь). По хорошему было бы писать по принятому ныне стандарту C++03, т.к. C++0x - уже не совсем С++. И потом, насколько я знаю, в этом стандарте уже введены лямбда-функции. Их уже даже VS 2010 поддерживает. Лучше бы этим воспользовались.

nestoklon, взгляните на приведённые куски кода: на мой, на Maslov'a, на venco, на свой, абстрагируйтесь от того, кто их написал, попробуйте оценить объективно и скажите которые из них написаны через ж--у? Без обид, но два последних примера - какая-то жесть. Я знаю язык С++, кучу времени на нём пишу, но этот код я сходу не понимаю. Нужно сидеть и вкуривать этот код, все эти шаблоны с кучей параметров, нужно лезть в доку по бусту. Вкуривать код, который математически записывается простенькой формулой! Ей богу, целый час уйдёт, а то и больше. Посчитать интеграл методом парабол - простейшая задачка численных методов, которую можно придумать. Что будет с реальными, более сложными задачами? Здесь совершенно прав

Postrelyonysh в сообщении #419195 писал(а):

Наоборот, наглядность в программировании - это когда наглядно даже для малоопытного программиста. Оно же - "самодокументируемость".

.

[Toucan]

cupuyc в сообщении #419389 писал(а):

которые из них написаны через ж--у?

cupuyc, предупреждение за ненормативную лексику

[nestoklon]

cupuyc в сообщении #419389 писал(а):

и скажите которые из них написаны через ж--у?

Без обид, но Ваш. Передавать оператор суммы -- это жесть. Чем больше маленьких функций, тем лучше, так что ли? Ну, по мне так это читабельности не сильно помогает.
Лично мне больше всего понравился код Maslov. Код venco короче моего, но там меньше общности, к которой я стремился (возможно зря). Зато без хаков c++0x.

cupuyc в сообщении #419389 писал(а):

но этот код я сходу не понимаю

Ну что, бывает. То, что Вам непонятно, я уже понял. Непонятно только, о чём этот факт говорит больше -- о коде или о Вас.

cupuyc в сообщении #419389 писал(а):

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

Метод парабол -- строчки с 32 по 42, из которых половина для читабельности и две указание распараллелить код. Вы их не нашли? А мне казалось, Вы хотели посмотреть, как на c++ "правильно" обращаться с функциями "в общем виде" на простом примере. Ну что я могу сделать, если "true c++" при ближайшем рассмотрении не поддерживается в устаревающем стандарте?

cupuyc в сообщении #419389 писал(а):

И потом, насколько я знаю, в этом стандарте уже введены лямбда-функции. Их уже даже VS 2010 поддерживает. Лучше бы этим воспользовались.

А, Вы даже не просмотрели код. Ну тогда о чём мы говорим?